SPINS: Security Protocols in Sensor Networks (Authors: Adrian Perrig, Robert Szewczyk, Victor Wen, David Culler and J.D.Tygar) Presenter Ajay Kulhari ak7q@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 Whys Confidentiality Authentication Integrity Fairness Challenges Limited resources Every node can be a target No trusted peer Decentralized and cooperative participation of all nodes 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

Communication scenario Confidentiality Node2 Base Station Msg Node1 Adversary

Communication Scenario Integrity Base Station Msg1’ Msg1 Node1 Adversary

Communication Scenario Authenticity I am the Base Station, Change these parameters Node 1 Base Station Node 2 Adversary Node 3 Node 4

Overview: Security in WSNs What 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 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

Overview Trust Assumptions Threat Model 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 Base station Node 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 Strong Freshness Protocol Code size constraints Reuse of encryption function saves code space Adds only 8 bytes per message Code size: 1.5 Kbytes

Block Cipher: RC5 Plaintext 1100 1100 RC5 block cipher Ciphertext Key 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 1100 1100 RC5 block cipher Ciphertext Key 10001101 11010010

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 KeyEncryption RC5 Block Cipher KeyMAC Key Master Keyrandom

SNEP Encryption (CTR Mode) Counter+1 Counter+1 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 RC5 Block Cipher RC5 Block Cipher KeyEncryption Keydecryption Pj+1 + Cj+1 + Pj+1

SNEP MAC (CBC Mode) Message Authentication Code = MAC(KMAC, X) MAC uses Cipher Block Chaining (CBC) Every block of input affects output X1 X2 XN + + RC5 RC5 RC5 KMAC KMAC KMAC 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 B Node A Msg, MAC(KMAC, Msg) {Msg}<Kencryption, Counter), MAC(KMAC, Counter|| {Msg}<Kencryption, Counter>)

Strong Freshness Node B Node A Request, Nonce Nonce generated randomly Sender includes Nonce with request Responder include nonce in MAC, but not in reply Node B Node A Request, Nonce {Response}<Kencryption, Counter), MAC(KMAC, Nonce || Counter|| {Response}<Kencryption, Counter>)

Counter Exchange Protocol Bootstrapping counter values To synchronize: A →B : NA B →A : CB, MAC(K’BA,NA || CB). Node B Node A CA CB, MAC(K’BA, CA||CB) 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 R2 M Sender M R3 M M R1 R4

Simple MAC Insecure for Broadcast K Sender M, MAC(K,M) M, MAC(K,M) R1 R4 K K M’, MAC(K,M’)

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 F(Kn) F(K2) F(K1) Kn Kn-1 K1 K0 ……. X

Broadcast Divide time into intervals Associate Ki with interval i  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 Nonce Tnow, Ki, Ti, Tint, , MAC(Kmaster, Nonce | Tnow | …)

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 Nonce Tnow, Ki, Ti, Tint, , MAC(Kmaster, Nonce | Tnow | …) 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 Nonce Tnow, Ki, Ti, Tint, , MAC(Kmaster, Nonce | Tnow | …) Msg, MAC(Kj, Msg) Kj 

Perfect robustness to packet loss Authenticate K3 K1 K2 K3 K4 K5 t Time 2 Time 3 Time 4 Time 5 Low overhead (1 MAC) Communication (same as SNEP) Computation (~ 2 MAC computations) Perfect robustness to packet loss Independent of number of receivers No digital signature required P1 K0 P2 K0 P3 K1 P4 K2 P5 K3 Verify MACs

Node Broadcast By request By proxy 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 Node B Base Station A,NA Random Nonce NA, NB, A, B, MAC(KmacB, NA | NB | A | B) Make random KAB {KAB}KencryB, MAC(KmacB, {KAB}KencryB) {KAB}KencryA, MAC(KmacA, {KAB}KencryA) Lots of Communication {Msg}Kab, MAC(KAB, {Msg}Kab) Secure “channel”

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 (a) Integrity of the curve path (b) Authentication

Trajectory Based Forwarding Adversary can play with integrity of the curve function. Forbidden Zone Intermediate Destination Straightforward Path Destination Curved trajectories have various applications that will be explained in the following slides. Each node knows its position. Trajectory independent of specific nodes and destination. No routing tables at each node. Trades off communication for computation. Each node takes a greedy decision to infer the next hop. Source

SPEED Authenticate node before using its table for routing. Strong Back-Pressure (Congestion) Uniform Back-Pressure

DV-hop Propagation Method Lot of trust has been placed on seed nodes. uTESLA protocol can be used for node to node authentication. Actual position [x1,y1,0] seed [x1’’,y1’’,4] [x2’’,y2’’,2] seed [x2,y2,0] 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 4 1 5 2 2 6 7 1 3 3 7 5 6 4 Coordinator Node

Comparison with security Papers 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. Small Communication costs Code reuse Keys between nodes setup through base station

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