Authentication Schemefor Routing Disruption Attack ... Path... · mobile environment. In this paper, we discover a strict cooperativedisruption attackonthe routepathandidentify the

2006 IEEE International Conference on

Systems, Man, and CyberneticsOctober 8-11, 2006, Taipei, Taiwan

A Path Authentication Scheme for Routing Disruption AttackPrevention in Ad Hoc Network

Li-Joe Lin, Shiuhpyng Shieh, Tzu-I Yang, and Warren W. Lin

Abstract Ad hoc routing protocols are vulnerable due to theabsence of security mechanisms, allowing attacks such as forgedrouting advertisements to disrupt the routing scheme. Researchwork has been proposed for securing the routing protocol in adhoc networks; however, solutions that utilize asymmetriccryptographic primitives are often infeasible in a constrainedmobile environment. In this paper, we discover a strictcooperative disruption attack on the route path and identify thedeficiency of present security mechanisms for protectingrouting information. We then propose a path authenticationscheme which relies on efficient symmetric cryptographicprimitives. The Random Assignment Path Authentication(RAPA) scheme guarantees the integrity of a complete requestroute path in the route discovery procedure and helps thecurrent on-demand routing protocol in resisting routingdisruption attacks.

I. INTRODUCTION

A D HOC wireless networks are adaptive and do not have apredefined infrastructure; therefore, they do not require

additional fixed devices, such as base stations or routers. Anytwo devices on the network can directly communicate if theyare both within radio transmission range. In general, an adhoc network consists of several participants, each of whommay play the role of an intermediate node and forwardpackets on behalf of others.

The design of a routing protocol must meet severalchallenging factors, such as high mobility in a dynamicallychanging topology, low computational power devices, etc.Thus, the routing protocol should take efficiency and low costfeatures into consideration. A proactive routing protocolrequires periodic updates of its routing table, causing constantoperational or bandwidth overhead. In contrast, a reactiverouting protocol is more feasible for the wireless environmentbecause it initiates the route discovery process only when itcannot find a route during data transmission.

Manuscript received March 30, 2006. This work was supported in part bythe National Science Council (NSC), the Institute for Information Industry(Ill), the Industrial Technology Research Institute (ITRI), the TaiwanInformation Security Center at NCTU (TWISC@NCTU), and the Team forResearch in Ubiquitous Secure Technology at UC Berkeley (TRUST).

L. J. Lin is with the Computer Science Department, National Chiao TungUniversity, Hsinchu, Taiwan, ROC (phone: 886-3-571-2121 ext 54705;e-mail: ljlingcsie.nctu.edu.tw).

S. P. Shieh, is with the University of California, Berkeley, CA 94720 USAon leave from the Computer Science Department, National Chiao TungUniversity, Hsinchu, Taiwan, ROC (e-mail: [email protected]).

T. I. Yang is with the Computer Science Department, National ChiaoTung University, Hsinchu, Taiwan, ROC (e-mail: tiyanggcsie.nctu.edu.tw).

W. W. Lin is with the Computer Science Department, National ChiaoTung University, Hsinchu, Taiwan, ROC (e-mail: warrengcsie.nctu.edu.tw).

A secure routing protocol is even more challenging todesign since each host can forward packets for others.Attackers can forge routing information to create an infiniterouting loop. Malicious nodes may also create a black hole byattracting packets in its vicinity and dropping them. A grayhole is a special case of the black hole attack in which theattacker selectively drops packets. The above attacks can bedetected by some probe mechanisms [4].

In this paper, we focus on routing disruption attackswhereby intermediate nodes along the route path floodfabricated routing control messages to dominate theforwarding resources [24] or modify routing messages topoison the route cache. We introduce a cooperative attackbehavior and identify the inadequacies of current secureon-demand routing protocols. Based on a secure on-demandrouting protocol, we propose an efficient path authenticationscheme which addresses the routing disruption behaviorunder the cooperative attack model. In addition, our schemeprovides flexibility for higher efficiency or security by finetuning the authentication cost and security level.Furthermore, we suggest a basic strategy with the ability tolocate and isolate malicious nodes.The remainder of this paper will be presented as follows:

