Secure Data Forwarding in Wireless Ad Hoc Networks

Transcription

1 Secure Data Forwarding in Wireless Ad Hoc Networs Qiang Huang, Ioannis C Avramopoulos, Hisashi obayashi and Bede Liu Department of Electrical Engineering, Princeton University, Princeton, NJ 08544, USA {qhuang, iavramop, hisashi, liu@princetonedu Abstract- Networ routing in wireless ad hoc networs is liable to attacs that may have a grave impact on networ operations Such attacs can be targeted at the route discovery process or the data pacet forwarding process Although the protection of route discovery is a critical prerequisite to ensure the robustness of the routing process, secured route discovery by no means eliminates attacs on routing We, accordingly, propose a secure data forwarding protocol that detects faulty lins in the pacet forwarding process, which enables the corresponding sources to progressively route pacets over non-faulty paths Index- Wireless Ad Hoc Networ, Security, Routing Protocol I INTRODUCTION The protection of routing from adversaries is necessary for any wireless ad hoc networ to be adopted for a critical mission Such necessity is exacerbated by the fact that the criteria for admitting routers in an ad hoc networ may not be strict An adversary can meet his objective to disrupt the pacet delivery service by attacing either route discovery or data pacet forwarding A secured route discovery protocol will not suffice to protect against a determined adversary; such an adversary can, for example, instruct its routers to announce fictitious lins so as to attract traffic and then drop the pacets they receive This paper proposes mechanisms to protect against such attacs by a faulty lin detection procedure that is integrated with data pacet forwarding We define a faulty lin as a lin that drops pacets, either because it is incident to a malicious node, or simply because its incident nodes have moved out of the communication range We would, ideally, lie to accurately pinpoint a faulty router or physical lin However, we are not aware of any mechanism that can achieve this property in a networ with malicious routers Instead, we develop a technique that can identify faulty lins; for each such lin at least one of the following conditions must be true: the upstream router is faulty, the lin is faulty or the downstream router is faulty In this regard, we present a secure data forwarding protocol F) that enables a source to reliably transmit data and detect faulty lins on its route to the destination F is designed to operate efficiently with resource constrained wireless nodes To the extent of our nowledge, it is the first protocol to introduce the one-time signature technique into Byzantine detection, which enables light-weight message authentication by utilizing a chaining verification mechanism It is also the first Byzantine detection protocol that can be deployed with distance vector protocols as it does not rely on source routing or the availability of a topological map The rest of the paper is organized as follows In Section, we explain our F protocol in detail In Section, we demonstrate attacs against the F protocol and how it copes with these attacs Section 4 presents simulation results and performance analysis In Section 5, we survey related wor by others Finally, we conclude in Section 6 II SECURE DATA FORWARDING WITH FAULT DETECTION In this section, we present our secure data forwarding F) scheme based on the operation of Ad Hoc On-demand Distance Vector routing protocol AODV) [, although F is a general technique that is also applicable to diagnose routing problems if other routing protocols are used A ain Components The F protocol utilizes the following mechanisms: Destination Acnowledgements The destination of every data pacet acnowledges its receipt to the source and every intermediate node An acnowledgement pacet AC) is generated that traverses in the reverse direction of the path traversed by the corresponding data pacet In AODV, the reverse path is automatically set up during the route request propagation ept alive as long as the forward path is active, since every delivery of a data pacet along the forward path will bring bac an AC pacet along the reverse path Timeouts For every data pacet its source and every intermediate node set for every data pacet a timeout to receive either a destination AC or a fault announcement for this pacet The timeout, which is set as the upper bound of the round trip time to the destination, detects delivery failures Fault Announcements When the timeout expires at a node, the node generates a fault announcement FA) for the pacet triggering the timeout) for its downstream lin in the pacet s route propagates this announcement upstream to the source If the timeout at the source expires, it detects a faulty lin and discovers a new route to the destination B Authentication echanism We use one-way hash chain and one-time hash tag commitment to authenticate messages and AC pacets against modification One-way hash chain [ authenticates the pacet sequence number and the one-time hash tag commitment binds the hash chain elements to a sequence of messages To create a hash chain, the source randomly chooses an initial value h N and computes the list of hash chain elements h,, h N, hn by repeatedly applying a one-way hash function H on h N N i generating h i = H hi+ ) = H h N ), for 0 < i N The source creates the hash chain elements in the decreasing order of subscript i and then over time uses certain elements of the chain to authenticate the pacet source and sequence number To use these values, the source discloses hashes in the chain in the order reverse to that of its generation This research has been supported, in part, from a wireless testbed project ORBIT) grant from the National Science Foundation NSF) The first author is supported by icrosoft Research Fellowship /05/$000 C) 005 IEEE 55

