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) , (650) PI Institution: SRI International Contract #: F 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 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 Intrusion Tolerance for NEST Intrusion-tolerant key-distribution services for large networks of microsensors 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 FY03 FY04 FY05  Enable deployment of sensor networks in hostile environments  Support other security services for wireless sensor networks:  Confidentiality and integrity of communication  Robust NEST services Self organizing protocols Low cost cryptography Detect/respond to 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.

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

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 Key expansion Round keys Ciphertext Plaintext

13 Performance Comparison Experiment: –CipherTest.nc component from TinySec –Encryption of 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: bytes, RAM per key: 104 bytes C version On the fly C version Preexpansion C+Asm On the fly C+Asm Preexpansion Run time57 s42 s28 s21 s Code size11226 bytes10824 bytes11869 bytes11067 bytes RAM per key32 bytes176 bytes32 bytes176 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) 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