Hao Yang, Fan Ye, Yuan Yuan, Songwu Lu, William Arbaugh (UCLA, IBM, U. Maryland) MobiHoc 2005

1. Toward Resilient Security in Wireless Sensor Networks. Hao Yang, Fan Ye, Yuan Yuan, Songwu Lu, William Arbaugh (UCLA, IBM, U. Maryland) MobiHoc 2005

2. Outline • Introduction and Background • On resiliency of existing solutions • LBRS Design • Analysis and Simulation Results • Discussions and Conclusions

3. Introduction • Target problems: • Compromised nodes inside attacks Report fabrication attacks • The compromised nodes forge nonexistent events that cause both false alarms and resource waste • Existing solution and their problem • Multiple parties endorse an legitimate event; en-route filtering. • Problem: Threshold breaks down. • Proposed approach: use location-based information to achieve resilience.

4. Assumptions • A Large scale sensor network that monitors a vast geographic terrain. • Size and shape of the terrain are known a priori • Sensor nodes are uniformly and randomly deployed in the terrain. • Once deployed, each node can obtain its geographic location via a localization scheme. • One resourceful sink with high survivability. • Sink knows all keys

5. Set ofsymmetric keys:k1, k2, k3… General En-route Filtering Framework • A node storesa set ofsymmetric keys. it usesone key to generate a Message Authentication Code (MAC) attached to an event report. It also usesits keys to verify the report forwarded to it. Each key has a unique index.

6. 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 occurrence: • A legitimate report must carry m distinct MACs. • Multiple nodes sense the event and collaboratively generate (one or more) reports with m MACs. | index1 | MAC1 Report | index3 | MAC3 | index4 | MAC4

7. Received Report Check if it has m MACs No No Check if it can verify the MACs Drop Forward packet Is the MAC valid? Yes No General En-route Filtering Framework • Intermediate nodes:

8. General En-route Filtering Framework • Sink verification: Sink knows all keys, it can verify every MAC. • Sink is the final guard

9. Outline • Introduction and Background • On resiliency of existing solutions • LBRS Design • Analysis and Simulation Results • Discussions and Conclusions

10. Interleaved Hop-by-Hop Authentication (IHA) • Design parameter: m • Each sensing cluster contains 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.

11. Interleaved Hop-by-Hop Authentication (IHA) An Application Scenario

12. IHA Overview • Node initialization and deployment • Each node has a unique id and should establish a pairwise key with each of its neighbors • Association discovery • Each node discovers the ids of all associated nodes • Report endorsement • t+1 nodes collaboratively generate a report when an event is detected • Each participating node generates two MACs, one with the key shared with the BS, and one with the key shared with its upper associated node • CH head collects all MACs and attaches them to the report, forwarding to the BS

13. IHA Overview • En-Route Filtering • Forwarding node verifies the MAC computed by its lower association node; if success, it removes the MAC and computed a new one with the key shared with its upper association node • Base Station Verification • BS contains a unique shared key with each sensor

14. Summary of IHA • IHA verifies the reports in a deterministic and hop-by-hop fashion • Two major drawbacks in resiliency • The protection breaks down when more than t nodes along the path are compromised • IHA relies on deterministic key sharing, which results in high overhead due to dynamism • Higher overhead to detect association nodes • No definition on key establishment

15. Statistical En-route Filtering (SEF) • Global key pool is divided into m partition. • Each node pre-loads with a few keys randomly chosen from a single partition • SEF is probabilistic • When an event occurs, detecting nodes jointly endorse the report with m MACs, each using a key in a different partition. • SEF assigns keys to nodes in a way that any intermediate node is able to verify the report with certain probability • Threshold: attackers obtain keys from m partition.

16. Outline • Introduction and Background • On resiliency of existing solutions • LBRS Design • Analysis and Simulation Results • Discussions and Conclusions

17. Location-Based Resilient Security (LBRS) • Terrain is divided into geographic grids and each cell is bonded 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 of them.

18. Location-Based Resilient Security (LBRS)

19. 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 SEF and IAH. • Two more new checking: • All m distinct MACs should be bonded to one cell. • Location attached in the report consistent with the location of MACs

20. Location-binding key generation • Location-binding key generation: The terrain is divided into geographic grids and each cell is bounded with L keys. • How to construct a grid? • How to derive keys based on the location information in a computationally efficient manner?

21. How to construct a grid • A virtual square grid is 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

22. 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() that is a one-way hash function. (Xi,Yj) is the location of the cell.

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

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

25. Location-guided key selection

26. Benefits of LBRS • Randomized multiple compromised nodes are difficult to compromise a cell (oblivious attacks). • Damage is bonded to some local cells (smart attacks). • Trade off between storage and filtering power • Location-guided key selection can reduce the keys stored on one node and still achieve reasonable filtering power.

27. Outline • Introduction and Background • On resiliency of existing solutions • Design • Analysis and Simulation Results • Discussions and Conclusions

28. Parameter settings

29. Analysis—Filtering Effectiveness • One node compromised, with a distance to the BS d0 • BS is in the center of the circular terrion • Detection Ratio: the percentage of forged reports being detected. Should be close to one. • Filtering Position: the number of hops a forged report can traverse before being dropped.

30. Analysis—Filtering Effectiveness

31. Analysis—Key Storage Overhead

32. Simulation • Platform: own simulator by Parsec language • 30K nodes, 5Km x 5Km field, 100m x 100m cell. • Each simulation repeated 1000 times.

33. Simulation—Resiliency to random node compromise (oblivious) • Compromised nodes randomly scattered. How many cells will be compromised.

34. Simulation—Resiliency to random node compromise Nc = Number of compromised nodes

35. Simulation—Filtering Power Kc = number of compromised keys in a cell

36. Simulation—Delivery Ratio

37. Outline • Introduction and Background • On resiliency of existing solutions • Design • Analysis and Simulation Results • Discussions and Conclusions

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

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

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