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

1
AriadneA Secure On-Demand Routing Protocol for
Ad Hoc Networks
2
Attacker Model

• We consider only active (transmitting) attackers
• Two kinds of active attackers
• Active-x-y is an attacker with y nodes
  (transmitters and receivers) and keys from x
  legitimate nodes

Active-1-2
3
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

4
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

5
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

6
Ariadne Pick Your Minotaur

• Three assumptions no one wants to make
• Setting up O(n2) keys
• Asymmetric cryptography
• Time synchronization
• Ariadne is compatible with three forms of key
  setup, each with one undesirable assumption
• Pairwise shared keys
• Digital signatures and asymmetric key setup
• Time-delayed broadcast authentication (TESLA)

7
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

8
Ariadne Security Mechanisms

• Thwarting excessive ROUTE REQUEST floods
• Preventing Hop Drop in ROUTE REQUESTs
• Securing Route Discovery
• Securing Route Maintenance

9
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
10
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
• If nodes are time-synchronized
• Also tie the chain element to time (e.g., element
  5 is can only be used between 1140am and
  1141am)
• An Active-x-y attacker can initiate Route
  Discoveries at only y times the maximum rate
  allowed for any single node

11
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

12
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
S
A
B
D
C
13
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

S
A
B
D
C
14
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)

S
A
B
D
C
15
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)

S
A
B
D
C
16
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

S
A
B
D
C
17
Route Authentication with Shared Keys

• 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

S
A
B
D
C
18
Route Authentication with Shared Keys

• 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

• 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

S
A
B
D
C
19
Route Authentication with Shared Keys

• 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

• 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

S
A
B
D
C
20
Route Authentication with Shared Keys

• 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

• 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

S
A
B
D
C
21
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
• Subsequent secret keys also reveal earlier keys
• Secret keys are verifiable, given senders public
  value

MAC must be received before the secret key is
scheduled to be disclosed
22
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
23
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 nodes key and MAC

S
A
B
D
C
24
Route Authentication with TESLA

• Each node forwarding a REQUEST includes a
  MACcomputed using a TESLA key

S
A
B
D
C
25
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

S
A
B
D
C
26
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

S
A
B
D
C
27
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 nodes key and MAC

S
A
B
D
C
28
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 improves protocol
  performance

29
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
• Dont assign a route a 0 probability of being
  used
• Short-term Denial-of-Service would otherwise
  result in permanent crippling of that route

30
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 dont simulate
• Malicious nodes
• Multipath routing
• Optimizations to Ariadne

31
Overhead
Byte Overhead
Packet Overhead
Authentication overhead increases Ariadnes byte
overhead
Ariadne performs better better tolerance of
short-term broken links than Crippled DSR
32
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
33
Much More in the Paper

• Discussion of related work
• More detailed discussion of assumptions
• A more complete overview of TESLA
• 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

34
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

35
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.ri
ce.edu/