1. SRDP: Securing Route Discovery in DSR
Jihye Kim and Gene Tsudik
Computer Science Department
University of California at Irvine
{Jihyek, D B
Good morning! I am Jihye Kim from UCI and I will talk about Securing Route Discovery Protocol in DSR. C H E S G F

2. Outline Introduction Secure Route Discovery Protocol (SRDP) Analysis
Conventional MACs
DH-based MACs
Accountable-Subgroup Multi-signatures (ASM)
Multi-signatures based on Gap Diffie-Hellman (GDH) Groups
Sequential Aggregate Signatures (SAS)
Analysis
Conclusion
University of California, Irvine

3. Introduction MANET Characteristics Dynamic Source Routing (DSR)
No fixed infrastructure and node mobility
Traditional routing protocol cannot be used.
Dynamic Source Routing (DSR)
Source obtains information of all nodes along a path to the destination on-demand.
Basic Operations
Route Discovery
Core function of DSR we will deal with.
Data routing
Route Maintenance, etc.
MANET, mobile ad-hoc network is a very attractive solution for ubiquitous computing because it does not require any fixed infrastructure to communicate with a remote host. Instead neighbors between communicating nodes should forward packets as a router. However, mostly due to mobility in MANET we cannot simply use traditional routing protocols.
Dynamic Source Routing (DSR) is an on-demand routing protocol for a source to get a path to a destination.
DSR consists of basic operations such as route discovery, data routing, route maintenance, and so on.
Among these operations, route discovery is a prerequisite core function of DSR. Our proposed scheme is dealing with this route discovery process.
Let’s see the basic route discovery protocol before we go to the security issue.
University of California, Irvine

4. Route Discovery Route discovery has two stages:
The source floods the network with ROUTE REQUEST (RREQ) and
The destination returns a ROUTE REPLY (RREP). D B
S-B-C-D
S-B-C
S-B C S
S-G-E
Route discovery is composed of two stages: route request and route reply.
When a source S needs to send a message to a destination D, it broadcasts a route request packet.
Upon receiving a new route request packet, an intermediate node adds its identifier to the route request packet and broadcasts it again.
Finally, route request will arrive the destination and it returns a route reply packet.
While route request by broadcast, route reply can be forwarded by unicast because the destination knows a route from the route request paket.
S-G-E H
RREQ S E S
S-G
S-G-E
RREP G F
University of California, Irvine

5. Security of Route Discovery
Like most network protocols, DSR is designed for non-adversarial networks.
An adversarial node can easily disrupt the route discovery process by adding, deleting, and modifying any node in the route.
Need to add Security Features for Route Discovery
University of California, Irvine

6. SRDP: Secure Route Discovery Protocol
Need following properties:
1. Source can authenticate each entry of the path.
2. No intermediate node can remove a previous node in the node list in the route discovery packet.
To secure route discovery protocol, first source should be able to …..
3. Destination (optionally, intermediate nodes) authenticates source to prevent DoS attacks
University of California, Irvine

7. Related/Previous Work
Ariadne [Hu, et al. Mobicom 2002]
Pros:
Node authentication based on TESLA
Very efficient using MACs
Cons:
Loose time synchronization required.
No non-repudiation
Combined size of MACs depends on route length
We want:
nonrepudiation is the ability to ensure that a party to a contract or a communication cannot deny the authenticity of their signature on a document or the sending of a message that they originated.
Adriadne was previously proposed.
What is tesla?
One of the main challenges of securing broadcast communication is source authentication, or enabling receivers of broadcast data to verify that the received data really originates from the claimed source and was not modified en route. This problem is complicated by mutually untrusted receivers and unreliable communication environments where the sender does not retransmit lost packets.
This article presents the TESLA (Timed Efficient Stream Loss-tolerant Authentication) broadcast authentication protocol, an efficient protocol with low communication and computation overhead, which scales to large numbers of receivers, and tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers.
Despite using purely symmetric cryptographic functions (MAC functions), TESLA achieves asymmetric properties. We discuss a PKI application based purely on TESLA, assuming that all network nodes are loosely time synchronized.
Broadcast authentication requires an asymmetric primitive, which TESLA provides through loosely synchronized clocks and delayed key disclosure. TESLA shares many common properties with asymmetric cryptographic mechanisms. In fact, assuming that all nodes in a network are time synchronized, any key of the key chain serves as a key chain commitment and is similar to a public key of a digital signature: any loosely time synchronized receiver with an authentic key chain commitment can authenticate messages, but not forge a message with a MAC that receivers would accept.
Non-repudiation
No Time Synchronization
Fixed-size Authentication Tag
University of California, Irvine

8. Attacks Active attacker Possible Attacks
Add, delete and modify the route
Possible Attacks
The adversary can add or delete a set of compromised nodes from the route
The adversary can control a sandwiched node list closed by attackers
In our security model, we prevent active attackers from changing the route.
However, there are possible attacks we cannot avoid: N2 S A1 N3 N4 A2 D N1
University of California, Irvine

9. Security Definition (informal)
Route Discovery is secure if, for a given a route:
1. The source can verify the presence of each honest node that appears in the route.
2. For all honest nodes appearing in the route, their view of the route is either the same or, if not the same, the discrepancy is detected by the source.
In our security model,
University of California, Irvine

10. Observations RREQ is processed by many nodes
RREP is processed by few nodes
Minimize overhead in RREQ
Shift as much as possible to RREP
MACs and signatures take more space than route elements
Need to minimize bw consumed (reason)
Also:
Minimize state maintained between RREQ/RREP
“Remember” only the route prefix or hash thereof
DSR already requires state to be kept
Now let’s overview DSR.
University of California, Irvine

11. Recap: DSR S B C D RREQ0 = [ RREQh, ( ) ]
If it it new, process RREQ and cache Sid B
RREP2 = [ RREPh ]
RREQ1 = [ RREQh, (B) ] C
If it it new, process RREQ and cache Sid
RREP1 = [ RREPh ]
RREQ2 = [ RREQh, (B, C) ] D
RREP0 = [ RREPh ]
University of California, Irvine

12. Generic SRDP S B C D Verify RREQ0 = [ RREQh, ( ) ]
If it it new, process RREQ and cache Sid and prefix B
RREP2 = [ RREPh, ( ) ]
RREQ1 = [ RREQh, (B) ]
Fetch and verify route prefix
If it it new, process RREQ and cache Sid and prefix C
RREP1 = [ RREPh, ( ) ]
RREQ2 = [ RREQh, (B, C) ]
Fetch and verify route prefix D
RREP0 = [ RREPh, ( ) ]
Verify
University of California, Irvine

13. Conventional MACs S B C D Fast, but requires pre-shared keys
& doesn’t provide non-repudiation
University of California, Irvine

14. MACs based on Diffie-Hellman
No pre-shared keys, relatively expensive
& doesn’t provide non-repudiation
University of California, Irvine

15. Accountable-Subgroup Multi-Signatures Micali, Ohta and Reyzin [ACM CCS’01] ( Based on Schnorr signatures ) S B C D
Note that state must be kept after RREQ  bad!
But, note that RREP processing is very lightweight
University of California, Irvine

16. Multi-signatures based on GDH Groups Boneh, Gentry, Shacham, and Lynn [Eurocrypt’03]
valid DDH triple B C D
University of California, Irvine

17. Sequential Aggregate Signatures with RSA Lysyanskaya, Micali, Reyzin, and Shacham [Eurocrypt’04]B Y C N Y D N
University of California, Irvine

18. Analysis Auth. tag generation cost of an intermediate node
* Can be done off-line or re-used from earlier RREQ processing
Auth. Tag verification cost of the source
* r is the number of nodes in the route list
Op. type DH
ASM
GDH
SAS
Exponentiations 2 1* 1
Scalar mult-ns
Exponent size
|p| for both
|q| ??
|n|
Op. type DH
ASM
GDH
SAS
Exponentiations 2 r
Scalar mult-ns
Exponent size
|p| for both
|q| & 160 ??
constant e.g., 3
MAC is omitted
University of California, Irvine

19. Some Experimental Results
Generation and Verification costs (msec) for route of length 10
Key size
Generation
p or n (bits)
q (bits) DH
ASM
GDH
SAS
1024
160
20.08
2.13
7.14
4.29
2048
224
131.53
10.25
22.78
26.10
Key size
Verification
p or n (bits)
q (bits) DH
ASM
GDH
SAS
1024
160
20.00
4.47
89.00
2.53
2048
224
132.97
17.96
256.30
7.92
We assume 10 hops
University of California, Irvine

20. Conclusion
SRDP severely limits the range of possible attacks on DSR Route Discovery by combining prefix caching and backward authentication
ASM-based aggregated signatures seem to be best suited
More experimentation needed to compare with Ariadne
Clearly, MACs are cheaper but extra bandwidth is costly!
Ultimately hard to compare since non-repudiation is not offered in Ariadne
University of California, Irvine

21. End
University of California, Irvine

22. Forward vs Backward Authentication
Partial route in RREQ is accumulated incrementally (via flooding) until destination is reached
RREP confirms the route by re-visiting it (via unicast) in reverse order.
RREQ
A node cannot know whether it will be on the eventual route.
It sees only partial route information, the prefix.
RREP
A node can include its authentication tag in the eventual route.
All nodes’ view of the route should be exactly the same.
1. Cache the prefix of RREQ
2. Check the prefix of RREQ
3. Compute the authentication tag on RREP via efficient signature aggregation mechanism
University of California, Irvine

23. Schnorr Signature Scheme re-cap
System-wide parameters: p, q, g, h()
p,q – primes, p-1=kq, g – generator, h(.) – hash fn.
Signer’s public key: y = g X mod p
Signer’s secret key: x
Signature generation: σ = (e,s) where:
r – randomly selected from Zq
e = h(m,gr)
s = (xe + r) mod q = [ x h(m,gr) + r ] mod q
Signature Verification: h ( m, gs y-e ) = ? = e
University of California, Irvine