360 likes | 488 Views
Toward Resilient Security in Wireless Sensor Networks . Hao Yang, Fan Ye, Yuan Yuan, Songwu Lu, William Arbaugh (UCLA, IBM, U. Maryland) MobiHoc 2005. Outline. Introduction and Background On resiliency of existing solutions Design Analysis and Simulation Results
E N D
Toward Resilient Security in Wireless Sensor Networks. Hao Yang, Fan Ye, Yuan Yuan, Songwu Lu, William Arbaugh (UCLA, IBM, U. Maryland) MobiHoc 2005
Outline • Introduction and Background • On resiliency of existing solutions • Design • Analysis and Simulation Results • Discussions and Conclusions
Introduction • Target problem: • Compromised nodes • Report fabrication attacks • Existing solution and their problem • Multiple parties endorse an legitimate event; en-route filtering. • Problem: Threshold breaks down. • Their approach: use location-based information to achieve resilience.
General Scenario • Large scale sensor network that monitors a vast geographic terrain. • Size and shape of the terrain is known a priori • Sensor nodes are uniformly randomly deployed to the terrain. • Once deployed, each node can obtain its geographic location via a localization scheme. • One resourceful sink.
Own keys:k1, … Others keys: k2, k3, k4, … General En-route Filtering Framework • Initial: A node store some keys, it use its own key to generate a Message Authentication Code (MAC) attached to an event report. It use others keys to verify the report forwarded to it. Each key has a unique index.
Report | index3 | MAC3 Report | index1 | MAC1 Report | index5 | MAC5 Report | index2 | MAC2 Report | index4 | MAC4 Report | index6 | MAC6 General En-route Filtering Framework • On event occur: A legitimate report must carry m distinct MACs. Multiple nodes sense the event and collaborate generate (one or more) reports with more than m MACs. | index1 | MAC1 Report | index3 | MAC3 | index4 | MAC4
Received Report Check if it has more than m MACs No No Check if it can verify the MACs Drop Forward packet Is the MACs valid? Yes No General En-route Filtering Framework • Intermediate nodes:
General En-route Filtering Framework • Sink verification: Sink knows every keys, it can verify every MACs.
Outline • Introduction and Background • On resiliency of existing solutions • Design • Analysis and Simulation Results • Discussions and Conclusions
Interleaved Hop-by-Hop Authentication (IHA) • Design parameter: m • Sensing cluster with at least m+1 nodes and a cluster head. • Along the path, two nodes that are m+1 hops away are associated by a pair-wise key. • Threshold: m.
Statistical En-route Filtering (SEF) • Global key pool is divided into m partition. • Each node pre-loaded with a few keys randomly chosen from a single partition. • When an event occurs, detecting nodes jointly endorse the report with m MACs, each using a key in a different partition. • Thershold: attackers obtain keys from m partition.
Outline • Introduction and Background • On resiliency of existing solutions • Design • Analysis and Simulation Results • Discussions and Conclusions
Location-Based Resilient Security (LBRS) • Terrain divided into geographic grid and each cell binded with L keys. • Each node stores one key for each of its sensing cells. • Each node randomly chosen a few remote cells based on location information as its verifiable cells, and store one key for each.
Location-Based Resilient Security (LBRS) • A legitimate report is jointly generated by detecting nodes, and should carries m distinct MACs. • Intermediate nodes and sink verification processes are similar to general framework. • Two more new check: • All m distinct MACs should bonded to one cell. • Location attached in the report consistent with the location of MACs
Location-binding key generation • Location-binding key generation: Terrain divided into geographic grid and each cell binded with L keys. • How to construct a grid? • How to derive keys based on the location information in a computationally efficient manner?
How to construct a grid • Construct a virtual square grid uniquely defined by two parameters: a cell size C, and a reference point (X0,Y0) (e.g., sink location). • Denote a cell by the location of its center, (Xi,Yj), such that
How to derive keys • Preload each node with: cell size C, reference (X0,Y0), master secret KI. • Once deployed, a node first obtains its geographic location through a localization scheme. • Derives keys during bootstrapping phase with • H() is a one-way hash function. (Xi,Yj) is the location of the cell.
Location-guided key selection • A node defines an upstream region based on location information and only forward packet for its upstream region. • After defined upstream region, for each cell in its upstream region, select it as a verifiable cell with probability • d is the node’s distance to the sink, Dmax is the max distance between network edge and sink
Location-guided key selection • How to select upstream region and accommodate node failures? • Designed to work with geographic routing protocol. • Upon moderate node failures, geographic routing protocol find a closer detoured paths . • Define beam width b. • Use b and d (distance to sink) to define upstream region.
Benefits • Damage is bonded to some local cells. • Randomized multiple compromised nodes are difficult to compromise a cell. • Location-guided key selection can reduce the keys stored on one node and still achieve reasonable filtering power.
Outline • Introduction and Background • On resiliency of existing solutions • Design • Analysis and Simulation Results • Discussions and Conclusions
Analysis—Filtering Effectiveness • One node compromised. • Detection Ratio: close to one. • Filtering Position:
Simulation • Platform: own simulator by Parsec language • 30K nodes, 5Km x 5Km field, 100m x 100m cell. • Each simulation repeated 1000 times.
Simulation—Resiliency to random node compromise • Compromised nodes randomly scattered. How many cells will be compromised.
Simulation—Resiliency to random node compromise • How many distinct keys compromised in cells Nc = Number of compromised nodes
Simulation—Filtering Power Kc = number of compromised keys in a cell
Outline • Introduction and Background • On resiliency of existing solutions • Design • Analysis and Simulation Results • Discussions and Conclusions
Discussion • Prototype implementation: could all these fit into sensor nodes?? • Platform: MICA2 • Code size: • 9358 bytes ROM, 665 bytes RAM • Execution time: 100x100 cells • Bootstrapping: 2.8 sec • MAC generation and verification: 10 ms
Discussion (Cont’) • Sensor deployment: • Location information is known? • Location information is required? • Routing • Upstream region estimation is designed to work with geographic routing protocols. • They found some non-geographic routing protocols (Directed Diffusion, GRAB) fit well with this model. • Require future study.
Conclusions • If location is a required information, embedded keys with locations seem to be obvious. • Upstream region model is a good way to reduce the key storage and still maintain the filtering power. • They did quite a bit of analysis and simulations to verify their claims. • Security setting is based on application scenario.