SPINS: Security Protocols for

Sensor Networks

Adrian Perrig, Robert Szewczyk, J.D.

Tygar, Victor Wen, and David Culler
Department of Electrical Engineering &
Computer Sciences, University of
California - Berkeley

Introduction

 Wireless sensor networks are increasingly

prevalent (or at least that was the prevailing thought in 2002)
 Sensors are very resource-limited
(SmartDust)
– Slow communication links (10 kbps)
– Limited computing power (8-bit, 4 MHz)
– Limited memory and storage (512 bytes)
– Limited battery life
– TinyOS

1
Sensor Applications

 Emergency response
– Buildings, roads, airports, etc.
 Energy management
– Mitigate blackouts by sensing temperature and load balance
information and redistributing power
 Medical monitoring
– Automatic medication administration
 Inventory management
– Distribution tracking
 Battlefield management
– Collect and distribute information about battlefield conditions

Motivation

 Some of these applications are critical

 Security is often ignored
– Too much power
– Too much communication overhead
– In some cases, not enough memory to even store
the parameters!
 1024-bit RSA

2
Is security on sensors possible?

 Remember, the devices are very resource-

constrained
 Asymmetric cryptography in particular is both:
– Computationally intensive, which shortens battery life
– Overhead intensive, which decreases overall efficiency
AND shortens battery life
 In wireless sensors, communications make up the majority of
energy consumption
 Overhead can be as long as 1000 bytes per packet!
 TESLA, a protocol developed for authenticated
broadcast, is unsuitable for sensors

TESLA

 Broadcast authentication mechanism using only

symmetric cryptographic primitives
 Receivers should be able to verify authentication
data but not generate it
 Senders and receivers should be loosely time-
synchronized
 Senders use one-way key chaining (more on this
later)
 Receivers only accept packets generated with secret
keys

3
The SPINS Approach

 Two components:
– SNEP (Sensor Network Encryption Protocol)
 Provides cryptographic strength, two-party data authentication,
replay protection, freshness, and integrity
– µTESLA
 Provides broadcast authentication
 Each station has a shared secret key with the base
station
 All cryptographic operations based on a single block
cipher

Architecture Assumptions

 Sensor networks have one or more base stations

 Base stations have significantly more power
 Periodic beacons establish routing topology
 Individual nodes communicate through the base
station
 Three types of communication:
– Node to base station
– Base station to node
– Broadcast (from base station)

4
Trust Assumptions

 Individual nodes are not trusted, but they do

trust themselves (at least in terms of
synchronization)
 The base station is trusted
 Broadcast medium is not trusted
 Single-node compromise should not
compromise the rest of the network

Security Requirements

 Confidentiality
– Transmissions should be recognizable only by authorized
receivers
 Authentication
– All messages must be verified as coming from trusted
sources
 Integrity
– Data is not altered in transit
 Freshness
– Data is not outdated
 A secure channel combines all of the above

5
The Building Blocks

 Sensor Network Encryption Protocol (SNEP)

– Provides data confidentiality
– Authentication
– Integrity
– Freshness
– Semantic security
 Identical messages encrypted differently using CTR
mode

SNEP Counters

 Senders and receivers share counters

 One shared counter per direction
 Requires synchronization
 Counter exchange (resynchronization) is
possible

6
Message Authentication

 Each pair of entities shares a master key ΧAB

 Pseudorandom functions allow for four keys to be
generated from this master key
– KAB – Encryption from A to B
– KBA – Encryption from B to A
– K’AB – MAC from A to B
– K’BA – MAC from B to A
 Using different keys for encryption and MAC reduces
weaknesses from potential interaction

Data Transmission

 Remember the shared counter

 Communication overhead is low since the counter is
not transmitted (8 bytes)
 Counter enforces an ordering of messages (weak
freshness)
 For strong freshness, send a request message (R) with
a nonce

7
Counter Exchange

 Initial exchange does not require encryption

 Strong freshness is achieved by using counter values
as nonces
 Resynchronization is a simple request/response pair

