Upload
nona
View
36
Download
0
Tags:
Embed Size (px)
DESCRIPTION
SRDP: Securing Route Discovery in DSR. Jihye Kim and Gene Tsudik Computer Science Department University of California at Irvine {Jihyek, gts}@ics.uci.edu. D. B. C. H. E. S. G. F. Outline. Introduction Secure Route Discovery Protocol (SRDP) Conventional MACs DH-based MACs - PowerPoint PPT Presentation
Citation preview
SRDP: Securing Route Discovery in DSR
Jihye Kim and Gene TsudikComputer Science DepartmentUniversity of California at Irvine
{Jihyek, gts}@ics.uci.edu
H
C
BD
E
FG
S
University of California, Irvine 2
Outline
Introduction Secure Route Discovery Protocol (SRDP)
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 No fixed infrastructure and node mobilityTraditional 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.
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).
S H
C
BD
E
FG
S
S
S-B
S-G S-G-E
S-G-ES-G-E
S-B-CS-B-C-D
RREQ
RREP
University of California, Irvine 5
Security of Route Discovery
Need to add Security Features for 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.
University of California, Irvine 6
SRDP: Secure Route Discovery Protocol
Need following properties:
1. Source can authenticate each entry of the path.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.
2. No intermediate node can remove a previous node in the node list in the route discovery packet.
3. Destination (optionally, intermediate nodes) authenticates source to prevent DoS attacks
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:
Non-repudiationNo Time Synchronization
Fixed-size Authentication Tag
University of California, Irvine 8
Attacks
Active attacker 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
A1A1 A2A2S DN1
N2
N3N3 N4N4
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.
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.
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.
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
University of California, Irvine 11
Recap: DSR
RREQ0 = [ RREQh, ( ) ]RREQ0 = [ RREQh, ( ) ]
RREQ1 = [ RREQh, (B) ]RREQ1 = [ RREQh, (B) ]
RREQ2 = [ RREQh, (B, C) ]RREQ2 = [ RREQh, (B, C) ]
If it it new, process RREQ and cache Sid
),,(,,,, DCBSSDRREPRREP idh RREP0 = [ RREPh ]
RREP0 = [ RREPh ]
RREP1 = [ RREPh ]RREP1 = [ RREPh ]
RREP2 = [ RREPh ]RREP2 = [ RREPh ]
S
D
B
C
idh SDSRREQRREQ ,,,
If it it new, process RREQ and cache Sid
University of California, Irvine 12
Generic SRDP
DCBRREQ0 = [ RREQh, ( ) ]
RREQ0 = [ RREQh, ( ) ]
RREQ1 = [ RREQh, (B) ]RREQ1 = [ RREQh, (B) ]
RREQ2 = [ RREQh, (B, C) ]RREQ2 = [ RREQh, (B, C) ]
),,(,,,, DCBSSDRREPRREP idh RREP0 = [ RREPh, ( ) ]
RREP0 = [ RREPh, ( ) ]D
RREP1 = [ RREPh, ( ) ]RREP1 = [ RREPh, ( ) ]
RREP2 = [ RREPh, ( ) ]RREP2 = [ RREPh, ( ) ]
S
D
B
C
Verify
Verify
,,,, idh SDSRREQRREQ
If it it new, process RREQ and cache Sid and prefix
If it it new, process RREQ and cache Sid and prefix
Fetch and verify route prefix
Fetch and verify route prefix
DC
DCB
University of California, Irvine 13
Conventional MACs
?DCB)))(||(||( hSDhSChSB RREPMACRREPMACRREPMACS
D
B
C
)||( DChBSDCB RREPMAC )||( DChBSDCB RREPMAC
)||( DhCSDC RREPMAC )||( DhCSDC RREPMAC
)( hDSD RREPMAC )( hDSD RREPMAC
Fast, but requires pre-shared keys& doesn’t provide non-repudiation
University of California, Irvine 14
MACs based on Diffie-Hellman
SBKDCDCB )(
SBKDCDCB )(
B
C
D
XhSSB
XhSSC
XhSSD
yK
yK
yK
SXhBCDy
DCB g?S
D
B
C SCKDDC )(
SCKDDC )(
SDKD g)( SDKD g)(
)(RREPHh
pgy
yy
iXi
DCBiiBCD
mod
},,{
No pre-shared keys, relatively expensive& doesn’t provide non-repudiation
University of California, Irvine 15
Accountable-Subgroup Multi-SignaturesMicali, Ohta and Reyzin [ACM CCS’01] ( Based on Schnorr signatures )
BrB gt BrB gt
CrBBC gtt CrBBC gtt
DrBCBCD gtt DrBCBCD gtt
CCDDC exr CCDDC exr
DDD exr DDD exr
BBDCDCB exr BBDCDCB exr
eBCDBCD ytg DCB ?
},,{
DCBiiBCD yyS
D
B
C
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]
S
D
B
C CxDDC h
CxDDC h
DxD h DxD h
BxDCDCB h
BxDCDCB h
?),,( DCBBCD hy valid DDH triple
)(RREPHh
},,{ DCBiiBCD yy
University of California, Irvine 17
Sequential Aggregate Signatureswith RSA Lysyanskaya, Micali, Reyzin, and Shacham [Eurocrypt’04]
S
D
B
C
)(mod Dx
DD nh D )(mod Dx
DD nh D)),(,( DDD ynRREPHh
)),(,( BBB ynRREPHh
)),(,( CCC ynRREPHh
)(mod)( Bx
BDCDCB nh B )(mod)( Bx
BDCDCB nh B
)(mod)( Cx
CDDC nh C )(mod)( Cx
CDDC nh C
?CD n
CDD n
b
11
01 b
Y
N
?BDC n
BDCDC n
b
11
01 b
Y
N
DDyD
CCCyDCD
BBByDCBDC
hn
nbnh
nbnh
D
C
B
?)(mod
)](mod[
)](mod[
1
2
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* 0 1
Scalar mult-ns 0 0 1 0
Exponent size |p| for both |q| ?? |n|
Op. type DH ASM GDH SAS
Exponentiations
2 2 0 r
Scalar mult-ns 0 0 2 0
Exponent size |p| for both |q| & 160 ?? constant e.g., 3
University of California, Irvine 19
Some Experimental Results
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
Generation and Verification costs (msec) for route of length 10
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
A node cannot know whether it will be on the eventual route.It sees only partial route information, the prefix.A node cannot know whether it will be on the eventual route.It sees only partial route information, the prefix.
A node can include its authentication tag in the eventual route. All nodes’ view of the route should be exactly the same.A node can include its authentication tag in the eventual route. All nodes’ view of the route should be exactly the same.
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 R
REP
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