Key Distribution in Sensor Networks (work in progress report) Adrian Perrig UC Berkeley

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

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

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

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

Traditional Approaches  Pre-load global key before deployment Vulnerable to node compromise  Pre-load all pair-wise keys Need O(n 2 ) 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

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 …

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, K A B  A : { A, B, K B } K A K AB = H( A | B | K A | K B )

Key Infection AB M4 M2 M3 M1  Broadcast keys with maximum signal strength

Key Whispering Extension AB M4 M2 M3 M1  Broadcast keys with minimum signal strength to reach neighbor

Secrecy Amplification A B C D E  A & B share K AB, A & C share K AC,, etc.  Strengthen secrecy of K’ AB A  C : { B, A, N A } K AC C  B : { B, A, N A } K CB B  D : { A, B, N B } K BD D  E : { A, B, N B } K DE E  A : { A, B, N B } K AE K’ AB = H( K AB | N A | N B )

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 DBasicWhisperSASA-W 21.1%0.4%1.0%0.3% 31.8%0.6%1.4%0.5% 52.9%1.0%2.4%0.8%

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

Traditional Approaches  Pre-load global key before deployment Vulnerable to node compromise  Pre-load all pair-wise keys Need O(n 2 ) 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

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

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

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

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

TESLA: Robust to Packet Loss K4K5K6K7 t Time 4Time 5Time 6Time 7 K3 P5 K5 P3 K3 P2 K2 P1 K2 Verify MACs P4 K4 FF Authenticate K5

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

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

Sending a TIK Frame MACDataKey MACDataKey time 

TIK Summary  Example: 11 Mbps network, 300m range With 1  s 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.

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