1 / 26

Ariadne: A Secure On-Demand Routing Protocol for Ad Hoc Networks

Ariadne: A Secure On-Demand Routing Protocol for Ad Hoc Networks. X. C. A. D. B. E. F. Active-1-2. Attacker Model. We consider only active (transmitting) attackers Active-x-y is an attacker with y nodes (transmitters and receivers) and keys from x legitimate nodes. Assumptions.

knox
Download Presentation

Ariadne: A Secure On-Demand Routing Protocol for Ad Hoc Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ariadne:A Secure On-Demand Routing Protocol for Ad Hoc Networks

  2. X C A D B E F Active-1-2 Attacker Model We consider only active (transmitting) attackers • Active-x-y is an attacker with y nodes (transmitters and receivers) and keys from x legitimate nodes

  3. Assumptions • We ignore security at Medium Access and PHY layers: • PHY: spread-spectrum, directional antennas, etc. • Simpler Medium Access Control protocols are harder to attack, and other work is ongoing • Reasonable key distribution: • Can distribute public key for each node • Shared keys between communicating nodes • Nodes need not be powerful (e.g., PDAs): • Allows protocol to be more general

  4. Ariadne Key Setup Ariadne can use any of three forms of key setup: • Pairwise shared keys: • (Requires setting up O(n2) keys) • Digital signatures and asymmetric key setup • (Uses expensive asymmetric cryptography) • Time-delayed broadcast authentication (TESLA) • (Requires time synchronization) Ariadne requires only one of these, each appropriate for different circumstances

  5. Ariadne Properties • Operates entirely on-demand • Similar to DSR, using source routing: • ROUTE REQUESTs, ROUTE REPLYs, and ROUTE ERRORs • Secure against all known Active-0-y and Active-1-1 attacks • Can use together with packet leashes to secure against many Active-x-y attacks • When attacker is located on too many routes: • All routes returned in ROUTE REPLYs include attacker • Could then piggyback data packet on ROUTE REQUEST • Equivalent to flooding

  6. Ariadne Security Mechanisms • Thwarting excessive ROUTE REQUEST floods • Preventing “Hop Drop” in ROUTE REQUESTs • Securing Route Discovery • Securing Route Maintenance

  7. ROUTE REQUEST Flooding Attack On-demand protocols discover routes using flooding An attacker can flood the network with this mechanism: • A solution: rate-limit Discoveries at forwarding nodes • But attacker can forge Discoveries from other nodes ROUTE REQUEST “from A” ROUTE REQUEST “from B” ROUTE REQUEST “from C” X ROUTE REQUEST “from D” ROUTE REQUEST “from E”

  8. Preventing ROUTE REQUEST Floods • Our Solution: Use a one-way hash chain: • Disclose a new element per Discovery (like S/KEY) • Authenticates the true source of the ROUTE REQUEST • Each element can only be used once • An Active-x-y attacker can initiate Route Discoveries at only y times the maximum rate allowed for any single node

  9. Hop Drop Attack As in DSR, Ariadne accumulates in the ROUTE REQUEST packet the list of hops traversed An attacker could drop or alter nodes on this list S S, A S, B S, B, C A B C S D

  10. h0 = MAC(KSD, request id) Preventing Hop Drop • Initiator S and Target D share (or generate) KSD • Initiator S adds h0 = MAC(KSD, request id) to REQUEST • (MAC = Message Authentication Code) A B C S D

  11. h1 = H(A || h0) h2 = H(B || h1) h3 = H(C || h2) Preventing Hop Drop • Initiator S and Target D share (or generate) KSD • Initiator S adds h0 = MAC(KSD, request id) to REQUEST • (MAC = Message Authentication Code) • Each hop computes hi = H(node address || hi-1) A B C S D

  12. D h3 = H(C || H(B || H(A || MAC(KSD, request id)))) h3 = H(C || h2) Preventing Hop Drop • Initiator S and Target D share (or generate) KSD • Initiator S adds h0 = MAC(KSD, request id) to REQUEST • (MAC = Message Authentication Code) • Each hop computes hi = H(node address || hi-1) • Target D can compute h0 and reconstruct each hi • Attack would be detected at the target using KSD A B C S D

  13. REQUEST(S, D, h3, MAC(KAD, p), MAC(KBD, p), MAC(KCD, p)) REQUEST(S, D, h2, MAC(KAD, p), MAC(KBD, p)) REQUEST(S, D, h1, MAC(KAD, p)) REQUEST(S, D, h0) Route Authentication with Shared Keys • If you have shared keys between all pairs of nodes: • Each node forwarding a REQUEST includes a MACcomputed with the key it shares with the target • This MAC is included in a MAC list, along with the node list as in a normal REQUEST packet If using shared keys between all pairs of nodes: • Each node forwarding a REQUEST includes a MACcomputed with the key it shares with the target • This MAC is included in a MAC list, analogous to the node list in a normal REQUEST packet A B C S D

  14. REPLY ((S,A,B,C,D), MAC(KSD, (S,A,B,C,D)) REQUEST(S, D, h3, MAC(KAD, p), MAC(KBD, p), MAC(KCD, p)) Route Authentication with Shared Keys • If you have shared keys between all pairs of nodes: • Each node forwarding a REQUEST includes a MACcomputed with the key it shares with the target • This MAC is included in a MAC list, along with the node list as in a normal REQUEST packet • Target checks MAC for each hop • If valid, target returns ROUTE REPLY to the initiator If using shared keys between all pairs of nodes: • Each node forwarding a REQUEST includes a MACcomputed with the key it shares with the target • This MAC is included in a MAC list, analogous to the node list in a normal REQUEST packet A B C S D

  15. TESLA Background • Efficient broadcast authentication • Relies on time synchronization • Authentication requires two pieces of information: • MAC of the data with a secret key • The secret key used to compute the MAC • Each secret key has a scheduled disclosure time • Time synchronization ensures security: • The “TESLA Security Condition”: • Behaves as if it were a public key protocol MAC must be received before the secret key is scheduled to be disclosed

  16. REQUEST(S, D, h2, MAC(KA, p), MAC(KB, p)) REQUEST(S, D, h3, MAC(KA, p), MAC(KB, p), MAC(KC, p)) REQUEST(S, D, h0) REQUEST(S, D, h1, MAC(KA, p)) Route Authentication with TESLA • Each node forwarding a REQUEST includes a MACcomputed using a TESLA key A B C S D

  17. REPLY(S, D, MAC(KA, p), MAC(KB, p), MAC(KC, p), MAC(KSD, (MAC(KA, p), MAC(KB, p), MAC(KC, p))) Route Authentication with TESLA • Each node forwarding a REQUEST includes a MACcomputed using a TESLA key • Target checks TESLA security condition for each hop, then authenticates REPLY to avoid modification A B C S D

  18. REPLY(S, D, MAC(KA, p), MAC(KB, p), MAC(KC, p), MAC(KSD, (MAC(KA, p), MAC(KB, p), MAC(KC, p)), KC, KB) REPLY(S, D, MAC(KA, p), MAC(KB, p), MAC(KC, p), MAC(KSD, (MAC(KA, p), MAC(KB, p), MAC(KC, p)), KC, KB , KA) REPLY(S, D, MAC(KA, p), MAC(KB, p), MAC(KC, p), MAC(KSD, (MAC(KA, p), MAC(KB, p), MAC(KC, p)), KC) Route Authentication with TESLA • Each node forwarding a REQUEST includes a MACcomputed using a TESLA key • Target checks TESLA security condition for each hop, then authenticates REPLY to avoid modification • Each intermediate node buffers packet until it can disclose its TESLA key, then includes key in the REPLY A B C S D

  19. REPLY(S, D, MAC(KA, p), MAC(KB, p), MAC(KC, p), MAC(KSD, (MAC(KA, p), MAC(KB, p), MAC(KC, p)), KC, KB , KA) Route Authentication with TESLA • Each node forwarding a REQUEST includes a MACcomputed using a TESLA key • Target checks TESLA security condition for each hop, then authenticates REPLY to avoid modification • Each intermediate node buffers packet until it can disclose its TESLA key, then includes key in the REPLY • Source verifies each node’s key and MAC A B C S D

  20. Authenticating ROUTE ERRORs • Attacker could send forged ROUTE ERRORs to break routes that are in use • Solution: Require ROUTE ERRORs to be authenticated • If using pairwise shared keys: • Authenticate ERROR to original source of packet • If using delayed broadcast authentication: • Include broadcast authentication in ERROR using a TESLA key • Also include latest TESLA key you can disclose • ERROR is buffered until appropriate key disclosed • Delayed authentication actually improvesprotocol performance

  21. Secure Route Maintenance • ROUTE ERRORs can be only an optimization • Malicious nodes might refuse to send them • To ensure Ariadne does not persistently use non-working paths: • Sources may use multipath routing • Each packet is acknowledged end-to-end,preferably using the reverse path • Sender more often chooses routes that successfully deliver packets • Don’t assign a route a 0% probability of being used: • Short-term Denial-of-Service would otherwise result in permanent crippling of that route

  22. Simulation Methodology • We simulate Ariadne with TESLA key setup: • Compared Ariadne with DSR and “crippled” DSR(without DSR optimizations not included in Ariadne) • 20 CBR sources each sending 4 packets per second • Each packet has 512 bytes of data • Random Waypoint mobility, max speed 20 m/s • Results show 60 runs with 95% confidence intervals • We don’t simulate: • Malicious nodes • Multipath routing • Optimizations to Ariadne

  23. Overhead Byte Overhead Packet Overhead Authentication overhead increases Ariadne’s byte overhead Ariadne performs better: better tolerance of short-term broken links than Crippled DSR

  24. Packet Delivery Ratio and Latency Packet Delivery Ratio Latency Equivalent to Crippled DSR Ariadne does less Route Discoveries than Crippled DSR, avoids waiting for a route

  25. Much More in the Paper… Several additional research contributions: • More detailed attacker model • Additional mechanisms to limit excessive ROUTE REQUEST flooding • A novel low-effort Denial-of-Service attack onIEEE 802.11 DCF • Using a KDC to bootstrap the network (each node needs only share a key with the KDC) • Using asymmetric cryptography for authenticationin Ariadne • Some route caching optimizations • Techniques for thwarting more sophisticated attacks • A detailed security analysis of Ariadne

  26. Conclusions • Ariadne achieves our design goals: • It is efficient: low CPU and network overhead • It is secure: resilient to compromised nodes • It operates entirely on-demand • Source routing makes security easier: • Source can circumvent a potentially malicious node • Source can authenticate each forwarding node • Relative to previous work, Ariadne is either: • More secure, more efficient, or more general For more information, see http://www.monarch.cs.rice.edu/

More Related