TinySec: A Link Layer Security Architecture for Wireless Sensor Networks

1. TinySec: A Link Layer Security Architecture for Wireless Sensor Networks SPINS: Security Protocol for Sensor Networks C. Karlof, N. Sastry, D. Wagner A. Perrig, R. Szewczyk, V. Wen, D. Culler, J. D. Tygar

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

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

4. Issues not considered in TinySec and SPINS • Denial of Service Attacks • Jamming • Resource Consumption Attacks • Wormhole attacks • … • Physical Tampering

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

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

7. Counter mode encryption & decryption • Ctr + K -> one-time pad

8. CBC (Cipher Block Chaining) MAC • Same code for encryption & MAC • Save storage • Semantic security: IV, e.g., counter, is not reused

9. Strong freshness • Strong freshness, e.g., for counter synchronization

10. 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 • 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

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

12. Packet format • TinySec-Auth only increases the msg size by 1 bytes • TinySec-AE increases it by 5 bytes

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

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

15. Encryption • Cypher independent • Symmetric key algorithms • Asymmetric algorithms are several orders of magnitude slower • Exception: elliptic curve alg. (ecTinyOS)

16. 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%

17. Keying Mechanism • Determine how cryptographic keys are distributed and shared throughout the network • Rule of thumb • Use different keys for different applications • Use separate keys for encryption and message authentication

18. Several Approaches to Keying • 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

19. Node-to-Node Key Agreement in SPINS • Secure key agreement • Strong key freshness

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

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

22. Authenticated Broadcast in SPINS (Cont’d) • Sender chooses the last key Kn randomly and generate successive keys by successively applying a one way hash 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

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

24. Evaluation • Packet size increase • Fixed • Extra computation time & energy needed for cryptography • Vary depending on implementation

25. Time to Execute Cipher Operations

26. Energy Consumption (to send 24 bytes)

27. Bandwidth Total #received packets/sec #Senders

28. End-to-end latency E2E delay (ms) #hops

29. Questions?