we introduce the path authentication mechanism in section IIand provide a security and cost analysis in section III.

II. PROPOSED SCHEME

We propose a path authentication mechanism, RandomAssignment Path Authentication (RAPA), with the flexibilityof trading performance for enhanced security. Itsnon-repudiation feature allows it to resist a blackmail attack,whereby a malicious node deliberately incriminates a normalnode. We will demonstrate a method to isolate a maliciousnode that attempts to modify the routing information.

A. Security AssumptionsWe assume the underlying data link layer provides reliable

bidirectional transmission. Each transmission is received byall neighbors, whom operate in promiscuous mode. Althoughthe physical transmission medium in ad hoc networks has afundamental Denial-of-Service vulnerability, such asjamming attack, we exclude this from our work. We also donot address attacks in the Medium Access Control layer.

In addition, we assume the pre-distribution of thenecessary public keys for broadcast authentication throughtechniques [9] outside the scope of this work. Furthermore,the initiator and target node are assumed to be trusted without

1-4244-0100-3/06/$20.00 ©2006 IEEE 1262

Authorized licensed use limited to: National Chiao Tung University. Downloaded on October 19, 2009 at 00:36 from IEEE Xplore. Restrictions apply.

loss of generality.

B. Random Assignment Path Authentication (RAPA)To defend against the cooperative-n attack model, RAPA

extends RAP [24] as a general secure routing component byutilizing HORS [13], an efficient authentication mechanism.For convenience, RAPA will focus on the behavior ofdelivering the Route Request message in the secure NeighborDetection protocol ofRAP. In designing a secure approach toforward Route Request messages, our scheme satisfies twomain characteristics: the forwarder must (1) authenticate theinitiator of a Route Request and (2) confirm the correctness ofa Route Request's source route field. Specifically, theforwarder must verify that each entity in the source route fielddid indeed deliver this Route Request. Before passing on theRoute Request, the forwarder should sign the source routefield. Instead of appending the full signature, however, wecan lower the cost of generation and verification usingevidence. Fig. 1 illustrates the basic flow process of aforwarder in RAPA.

ReceiveRoute Request

Verifinitiator Invalidfield

