Intrusion Tolerance for NEST

1
Intrusion Tolerance for NEST
NEST PI Meeting January 29, 2003

• Bruno Dutertre, Steven Cheung
• SRI International

2
Administrative

• Project Title Intrusion Tolerance for Networked
  Embedded Sys.
• PM Vijay Raghavan
• PI Bruno Dutertre and Steven Cheung
• PI phone [phone]
• PI email bruno_at_sdl.sri.com, cheung_at_sdl.sri.com
• Institution SRI International
• Contract F30602-02-C-0212
• Award start date 9/20/2002
• Award end date 12/20/2004
• Agent name organization Raymond Liuzzi,
  AFRL/Rome

3
Subcontractors and Collaborators

• SRI Collaborators
• Hassen Saïdi, Ulf Lindqvist, Joshua D. Levy
• Collaboration with other NEST security projects
  on Security Minitask
• BBN
• UMass/UMich/ASU
• Berkeley

4
Intrusion Tolerance for NEST
Intrusion-tolerant key-distribution services for
large networks of microsensors

• Build low-cost key-management services for sensor
  networks
• Localized authentication protocols for
  bootstrapping
• Chains of trusted intermediaries for key
  establishment between remote nodes
• Secret sharing disjoint paths for tolerating
  compromised nodes
• Intrusion detection for motes
• Detect denial-of-service attacks
• Detect misbehaving nodes

Self organizing protocols Low cost
cryptography Detect/respondto DoS attacks

• Enable deployment of sensor networks in hostile
  environments
• Support other security services for wireless
  sensor networks
• Confidentiality and integrity of communication
• Robust NEST services

FY03 FY04 FY05
2QFY03 Design Bootstrapping Protocols 3QFY03
Baseline Intrusion Detection 4QFY03 Design
Intrusion-tolerant Key-Distribution
Protocols 1QFY04 Experimental Validation and
Demo 1QFY05 Integration and Final Demo
5
Objective

• Low-cost intrusion-tolerant key management and
  intrusion detection for large-scale networks of
  small wireless devices
• Constraints
• Use only (inexpensive) symmetric-key crypto
  algorithms
• Decentralized (no server) and autonomous (reduced
  administrative overhead)

6
Approach

• Bootstrapping
• Build initial secure local links between
  neighbors
• Nonlocal key distribution
• Rely on chains of intermediaries
• Use secret sharing when intermediaries are not
  fully trusted
• Intrusion detection
• Detect and locate nontrustworthy nodes
• Detect some external attacks

7
Bootstrapping

• Establish secure local links between neighbor
  devices quickly after deployment
• Exploit initial trust (it takes time for an
  adversary to capture/compromise devices)
• Weak authentication is enough (need only to
  recognize that your neighbor was deployed at the
  same time as you)
• Focusing on local links improves efficiency

8
Basic Bootstrapping Scheme

• For a set S of devices to be deployed
• Construct a symmetric key K
• Distribute it to all devices in the set
• K enables two neighbor devices A and B
• To recognize that they both belong to S (weak
  authentication)
• To generate and exchange a key for future
  communication
• Possible drawback
• Every device from S in communication range of A
  and B can discover . More robust variants
  are possible.

9
Leveraging Local Trust

• To establish keys between distant nodes
• use chains of trusted intermediaries
• To tolerate compromised nodes
• disjoint chains and secret sharing

10
Tradeoffs

• Security increases with
• the number of disjoint paths
• the number of shares
• but these also increase cost
• Challenges
• Implement cheap secret sharing techniques
• Quantify the security achieved
• Find the right tradeoff for an assumed fraction
  of compromised nodes

11
Recent Experimentation

• Investigation of tradeoffs in the implementation
  of the Rijndael (AES) block cipher
• Version implemented
• 128 bit key / 128 bit blocks
• 10 rounds (11 round keys)
• Implementation variants
• Precomputation or on-the-fly computation of round
  keys (tradeoff speed vs. memory)
• C or CAssembler (speed vs. portability)

12
Round keys in AES

• Preexpansion
• Compute round keys once and store them (176
  bytes)
• Better if memory is available and many data
  encrypted with the same key K
• On-the-fly computation of round keys
• Need only store K0 and K10 (32 bytes)
• Better if many keys are used

13
Performance Comparison

• Experiment
• CipherTest.nc component from TinySec
• Encryption of 20000 blocks of 128 bits using the
  same key
• Using TinySec RC5 implementation instead of AES
• 64 bit blocks, 64 bit key, CAsm, preexpansion of
  round keys
• Run time 10s, code size 11504 bytes, RAM per
  key 104 bytes

14
Intrusion Detection

• Goals
• Detect compromised nodes (to remove them from
  chains)
• Detect other intrusions denial-of-service
  attacks, e.g., attempts to drain power
• Cryptography is ineffective against these

15
Intrusion Detection Approach

• Develop models of attacks and establish event
  monitoring requirements
• What must be monitored?
• How to collect and distribute the data?
• Develop diagnosis methods
• Identify the source of the attack if possible
• Possible responses
• Avoid nodes that are considered compromised
• Hibernation to counter DoS or power-draining
  attacks
• Send alerts to other motes or base station

16
Design of IDS for Motes

• Two-tiered detection strategy
• Low-overhead monitoring for nodes to detect
  external attacks
• Mutual monitoring among neighbor nodes
• Specification-based intrusion detection Ko et
  al. 94, 97
• Develop specifications to characterize the
  expected behavior of applications
• Detect activities that violate these
  specifications
• Potential to detect unknown attacks
• Used for detecting access violations and invalid
  call sequences

17
Local Detection

• Applying specification-based approach to resource
  consumption
• Specify the communication behavior of an
  application
• Monitor messages sent and received
• Detect violations (e.g., receiving many messages
  within a time window in a power draining attack)

18
Mutual Monitoring

• Neighbor nodes exchange status messages
  periodically
• If a node receives no status message from a
  neighbor for a certain period of time, it
  generates an alert
• Can detect additional DoS attacks such as
  physical attacks against motes

19
Goals and Success Criteria

• Planned Demo on Berkeley OEP
• Application scenario
• Perimeter monitoring application (optical
  sensors)
• 15-20 motes one base station
• Goals
• Demonstrate key-distribution in the presence of
  compromised motes
• Demonstrate intrusion detection and response
  (both external attacks and misbehaving motes)
• Evaluation Metrics
• How many compromised motes can be tolerated?
• Setup time for bootstrapping and key exchange
• Detection time
• Computation, memory, and communication overhead

20
Project Plans

• Bootstrapping protocol
• Under development
• Planned prototype March 2003
• Intrusion detection
• Develop specification of mote behavior in demo
  application
• Implement prototype (planned for June 03)
• Chaining-based key distribution
• Baseline prototype for demo
• Advanced prototype and tradeoff analysis for later

21
Schedule
22
Technology Transition

• Distribution of software
• Open source distribution
• Compatible with TinyOS and TinySec
• Other possible transfer opportunities
• With other SRI teams working on Ad Hoc wireless
  networks