µTESLA: Authenticated Broadcast

 Very similar to TESLA, but with some changes to

reduce overhead (standard TESLA is 24 bytes)
– Sensor packets are only ~ 30 bytes
 No digital signatures are used to initially authenticate
– Only symmetric mechanisms used
 Key disclosure is less frequent (once per time period
instead of once per packet)
 The number of authenticated senders is restricted
 (Same problems as TESLA!)

8
µTESLA, continued

 Requires that communicating nodes are

loosely time synchronized
 Also requires that each node knows the
maximum synchronization error
 Time is divided into epochs, with one key
used per epoch

µTESLA One-Way Key Chain

 Using a one-way function (such as MD5), some key K(j)

can be generated as MD5(K(j+1))
 Keys are generated in reverse order (preventing the
discovery of keys not yet known outside of the sender)
 Receivers buffer packets until keys are disclosed and
the contents authenticated
– When key K2 is disclosed, receivers can authenticate packets
P1 and P2

9
µTESLA: Key Disclosure

 Keys are disclosed when:

– Some time longer than any reasonable round-trip
delay between the sender and receiver has
passed
– This prevents artificial packet injection since
packets generated with a previously-disclosed
key will be known to be outdated (and likely
forged)

µTESLA: Adding Receivers

 New receivers need only one authentic key

– The one-way chain allows verification of future keys
 Receivers must be loosely synchronized
 This requires strong freshness and two-party
authentication
– SNEP’s request/response pair works
– Sender responds to a request with its current time,
some key of the chain, the start time of a time interval,
the duration, and the disclosure delay
– Does not need to be encrypted

10
µTESLA: Authenticating Packets

 Receivers discard packets that have unusually long

delay
– Could have been generated with already-disclosed keys
 Receivers can only verify packets once keys have
been disclosed
 There is some inherent delay in authenticated
broadcast since receivers must some time intervals
before authenticating a received broadcast packet

µTESLA: Node Broadcast

 Node memory is insufficient for one-way key

chains, so nodes can either:
– Broadcast through the base station using SNEP
– Broadcasts data, but the base station handles the
key chain (sending current values to the
broadcasting node)
 Generally too energy-intensive for a node, so the base
station might disclose keys or handle adding receivers

11
Implementation

 Remember the system resource limitations

– 8 Kbytes read-only program memory
 Some must be used for TinyOS
 Some must be used for the actual sensor application
– 512 bytes of RAM

Implementation - Block Cipher

 RC5 was chosen for its simplicity

– AES and DES required too much memory
– TEA not sufficient cryptanalyzed
 Only costly operations are 32-bit data-
dependent rotations
 Code tuned from OpenSSL implementation
based on desired functionality
– Results in a 40% decrease in code size

12
RC5 Operation & RNG

 CTR mode encryption used

– Removes the need for separate decryption
– Single-block error propagation good for wireless
transmission environments
– Enforces message ordering
 MAC function used to generate random
numbers with

Message Authentication

 CBC-MAC is used
 One MAC computed per packet
– Achieves both integrity and authentication since the MAC
keys are unidirectional

13
Key Derivation

 MAC function used to generate keys from the known

shared master key (between each node and the base
station)
– FK(x) = MAC(K,x)
– Each key is computationally independent

Evaluation

 Differences arise from the implementation of the

data-dependent rotation (a 32-bit operation) on
an 8-bit processor
 Protocol itself is 574 bytes, for just over 2 Kbytes
total

14
Aside: “Fast” is a relative term

 At 1.10 ms per encryption, total encryption

throughput (without MAC) is about 116.4
kbps
 “Fast” FPGA-based encryption of AES can
achieve a throughput of at least 30 Gbps
– Only about 250,000 times faster

More Evaluation

 Key disclosure interval is 2

 To check validity, this means two key setup
operations and two encryptions
 To check message integrity, two key setup
operations, two encryptions, and up to four
MAC operations are needed – 17.74 ms total
 Limiting factor is actually the amount of
memory dedicated to buffering

