Secure Routing in Sensor Networks: A Clean-Slate Approach

1. Secure Sensor RoutingA Clean-Slate Approach Bryan Parno, Mark Luk, Evan Gaustad, Adrian Perrig Carnegie Mellon University

2. Sensor Networks • Thousands of nodes, each with: • A CPU and ~10 KB of RAM • A radio • Sensors (e.g., heat, motion, sound) • Limited power • Communicate via multi-hop routing • Applications: burglar alarms, emergency response, industrial uses All require secure routing!

3. Attacks on Routing • Inject incorrect routing information or alter setup/update messages • Compromise sensors • Provide malicious routing data/messages • Suppress (selectively) routing messages • Specific attacks: • Blackhole • Wormhole • Replication • Denial of Service • Sybil • Rushing • Slander • Framing

4. Consequences of Routing Attacks • Controlling routing allows the attacker to control the network’s communication • Can view, modify, and/or drop messages • Create loops to exhaust legitimate nodes • Prevent or subvert proper network functionality

5. Techniques for Secure Routing • Prevention • Harden protocols by restricting participants’ actions • Typically employs cryptography • Only forestalls known attacks • Detection & Recovery • Monitor behavior for malicious activity • Eliminate malicious participants • Must be able to distinguish anomalous behavior and accurately assign blame • Resilience • Maintain availability even under unpredicted attacks • Provide graceful performance degradation

6. Previous Work • Sensor routing • Most assume trusted environment • INSENS only applicable to certain topologies • SIGF requires GPS • Other secure routing protocols • Typically rely on a single technique • Prevention: S-BGP, Ariadne • Detection & Recovery: Watchdog, Pathrater, Secure Traceroute • Resilience: INSENS • Inappropriate for resource-constrained sensor nodes • Require PKI or excessive amounts of memory, computation or communication

7. Goals • Start from a clean-slate • Incorporate all three security techniques • Prevention, detection & recovery, and resilience • Provide highly secure, highly available point-to-point routing • Necessary in many applications, e.g., Geographic Hash Tables (GHTs), key establishment, etc. • Minimize resource utilization

8. Outline • Introduction • Overview and Assumptions • Address and Routing Setup • Forwarding • Detection and Recovery • Simulation and Implementation

9. Our Routing Protocol Architecture • Establish routing tables and network addresses • Use prevention techniques to thwart active attackers • Detect and recover from attempts to deviate from the protocol or to launch additional attacks • Apply resilient routing techniques to forward packets • Uses the securely established routing tables and network addresses

10. Assumptions • Network authority (NA) uses a public/private keypair {KNA , K-1NA} • Each sensor node preloaded with: • Network authority’s public key KNA • Unique IDx • Certificate: Sig(K-1NA, IDx) • Signature scheme optimizes for verification • Intended for networks of primarily stationary sensors

11. Outline • Introduction • Overview and Assumptions • Address and Routing Setup • Forwarding • Detection and Recovery • Simulation and Implementation

12. Node Routing ID Address Table A 0.1 B 0.0 C 1.1 D 1.0 Address and Route Setup Overview • Goal: • Assign a unique network address to each node • Populate each node’s routing table • Accomplished with a recursive grouping algorithm • Initially, each sensor constitutes its own group • Groups repeatedly merge until all nodes belong to same group • Each time a node’s group merges, the node adds one bit to its network address and one entry to its routing table

13. Recursive Grouping Algorithm • Groups act in an asynchronous, distributed fashion • Each group: • Collects information about its neighbors • Proposes to merge with smallest neighboring group • Based on number of nodes in the group • Ties broken based on group ID • This metric keeps addresses and routing tables small • Mutual proposal triggers merge • Entire process is deterministic for a given topology • Limits the damage an attacker can inflict

14. Recursive Grouping Example

15. Calculating Network Addresses • Assume G and G’ decide to merge • Each node in G independently extends its network address by one bit based on: • Nodes in G’ make similar changes

16. Network Addresses Formation

