SenSec: Scalable Emulation of Sensor Network Security

1. SenSec: Scalable Emulation of Sensor Network Security Yi-Tao Wang, Rajive Bagrodia UCLA Computer Science Department DAWN MURI Meeting October 6, 2009

2. Motivation • Security is an on-going process and any secure system should undergo rigid testing • Important to test sensor network security with realistic environments and attacks • Increased complexity of deployed sensor networks makes testing difficult • Current simulators are more focused on validating rudimentary behavior of sensor networks

3. Current Tools • Simulators (TOSSIM, EmTOS, etc) • Validates basic application behavior • Lacks detailed simulation models • Restricts accuracy and expressiveness of their simulations • Cannot evaluate applications in deployment conditions • Physical testbeds • Accurate • Lacks spatial and temporal scalability • Difficult to perform simulations under complex conditions • Can’t repeat simulations

4. SenSec Framework • Simulates sensor networks under attacks to evaluate • Vulnerability of network • Network Security Protocols (Encryption, Intrusion Detection Systems, etc.) • Effectiveness of new attacks • Runs unmodified TinyOS applications • Validate behavior • Optimize design parameters

5. SenSec Framework (cont.) • Leverages existing physical layer models in network simulators to provide more accurate simulations • Supports a diverse set of scenarios • heterogeneous networks • mobile data mules • multiple operating systems • Models for clock drift, battery, and sensing channel

6. SenSec Framework (cont.) • Composed of independent attack emulation and TinyOS emulation systems • Supports evaluation of attacks on emulated TinyOS applications or simulated nodes • TinyOS emulation added for higher fidelity between simulations and real-life deployment

7. TinyOS Emulation • Each sensor networknode can run anemulated TinyOSapplication • Override drivers in TinyOS to communicate with DES • TinyOS applications think DES is just another hardware platform

8. TinyOS Emulation (cont.) • Hardware interactions communicates with a CFP in the DES that: • Uses models to return values (i.e., get sensor readings) • Queue events in the DES (i.e., send packet)

9. TinyOS Emulation (cont.) • DES considers emulated TinyOS applications asabstract nodes • Applications run as • Threads for fasterexecution and betterscalability • Processes so moreone application can be emulated in the same simulation

10. Control Flow of TinyOS application • DES boots eachemulated application • Application executesuntil context switch • Replaced components inTinyOS (squares)interact with CFPs (roundedsquares) in the DES • When the application has finished executing for the current time step, it will context switch (italics) back to the DES until the next time step

11. Models: Clocks Drift • From Stochastic model estimation of network time variance. White Paper, Symmetricom. f = fnom + ∆f0 + a (t – t0) + ∆fn(t) + ∆fe(t) • f – frequency of inaccurate clock • fnom – nominal frequency • t0 – starting time • a – aging rate • ∆fn(t) – noise term • ∆fe(t) – environmental term

12. Models: Battery • Two models • Simple: deduct amount of power for every transaction (transmission, reception of a packet, carrier sensing) • Non-linear discharge (from D. Rakhmatov and S. Vrudhula. Energy management for battery-powered embedded systems.) • If I(t) is the current drawn from the battery at time t, then battery capacity used after time T is

13. Models: Sensing Channel • Diffusive • Assigns value at each space-time coordinate • User defines values at specific coordinates and bilinear spine interpolation is used to calculate the values at the other points • Dynamic environment can be defined with 4 corner points • Mobility • Triggered when targets are in range • Random • Random value between user defined min and max

14. Accuracy of TinyOS emulation • Compared results from SenSec to those from Harvard’s MoteLab and other TinyOS emulators • Application routes periodic packets from one sender to one receiver

15. Accuracy of TinyOS emulation (cont.) • Other tools are unable to match the accuracy due to less accurate models or lack of certain models • Although they can be extended with more accurate models, it’s more efficient to leverage existing models in network simulators

16. Attack Emulation • Attack Emulation System • Parses defined attacks from user or attack repository • Validates attack (i.e., attacking existing nodes) • Based on the current state of the simulation, it generates a sequence of events that is fed into the DES for each time step

17. Attack Emulation (cont.) • Attack Repository • Organize test cases of attacks • Accommodate future scenarios • Stored cases can have parameters for changes in attack behavior (i.e., timing) • Object-oriented hierarchy facilitate creation of new attacks and composition of existing attacks

18. Attack Emulation (cont.) • Attack Handlers • Interface between the DES and the Attack Emulation System (AES) • Feeds in the current state of the system • Translates the desired events from the AES and queues them in the DES

19. Attack Emulation (cont.) • Limits the definition of attacks to realistic behaviors • Can only control the behavior of the attacker and compromised nodes • Can automatically change any node to a compromised node • When unconcerned about the initial compromise process • Compromised node can be simulated or running emulated TinyOS code

20. Attack Models • Supports attacks at the network layer (no jamming) • Current models: Repetition attack, Delay attack, Data alteration, Packet spoofing, Selective Forwarding, Sybil, Wormhole, DDoS, HELLO flooding • Many attacks contain common elements which can be modularized and used by multiple attacks without repetition

21. Case Study: Security of Routing Protocols • Evaluate the security of two routing protocols used in TinyOS: • Multihop: Creates routing trees based on the hop count to the base station • MintRoute: Creates routing trees based on the link quality and only changes routes if a new route is 75% better than the current route

22. Case Study: Security of Routing Protocols (cont.) • Setup • 7 x 7 grid • Each node can only hear its 2 – 8 neighbors • The base station is at the top left • Simulated Attacks • Selective forwarding: attacker drops some packets • Sinkhole: attacker sends good link quality • HELLO flooding: attacker pretends to the base station • Sybil: attacker pretends to be more than one node to fill up neighbors’ routing tables • Variations of Sinkhole and Hello flooding that send spoofed messages that show poor neighbor quality

23. Case Study: Security of Routing Protocols Results • Selective forwarding poses minimal risk since nodes switch away as soon as it starts dropping too many packets • Sybil works well in both cases but requires more packets than most of the other attacks

24. Case Study: Security of Routing Protocols Results (cont.) • HELLO flooding works relatively well in both cases but only if the attacker keeps convincing neighbors that the real base station has a poor quality • A vulnerability that is easily exploited in both protocols is the use of old sequence numbers to determine poor link quality

25. Case Study: Security of Routing Protocols Results (cont.) • All attacks work better the closer they are to the base station because they capture larger subtrees • Protocols that don’t change links easily (MintRoute) are naturally more resistant to HELLO 1 and Sinkhole 1 attacks

26. Case Study: Security of Routing Protocols Results (cont.) • SenSec’s benefits • Detailed evaluation of sensor networks under controlled and repeatable environments • Support for unmodified implementations of protocols before deployment • Easily identify vulnerabilities design issues and environment conditions

27. Future Work • Evaluation of existing sensor network security protocols • Test performance under various scenarios • Identify common strength and weaknesses between protocols • Create improved security measures (IDS, encryption schemes, etc.) • Emulation of specific hardware (i.e., Mica2, tmote sky, etc.)