SPINS: Security Protocols in Sensor

Networks

(Authors: Adrian Perrig, Robert Szewczyk, Victor Wen, David Culler and J.D.Tygar)

Presenter

Ajay KulhariAjay Kulhariak7q@cs.virginia.edu

University of Virginia

Outline

Overview Contribution SPINS security building blocks Applications Comparison with other papers Evaluation Discussion & Conclusion

Overview: Security in WSNs What and WhysWhat and Whys

Confidentiality Authentication Integrity Fairness

Challenges Limited resources Every node can be a target No trusted peer Decentralized and cooperative participation of all

nodes

Communication scenario

Confidentiality

Adversary

Node1Base StationMsg

Node2

Communication Scenario

Integrity

Adversary

Node1Base StationMsg1

Msg1’

Communication Scenario

Authenticity

Base StationAdversary

Node 1

Node 2

Node 3

Node 4

I am the Base Station,Change these parameters

Overview: Security in WSNs What and Whys

Confidentiality Authentication Integrity Fairness

ChallengesChallenges Limited resources Every node can be a target No trusted peer Decentralized and cooperative participation of all

nodes

Overview

Trust Assumptions No trust assumption on communication infrastructure No hardware security assumptions Nodes are un-trusted Nodes trust the Base Station Secret master key is shared Nodes trust themselves (clock, sensors)

Threat Model False Identity Eavesdropping Replay

Overview

Security Goals: Data Confidentiality Two Party data authentication & Integrity Data Freshness Efficient broadcast authentication Energy efficiency by minimizing communication

Novelty & Contribution

Novelty in showing that security can be incorporated in sensor networks with proper choice of crypto and protocol design.

Designed the first set of security protocols satisfying most of the WSNs constrained nature.

The protocols will serve as base protocols for more sophisticated security services

System Assumptions

Communication patterns Frequent node-base station exchanges Frequent network flooding from base Node-node interactions infrequent

Base station Sufficient memory, power Shares secret key with each node

Node Limited resources, limited trust

SPINS: Building Blocks

SNEP Sensor-Network Encryption Protocol Secures point-to-point communication

TESLA Micro Timed Efficient Stream Loss-

tolerant Authentication Provides broadcast authentication

First Protocol: SNEP Use simple symmetric encryption function

(RC5) provides: Encryption & Decryption Message Authentication Code Pseudorandom number generation Hash Function

Secrecy and Confidentiality Semantic security against chosen ciphertext attack

(strongest security notion for encryption) Authentication Replay protection

Block Cipher: RC5

Main Feature: Data dependent Rotation Parameterized for word size, number of rounds, length of the key Low memory requirements Subset of RC5 with 40% reduction in code size Reused to save memory

Plaintext

RC5 block cipherKey Ciphertext

1100 1100

11010010 10001101

Key Generation/Setup

Nodes and base station share a master key pre-deployment Other keys are bootstrapped from the master key:

Encryption key Message Authentication code key Random number generator key

Counter

RC5 BlockCipherKey Master KeyMAC

KeyEncryption

Keyrandom

SNEP Encryption (CTR Mode)

E = {D}<Keyencryption, counter> Counter is shared state RC5 generates “random” data to XOR with message Weak freshness guaranteed Try different counter if messages are lost

Last resort: explicit resynchronization of counter Decryption is identical

Counter+1

RC5 Block CipherKeyEncryption

+Pj+1 Cj+1

Counter+1

RC5 Block CipherKeydecryption

+ Pj+1

SNEP MAC (CBC Mode)

Message Authentication Code = MAC(KMAC, X) MAC uses Cipher Block Chaining (CBC) Every block of input affects output

KMAC RC5

X1

KMAC RC5

X2

KMAC RC5

XN

MAC

+ +

Authentication, Confidentiality

Without encryption, can have authentication only For encrypted messages, the counter is included in the MAC Base station keeps current counter for every node

Node A

Msg, MAC(KMAC, Msg)

{Msg}<Kencryption, Counter), MAC(KMAC, Counter|| {Msg}<Kencryption, Counter>)

Node B

Strong Freshness

Nonce generated randomly Sender includes Nonce with request Responder include nonce in MAC, but not in reply

Node A

Request, Nonce

{Response}<Kencryption, Counter), MAC(KMAC, Nonce || Counter|| {Response}<Kencryption, Counter>)

Node B

Counter Exchange Protocol Bootstrapping counter values

To synchronize: A →B : NA B →A : CB, MAC(K’BA,NA || CB).

Node A

CA

CB, MAC(K’BA, CA||CB)

Node B

MAC(K’AB, CA||CB)

TESLA (micro TESLA)

TESLA : efficient source authentication in multicast for wired networks.

µTESLA: authentication in broadcast for WSNs. µTESLA removes or adapts the expensive

features of TESLA Asymmetric digital signature is replaced by

symmetric key Frequency of key disclosure is greatly lessened. Only the Base Station stores the key chain. Inter-node communication is made possible by

the Base Station

Broadcast Authentication

Broadcast is basic communication mechanism

Sender broadcasts data Each receiver verifies data origin

Sender

R1

M

R4

M

R3R2 MM

Simple MAC Insecure for Broadcast

Sender

R1

M, MAC(K,M)

R4

M, MAC(K,M)

M’, MAC(K,M’)

K

K K

TESLA: Authenticated Broadcast

Uses purely symmetric primitives

Asymmetry from delayed key

disclosure

Self-authenticating keys

Requires loose time synchronization

Use SNEP with strong freshness

Key Setup

Main idea: One-way key chains K0 is initial commitment to chain Base station gives K0 to all nodes

Kn Kn-1 K1 K0

X

…….F(Kn) F(K1)F(K2)