2 In each round of pacet transmission, the source commits a string, called the one-time hash tag commitment, to bind the next message to the current revealed hash chain element and its successor In the next round, the source reveals the value of this string, proving its nowledge of the corresponding hash chain element and, thus, authenticating the message content The source also needs an efficient way to validate the destination AC In the F protocol, the source generates a fresh AC nonce for each data pacet encrypts the nonce so that only the destination can decrypt it Authenticating the hashed value of the AC nonce during the pacet propagation process enables easy verification of the corresponding destination AC, which must bear the plaintext of the nonce We assume each lin is assigned a priori reserved buffer for every source node in the networ This ensures that normal pacets are not dropped in the interface queue because of congestion Authentication ensures that the reserved buffer is allocated to its intended source that protects against a vicious flooding attac The next subsection presents a detailed description of how to use the chaining authentication mechanism in F protocol C Authentication of Data and AC Pacets in F Consider the source S has a sequence of data pacets { m, m, mn to send to the destination D, where mi contains the monotone increasing pacet sequence number i i n ) We assume S and D share a secret ey We also assume neighboring nodes can establish pair-wise lin eys using, eg, a public-ey infrastructure PI) We use the following notation: E x) denotes encryption of message x using secret ey [ y HAC stands for a concatenation of message y and its authentication tag, computed by applying an HAC eyed-hash message authentication code [) function on the message y, using secret ey pacet # denotes the sequence number of data pacets The initialization step: To bootstrap the chaining authentication mechanism, the source S uses a conventional digital signature scheme to sign the first hash chain element h the initial commitment S selects two random AC nonce n and n, for the purpose of authenticating destination AC of pacets m and m S then encrypts m, n ) and m, n ) appends an authentication tag by applying HAC function [ on the encrypted message together with the address information, using the secret ey that it shares with the destination generates = [ addr _ S, E m, n) HAC and = [ addr _ S, E m, n ) HAC, where addr_s and addr_d are source and destination addresses respectively If an unexpired route to the destination exists in its routing table, S forwards to its downstream hop the first pacet: sg = [ pacet # =,, h ), Sig, h )), H, h )), S where Sig S, h )) is the digital signature of the source, which authenticates, h the hashed nonce H n ) to every down stream router sg also includes a one-time hash tag commitment H, h )) that binds the next message and H n ) to the second hash chain element h, so that they can be authenticated upon the release of the correct value of h According to its hop count to the destination, S then sets a timeout to receive either a destination AC or an FA from a downstream router for this pacet With the nowledge of the public ey of S, each downstream node can verify that the content of [, h ) is not modified during transmission A downstream router then creates a pacet forwarding entry pacet # =, e, e, e ) associated with the source S and the destination D, in which it stores the authenticated hashed nonce H n ), as e = H n ), which will be used to authenticate the destination AC for sg It also stores the authenticated hash chain element h, as e = the commitment e = H, h, H )), which h n together will be used to authenticate the message to be sent in the second round After forwarding the pacet, the intermediate router sets a timeout to receive either a destination AC or an FA from its next hop for pacet sg When the destination D receives sg, it verifies the authentication tag HAC contained in If the chec succeeds, it decrypts the message and obtains the first data pacet m and the nonce n The destination then schedules an acnowledgement pacet AC for transmission along the reverse of the path that the pacet sg traversed AC reflects the pacet sequence number The destination also appends n as an authentication tag to AC When an upstream router receives AC, it verifies its authenticity and that a timeout is pending for the corresponding pacet sg The router validates the authenticity of AC by applying the hash function H on the authentication tag n attached in the AC pacet verifies if the result H n ) is the same as e stored in the pacet forwarding entry If any chec fails, it drops AC Otherwise it cancels the timeout and further forwards AC upstream If the source receives AC with valid nonce n, it assumes successful delivery of the pacet m, since only the destination can correctly decrypt the nonce n The second round: After receiving a valid AC from the destination, the source randomly selects a new nonce n forwards the second pacet: sg = [ pacet # =,, h ), H, h )) to downstream routers, where = [ addr_ S, E m, n ) HAC In sg, the source reveals the second hash chain element h to authenticate the current pacet sequence number h is also used, together with the 56

3 st Step: Initialization Source S sg = [ pacet# =,, h ), = [ addr _ S, E m, n) HAC = [ addr _ S, E m, n ) HAC Set timeout to receive destination AC or FA Sig, h )), H, h )), S Downstream Router Verify Sig S, h, H n )) Drop sg if authentication fails Otherwise, Store pacet # =, e e, e, e = h, e = H n ), e = H, h )) Destination D sg Chec Verify HAC E m, n ) Set timer for AC or FA Verify n If true, assume m successful Yes, Cancel timer, Forward Upstream AC n Verify H n ) = e? No, drop AC AC n AC n th Round: Source S sg = + = [ addr _ S, E m, ) + n + HAC Set timeout to receive destination AC or FA [ pacet # =,, h ), H +, h + + )) Verify if H h ) = e, H, h )) = e Drop sg if authentication fails Otherwise, Store pacet # =, e, e, e = e Downstream Router sg h, e = H n ), e = H, h, H n )) sg Destination D Chec Verify HAC E m, n ) Set timer for AC or FA Verify n If true, assume m successful Yes, Cancel timer, Forward Upstream AC n Verify H n ) = e? No, drop AC AC n AC n Fig The authentication process of the data and AC pacets previously released commitment tag H, h )), to authenticate the current message and H n ) A new commitment H, h )) is included to authenticate the messages to be sent in round three Each downstream router can verify h by validating if H h ) is equal to e = h stored in the pacet forwarding entry associated with S and D It then applies the hash function H on the received message [ h, H ) calculates if the, n result is equivalent to the previous stored commitment e If both checs succeed, the router verifies that the content of [, h ) has not been modified Next, it updates the corresponding pacet forwarding entry as pacet #=, e = h, e = H n ), e = H, h, H )) The pacet sg is then n scheduled for transmission to the next hop and a timeout is set to receive either a destination AC or FA When the destination receives sg, it verifies HAC contained in It drops sg if the authentication fails Otherwise, it decrypts the data pacet m, the nonce n then sends AC bac to the source AC reflects sequence number pacet#= and bears n as its authentication tag Upstream routers accept AC and cancel their timers for sg only if H n ) is the same as the stored commitment e in their pacet forwarding entries The source sends out the third pacet upon the reception of a valid AC Fig illustrates the authentication process of data and AC pacets In summary, the source initially uses digital signature to bootstrap the first hash chain element h At each round of the protocol, the source commits a string consisting of the next message, the next hash chain element a hash of the next AC nonce, by publishing a hash of the string This one-time hash tag commitment binds the next message to the current revealed hash chain element and its successor In the next round, the source reveals the value of this string, proving its nowledge of the next hash chain element and, thus, authenticating the next message This chaining authentication mechanism enables efficient pacet verification, as only the first step requires digital signature computations all the subsequent rounds only involve simple hash computations 57

4 D Fault Detection If the timeout at an intermediate node expires, it schedules for transmission to the source an FA for the first downstream lin The FA reflects the sequence number of the failed pacet Suppose that the FA is only protected by an HAC computed with the secret ey shared between the reporting node and the source, malicious upstream nodes can simply modify the FA so it will be considered as invalid by the source To prevent this attac, we use the feedbac mechanism proposed by Awerbuch et al [4, by incorporating the onion encryption [5 method in the FA propagation process Furthermore, transmission of the FA pacets between each pair of nodes is protected by an HAC computed using the secret ey shared by the transmitter and the receiver ie, the next upstream hop of the transmitter), so that the receiver can verify the FA pacet is indeed from its downstream hop The reason is explained in Section III Pseudo-code for the FA forwarding process is given in Fig When an intermediate router receives an FA, it verifies that the FA is forwarded from its downstream lin and that a timeout is pending for the corresponding data pacet It then cancels the timeout and propagates to its upstream a new FA, which contains its node address, the sequence number of the failed pacet, the encrypted FA pacet received from its first downstream hop an HAC of the new FA Both the encryption and the HAC are computed using the secret ey that it shares with the source If the source timeout expires, it mars its first downstream lin as faulty Upon the reception of an FA, the source S checs the FA from each intermediate node by successively verifying the HACs and decrypting the next FA Following the last valid FA, S discovers a faulty lin S then performs the secure route discovery to find a new path to the destination E Having ultiple Outstanding Pacets and Tolerating Pacet Losses In the F protocol, we require that the source forwards the next message only after it receives the destination AC for the previous one This is to ensure that the previous pacet has been received by all downstream nodes, since the authentication of each pacet depends on the commitment contained in the previous one However, we notice that the requirement to wait for the previous AC before transmitting the next message may cause delayed processing of the data pacet Furthermore, if a data pacet is dropped either innocuously or maliciously, routers downstream to the location of the drop may not be able to verify the authenticity of the next data pacet One way to address the first problem is to partition the sequence number space that is assigned to a source-destination pair and independently apply our protocol to each partition The second problem can be addressed by retransmitting dropped pacets until their receipt by the destination is acnowledged in combination with a mechanism to detect the locations where retransmitted pacets are being dropped Both mechanisms have been investigated in our technical report [6 and we refer the reader to this technical report for the details // This function is called when an intermediate router s timeout expires intermediatesource, pacet#) cancel_timeout pacet#); enc= this_node first_downstream_lin; transmitter = this_node; FA= [source, pacet#, transmitter, enc, Hmacsource + pacet# + transmitter + enc), sourceey); send FA, HmacFA, this_nodeprevhopey)); // This function is called when an intermediate router receives an FA intermediatefa) if HmacFA, this_nodenexthopey) is valid) { if timeout_pending FApacet#)) { cancel_timeout FApacet#); enc=encrypt FAtransmitter + FAenc + FAHmac), FAsourceey); transmitter = this_node; FA= [FAsource, FApacet#, transmitter, enc, Hmac FAsource +FApacet#+ transmitter +enc), FAsourceey)); send FA, HmacFA, this_nodeprevhopey)); // This function is called at the source when receiving an FA sourcefa) if timeout_pending FApacet#)) { cancel_timeout FApacet#); source = FAsource; faulty_linstart = this_node; while FAenc!= FA transmitter first_downstream_lin) { if FAHmac!= Hmacsource + FApacet# + FA transmitter + FAenc), FA transmitterey)) { faulty_linend = FA transmitter; Report_faulty_lin faulty_linstart, faulty_linend); Return; faulty_lin_start = FA transmitter; FA transmitter, FAenc, FAHmac = Decrypt FAenc, FA transmitterey); Report_faulty_lin FAenc); Fig Pseudo-code for the FA propogation process F Secure Route Discovery Since lin failure problems are often due to non-malicious causes congestion, node movement, etc), a reasonable first step after identifying a faulty lin is to route around it The source can notify downstream routers of the problem try to discover a new route that does not include the detected faulty lin If repeated attempts of rerouting are of no avail, then it becomes more liely that an attacer is responsible for the lin failure problem An out-of-band action, such as human intervention, can be taen to solve the problem The source that discovers a faulty lin during the data forwarding process needs to initiate a route request RREQ) pacet in order to find a new path to the destination A secure route discovery protocol [7-0 must be used in conjunction with F to enhance the robustness of the overall data transmission process In the RREQ, the source specifies and signs any faulty lin that it detected Other nodes in the networ would then tae the faulty lin information into account in deciding whether to forward or suppress a route request try to route around the specified faulty lin However, other nodes should not use this information to alter their own exclusion lin list, so as to prevent the adversary from incriminating innocent nodes 58

5 The route request RREQ) is flooded to guarantee that RREQ reaches the destination The route reply RREP) is unicast under normal conditions to reduce communication overhead However, an adversary on the selected path may bloc the RREP message and prevent the path from being established Therefore, we use a specific RREP-multicast bit that is embedded in the RREQ header to indicate that the source requests the destination to multicast the RREP pacets This bit is turned on only if the source cannot obtain a RREP pacet after a threshold number of route request retries Since the RREQ must be signed by the source, there is no means for adversaries to change this bit We require that routers must also attach to any routing pacet that they forward to the next hop an HAC computed using pair-wise lin eys, so that the receiver can verify identity of the transmitter This requirement guarantees correct neighboring hop information and prevents attacers from incriminating non-faulty lins by impersonation III SECURITY ANALYSIS The security of the authentication mechanism used in F protocol follows inductively Assuming faithful execution up to round an attacer has intercepted the th message and obtained the string, h ), H +, h +, H n + )) He cannot modify ) as the commitment H, h, H n )) which was sent in the previous round contains them; he cannot change the current commitment H +, h +, H n + )) either, as it contains as an input h + which he does not now, but which is committed by h ; and if he forwards anything other than the correct value of h, then this will fail to verify against the previous hash chain element h With any modification to ) or h, which are protected by the previous commitment and the hash chain, the current pacet will be dropped by the adversary's next hop odifying the current commitment H +, h +, H n + )) is equivalent to dropping the next pacet In either case, the adversary will eventually be detected by its upstream hop Authenticating the hashed value of the AC nonce H n ) during the pacet propagation process enables easy verification of the corresponding AC from the destination Since only the destination can decrypt the nonce, the reception of a valid AC with the correct nonce implies successful delivery of the pacet to the destination The onion encryption of FA prevents the adversary from incriminating non-faulty lins by modifying the FA pacet or generating false FA Such misbehaviors can be detected by the source during its successive verification of the HAC contained in the FA from each intermediate node FA transmission is protected with an HAC computed with a lin ey that the transmitter and the receiver share, so that the receiver accepts the FA only if it verifies the FA comes from its downstream hop the neighboring hop information is authenticated in the route discovery process, as described in Section II-E) Without this protection, the adversary could send a spurious FA to a non-faulty router that has already forwarded the pacet If the non-faulty router has no means to verify the identity of the originator of the FA, it will accept the spurious FA and later drop the legitimate AC or FA since it has cancelled the timer for this pacet The consequence is that the source will detect the non-faulty lin that is incident on the afore-mentioned non-faulty router as faulty oreover, we request the transmission of data pacets is authenticated by an HAC computed with a lin ey shared between the transmitter and receiver, so that the receiver only accepts data pacets coming from its upstream hop on the data forwarding path This is to prevent the wormhole attacers [ from incriminating non-faulty lins Suppose W and W are two attacers which form a wormhole by establishing a path and tunnel pacets from one to another Assuming in the th round, W has intercepted the th message and obtained the string, h ), H +, h +, H n + )) W can tunnel it to W, which modifies the content of H +, h +, H n + )) sends, h ), H ' +, h +, H n + )) to its nearby node B on the pacet forwarding path If B has no means to authenticate the transmitter, it will accept the modified pacet and stores H ' +, h +, H n + )) as the commitment for the next message, since the authentication of, h ) succeeds W then sends the unmodified message downstream When B receives the correct th message forwarded by its previous hop A, it will drop the pacet, since it has already forwarded this message with the same sequence number In the next round, when A forwards to B the +) th message +, h +, H n + ), H +, h +, H n + )), B is going to drop it, as it fails to verify against the false commitment H ' +, h +, H n + )) that B obtained in the previous round from W Eventually, A will generate an FA to report the non-faulty lin AB However, by verifying the transmitter s identity, B will reject the modified message sent from W, since it is not in its upstream hop on the data forwarding path Being a malicious source, the adversary may generate an invalid HAC for the destination attach a valid signature on the pacet The downstream nodes cannot verify HAC except the destination, which will then drop the pacet Such an attempt causes the previous hop of the destination to generate an FA with regard to the non-faulty lin that is incident to the destination Our protocol dictates the FA to be interpreted and acted upon only by the source, so these false FAs have no effect on any non-faulty routers IV PERFORANCE ANALYSIS Our protocol enables efficient security processing of data and control pacets since only symmetric cryptography is used except in the initialization step, where a digital signature is used to bootstrap the first hash chain element To evaluate the ability of F to discover and maintain routes for delivery of data pacets, we used ns- with CU mobility extensions [ to simulate its operation and compare it with the AODV protocol 59

6 We used the 80 AC layer and CBR traffic over UDP The parameters for our simulation are given in Table I Each node moves according to the random waypoint model [: it starts at a random position, travels to another random location with a velocity uniformly chosen between 0 and v max and then pauses for a configured period, before choosing another random location and repeating the same steps We ran simulations for maximum node speeds of, 5, 0, 5 and 0 m/s, with a pause time fixed at 0 seconds Each source forwards 4 CBR pacets per second and the application data payload size is 5 bytes We modeled an enhanced version of F by utilizing 4 hash chains and independently applying our protocol to four partitions of the sequence number space, which enables 4 outstanding pacets simultaneously We modified the ns- AODV model in several ways We increased the pacet sizes to incorporate additional fields that are necessary for authenticating the pacets We added another pacet type for FA In our simulation, we used a digital signature of 60 bits eg ECPVS digital signature [) and a hash of 60 bits In addition, a signature generation delay of ms and verification delay of 4 ms were used for our protocol These values were obtained by measuring the performance of the ECPVS algorithm on a laptop computer with a obile Pentium III 856 Hz) processor Furthermore, we measured 0µs on average to compute an HAC for 5 byte pacet using the SHA- hash function In order to compare the performance of the F-enhanced AODV and the plain AODV, both protocols were run under identical mobility and traffic scenarios A basic version of AODV was used, which did not include optimizations such as periodic hello pacets and local repair of routes Lin layer feedbac was enabled Table II shows the comparison results that compare the F-enhanced AODV protocol with the plain AODV protocol Each data point is the average of 0 simulation runs with identical configuration but different randomly generated mobility patterns We computed three metrics for each simulation run: Pacet Delivery Ratio PDR): Adding the security features in F reduces the PDR by % on average and by no more than % at any moving speed, which suggests that the Fenhanced AODV is still highly effective in discovering and maintaining routes for delivery of data pacets Byte Overhead: This is defined as the ratio of overhead control bytes to delivered data bytes The transmission of control bytes at each hop along the route was counted as one transmission in the calculation of this metric The bytes overhead of F-enhanced AODV is significantly higher than plain AODV, due to the authentication byte overhead in routing and data control pacets, including signatures, hash tags, FAs and ACs We notice that the byte overhead of Fenhanced AODV reduces at higher mobility This is because fewer pacets are delivered hence less hash tags and ACs are transmitted Although the number of routing pacets increases at higher mobility, since the number of route discoveries is a small fraction of the number of pacets and ACs delivered, the overall byte overhead is reduced TABLE II PERFORANCE RESULTS COPARING F-ENHANCED AODV AND AODV PDR %) Byte Overhead Delay seconds) v max TABLE I PARAETERS FOR F SIULATIONS Number of Nodes 50 Pause Time 0 seconds Space Size 000 m x 000 m Node Transmission Range 50 m Number of Source-Destination Pairs 0 Source Data Pattern 4 pacets/second Application Data Payload Size 5 bytes/pacet ECPVS Signature Length Hash Length 60 bits 60 bits AODV F AODV F AODV F m/s m/s m/s m/s m/s Average End-to-End Delay of Data Pacets: The data pacet latency for F-enhanced AODV protocol is only slightly higher than plain AODV, with additional 78 ms delay on average This is due to the digital signature generation and verification for each route discovery process The authentication of data pacets only requires signature verification at the first step The following steps use efficient hash verification, which taes less than 0µs Therefore, the security processing of the F protocol does not incur significant delays We should also point out that our protocol requires from intermediate routers the maintenance of a certain amount of state for every route utilized in pacet forwarding For example, it requires the scheduling of a timeout for every valid received pacet However, this state does not impose a significant overhead primarily because of the limited depth of the pipelines that are available in ad hoc networs due to the limited available bandwidth, the shared medium the physical characteristics of wireless broadcast channels In this section we evaluated the performance of the F protocol in a non-adversarial setting The security properties of our protocol were discussed in Section III The validation of the recovery capabilities of F by simulation is a topic of current investigation V RELATED WOR The earliest wor on fault-tolerant forwarding was done by Radia Perlman [4 Perlman designed the Networ-layer protocol with Byzantine Robustness NPBR) which addresses denial of service at the expense of flooding and digital signatures This flooding protocol was proposed to protect topology discovery whereas for data pacet forwarding the use 50

