Intrusion Tolerance
for NEST
NEST PI Meeting
January 29, 2003
Bruno Dutertre, Steven Cheung
SRI International
1
Administrative
• Project Title: Intrusion Tolerance for Networked Embedded Sys.
• PM: Vijay Raghavan
• PI: Bruno Dutertre and Steven Cheung
• PI phone # : (650) 859-2717, (650) 859-5706
• PI email: [email protected], [email protected]
• 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
2
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
3
Intrusion Tolerance for NEST
Problem and Challenge
Intrusion-tolerant key-distribution services for large
networks of microsensors
Self organizing
protocols
Low cost
cryptography
Detect/respond
to DoS attacks
Impact
Enable deployment of sensor networks in hostile
environments
Support other security services for wireless sensor
networks:
 Confidentiality and integrity of communication
 Robust NEST services
New Ideas
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
Schedule
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
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)
5
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
6
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
7
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 K ab for future
communication
• Possible drawback:
– Every device from S in communication range of A
and B can discover K ab. More robust variants are
possible.
8
Leveraging Local Trust
B
K ab
K bc
C
K cd
K ce
A
K ae
D
K de
E
• To establish keys between distant nodes:
– use chains of trusted intermediaries
• To tolerate compromised nodes:
– disjoint chains and secret sharing
9
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
10
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 C+Assembler (speed vs. portability)
11
Round keys in AES
K
Key expansion
K0
K1
K9
K 10 Round keys
Plaintext
Ciphertext
• 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
12
Performance Comparison
C version
On the fly
C version
Preexpansion
C+Asm
On the fly
C+Asm
Preexpansion
Run time
57 s
42 s
28 s
21 s
Code size
11226 bytes
10824 bytes
11869 bytes
11067 bytes
RAM per key
32 bytes
176 bytes
32 bytes
176 bytes
• 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, C+Asm, preexpansion of round keys
– Run time: 10s, code size: 11504 bytes, RAM per key: 104 bytes
13
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
14
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
15
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
16
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)
17
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
18
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
19
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
20
Schedule
21
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
22