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

24
Key Distribution in Sensor Networks (work in progress report) Adrian Perrig UC Berkeley
  • date post

    22-Dec-2015
  • Category

    Documents

  • view

    214
  • download

    0

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

Key Distribution inSensor 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 = 11000 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(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

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

• B A : { A, B, KB }KA

• KAB = H( A | B | KA | KB )

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

AB

C

DE

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 )

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

D Basic Whisper SA SA-W

2 1.1% 0.4% 1.0% 0.3%

3 1.8% 0.6% 1.4% 0.5%

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

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

P

MAC(K,P)

Kdisclosed

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

K4 K5 K6 K7

tTime 4 Time 5 Time 6 Time 7

K3

P2

K5

P1

K3

Authentication of P1: MAC(K5, P1 )

FF

Authenticate K5

Verify MAC

FK6

FK5

TESLA: Robust to Packet Loss

K4 K5 K6 K7

tTime 4 Time 5 Time 6 Time 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

MAC Data Key

MAC Data Key

time

TIK Summary

Example:• 11 Mbps network, 300m range

• With 1s 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