15
Energy Usage (SNEP)

 Costs based on 30-byte packets

 Notice the costs are heavily skewed towards
communication
 No additional cost for encrypted data transmission
since encrypted block size is the same as plaintext

Energy Usage (µTESLA)

 Same as SNEP, but:

– Periodic key disclosure combined with routing
updates
– Can be viewed as free if routing updates are
considered necessary
– Can also be viewed as wasted energy if
authenticated routing is considered a waste

16
Other Security Issues

 No consideration of covert channels

 No consideration of compromised nodes
 No consideration of DoS attacks
 No consideration of non-repudiation

Applications

 Authenticated routing built on µTESLA

 Routing beacons broadcast periodically
 When nodes receive beacons, if they have not
received a beacon in the current time interval they:
– Accept the sender as a parent
– Broadcast a routing beacon with itself as the sender
 µTESLA key disclosure packets can serve as
beacons
– Authenticity and freshness guaranteed
– Nodes use watchdog behavior for anomaly detection
(misbehaving nodes)

17
More Applications

 Node-to-node key agreement

 SNEP ensures strong freshness, confidentiality,
and authentication using symmetric cryptography
 Nodes A and B use a mutually trusted base station
S for exchange
 Base station does most of the work

Related Work

 Key distribution and key agreement in

resource-constrained environments
 Asymmetric cryptography in ad-hoc networks
 Ad-hoc peer-to-peer authentication based on
public key certificates
 Cryptography in relatively primitive devices

 (The paper has 57 references, 26 of which are cited in the related work
section.)

18
Conclusion

 SNEP and µTESLA together provide secure

communication channels using only
symmetric cryptography in sensor networks
– Confidentiality
– Authentication
– Integrity
– Freshness
– Low overhead

Contributions & Merits

 The SPINS method is a comprehensive

security protocol for sensor networks using
only symmetric cryptography
– Relatively low communication overhead
– Compact (runs on SmartDust)
– Relatively resistant to compromise
 Pretty advanced for 2002

19
Contributions & Merits

 Combines two unique methods

– SNEP & µTESLA
 Actually implemented on SmartDust sensors
– Gives actual performance numbers on extremely
resource-constrained environments
– Some limited analysis on energy consumption
 Simple yet effective design choices
– Use of a single block cipher for all operations
– Counter mode encryption

Contributions & Merits

 SPINS is relatively universal and extensible

to many other embedded applications
 Two application examples given
– Authenticated routing in ad-hoc networks using
key disclosure packets as routing beacons
– Secure node-to-node key agreement using
symmetric cryptography

20
Weaknesses & Drawbacks

 Weak mobility model

– Sensor networks assumed to have a base station
 What if they don’t?
 Lots of other papers assume nodes take turns being the
base station, negating the “supernode” assumption
– It appears mobility is limited or infrequent
 If it isn’t, the overhead from the routing beacons might
be significant

Weaknesses & Drawbacks

 Time synchronization is a key assumption

– Clock drift is actually a major problem in sensor networks
using crystal oscillators
 D. Scott, ACM SE Regional Conference, 2005
– Packet loss is also potentially a major issue in wireless
environments
 Both can be mitigated by resynchronizing the
counter or sending it with the message
– But this leads to huge (and potentially devastating)
overhead in sensor networks!
 Clock drift could lead to attacks

21
Weaknesses & Drawbacks

 Only one cipher is used (RC5)

– RC5 is simple, but does have weaknesses
 Other assumptions are inaccurate
– AES doesn’t require lookup tables
– TEA was cryptanalyzed (and broken) in 1997
– XTEA and XXTEA existed (and were better
options)
 Extremely small code size (smaller than RC5)

Weaknesses & Drawbacks

 No non-repudiation
 No study of compromised nodes
 No study of the effects of error rates on
energy consumption

22
Future Work & Extensions

 Consider testing other ciphers

 Given a more advanced platform (as we
would expect with time) what can be done?
– NTRU and Rabin for asymmetry
– AES or RC6 for symmetry
 Test the effects of clock drift
 Test the effects of errors in transmission
 Questions?

23