Broadcast

Divide time into intervals Associate Ki with interval i Messages sent in interval i use Ki in MAC Ki is revealed at time i + Nodes authenticate Ki and messages using Ki

K0 K1 K2 K3 …

0 1 2 3 4 time

Bootstrapping new receiver

Node sends random Nonce to base station Base station responds with bootstrap:

Tnow Time at base station Ki Previously disclosed key Ti Starting time of interval i Tint Interval duration Disclosure delay

Node A Base Station

Tnow, Ki, Ti, Tint, , MAC(Kmaster, Nonce | Tnow | …)

Nonce

Broadcasting Authenticated Packets

In interval j, base station broadcasts Msg Node verifies that key Kj has not been disclosed yet Node stores Msg

Node A Base Station

Tnow, Ki, Ti, Tint, , MAC(Kmaster, Nonce | Tnow | …)

Nonce

Msg, MAC(Kj, Msg)

Node authenticating packets

After disclosure interval , base station broadcasts Kj Node verifies that F(Kj) = Kj-1, or F(F(Kj)) = Kj-2, etc. Node verifies MAC of Msg Node delivers Msg

Node A Base Station

Tnow, Ki, Ti, Tint, , MAC(Kmaster, Nonce | Tnow | …)

Nonce

Msg, MAC(Kj, Msg)

Kj

Perfect robustness to packet loss

K2 K3 K4 K5

tTime 2 Time 3 Time 4 Time 5

K1

P5

K3

P3

K1

P2

K0

P1

K0

Verify MACs

P4

K2

FF

Authenticate K3

Node Broadcast

By request Node requests key from base station Node broadcasts using key Base station or Node reveal key later

By proxy Node sends message to base station Base station broadcasts on node’s

behalf

TESLA Issues Important parameters: time interval, disclosure

delay Delay must be greater than RTT to ensure integrity Parameters define maximum delay until messages

can be processed Nodes must buffer broadcasts until key is disclosed Requires loose time synchronization in network Base station commits to maximum number of

broadcasts when forming chain When current chain is exhausted, all nodes must be

bootstrapped with a new one

Authenticated Routing

Simple “Breadth-first search” routing algorithm Routing scheme assumes bidirectional communication Base station periodically broadcasts beacon

BS

Authenticated Routing

First reception of authenticated beacon during current routing interval defines “parent”

At reception of a beacon, if it’s fresh then accept sender as its parent in the route and broadcast another beacon with the node’s id as sender id

BS

Authenticated Routing

Messages are routed through parent towards base station

Attacker cannot re-route arbitrary links

BS

Authenticated Routing

How to ensure that routing request is from BS? Use TESLA key disclosure packet as routing beacon Reception of TESLA packet guarantees that it’s from BS

and it’s fresh At each time interval, accept first node sending

authenticated packet as parent

BS

Node to Node Key Agreement Node A Base Station

NA, NB, A, B, MAC(KmacB, NA | NB | A | B)

A,NA

Node B

{KAB}KencryB, MAC(KmacB, {KAB}KencryB)

{KAB}KencryA, MAC(KmacA, {KAB}KencryA)

Make random KAB

{Msg}Kab, MAC(KAB, {Msg}Kab)

Secure “channel”

Random Nonce

Lots of Communication

Comparison with other papers

Routing: Trajectory based Forwarding SPEED

Localization: DV-Hop

Needed Node to Node broadcast authentication

Secure verification of local claims

Trajectory Based Forwarding

Source

Destination

Adversary can play with integrity of the curve function.

Forbidden Zone Intermediate Destination

StraightforwardPath

SPEED

Authenticate node before using its table for routing.

UniformBack-Pressure

Strong Back-Pressure(Congestion)

DV-hop Propagation Method

Lot of trust has been placed on seed nodes. uTESLA protocol can be used for node to node

authentication.

[x1,y1,0]

[x2,y2,0]

seed

seed

Actual position

[x2’’,y2’’,2]

[x1’’,y1’’,4]

Actual position

Comparison with other papers Power Control:

Differentiated Surveillance Change parameters on authentication Use uTESLA authenticated broadcast

SPAN Uses broadcast messages to discover and react

to change in topology Messages need to be authentic for proper power

saving

SPAN

Uses broadcast messages to discover and react to change in topology

Comparison with security Papers

Security: Efficient Distribution of key chain commitments

Removes the requirement of unicast-based initialization with sensor nodes

Random key pre-distribution schemes Efficient node to node authentication without

involving base station

Evaluation (Energy cost) Highest overhead is from transmission of 8-

byte MAC per packet

Evaluation

SPINS Summary

Rigid communication patterns Unique ID required Time synchronized network Pre-loaded master keys Memory Usage: master keys &

counters, broadcast key chain Power Usage: all nodes communicate

with it, or use it to setup keys

Discussion: Drawbacks

The TESLA protocol lacks scalability require initial key commitment with each

nodes, which is very communication intensive

SPINS uses source routing, so vulnerable to traffic analysis

No mechanism to determine and deal with compromised nodes.

Discussion: Risks Un-addressed

Information leakage through covert channels

Denial of service attacks Speeding up / delaying packets does not help

No Non-repudiation As there is no digital signature

accuracy of sensor data truthfulness of data is completely separate from the

authentication, confidentiality, and freshness addressed by data analysis techniques

Conclusion Interesting security protocols feasible in sensor

networks Broadcast authentication in resource-

constrained environments Minimal security overheads

Computation, memory, communication Relevance to future sensor networks

Energy limitations persist Tendency to use minimal hardware Applicable to other communication systems

Future work

Security architecture for peer-to-peer communication

Interaction between encryption and data coding protocols

Interaction between authentication and aggregation within the sensor network