TinySec: A Link Layer Security Architecture for Wireless Sensor Networks C. Karlof, N. Sastry, D. Wagner SPINS: Security Protocol for Sensor Networks A.

TinySec: A Link Layer Security Architecture for Wireless Sensor Networks

C. Karlof, N. Sastry, D. Wagner

SPINS: Security Protocol for Sensor Networks

A. Perrig, R. Szewczyk, V. Wen, D. Culler, J. D. Tygar

Sensor Networks Many important applications, e.g.,

habitat monitoring, rescue operation, battle field monitoring

Without adequate security, wide deployment might be impossible Severe energy, resource constraints Take advantage of the constraints

Even a powerful adversary is limited to a small number of packets per unit time to inject or eavesdrop due to the limited wireless bandwidth, e.g., 19.2Kbps

Software implementation is possible

Motivation for Link Layer Security End-to-end security, e.g., SSH, SSL, or

IPSec, in conventional networks Message integrity is only checked at the

destination Dominant traffic is end-to-end

Dominant traffic is many-to-one in sensor networks Intermediate nodes need to access and

aggregate data End-to-end security is subject to DoS attacks

Relay a packet injected by an adversary wasting energy

Non-Issues

Denial of Service Attacks Jamming Resource Consumption Attacks Wormhole attacks …

Physical Tampering

Design Goals Message authentication (integrity)

MAC (Message Authentication Code): Secure checksum

Confidentiality Encryption

Symmetric key system TinySec uses a network-wide master key and

message authentication key SNEP of SPINS adopts a secret key between the

base station and a sensor node Optional

Authenticity & Confidentiality: SNEP (Part of SPINS)

Replay protection Semantic security

Encrypting the same plaintex twice should give two different cyphertexts

Use a unique IV (Initialization Vector) for each invocation of the encryption algorithm

Weak freshness Just order the messages, but cannot guarantee A is responding

to B’s request Low communication overhead

Counter values kept at each end point; no need to include in each message

Counter mode encryption & decryption

Ctr + K -> one-time pad

CBC MAC

Same code for encryption & MAC Save storage Semantic security: IV, e.g., counter, is not

reused

Strong freshness

Strong freshness, e.g., for counter synchronization

TinySec Design Goals Efficiency

Minimal communication, computation & memory overhead

Ease of Use 50% - 80% of 802.11 networks without any cryptographic

protection TynySec= true in the Makefile Right set of APIs Easy to use & customize considering the application

needs Portability

Included in TinyOS (& TOSSIM) TinyOS runs on a number of platforms including Texas

Instruments, Atmel, Intel x86, and StrongArm

TinySec Design

TinySec-AE: Authenticated encryption Encrypt the payload and compute the

MAC over the packet header and encrypted data

TinySec-Auth: Authentication only Authenticate the entire packet with a

MAC, but the data is not encrypted

Packet format

• TinySec-Auth only increases the msg size by 1 bytes• TinySec-AE increases it by 5 bytes

Security Analysis

4 byte MAC 232/2 = 216 trials to forge

Key space is reduced by squqre root due to birthday paradox

Not enough for security in conventional networks

On 19.2kbps channel, only 40 trials/s are possible => 20 months!

Adversary has to send it to an authorized receiver

Confidentiality Counter If there are n nodes and 16 bit

counter is used, an instance of IV is reused after n*216 packets

19.2Kbps, one packet per minute per node

IV is reused after 45 days Redistribute a new symmetric key

Encryption Cypher independent Symmetric key algorithms

Asymmetric algorithms are several orders of magnitude slower

Exception: elliptic curve alg. (ecTinyOS)

Time to execute cipher operations on the Mica2 sensor nodes (block cipher algorithms)

Byte time Time to transmit one byte 0.42ms on Mica2 TinySec-AE increases latency by 8% TinySec-Auth increases it by 1.5%

Keying Mechanism Determine how cryptographic keys are distributed and shared

throughout the network Use different keys for different applications

Use separate keys for encryption and message authentication Network-wide keying

Simple Vulnerable to node capture

Per-link keying Graceful degradation in the presence of compromised nodes Key distribution protocol is needed Passive participation & local broadcast are impossible

Per-group keying Graceful degradation in the presence of compromised nodes Key distribution is required Supports passive participation & local broadcast

Node-to-Node Key Agreement in SPINS

Secure key agreement Strong key freshness Most comm done by the base station

Authenticated Broadcast in SPINS - uTESLA

Generally, authenticated broadcast requires an asymmetric mechanism

Symmetric schemes are not secure Any receiver with the MAC key can

impersonate Asymmetric schemes are too

expensive Requires 50 – 1000 bytes/packet for

signature

Authenticated Broadcast in SPINS (Cont’d)

Delayed key exposure A node has to buffer the received data until

it receives the next key to verify the current key

Authenticated Broadcast in SPINS (Cont’d)

Sender chooses the last key Kn randomly and generate successive keys by successively applying a one way function F, e.g., MD5

In time interval t, sender uses Kt to authenticate the message

Sender releases Kt after intervals after the end of the time interval t

Implementation TinySec in 3000 lines of nesC code Requires 728 bytes of RAM and 7146 bytes of

program space 256 bytes of RAM & 8152 bytes of ROM

Modify TinyOS 1.1.2 radio stack to redirect byte level radio events to the TinySecM module

Modification of the scheduler Signal TinySecM when the MAC layer successfully

acquires the channel Begin the cryptographic computations Assign high priority to cryptographic operations

Evaluation

Packet size increase Fixed

Extra computation time & energy needed for cryptography Vary depending on implementation

Expected Latency Caused by TinySec

Time to Execute Cipher Operations

Energy Consumption (to send 24 bytes)

Bandwidth

#Senders

Total #received packets/sec

End-to-end latency

#hops

E2E delay (ms)

Questions?