TinySec: Security for TinyOS

1
TinySec Security for TinyOS

• C. Karlof, N. Sastry, D. Wagner
• November 20, 2002

2
Goals of TinySec

• Access Control
• Authorized participants only
• Integrity
• Altering and retransmitting a message should be
  difficult
• Confidentiality
• Transparent to applications and programmers

3
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

4
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 is needed to achieve semantic security
• A message looks different every time it is
• encrypted
• iv reuse may leak information

5
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

m2
m1
length
Ek
Ek
Ek
MAC
CBC-MAC Mode
6
Packet Format

• Key Differences
• No CRC -2 bytes
• No group ID -1 bytes
• MAC 4 bytes
• IV 4 bytes
• Total 5 bytes

7
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

8
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
• Cant 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 (!!)

9
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

10
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 IVs, 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

11
Performance RC5 Cipher
12
Current Status

• Working w/ Phil to get into broken/experimental
• TinySec needs to be incorporated into January
  retreat demos.

13
TinyOS System Changes
MicaHighSpeedRadio
TinySec
CBC-Mode
CBC-MAC
RC5
14
Tradeoffs 2 IV allocations

• Most secure idea for IV

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?

15
(No Transcript)