Adrian Perrig, Robert Szewczyk, Victor Wen

1
Security Protocols for Sensor Networks

• Adrian Perrig, Robert Szewczyk, Victor Wen
• UC Berkeley, December 2000

2
Motivation

• Sensor networks proliferation
• environmental data gathering increases in
  importance
• more decisions will be made on the basis of this
  data
• Security in sensor networks has not been
  addressed
• sensor networks have to work in
• hostile environment
• multiple administrative domains
• need to tolerate byzantine failures of individual
  nodes, or compromised nodes - minimize
  adversarys impact on the network
• often can substitute trust for a more expensive
  verification
• data accuracy provided through redundancy of
  sensors
• but it helps to be able to verify the source of
  the data

3
Example Sensor Network

• Hardware resources
• 4 MHz 8-bit processor, short range RF
  communication
• 8 KB of program memory(flash), 512 bytes of RAM,
  some high latency storage
• Operating environment TinyOS
• small, event driven operating system
• Communication architecture
• broadcast a fundamental primitive of network
  access
• base station, multihop routing
• currently, limited local exchanges of data
• Active Message-like programming interface
• Energy efficiency of paramount importance
• minimize transmission size
• minimize required processing, memory requirements
• Security mechanism not an end in themselves
• merely a building block which needs to coexist
  with other functions

4
Security architecture

• Authentication is of paramount importance
• network management functions, e.g. routing,
  administration
• authentication of a data source is a first step
  towards verifying the data
• Secrecy of messages often secondary
• BUT, necessary for certain management tasks, e.g.
  key distribution
• Trusted computing base
• base station - necessary for extracting any data
  from the network
• local clock - trust that it has a small drift

5
Cryptographic Algorithms

• RC5 Chosen because of its code size and
  performance
• Total code size on Atmel 8-bit processor 1.6KB
  (smallest code version)
• No multiplication needed.
• Requires 32-bit rotate based on input data. ISA
  supports only 1-bit rotate. Overcome by hand-code
  assembly to improve code density and speed.
• Rijndael investigated and rejected because
• 822 bytes of table for encryption only.
• Faster version requires more than 10KB of memory
  for tables.
• RC5 faster than standard implementation.
• TEA and TREYFER rejected because
• Not sufficiently analyzed.
• Public key cryptography WAY too expensive

6
Secure and Authenticated Node-Base Communication

• Confidentiality based on on RC5 OFB encryption
  mode
• only encryption primitive is needed.
• OFB is stream-cipher by nature. Thus, the size of
  ciphertext is equal to the plaintext, not
  multiple of block size. This could save bandwidth
  all of payload mean something.
• Authentication RC5-based 8-byte MAC in the
  packet
• MAC computed by iteratively encrypt and xor
  plaintext.
• Mote lt-gt Base Station payload, IVKsrc, dst,
  seqno, payload, IVKK
• Where means encryption and means MAC
• Key distribution
• Each node shares a single secret key K with the
  base station
• KencryptionRC5(0,K)
• KMAC RC5(1,K)
• Krandom RC5(2,K)
• Lifetime of keys limited by the battery life

7
Freshness guarantees

• Weak freshness guarantee
• Base and mote uses nonconflicting counters as IV.
• IV are included in the packet, and incremented
  after every message.
• Freshness guaranteed through monotonicity
• Used when a node participates in the network
• M --gt N IV payloadksrc, dst, IV payloadkk
• Strong freshness guarantee
• Needed for messages requiring strong time
  ordering, e.g. initial synchronization with the
  network
• Random nonce, generated via RC5 encrypting
  primitive, sent along in the packet. Accept
  return message only if return nonce matches.
• M ? BS nonce
• BS ? M Time, nonceK

8
Authenticated broadcast

• TESLA protocol
• shared key protocol, uses a keychain of shared
  keys computed with a one-way function g
• authentication based on delayed key disclosure
• requires time synchronization
• Adaptation of TESLA protocol
• use routing updates to disclose TESLA keys
• use routing updates for clock synchronization
• artificially slow down local clocks - makes it
  easier to synchronize
• Important side benefit authenticated routing

9
Performance

• RC5 Implemented both on Mote and PC (in Java)
• Test Platform
• PC Pentium III 650MHz, 32-bit processor, 640MB
  RAM, IBM JDK 1.3 with JIT enabled
• Mote Atmel 4MHz, 8-bit processor, 512 bytes RAM,
  8KB Flash RAM (for code)

PC Performance Table
Mote Performance Table
Code Size Breakdown (in bytes)
RAM Usage
10
Conclusions

• Security subsystem possible with limited
  resources
• need for flexible primitives, resusable within
  the application
• first computationally intensive application on
  the TinyOS
• more RAM would be helpful!
• Security protocols are application dependent
• with our primitives it is possible to build a
  wide variety of protocols
• Future work
• Privacy concerns
• Security architecture for peer-to-peer
  communication
• Interaction between encryption and data coding
  protocols

11
Open problems

• Privacy concerns
• Security architecture for peer-to-peer
  communication
• Interaction between encryption and data coding
  protocols