TinySec: Security for TinyOS

C. Karlof, N. Sastry, D. Wagner

November 20, 2002

Goals of TinySec

• Access Control– Authorized participants only

• Integrity– Altering and retransmitting a message should

be difficult

• Confidentiality• Transparent to applications and

programmers

Block Ciphers

• Pseudorandom permutation (invertible)– DES, RC5, Skipjack, AES – Maps n bits of plaintext to n bits of ciphertext

• Block size n is typically 64 or 128 bits

• Key size k is typically 64 or 128 bits

nKnk

k

E }1,0{}1,0{: }1,0{

Symmetric key encryption

• Confidentiality achieved by encryption• Encryption schemes (modes) can be built using block

ciphers– CBC-mode: break a m bit message

into 64 bit chunks (m1,m2,..)– Transmit (c1, c2, …) and iv

iv

m2m1

c1 c2

Ek EkEk

CBC-Mode

• iv is needed to achieve semantic security– A message looks different every time it is

encrypted– iv reuse may leak information

Message Authentication Codes• Encryption is not enough to ensure message integrity

– Receiver cannot detect changes in the ciphertext– Resulting plaintext will still be valid

• Integrity achieved by a message authentication code– A t bit cryptographic checksum with a k bit key from an m bit message

– Can detect both malicious changes and random errors

– Replaces CRC– Can be built using a block cipher– MAC key should be different

than encryption key

tKm k

}1,0{}1,0{:MAC }1,0{

length

m2m1

MAC

Ek EkEk

CBC-MAC Mode

Packet Format

dest AM IV length data MAC

2 1 4 1 4

Encrypted

MAC’ed

• Key DifferencesNo CRC -2 bytesNo group ID -1 bytesMAC +4 bytesIV +4 bytes

• Total: +5 bytes

Usage: How does this change my life?

• Need to be aware of keys & keyfile– Currently, keys part of program, not intrinsic to mote (similar to

moteID)– Plan to use EEPROM to tie key to mote– Makerules generates a keyfile if none exists and then uses it for

programming all motes;– Keyfiles tied to a particular TinyOS installation. Manual transfer

needed to install motes from different computers.

• Only application level code change:– Just use SecureGenericComm instead of GenericComm

• Works on Simulator

Implications for reliable transport

• CRC is replaced by MAC• CRC is lightweight, MAC computation is expensive (~1000 vs.

~10000 cycles for 24 byte packet)• MAC still detects errors, but computation must be completed in time

for ACK transmission• For each 8 bytes received, a block cipher called is needed (~1750

cycles) too expensive to run in SpiByteFifo event handler• Can’t run as a task: no real-time completion guarantees• Trick: Run synchronously in event handler with interrupts enabled• Like a preemptive priority scheduler that only TinySec can use (!!)

Tradeoffs 1

• Early rejection– Still possible to reject based on dest or AM type– Question: Group ID provided weak access control; still

needed?• Short packets are expensive

– Min data size is 8 bytes (size of block cipher)– Restriction can be elminated with reduced security (run

in stream cipher mode)– Question: Is this a good tradeoff?

• Packet length not affected for more than 8 bytes of data

Analysis

• Access control and integrity– Probability of blind MAC forgery 1/232

– Industrial strength is usually 1/264 or less– Replay protection not provided, but can be done better at higher

layers

• Confidentiality– Lots of ways to structure and manage IV’s, but IV reuse will occur

after ~65000 messages from each node– For CBC mode, IV reuse is not as severe has other modes

• Does not necessarily leak plaintext

– Common solution is to increase IV length adds packet overhead

Performance: RC5 CipherRol32 cycles RC5 cipher op

cyclesTime

C version 207 ~5750 + 1.70 ms

SPINS [C + asm] ~85 avg ~2775 avg .75 ms

TinySec [C + asm] ~42 avg ~1775 avg .50 ms

Number Block Cipher Ops

(m byte msg)

CBC-Encryption

CBC-MAC

Total

18/ m

18/ m

28/2 m

Current Status

• Working w/ Phil to get into broken/experimental

• TinySec needs to be incorporated into January retreat demos.

TinyOS System Changes

MicaHighSpeedRadio

TinySec

CBC-Mode

RC5

CBC-MAC

Tradeoffs 2: IV allocations

• Most secure idea for IV:

src ID counterIV

2 2• Counter must be persistent across reboot

• Gives each sender ~65000 messages before IV is reused (worst case)

• Question: src ID good for security (replay, IV) useful for other things?