sensec: scalable emulation of sensor network security
Post on 23-Jan-2016
38 Views
Preview:
DESCRIPTION
TRANSCRIPT
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.)
top related