SPINS:
Security Protocols for
Sensor Networks
Adrian Perrig
Robert Szewczyk
Victor Wen
David Culler
Doug Tygar
UC Berkeley
Sensor Networks are Emerging
 Many applications
• Real-time traffic monitoring
• Seismic safety
• Energy efficiency
 Need secure communication protocols
Sensors in Cory Hall
Sample Sensor Data
Light
intensity
Temperature
Hacker
Attack!
Security for Sensor Networks
 Authentication
• Ensures data integrity & origin
• Prevents injecting bogus messages
 Confidentiality
• Ensures secrecy of data
• Prevents eavesdropping
Challenge: Resource Constraints
 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
SPINS: Our Solution
 SNEP
• Sensor-Network Encryption Protocol
• Secures point-to-point communication
 TESLA
• Micro Timed Efficient Stream Losstolerant Authentication
• Provides broadcast authentication
System 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
SNEP Security Goals
 Secure point-to-point communication
• Confidentiality, secrecy
• Authenticity and integrity
• Message freshness to prevent replay
 Why not use existing protocols?
• E.g. SSL/TLS, IPSEC
Asymmetric Cryptography
is Unsuitable
 Overhead of digital signatures
• High generation cost
• High verification cost
• High memory requirement
• High communication cost
O(minutes)
O(seconds)
~128 bytes
 SNEP only uses symmetric crypto
Basic Crypto Primitives
 Code size constraints  code reuse
 Only use block cipher encrypt function
• Counter mode encryption
• Cipher-block-chaining message
authentication code (MAC)
• Pseudo-Random Generator
SNEP Protocol Details
 A and B share
• Encryption keys: KAB KBA
• MAC keys: K'AB K'BA
• Counters: CA CB
 To send data D, A sends to B:
A  B: {D}<K , C >
AB A
MAC( K'AB , [CA || {D}<K
]
,
>
C
AB A
)
SNEP Properties
 Secrecy & confidentiality
• Semantic security against chosen ciphertext
attack (strongest security notion for encryption)
 Authentication
 Replay protection
 Code size: 1.5 Kbytes
 Strong freshness protocol in paper
Broadcast Authentication
 Broadcast is basic communication mechanism
 Sender broadcasts data
 Each receiver verifies data origin
Alice
M
Sender
M
Bob
M
M
Carol
Dave
Simple MAC Insecure for Broadcast
K
Sender
M, MAC(K,M)
K
Alice
M, MAC(K,M)
Bob
M', MAC(K,M') K
TESLA: Authenticated Broadcast
 Uses purely symmetric primitives
 Asymmetry from delayed key disclosure
 Self-authenticating keys
 Requires loose time synchronization
• Use SNEP with strong freshness
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
F
Time 4
K5
Time 5
F
K6
Time 6
F
K7
Time 7
P1
P2
K3
K5
Verify MAC
t
TESLA Quick Overview II
 Perfect robustness to packet loss
Authenticate K5
K3
F
K4
Time 4
P1
F
K5
K6
Time 5
Time 6
K7
Time 7
P2
P3
P4
P5
K2 K2
K3
K4
K5
Verify MACs
t
TESLA Properties
 Low overhead (1 MAC)
• Communication (same as SNEP)
• Computation (~ 2 MAC computations)
 Perfect robustness to packet loss
 Independent of number of receivers
Energy Cost for Sending a Message
 Typical packet size: 28 bytes
Security Computation 2%
MAC transmission
21%
Data
transmission
77%
Related Work in Broadcast Authentication
 Symmetric schemes
• Link-state routing updates [Cheung ’97]
• Multi-MAC [Canetti et al. ’99]
 Asymmetric schemes
• Merkle hash tree [Wong & Lam ’98]
 Chained hashes
• EMSS [Perrig, Canetti, Tygar, Song ’00]
• [Golle & Modadugu ’01]
• [Miner & Staddon ’01]
 Hybrid schemes
• Stream signature [Gennaro & Rohatgi ’97]
• K-times signature [Rohatgi ’99]
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