1 / 15

TinySec: Security for TinyOS

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.

bern
Download Presentation

TinySec: Security for TinyOS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. m1 m2 iv Ek Ek Ek c1 c2 CBC-Mode 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 m1 m2 length Ek Ek Ek MAC CBC-MAC Mode

  6. dest AM IV length data MAC 2 1 4 1 4 Encrypted MAC’ed 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 • 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 (!!)

  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 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

  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-MAC CBC-Mode RC5

  14. src ID counter IV 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?

More Related