“TinySec: A Link Layer Security Architecture for Wireless Sensor Networks”

1. “TinySec: A Link Layer Security Architecture for Wireless Sensor Networks” Chris Karlof, Naveen Sastry, David Wagner UC Berkeley Summary presented by Gary Woo CS 577

2. Outline • Sensor Networks • Design goals • Design • Analysis • Implementation • Evaluation • Conclusion CS 577

3. Sensor Networks • “heterogeneous system combining tiny sensors and actuators with general-purpose computing elements” • Nodes are low cost and low power • Applications: • Habitat monitoring • Burglar alarms • Medical monitoring • Emergency response • Battlefield management CS 577

4. Design goals • Security • Message integrity (MAC) • Confidentiality (Encryption) • Replay protection (Counter/IV) • Performance • Increase in processor/RAM demand is bad • Increase in message length is worse • Ease of use • Transparency • Portability CS 577

5. Design • Modes • Authentication (TinySec-Auth) • Authenticated encryption (TinySec-AE) • Encryption • Cipher Block Chaining • IV (8 bytes) formed by destination address, Active Message type, length, source, and 2 byte counter • Message Integrity • MAC computed over entire message CS 577

6. Plain text Plain text Initialization Vector Encryption Encryption key key Cipher text Cipher text Cipher Block Chaining • All nodes share secret key • Provable secure when IV not repeated • Pre-encrypt IV to avoid IV and Plain text incremented by 1 leakage • Ciphertext stealing, min size = 8 bytes, otherwise same size as plaintext CS 577

7. Initialization Vector • Counters provides 2n + 1 packets before reuse • Random provides 2n/2 packets before reuse due to the birthday paradox (for any 23 people two will have matching birthdays greater than 50% of the time) • Reuse destination address, active message type, and length • New fields: source, 2 byte counter CS 577

8. CBC MAC • Ensures that bits changed in the message will be detected • Reuse of CBC algorithm saves code space • XORs the encryption of the message length with the first plaintext block (uses encrypted message length as IV) CS 577

9. Packet format • Early rejection (header not encrypted) • Replaces 2 byte CRC and 1 byte group field with MAC • TinySec-AE has Src (2 bytes) and Ctr (2 bytes) that TinySec-Auth doesn’t, which has 1 more byte than TinyOS CS 577

10. Analysis • MAC is 4 bytes, 1 in 232 chance of forging correctly • 19.2kb/s channels allows only 40 attempts per second (231 attempts will take 20 months!) • Denial of service, as link will be captured • Avoids birthday paradox (uses counter) • Each node can send 216 messages before reuse of IV • CBC mode with IV reuse leaks longest shared prefix of the 2 messages (must be same src/dst pair, length, AM type) • Should update keys before reuse CS 577

11. Implementation • Security • MAC and CBC for encryption • Performance • Runs with 728 bytes of ram and 7146 bytes of program space • Ease of use • Add “TINYSEC=true” when making code CS 577

12. Implementation (cont.) • Transparency • Runs at the Link Layer • Portability • Distributed with TinyOS CS 577

13. Implementation (cont.) • TinySec implemented in 3000 lines of nesC • Modified task scheduler (cryptographic operations higher priority than others) • Uses top 2 bits of length selects TinySec mode • Max payload length is 29 bytes CS 577

14. Evaluation • Increased message length • Reduces bandwidth • Increase latency • Increases energy consumption • Added cryptography • Increased computation time • Increased energy consumption CS 577

15. Evaluation (Increased send time) • Increased send time depends on TinySec mode • About 1.6% increase for each byte CS 577

16. Evaluation (Encryption computation time) • Byte time must be small • CBC operates on blocks of 8 bytes • Rule of thumb: less than a few byte times CS 577

17. TinyOS TinySec Auth TinySec AE Evaluation (Energy costs) • Yellow shading shows extra energy costs of computing MAC and performing CBC • Blue shading shows extra energy from increased message length CS 577

18. Evaluation (Energy costs cont.) • Increase for TinySec-Auth • 1% from increased packet length • 2% from extra computation • Increase for TinySec-AE • 6% from increased packet length • 4% from extra computation CS 577

19. Evaluation (Throughput) • TinySec-Auth performs just as No TinySec • TinySec-AE performs ~6% lower at >5 senders CS 577

20. Evaluation (Latency) • Increased message length • TinySec-Auth: 1 byte • TinySec-AE: 5 bytes CS 577

21. Evaluation (Latency cont.) • TinySec-Auth increase by 1.1 byte times • TinySec-AE increase by 4.6 byte times CS 577

22. Evaluation (Ease of use) • No changes needed to higher layers (TinySec is at Link Layer) • Need to modify makefile to enable TinySec • Current work: • TinyPK (RSA to exchange keys) • TinyCrypt (elliptical curve cryptography) • SRI’s key exchange • SecureSense’s dynamic security service • Bosch burglar alarm CS 577

23. Conclusion • TinySec-Auth • Provides message integrity • Increases energy consumption by 3% • TinySec-AE • Provides message integrity and confidentiality • Increases energy consumption by 10% • Limited gains switching to hardware as increase message length is the cause CS 577

24. References and Acknowledgements • Author’s electronic version of paper (other figures and tables were taken from this document): • http://www.cs.berkeley.edu/~nks/papers/tinysec-sensys04.pdf CS 577