SPINS: Security Protocols for Sensor Networks
Authors: Adrian Perrig, Robert Szewczyk, Victor Wen,David Culler and J.D.Tygar
Presented By : Tanu Sharma
(Some slides have been taken from authors sites)
Outline
Security for sensor networks
- Research Problem
Proposed Techniques
- SPINS building blocks
Applications Related Work Discussion Conclusion
Sensor Networks are emerging
Many applications
- Real-time traffic monitoring - Military applications - Emergency and critical systems etc.
Need secure communication protocols
Security for Sensor Networks
Data Authentication Data Confidentiality Data Integrity Data Freshness
- Weak Freshness
- Partial message ordering, no delay information - Useful for sensor measurements
- Strong
Freshness
- Total ordering on req-res pair, delay estimation - Useful for time synchronization
Challenge: Resource Constraints
Limited energy Limited computation(4MHz 8-bit) Limited memory(512 bytes) Limited code size(8 Kbytes) Limited communication(30 byte packets) Energy consuming communication
Contributions
SNEP
-Sensor Network Encryption Protocol
-Secures point-to-point communication
TESLA
-Micro Timed Efficient Stream Loss-tolerant Authentication -Provides broadcast authentication
System Assumptions
Communication patterns
-Node to base station (e.g. sensor readings)
-Base station to node (e.g. specific requests) -Base station to all nodes
Base Station
-Sufficient memory, power -Shares secret key with each node
E C
Base Station
G F D B A
Node
-Limited resources, limited trust
Notation
A, B NA CA AB KAB KAB {M}KAB {M}<KAB,IV> MAC(KAB,M) Principals( nodes) Nonce generated by A Counter generated by A Master secret key between A and B ( no direction information) Secret encryption key between A and B (depends on direction) Secret MAC key between A and B (depends on direction) Encryption of message M with KAB Encryption of message M using key KAB and initialization vector IV Message authentication code (MAC) of M
SNEP
Data Confidentiality (Semantic Security ) Data Authentication Replay Protection Weak Freshness Low Communication Overhead
Key Generation /Setup
Counter KeyEncryption Key Master RC5 Block Cipher KeyMAC Keyrandom
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
Authentication, Confidentiality
Node A
M, MAC(KAB, M)
Node B
{M}<KAB, CA>, MAC(KAB, CA|| {M}<KAB, CA>)
Without encryption can have only authentication For encrypted messages, the counter is included in the MAC Base station keeps current counter for every node
Strong Freshness
Node A Request, NA Node B
{Response}<KBA, CB), MAC(KBA, NA || CB|| {Response}<KBA, CB>)
Nonce generated randomly Sender includes Nonce with request Responder include nonce in MAC, but not in reply
Counter Exchange Protocol
Bootstrapping counter values
Node A CA CB, MAC(KBA, CA||CB) MAC(KAB, CA||CB) Node B
To synchronize: A B : B A :
NA CB, MAC(KBA,NA || CB).
TESLA : Authenticated Broadcast
TESLA : efficient source authentication in multicast for
wired networks.
Problems with TESLA
-Digital Signature for initial packet authentication
TESLA uses only symmetric mechanism
-Overhead of 24 bytes per packet
TESLA discloses key once per epoch
-One way key chain is too big
TESLA restricts number of authenticated senders
Key Setup
Kn
F(Kn)
Kn-1
F(K2) .
K1
F(K1)
K0
Main idea: One-way key chains K0 is initial commitment to chain Base station gives K0 to all nodes
TESLA Quick Overview I
Keys disclosed 2 time intervals after use Receiver knows authentic K3 Authentication of P1:MAC(K5,P1) Authenticate K5 K3 F K4 Time 4 Verify MAC F K5 Time 5 P1 K3 F K6 Time 6 F K7 Time 7 P2 K5 t
TESLA Quick Overview II
Perfect robustness to packet loss
Authenticate K5 K3 F K4 Time 4 P1 P2 F K5 Time 5 P3 K3 K6 Time 6 P4 K4 K7 Time 7 P5 K5 t
K2 K2
Verify MACs
TESLA Properties
Asymmetry from delayed key disclosure Self-authenticating keys Requires loose time synchronization Low overhead (1 MAC)
- Communication (same as SNEP) - Computation (~ 2 MAC computations)
Independent of number of receivers
Applications
Authenticated Routing Node to Node Agreement
A B S S B: S: A: B: NA, A NA,NB, A, B, MAC(KBS, NA || NB || A || B) {SKAB}KSA , MAC(KSA,NA || A || {SKAB}KSA ) {SKAB}KSB , MAC(KSB,NB || B || {SKAB}KSB )
Related Work in Broadcast Authentication
Symmetric schemes
- Link-state routing updates - Multi-MAC
Asymmetric schemes
- Merkle hash tree
Chained hashes
- EMSS
Hybrid schemes
-Stream signature -K-times signature
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
Discussion: Risks Un-addressed
Information leakage through covert channels No mechanism to determine and deal with compromised nodes. Denial of service attacks No Non-repudiation
Conclusion
Strong security protocols affordable
- First broadcast authentication
Low security overhead
- Computation, memory, communication
Apply to future sensor networks
-Energy limitations persist -Tendency to use minimal hardware
Base protocol for more sophisticated security services
