SenSec: Scalable Emulation of Sensor Network Security

Yi-Tao Wang, Rajive Bagrodia

UCLA Computer Science Department

DAWN MURI Meeting

October 6, 2009

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

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

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

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

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

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

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)

TinyOS Emulation (cont.)

DES considers emulated TinyOS applications asabstract nodes

Applications run as Threads for faster

execution and betterscalability

Processes so moreone application can be emulated in the same simulation

Control Flow of TinyOS application DES boots each

emulated application Application executes

until 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.)