SPINS-SPINS: Security Protocols for Sensor Networks

[seminar class]

Presented By :
Tanu Sharma

---

[attachment=9866]
SPINS: Security Protocols for Sensor Networks
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
• Node
-Limited resources, limited trust
• Notation
• SNEP
• Data Confidentiality (Semantic Security )
• Data Authentication
• Replay Protection
• Weak Freshness
• Low Communication Overhead
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
• Authentication, Confidentiality
• 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
• Counter Exchange Protocol
• Bootstrapping counter values
• µ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
• Main idea: One-way key chains
• K0 is initial commitment to chain
• Base station gives K0 to all nodes
• mTESLA 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: NA, A
B S: NA,NB, A, B, MAC(K’BS, NA || NB || A || B)
S A: {SKAB}KSA , MAC(K’SA,NA || A || {SKAB}KSA )
S B: {SKAB}KSB , MAC(K’SB,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 mTESLA 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