Valid ( DiscardValid ~Route Request

Vrifsource route Invalid

field

Valid ~~~xposeValid Malicious Node

Append signatureand forward

Route Request

Fig. 1. Flow process of a forwarder.

Our scheme provides the initiator with the ability to adjustthe security level ofthe Route Request path. A higher securitylevel reduces the possibility of an attacker injecting bogusrouting information into the Route Request message;however, it will degrade the routing performance. We suggesta strategy that raises the security level when construction ofan authentication route path is in doubt. Fig. 2 depicts thedecision process of an initiator in selecting a security level.

C. NotationsWe use the following notation:

* S denotes a source (initiator) node* D denotes a destination (target) node* A-B [M]: node A sends message M to node B* A4* [M]: node A broadcasts message M

Generate Random ANumber Set

vForward RouteRequest andtrigger route

discovery timer

Check ifdiscovery timertso

Adjust authenticationsecurity level

(discovery_Timeout)

Ye

-- - Yes"

No

Reset security level(discovery_Success)

Fig. 2. Flow process of an initiator.

* A [H(M)] : node A generates the hash value ofmessage M

0 <>: An empty data field or data message list* SKA(91) : A's private slices indexes by a random

set $R* E;i: node i's signature* G i: node i's path signature assigned by initiator

* *- : Random Generation Process

* <-s : Signature Process

D. RAPA Protocol DescriptionIn this section, we detail the structure of a Route Request

and Route Reply message.A Route Request in RAPA contains eight primary fields:

Route Request, initiator, target, assigned random list,initiator's signature, source route, path authenticator list,and forwarder's signature. The initiator and target fieldconsist of the address of the initiator and target node,respectively. The assignedrandom list field is a set ofrandomnumbers generated by the initiator. RAPA requires that eachcommunicating node i possess two different secret keys,{SKS,SKP } , where SKs is for standard signatures and

SKP is for path authentication. Before distributing a RouteRequest to the target node, the initiator must first randomlyassign k random numbers {.ir, l2, --.kj} . These random

numbers are used to index the k-th private slice of SK P,which is appended to the path authenticator list by theforwarder for path authentication. The initiator's signature isa partial slice of the SK/, which is used to sign the initiator,target, and assigned random list fields. The source route fieldlists the address of all previous forwarders along the path. Theforwarder signs the entire Route Request message andreplaces the previousforwarder's signature.

1263


Once a target node receives the Route Request andconfirms the validity of the signatures and authenticators list,it retums a Route Reply message. The Route Reply message

is a condensed version of the Route Request message withoutthe assigned random list, path authenticator list, andforwarder's authenticator. Also, the source route field isreversed and the signature of the target node is appended.

Fig. 3 provides an example of our RAPA protocol. RREQand RREP denote Route Request and Route Reply,respectively.

S S,R, [T I ..., ;n]

S :Xs [RREQ ,< S,D >,'i]S *: [RREQ, S, D,93, s, < SourceRout e >,

< pathAuthLi st >, < forwarderS ign >]

A CA<-- [SKA(9)]A IXA- [YLs,< S, A >,< CA >]A -- * :[RREQ ,S,D, 9, Is,< S,A >,< (-A >,< EA >]

B :CB [SKA(9J )]

B BLs [Ys,< S, A,B >,< aA, oB >]B -> * :[RREQ ,S,D,91,Xs,< S,A,B >,

<CAU,7B >,< EB>]

D: Y-D [RREP ,D,S,< B,A,S >]D B :[RREP ,D,S,< B,A,S >,4D]B A :[RREP ,D,S,< B,A,S >,ED]

A X S :[RREP ,D,S,< B,A,S >,ED]Fig. 3 An example ofRAPA.

E. Forwarder ProcedureWhen a forwarding node receives a Route Request

message, it must verify and sign the message before passing iton. First, the node performs RAPA Verify to check thevalidity of the Route Request. Then, the forwarding nodeexecutes RAPA_Sign on valid messages to generate andappend its signature to the Route Request. Otherwise, thenode discards invalid messages. The forwarder may alsoannounce the presence of a malicious node.

Fig. 4. Signature verification and generation of forwarder.

F. Defense against Cooperative AttackersWe demonstrate how RAPA can protect the routing

protocol from cooperative attacks. Fig. 5 provides an exampleS -> * :[RREQ,S,D,9,Es,<>,<>]MI: OFMi < [SKMl(93)]

MI: EMl [[Es, < 5, A >, < CA >]MI -- **: [RREQ, S, D, 91, Es, < S, MI >,< crMI >, EM1]

M2: UM2 < [SKM2(2O)]M2: EM2 <- [Es, < S, MI, M2 >, < CMI, CM2 >]M2 -> * : [RREQ, S, D, 91, Es, < S, MI,M2 >,

<C7M1nCM2 >,EM2]F: RAPA Veriqf

Fig. 5. Cooperative attack scenario.

1264

AI A] Ak AkIF PK7n,s Hash( SK st ) or PK7s , # Hash( PK'1it)THEN Output: FALSE

End-IF{il... ikl = split Hash(RREQ[initiator's signature, sourceroute, hops authenticator list]) into k indexes of index'length is log2t bits

IF PK>, =Hash( SKs>, ) and PKs, =Hash( SK )

THEN select all nodes i in {source route)if1 f1 ifn if7

IF PK =Hash( SK7 ) and PK =Hash( SKTHEN Output: TRUE

ELSEBroadcast RREQ to announce the previous node f asmalicious nodes

End-IFELSE

Output: FALSEEnd-IFIRAPA_Sign {Input: a route request message RREQ{Z1 7n = RREQ[assigned random list]

Cf {SKP...,SKP}Append af to RREQSplit Hash(RREQ) into k indexes and interpret as aninteger i for 1 _j_ k

If= SK, ... SKs

Replace Zf in RREQForward RREQI

Parameters: t, k. n, {SKS,SKP}j, ft public slices for standard signature

k: choose k private slices as signaturen n private slices assigned by initiatorsVK : node i's private keys for standard signingsKP : node i's private keys for path authentication

: previous hop node's identityf : current forwarder's identityinit : initiator's identityRAPA_Verif {Input: a route request message RREQ{... jJ} = split Hash(RREQ[initiator, target, assignedrandom list]) into k indexes of index' length is log2t bits


of a cooperative attack scenario. Our protocol utilizes HORSto sign the route request, preventing malicious nodes Ml andM2 from impersonating an initiator. Since RAP piggybacks asignature one-hop away, it is not sufficient to preventcooperative attackers from inserting a forged routing path,which can cause Route Discovery to fail. In RAPA, we askeach forwarding node (Ml, M2, and F in our example) topiggyback their identifier, which is also signed using HORS.We provide a security analysis of our scheme in section 3.

G. Reactive Security Adjustment StrategyDuring a routing disruption attack, an initiator may fail to

find a working route using the underlying routing protocol.By applying RAPA, an initiator may discover a usable routeat the cost of additional computational overhead fromauthentication. Since the security strength depends on thequantity of random numbers selected by the initiator, wesuggest a simple, yet flexible strategy which allows therouting protocol to dynamically adjust the security level.discovery_Timeout and discovery_Success proceduresexecute when Route Discovery fails or succeeds in finding aroute, respectively. In RAPA_Init, the initiator determines theamount of random numbers for path authenticationdepending upon the accumulated number of timeouts andinterval factor during Route Discovery. Thus, the initiatorraises the security level after successive timeouts whilewaiting for a Route Reply.

H. Malicious Node Isolation MethodIn our protocol, each node maintains a blacklist for

blocking malicious nodes. RAPA can isolate maliciousnodes from a network after sensing disruptive behavior. Todetect a malicious node, the forwarder must be able torecognize forged records in the path authentication list. In theexample shown in Fig. 5, a well-behaved node F can expose amalicious node M2 by broadcasting the forged requestmessage. Since this announcement message containsnon-repudiation information, each node can verify theincriminating evidence and add the malicious node to its ownblacklist. Without including its signature in the forwarder'ssignature field, node F is still able to discard a forged requestmessage; however, it loses the ability to announce thepresence of the malicious node M2.

III. SECURITY ANALYSIS

We discuss the security issues and properties of RAPA inthis section. We divided it into three assessment phases: 1)source authentication 2) path authentication 3) costcomparison a simple approach.

A. Security strength ofstandard signaturefor HORSThe security of HORS depends on two important factors:

the "subset-resilient" property of hash operations and theprobability to forge a signature. The subset-resilient feature,which is formally defined in HORS, guarantees that it isinfeasible to find two distinct messages that will result in at

Parameters: accfailTimes, max-level, interval

acc_failTimes: number of Route Discovery failures

max-level: max security levelinterval: step size for increasing security levelMaxFailTimes : max number of route Discovery failure

RAPA_Init {Input:RREQ

91 MIN(accJfailTimes *interval, max level)Append the signature sign(RREQ) and randomnumbers set 91DO original Route Discovery procedure

}

discovery_Timeout {accfailTimes<- accjailTimes+1IF ace_JailTimes < MaxFailTimesTHEN trigger RAPA_Init procedure

v

discovery_Success {accjfailTimes*- 1Prepare data for transmission

I

Fig. 6. Algorithm for reactive security adjustment strategy.

most ks-element subset of T='{... tsj. If the attacker tries toforge a signature after obtaining signatures on R messages,

then the probability is trivially at most ( )k Given

parameter settings of R=4, ks,1024, and t5,16, the securitystrength is 2-64. This decrease in security strength suggests aneed for more frequent re-keying.

B. Random Number Set Collision in Path AuthenticationFor an adaptive chosen message attack, the attacker tries to

invert the public slices of the one way function H for whichthe corresponding secret slices has not been released. Thesecurity strength is reduced to the one-wayness and thecollision-resistance of H. The security parameter ofH is thebit length L of its input string. To forge the authenticator of aforwarder, an attacker must guess kp*2L values, where kp isthe number of private slices for one authenticator in the pathauthentication. We use the term "authenticator" rather than"signature" for the information appended by each forwarderof our path authentication mechanism because it does notrequire a signature operation.

In the case of a non-adaptive chosen message attack, theattacker tries to forge the forwarder's authenticator bychoosing r released private slices, where r is related to the

1265


average number of neighboring nodes, the total number ofnodes, and the density of the network. If a forwarder detects a

duplicate random number set, it can refuse to append thecorresponding authenticators and report back to the initiator.Since two initiators may accidentally issue the same randomnumber set, we are interested in this collision probability. LetW(i, j) be the probability that no two route requests, i and j,contain the same random number set. That is,

W(i,j) (j-1)x(j-2)x...x(j -(i- 1)) j!ij (j- i)!ji

The collision probability, which increases as the adversaryaccumulates released private slices, is

P(i, j)= W(i, j) = 1-(j - i)!j'

Since this is similar to the birthday problem analysis [19], wecan estimate the collision probability as

P(i,j)I1-'(i-1)/2

i32j 6(j- i+1)

This approximation probability is useful for determining a

suitable time to re-key. Given a threshold value Phreshold, wecan use the following algorithm to estimate the average

re-keying interval X.

Fig. 7. Algorithm for estimating re-keying interval.

Consider the example in [7] in which a network with twohundred nodes operates in an area of 400 square meters. Anode has a communication range of one meter. Furthermore,each node has an average of three neighbor nodes, which weobtained from the statistical study in [8]. We use similarsecurity parameters as in HORS, setting tp,1024 and kp=16.Let V (n) be the probability that an initiator's random numberset conflicts with another as follows:

nC;T(n)k=k r!(t k)!t!a(r - k)!

We utilize Stirling's approximation,

N!; (2N+ 1)xzr x NT xe-N

to simplify VJ (n), obtaining

T(n)=nx j(r. )x( r x(t-k )x(r-kkt.(r r -k t t-k

Given the above parameters, we observe a probability of9.8301e-006 and 0.015 after 512 and 768 private slices havebeen disclosed, respectively. This probability is directlyrelated to the rejecting request probability for a forwarder andreflects the adaptability of our proposed scheme.We model how TI (n) and the expected value of collisions

changes. The expected value reflects the number of disclosedprivate slices after initiating the re-keying procedure. In Fig.9, we fix tp at 1024 and vary kp. From our results, we expect a

collision after exposing 448 private slices for kp,16. Bydoubling k , we can reveal an additional 200 exposed slicesbefore observing a collision. Fig. 10, which sets kp at 16,shows that the tolerated number of exposed private slicesonly increase by 100 from t=1024 to tp, 1280.

430 k-;2

::! 'Z4X ~ ~ ~~ ~ ~ ~ ~ ~ ~ ~ ~ .

-40

0 100 40 00 Gooo~~~~~4*e sub" pff olm

" 700 :W0

v-10

t Fs.3225

1.: 024

).

400 too 250 n0o 400 500

-At.aZ

a0t *stZ~~~~~~..X.0W; X

.0

600 TOO

Fig. 9. Variation of logio(T (n)) and the expected value forthe same number of public slices

1266

Parameters: tp, kp, r, Pthresholdtp public sliceskp private slicesr : private slices have been releasedn average number of neighbor nodesPthreshold : max tolerated collision probabilityX : average re-keying intervalEstimate_RekeyInterval {Initialize: kX*0DO kX-X+1UNTIL P(n, C{'P _jCn1)r) >'hehlkp kp threshold

End-DOOutput: X}


.10

i= .15 t'

.20

VAMB ki__S12o

4010 100 200 300 400 0 00

ACWVo *04 VV s&oe

0

4

I.tX0I -0 r

I 1

I20

0 100 200 30 s400Ataao*#

1-,.s

RAPA Simple

Sign 1 1

Verify (kp x Tj1) + (ks + 2) ((kp + 1) xoi) + (k, + 1)

Overall (kpxI)i+(L- 1)x(k, +3) ((kp +1)xI)+(L- 1)x(k +2)

Table 1 Generalized hash operation costs on a route requestpath of length L.

The overall cost encompasses the signature generation andverification cost of each intermediate node along the routepath. Fig. 11 illustrates the difference in cost givenparameters tp=1024 and varying values of kp. If the number ofdisclosed private slices is half the amount of total publicslices, then the probability of forging a signature that HORSprovides is 1 . Since RAPA exhibits a collision probability

2-16of we can reduce kp to achieve an equivalent security~~~~2strength as HORS. By applying the Estimate RekeyIntervalprocedure, we can estimate an appropriate value for kp.

~~~~~~~~~~~~t 12Assuming P(3,C CtP12 1 and tp=1024, then kp is atkpk 216

most 4. Our scheme can lower the collision probability if wesettle for a larger value of kP.

t-S!2 FtEIS1-512k.1WON WS~1t-inok~-10

50 0

Fig. 1O.Variation of loglo(T (n)) and the expected value forthe same number of private slices

Our analysis confirms that the probability of collisionsamong the random number set chosen by an initiator isnegligible, and that it increases slowly as an adversaryaccumulates disclosed private slices.

C. Comparison ofCostfor Forwarding Route RequestIn this section, we compare the verification and signature

cost between our proposed scheme and a simple approach.We consider a simplistic method for path authentication inwhich each forwarding node piggybacks their signaturerather than the authenticator of our scheme. During a routingdisruption attack, the simple approach will incur significantcost in bandwidth and verification because it piggybacks thesignature of each hop. To sign a route request, the forwardermust apply a hash function on the message to obtain theindexes of the private slices. Because RAPA does not requirethis extra hash, our scheme reduces the cost as the route pathincreases.

Table 1 generalizes the verification and signature cost ofthe forwarders for a route request path of length L. Thesymbol ai denotes the number of previous hops throughwhich a route request packet has passed at the i-thintermediate node on the route request path.

a00r

5000

t 46000

1 3000

I20

1ow0

5 1i 20 25 30

RQ*eP0£ tL0l(HOW

Fig. 11 RAPA and simple method cost difference

As shown in Fig. 12, the number of hash operationsincreases rapidly as the path length of the route grows in thesimple approach. This implies RAPA provides betterscalability than the simple method.

1267

II

_~kfl

I

I


am.0

$iWUAwor#oA7000

0000

'14000

200

100

to__ is_Io5 X*W PO" LO&(N

2$

----I

Fig. 12 Overall cost comparison

REFERENCES

[1] A. Perrig, R. Canetti, D. Song, and J. D. Tygar. "Efficient and SecureSource Authentication for Multicast." In Network and DistributedSystem Security Symposium (NDSS '01), pp. 35-46, February 2001.

[2] A. Perrig. "The BiBa one-time signature and broadcast authenticationprotocol." In Proceedings of the 8th ACM conference on Computer andCommunications Security, pp. 28-37, November 2001.

[3] A. A. Pirzada, C. McDonald. "Kerberos assisted Authentication inMobile Ad-hoc Networks." In Proceedings of the 27th conference onAustralasian Computer Science, Volume 26, pp. 41-46, January 2004.

[4] B. Awerbuch, D. Holmer, C. Nita-Rotaru and H. Rubens. "Anon-demand secure routing protocol resilient to byzantine failures." InProceedings ofthe ACM workshop on Wireless security (WiSe'02), pp.21-30, September 2002.

[5] C. E. Perkins, E. M. Belding-Royer, and S. R. Das. "Ad HocOn-demand Distance Vector (AODV) Routing." Internet-Draft,draft-ietf-manet-aodv-13.txt, February 2003.

[6] D. B. Johnson, D. A. Maltz, and J. Broch, "DSR: The Dynamic SourceRouting Protocol for Multi-Hop Wireless Ad Hoc Networks." In AdHoc Networking, pp. 139-172. Addison-Wesley, 2001.

[7] D. B. Johnson, D. A. Maltz, Y. C. Hu, and J. G. Jetcheva. "TheDynamic Source Routing Protocol for Mobile Ad Hoc Networks."Internet-Draft, draft-ietf-manet-dsr-09.txt, April 2003.

[8] H. Li and D. Yu. "A statistical study of neighbor node properties in adhoc network." In Proceedings of the International Conference onParallel Processing Workshops (ICPPW'02), pp. 103-108, August2002.

[9] J. P. Hubaux, L. Buttyan and S. Capkun. "The Quest for Security inMobile Ad Hoc Networks." In Proceedings of the 2nd ACMinternational symposium on Mobile ad hoc networking and computing(MobiHOCO'1), pp. 146-155, October 2001.

[10] J. Broch, D. A. Maltz, D. B. Johnson, Y. C. Hu, and J. G. Jetcheva. "APerformance Comparison of Multi-Hop Wireless Ad Hoc NetworkRouting Protocols." In Proceedings of the Fourth ACM/IEEEInternational Conference on Mobile Computing and Networking(MobiCom'98), pp. 85-97, October 1998.

[11] K. Sanzgiri, B. Dahill, B. N. Levine, C. Shields, E. M. Belding-Royer."A Secure Routing Protocol for Ad Hoc Networks." In Proceedings of10th IEEE International Conference on Network Protocols (ICNP'02),pp. 78-87, November 2002.

[12] L. Eschenauer, V. D. Gligor. "Key management and key exchange: Akey-management scheme for distributed sensor networks." InProceedings of the 9th ACM conference on Computer andCommunications Security, pp. 41-47, November 2002.

[13] L. Reyzin and N. Reyzin. "Better than BiBa: Short One-TimeSignatures with Fast Signing and Verifying." In Proceedings of the 7thAustralian Conference on Information Security and Privacy, pp.144-153, July 2002.

[14] M. G. Zapata and N. Asokan. "Securing Ad hoc Routing Protocols." InProceedings of the 2002 ACM workshop on Wireless security(WiSe'02), pp. 1-10, September 2002.

[15] M. G. Zapata. "Secure Ad hoc On-Demand Distance Vector (SAODV)Routing." Internet-Draft, draft-guerrero-manet-saodv-00.txt August2002.

[16] P. Papadimitratos and Z. J. Hass. "Secure Routing for Mobile Ad hocNetworks." In Proceedings of the SCS Communication Networks andDistributed Systems Modeling and Simulation Conference (CNDS'02),January 2002.

[17] P. Johansson, T. Larsson, N. Hedman, B. Mielczarek, and M.Degermark. "Scenario-based Performance Analysis of RoutingProtocols for Mobile Ad-hoc Networks." In Proceedings of the FifthAnnual ACM/IEEE International Conference on Mobile Computingand Networking (MobiCom'99), pp. 195-206, August 1999.

[18] S. Capkun, L. Buttyan and J. P. Hubaux. "Self-organized public-keymanagement for mobile ad hoc networks." In IEEE Transactions onMobile Computing, pp. 52-64, March 2003.

[19] M. Sayrafiezadeh. "The Birthday Problem Revisited." MathematicsMagazine 67, pp. 220-223, 1994.

[20] S. Zhu, S. Xu, S. Setia and S. Jajodia. "Establishing Pairwise Keys forSecure Communication in Ad Hoc Networks: A ProbabilisticApproach." In Proceedings of the 11th IEEE International Conferenceon Network Protocols, pp. 326, November 2003.

[21] S. Marti, T. J. Giuli, K. Lai and M. Baker. "Mitigating routingmisbehavior in mobile ad hoc networks." In Proceedings of the 6thannual international conference on Mobile computing and networking(MOBICOM 2000), pp. 255-265, August 2000.

[22] Y. C. Hu, A. Perrig, and D. B. Johnson. "Wormhole detection inwireless ad hoc networks," Department of Computer Science, RiceUniversity, Tech. Rep. TROI-384, June 2002

[23] Y. C. Hu, A. Perrig, and D. B. Johnson. "Ariadne: A SecureOn-Demand Routing Protocol for Ad Hoc Networks." In Proceedingsof the Eighth Annual International Conference on Mobile Computingand Networking (MobiCom'02), pp. 12-23, September 2002.

[24] Y. C. Hu, A. Perrig, and D. B. Johnson. "Rushing attacks and defense inwireless ad hoc network routing protocols." In Proceedings of the 2003ACM workshop on Wireless security (WiSe'03), pp. 30-40, September2003.

1268

t


Documents

Authentication Schemefor Routing Disruption Attack ... Path... · mobile environment. In this paper, we discover a strict cooperativedisruption attackonthe routepathandidentify the