17. Populating Routing Tables • Assume G and G’ decide to merge • Each node in G records the neighbor from whom it heard about G’ in its current routing table slot D G G’ G

18. Sample Routing Table 1.1.0

19. Outline • Introduction • Overview and Assumptions • Address and Routing Setup • Forwarding • Detection and Recovery • Simulation and Implementation

20. Forwarding • Basic forwarding similar to area-style forwarding • Given a destination network address route towards node with longest matching prefix • Path length in logical hops bound by log(n) • A logical hop may require several physical hops

21. Forwarding Example Message from 1.1.0 to 0.0.0 1.1.0 0.1.1 0.0.1 1.1.0

22. Outline • Introduction • Overview and Assumptions • Address and Routing Setup • Forwarding • Detection and Recovery • Threats • Detecting Grouping Deviations • Eliminating Malicious Nodes • Simulation and Implementation

23. Threats • Compromised nodes may lie about group size or ID to subvert route setup • Compromised nodes may claim multiple IDs or try to simultaneously group with several other nodes

24. Detecting Grouping Deviations • Maintain a Grouping Verification Tree (GVT) for each group during recursive grouping • Prevents attacker from lying about group ID or size • Based on a hash tree construction • Before two groups merge, they verify each other’s GVT • Integrity of the GVTs insures integrity of the recursive grouping algorithm • Final GVT covers all nodes in the network • Can be used to authenticate any node’s network address

25. Background: Hash Trees • Employ a one-way hash function H: {0,1}*→{0,1}ρto create one-way data structures • The Merkle Tree is one such data structure • Each internal node calculated as: Parent = H(ChildL || ChildR) • Authenticates a leaf node given the root value and nodes along the path to the root

26. Group ID Computation • Assume G and G’ decide to merge • Each node in G independently calculates the new group ID as:

27. GVT Formation • One GVT per group • GVT leaves are IDs of nodes in the group • Internal nodes represent intermediate group IDs • Each node maintains information about its branch of the GVT • Specifically, the group ID and size of each merge partner

28. λ GVT Verification • Before merging, group G verifies the GVT for G’ (and vice versa) • G’ announces its group ID (and size) • Group G sends a challenge value to G’ • The challenge uniquely selects a node in G’ • Chosen node sends its certificate and GVT information to G • Nodes in G verify the GVT values Responder Challenger

29. Eliminating Malicious Nodes • Legitimate nodes use the Honeybee mechanism to eliminate malicious nodes • To revoke malicious node M, legitimate node L broadcasts: • IDL, IDM, and a signature • Legitimate nodes revoke M and L • Prevents a compromised node from revoking more than one legitimate node

30. Outline • Introduction • Overview and Assumptions • Address and Routing Setup • Forwarding • Detection and Recovery • Simulation and Implementation

31. Simulations • Comparison against Beacon Vector Routing (BVR) protocol [NSDI 2005] • Optimized for efficiency • No security included • Experimental Setup: • 500 nodes, random deployment, DOI radio model • Summary of Results: • Our routing success rate: 100% • Paths longer than shortest path • Distributes overhead evenly throughout network • Better than BVR, even in topologies with voids

32. Metric: Path Stretch • Stretch = Protocol Path Length / Optimal Path Length • Optimistic for BVR: does not include failed BVR routes

33. ~ 168,000 messages Metric: Load Distribution - Uniform

34. ~ 26,000 messages Metric: Load Distribution - Irregular

35. Implementation • Developed in NesC on TinyOS using Telos sensor nodes • Source code to be available soon • Challenges overcome: • Reliable Broadcast • Asynchronicity • Asymmetric Links • Ongoing work to expand the current testbed

36. Other Contributions • Techniques for resilient forwarding • Duplicate detection • Proofs of performance and correctness • Implementation details

37. Conclusions • Secure sensor routing is an important and difficult problem • Most previous techniques assume a trusted environment or use a single security technique • We design a protocol incorporating all three security techniques that still compares favorably to insecure protocols

38. Thank you! parno@cmu.edu