7 of multipath routing was proposed by Perlman In contrast, in this paper, we are addressing the detection of data pacet forwarding misbehavior at the lin level rather than the path level Perlman also proposed an approach to fine-grained detection of malicious forwarding behavior that can be seen as a precursor to Byzantine detection protocols ultipath routing and misbehavior detection at the path level were also investigated in [5 Awerbuch et al [4 propose a protocol that detects faulty lins by using adaptive probing techniques and routes around faults F uses the onion encryption technique that was proposed in [4 for forwarding faults However, the protocol in [4 assumes the source node has the full path information to the destination, so it can add a message authentication code AC) and encrypt the probing information with the secret ey that it shares with probing nodes and, therefore, it cannot be used with distance vector protocols Padmanabhan and Simon s Secure Traceroute [6 uses signed probe pacets targeting intermediate routers, which enable end hosts or routers to adaptively detect and locate the source of routing misbehaviors Our recent paper [7,8 presents a secure routing scheme given the existence of a path of non-faulty routers between the source and the destination Validation of data and control pacets requires the computation of ACs and hashes The AC authentication mechanism is based on the assumption of source routing and hence the scheme is not directly applicable to situations where a distance vector routing protocol is used Forwarding misbehavior detection has also been investtigated for wired networs, for example, in [9, 0 One-time signature was first introduced by Lamport [ Anderson et al [ present the Guy Fawes protocol which provides stream authentication between two parties By maing signatures interactive, their protocol constructs digital signatures that require only a small number of hash function computations each However, the scheme cannot tolerate pacet loss and does not scale to a large number of receivers Perrig et al proposed a stream authentication protocol called TESLA [, which provides authenticated broadcast based on efficient AC computation and delayed disclosure of the authentication ey, without the limitations of the Guy Fawes protocol TESLA employs a chain of authentication eys lined to each other by a one way function The security is guaranteed by time synchronization, so the receiver can unambiguously decide that the sender has not yet disclosed the ey to authenticate the received pacet In our case of Byzantine detection, a source wants to reliably unicast a sequence of pacets to one destination locates faults on the pacet forwarding path if any Since the pacet forwarding is not a broadcast process, we use a chaining mechanism similar to the Guy Faws protocol save the overhead of performing synchronization among the networ nodes To overcome the limitation of pacet loss, we adopt the ey chain idea in TESLA that lets us bind a hash chain to a sequence of messages Other wor in secure routing [7-0 is concerned with protecting route discovery F, on the other hand, targets at securing the data forwarding process F is intended to be used in conjunction with a secure route discovery protocol to enhance the overall system robustness VI CONCLUSION This paper has presented the F protocol, which provides a solution for secure data forwarding in wireless ad hoc networs The protocol can detect and locate faulty lins on a per pacet basis so that an appropriate action can be taen F provides authentication using efficient hash chains and one-time hash tag commitments The simulation results show that the F-enhanced AODV is as efficient as the plain AODV in discovering and maintaining routes for delivery of data pacets, at the cost of using larger routing pacets and adding data control pacets which result in a higher overall bytes overhead in exchange for a slightly higher pacet delivery latency because of the cryptographic computation incurred REFERENCES [ C Perins and E Royer, Ad-Hoc On-Demand Distance Vector Routing, Proc IEEE WCSA, 999 [ L Lamport, Constructing Digital Signature Based on a Conventional Encryption Function, SRI TR CSL ) [ The eyed-hash essage Authentication Code HAC), No FIPS 98, National Institute for Standards and Technology NIST), 00 [4 B Awerbuch, D Holmer, C Nita-Rotaru, H Rubens, An On-Demand Secure Routing Protocol Resilient to Byzantine Failures, Proc AC Wise, 00 [5 P F Syverson, D Goldschlag G Reed, Anonymous connections and onion routing, Proc IEEE Symposium on Security and Privacy, 997 [6 I Avramopoulos, H obayashi, A rishnamurthy R Wang, Opt and Vent: An Efficient Protocol for Byzantine Detection in Wireless Ad Hoc Networ Routing, Technical Report TR-709-4, Princeton University, Dept of Computer Science, Oct 004 [7 Sanzgiri, B Dahill, B N Levine, C Shields E Belding-Royer, A Secure Routing Protocol for Ad Hoc Networs, Proc IEEE ICNP 00 [8 Y C Hu, D Johnson A Perrig, SEAD: Secure efficient distance vector routing for mobile wireless ad hoc networs, Proc IEEE WCSA, 00 [9 Yih-Chun Hu, Adrian Perrig, David B Johnson, Ariadne: A secure On-Demand Routing Protocol for Ad hoc Networs, Proc AC obicom 00 [0 P Papadimitratos and Z Haas, Secure Routing for obile Ad Hoc Networs, Proc SCS Communication Networs and Distributed Systems odeling and Simulation Conference, 00 [ Yih-Chun Hu, Adrian Perrig David B Johnson, Pacet Leashes: A Defense against Wormhole Attacs in Wireless Ad Hoc Networs, in Proc of Infocom 00 [ J Broch, D A altz, D B Johnson, Y C Hu J Jetcheva, A performance comparison of multi-hop wireless ad hoc networ routing protocols, Proc AC obicom998 [ Elliptic Curve Pintsov Vanstone Signature, IEEE P6: Standard Specifications for Public-ey Cryptography [4 R Perlman, Networ Layer Protocols with Byzantine Robustness, PhD thesis, IT LCS TR-49, October 988 [5 P Papadimitratos and Z Haas, Secure essage Transmission in obile Ad Hoc Networs, Elsevier Ad Hoc Networs Journal, ), 00 [6 V N Padmanabhan and D R Simon, Secure traceroute to detect faulty or malicious routing, Computer Communications Review, ):77 8, 00 [7 I Avramopoulos, H obayashi, R Wang A rishnamurthy, Highly Secure and Efficient Routing, Proc IEEE Infocom, arch 004 [8 I Avramopoulos, H obayashi, R Wang A rishnamurthy, Amendment to: Highly Secure and Efficient Routing, amendment to [4, Feb 004 [9 A izra, arzullo S Savage, Fault-Tolerant Forwarding in the Face of alicious Routers, Proc nd Bertinoro Worshop on Future Directions in Distributed Computing, 004 [0 A izra, arzullo S Savage, Detecting alicious Routers, Technical Report CS , University of San Diego, Dept of Computer Science, 004 [ R Anderson, F Bergadano, B Crispo, J-H Lee, C anifavas and R Needham, A New Family of Authentication Protocols, ACOSR: AC Operating Systems Review, vol, 998 [ A Perrig, R Canetti, D Song D Tygar, Efficient authentication and signing of multicast streams over lossy channels, ProcIEEE Security and Privacy Symposium, ay 000 5