Title: SPINS: Security Protocols in Sensor Networks
1SPINS Security Protocols in Sensor Networks
- (Authors Adrian Perrig, Robert Szewczyk, Victor
Wen, - David Culler and J.D.Tygar)
- Presenter
- Ajay Kulhari
- ak7q_at_cs.virginia.edu
- University of Virginia
2Outline
- Overview
- Contribution
- SPINS security building blocks
- Applications
- Comparison with other papers
- Evaluation
- Discussion Conclusion
3Overview 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
4Communication scenario
Node2
Base Station
Msg
Node1
Adversary
5Communication Scenario
Base Station
Msg1
Msg1
Node1
Adversary
6Communication Scenario
I am the Base Station, Change these parameters
Node 1
Base Station
Node 2
Adversary
Node 3
Node 4
7Overview 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
8Overview
- 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
9Overview
- Security Goals
- Data Confidentiality
- Two Party data authentication Integrity
- Data Freshness
- Efficient broadcast authentication
- Energy efficiency by minimizing communication
10Novelty 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
11System 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
12SPINS Building Blocks
- SNEP
- Sensor-Network Encryption Protocol
- Secures point-to-point communication
- ?TESLA
- Micro Timed Efficient Stream Loss-tolerant
Authentication - Provides broadcast authentication
13First 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
14Block 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
1100 1100
RC5 block cipher
Ciphertext
Key
10001101
11010010
15Key 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
16SNEP Encryption (CTR Mode)
Counter1
Counter1
- E DltKeyencryption, countergt
- 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
Pj1
Cj1
Pj1
17SNEP 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
18Authentication, 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)
MsgltKencryption, Counter), MAC(KMAC, Counter
MsgltKencryption, Countergt)
19Strong Freshness
- Nonce generated randomly
- Sender includes Nonce with request
- Responder include nonce in MAC, but not in reply
Node B
Node A
Request, Nonce
ResponseltKencryption, Counter), MAC(KMAC,
Nonce Counter ResponseltKencryption,
Countergt)
20Counter Exchange Protocol
- Bootstrapping counter values
- To synchronize
- A ?B NA
- B ?A CB, MAC(KBA,NA CB).
Node B
Node A
CA
CB, MAC(KBA, CACB)
MAC(KAB, CACB)
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
22Broadcast Authentication
- Broadcast is basic communication mechanism
- Sender broadcasts data
- Each receiver verifies data origin
Sender
R3
R2
M
M
M
M
R1
R4
23Simple MAC Insecure for Broadcast
K
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
25Key Setup
- Main idea One-way key chains
- K0 is initial commitment to chain
- Base station gives K0 to all nodes
F(Kn)
F(K1)
F(K2)
Kn
Kn-1
K1
K0
.
X
26Broadcast
- 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
27Bootstrapping 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
28Broadcasting 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
)
29Node 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)
30Perfect robustness to packet loss
K2
K3
K4
K5
K1
t
Time 2
Time 3
Time 4
Time 5
31Node 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 nodes 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
33Authenticated Routing
- Simple Breadth-first search routing algorithm
- Routing scheme assumes bidirectional
communication - Base station periodically broadcasts beacon
BS
34Authenticated Routing
- First reception of authenticated beacon during
current routing interval defines parent - At reception of a beacon, if its fresh then
accept sender as its parent in the route and
broadcast another beacon with the nodes id as
sender id
BS
35Authenticated Routing
- Messages are routed through parent towards base
station - Attacker cannot re-route arbitrary links
BS
36Authenticated Routing
- How to ensure that routing request is from BS?
- Use ?TESLA key disclosure packet as routing
beacon - Reception of ?TESLA packet guarantees that its
from BS and its fresh - At each time interval, accept first node sending
authenticated packet as parent
BS
37Node to Node Key Agreement
Node A
Base Station
Node B
Random Nonce
Make random KAB
Lots of Communication
38Comparison with other papers
- Routing
- Trajectory based Forwarding
- SPEED
- Localization
- DV-Hop
- Needed Node to Node broadcast authentication
- Secure verification of local claims
39Trajectory Based Forwarding
- Adversary can play with integrity of the curve
function.
Forbidden Zone
Intermediate Destination
Destination
Straightforward Path
Source
40SPEED
- Authenticate node before using its table for
routing.
Strong Back-Pressure (Congestion)
Uniform Back-Pressure
41DV-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
42Comparison 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
43SPAN
- Uses broadcast messages to discover and react to
change in topology
4
1
5
2
2
6
7
1
3
3
7
5
6
Coordinator
4
Node
44Comparison 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
45Evaluation (Energy cost)
- Highest overhead is from transmission of 8-byte
MAC per packet
46Evaluation
47SPINS 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
48Discussion 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.
49Discussion 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
50Conclusion
- 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
51Future work
- Security architecture for peer-to-peer
communication - Interaction between encryption and data coding
protocols - Interaction between authentication and
aggregation within the sensor network