Key Distribution in Sensor Networks (work in progress report)

1. Key Distribution inSensor Networks(work in progress report) Adrian Perrig UC Berkeley

2. Applications need Security • Earthquake & fire sensors • Pollution monitoring • Energy management • Military applications • Absence of security enables attacks such as spoofing & replay attacks, resulting in DoS or system compromise

3. Main Security Requirements • Authentication • Receiver verifies sender (prevents spoofing) • Also provides integrity • Confidentiality • Data remains secret • Freshness • Receiver knows message is recent (prevents replay) • Digital signatures (non-repudiation) • Receiver can prove sender to third party • Usually not necessary

4. System Constraints • Sensors not tamper-proof • Limited energy • Limited computation (4 MHz 8-bit) • Limited memory (512 bytes) • Limited code size (8 Kbytes) • ~3.5 K base code (“TinyOS” + radio encoder) • Only 4.5 K for application & security • Limited communication (30 byte packets) • Energy-consuming communication • 1 byte transmission = 11000 instructions

5. Scenario 1: Static Nodes • Nodes don’t move • Drop sensor nodes from airplanes • Build sensor nodes into bricks, steel beams • Topology change only for node addition and removal • Goal: Set up shared keys among neighbor nodes

6. Traditional Approaches • Pre-load global key before deployment • Vulnerable to node compromise • Pre-load all pair-wise keys • Need O(n2) keys • Vulnerable to node compromise • Hard to add new nodes • Diffie-Hellman key agreement • Computationally expensive • Might work if only needed initially • Prone to denial-of-service attacks

7. More Approaches • SPINS [with Culler, Szewczyk, Tygar, Wen] • Base station shares key with each node • New keys setup through base station • Expensive to set up all keys among neighbors through base station • Can we do better? • Let’s try a crazy idea …

8. Key Infection • Collaboration with Ross Anderson • Goal: Nodes set up keys with neighbors • Assumptions: • Attacker nodes have same capability as good nodes • Attacker nodes less dense than good nodes • Attacker compromises small fraction of good nodes • Basic key agreement protocol • A * : A, KA • B A : { A, B, KB }KA • KAB = H( A | B | KA | KB )

9. Key Infection • Broadcast keys with maximum signal strength M1 M4 M3 B A M2

10. Key Whispering Extension • Broadcast keys with minimum signal strength to reach neighbor M1 M4 M3 B A M2

11. Secrecy Amplification • A & B share KAB, A & C share KAC, , etc. • Strengthen secrecy of K’AB • A C : { B, A, NA }KAC • C B : { B, A, NA }KCB • B D : { A, B, NB }KBD • D E : { A, B, NB }KDE • E A : { A, B, NB }KAE • K’AB = H( KAB| NA | NB ) C B A E D

12. Key Infection Summary • Highly efficient • Detailed analysis in progress • Preliminary simulation results: • Nodes uniformly distributed over a plane • D (density): average # of nodes within radio range • # of attacker nodes = 1% of good nodes • Table shows fraction of compromised links

13. Scenario 2: Dynamic Nodes • Assume nodes roam around • Any pair of nodes communicates • Per-message authentication & freshness

14. Traditional Approaches • Pre-load global key before deployment • Vulnerable to node compromise • Pre-load all pair-wise keys • Need O(n2) keys • Vulnerable to node compromise • Hard to add new nodes • Digital signatures • Too expensive on a per-message basis • Prone to denial-of-service attacks

15. TESLA for Authentication • With Canetti, Song, Tygar • Designed for broadcast authentication • Use for point-to-point authentication • Only need to set up n public keys • Uses efficient symmetric crypto • Requires loose time synchronization

16. 1: Verify K 2: Verify MAC 3: P Authentic! Basic Authentication Mechanism • F: one-way function P F(K) Authentic Commitment K disclosed MAC(K,P) t

17. Security Condition • Security condition (for packet P): on arrival of P, receiver is certain that sender did not yet disclose K • If security condition not satisfied, drop packet • Attacker can at most do denial-of-service attack • Speeding up / delaying packets does not help

18. F Authenticate K5 K5 F K6 F F P2 Verify MAC K5 TESLA • Keys disclosed 2 time intervals after use • Receiver knows authentic K3 • Authentication of P1: MAC(K5, P1 ) K3 K4 K5 K6 K7 t Time 4 Time 5 Time 6 Time 7 P1 K3

19. Authenticate K5 F F P1 P2 P3 P4 P5 K2 K2 K3 K4 K5 Verify MACs TESLA: Robust to Packet Loss K3 K4 K5 K6 K7 t Time 4 Time 5 Time 6 Time 7

20. Summary • Low overhead • Communication (~ 20 bytes) • Computation (~ 1 MAC computation per packet) • Perfect robustness to packet loss • Delayed authentication • Also provides freshness • Drawback: not secure with time travel

21. TIK: TESLA with Instant Key Disclosure • With Hu, Johnson • Assume accurate time synchronization • Trimble Thunderbolt GPS clock: ±180 ns • Can disclose key in same packet! • Receiver instantly authenticates packet

22. D Sending a TIK Frame MAC Data Key MAC Data Key time

23. TIK Summary • Example: • 11 Mbps network, 300m range • With 1ms time synchronization error (e.g. GPS clock synchronization), works for packet size > 20 bytes • Provides strong freshness guarantee • Works for more powerful sensor nodes, PDAs, cell phones, etc.

24. Conclusion & Open Problems • Efficient key establishment is challenging • Large static sensor networks • Use key infection for local key establishment? • Dynamic sensor networks • TESLA for point-to-point authentication • Also provides freshness • Accurate time sync: TIK