1. SPINS: Security Protocols in Sensor Networks
(Authors: Adrian Perrig, Robert Szewczyk, Victor Wen,
David Culler and J.D.Tygar)
Presenter
Ajay Kulhari
University of Virginia

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

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

4. Communication scenario
Confidentiality
Node2
Base Station
Msg
Node1
Adversary

5. Communication Scenario
Integrity
Base Station
Msg1’
Msg1
Node1
Adversary

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

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

8. 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

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

10. 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

11. 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

12. SPINS: Building Blocks
SNEP
Sensor-Network Encryption Protocol
Secures point-to-point communication
TESLA
Micro Timed Efficient Stream Loss-tolerant Authentication
Provides broadcast authentication

13. 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

14. 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
RC5 block
cipher
Ciphertext
Key

15. 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

16. 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

17. 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

18. 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>)

19. 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>)

20. 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)

21. 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

22. Broadcast Authentication
Broadcast is basic communication mechanism
Sender broadcasts data
Each receiver verifies data origin R2 M
Sender M R3 M M R1 R4

23. Simple MAC Insecure for BroadcastK
Sender
M, MAC(K,M)
M, MAC(K,M) R1 R4 K K
M’, MAC(K,M’)

24. TESLA: Authenticated Broadcast
Uses purely symmetric primitives
Asymmetry from delayed key disclosure
Self-authenticating keys
Requires loose time synchronization
Use SNEP with strong freshness

25. 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

26. 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 …
time

27. 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 | …)

28. 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)

29. 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 

30. 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

31. 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

32. 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

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

34. 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

35. Authenticated Routing
Messages are routed through parent towards base station
Attacker cannot re-route arbitrary links BS

36. 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

37. 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”

38. 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

39. 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

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

41. 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

42. 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

43. 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

44. 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

45. Evaluation (Energy cost)
Highest overhead is from transmission of 8-byte MAC per packet

46. Evaluation

47. 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

48. 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

49. 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

50. 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

51. 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