1

Intrusion Tolerance for NEST

Bruno Dutertre, Steven Cheung

SRI International

NEST PI Meeting

January 29, 2003

2

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: bruno@sdl.sri.com, cheung@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

Problem and Challenge

Impact

New Ideas

Schedule

Build low-cost key-management services for sensor networks:Localized authentication protocols for

bootstrappingChains of trusted intermediaries for key

establishment between remote nodesSecret sharing + disjoint paths for tolerating

compromised nodes Intrusion detection for motes:

Detect denial-of-service attacksDetect misbehaving nodes

Intrusion Tolerance for NEST

Intrusion-tolerant key-distribution services for large networks of microsensors

2QFY03: Design Bootstrapping Protocols3QFY03: Baseline Intrusion Detection4QFY03: Design Intrusion-tolerant Key-Distribution Protocols1QFY04: Experimental Validation and Demo1QFY05: Integration and Final Demo

FY03 FY04 FY05

Enable deployment of sensor networks in hostile environments

Support other security services for wireless sensor networks:Confidentiality and integrity of communicationRobust NEST services

Self organizingprotocols

Low cost cryptography

Detect/respondto DoS attacks

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.

abK

abK

9

Leveraging Local Trust

• To establish keys between distant nodes:– use chains of trusted intermediaries

• To tolerate compromised nodes:– disjoint chains and secret sharing

A

B C

D

E

abKbcK

cdK

deKaeK

ceK

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 C+Assembler (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

0K 1K 9K 10K

KKey expansion

Round keys

CiphertextPlaintext

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, C+Asm, preexpansion of round keys– Run time: 10s, code size: 11504 bytes, RAM per key: 104 bytes

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

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