Secure Data Forwarding in Wireless Ad Hoc Networks - CiteSeerX

Secure Data Forwarding in Wireless Ad Hoc Networks Qiang Huang, Ioannis C. Avramopoulos, Hisashi Kobayashi and Bede Liu Department of Electrical Engineering, Princeton University, Princeton, NJ 08544, USA E-mail:{qhuang, iavramop, hisashi, liu}@princeton.edu Abstract- Network routing in wireless ad hoc networks is liable to attacks that may have a grave impact on network operations. Such attacks can be targeted at the route discovery process or the data packet 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 attacks on routing. We, accordingly, propose a secure data forwarding protocol that detects faulty links in the packet forwarding process, which enables the corresponding sources to progressively route packets over non-faulty paths. Index- Wireless Ad Hoc Network, Security, Routing Protocol

I. INTRODUCTION The protection of routing from adversaries is necessary for any wireless ad hoc network to be adopted for a critical mission. Such necessity is exacerbated by the fact that the criteria for admitting routers in an ad hoc network may not be strict. An adversary can meet his objective to disrupt the packet delivery service by attacking either route discovery or data packet 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 links so as to attract traffic and then drop the packets they receive. This paper proposes mechanisms to protect against such attacks by a faulty link detection procedure that is integrated with data packet forwarding. We define a faulty link as a link that drops packets, 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, like to accurately pinpoint a faulty router or physical link. However, we are not aware of any mechanism that can achieve this property in a network with malicious routers. Instead, we develop a technique that can identify faulty links; for each such link at least one of the following conditions must be true: the upstream router is faulty, the link is faulty or the downstream router is faulty. In this regard, we present a secure data forwarding protocol (SDF) that enables a source to reliably transmit data and detect faulty links on its route to the destination. SDF is designed to operate efficiently with resource constrained wireless nodes. To the extent of our knowledge, 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 2, we explain our SDF protocol in detail. In Section 3, we demonstrate attacks against the SDF protocol and how it copes

with these attacks. Section 4 presents simulation results and performance analysis. In Section 5, we survey related work by others. Finally, we conclude in Section 6. II. SECURE DATA FORWARDING WITH FAULT DETECTION In this section, we present our secure data forwarding (SDF) scheme based on the operation of Ad Hoc On-demand Distance Vector routing protocol (AODV) [1], although SDF is a general technique that is also applicable to diagnose routing problems if other routing protocols are used. A. Main Components The SDF protocol utilizes the following mechanisms: Destination Acknowledgements. The destination of every data packet acknowledges its receipt to the source and every intermediate node. An acknowledgement packet (ACK) is generated that traverses in the reverse direction of the path traversed by the corresponding data packet. In AODV, the reverse path is automatically set up during the route request propagation, and kept alive as long as the forward path is active, since every delivery of a data packet along the forward path will bring back an ACK packet along the reverse path. Timeouts. For every data packet its source and every intermediate node set for every data packet a timeout to receive either a destination ACK or a fault announcement for this packet. 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 packet triggering the timeout) for its downstream link in the packet’s route, and propagates this announcement upstream to the source. If the timeout at the source expires, it detects a faulty link and discovers a new route to the destination. B. Authentication Mechanism We use one-way hash chain and one-time hash tag commitment to authenticate messages and ACK packets against modification. One-way hash chain [2] authenticates the packet 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 hN and computes the list of hash chain elements h1 ,", hN −1 , hN by repeatedly applying a one-way hash function H on hN , and generating hi = H (hi +1 ) = H N −i (h N ) , for 0 < i ≤ N − 1 . 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 packet 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 Microsoft Research Fellowship.

3525 0-7803-8938-7/05/$20.00 (C) 2005 IEEE

In each round of packet 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 knowledge of the corresponding hash chain element and, thus, authenticating the message content. The source also needs an efficient way to validate the destination ACK. In the SDF protocol, the source generates a fresh ACK nonce for each data packet, and encrypts the nonce so that only the destination can decrypt it. Authenticating the hashed value of the ACK nonce during the packet propagation process enables easy verification of the corresponding destination ACK, which must bear the plaintext of the nonce. We assume each link is assigned a priori reserved buffer for every source node in the network. This ensures that normal packets 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 attack. The next subsection presents a detailed description of how to use the chaining authentication mechanism in SDF protocol. C. Authentication of Data and ACK Packets in SDF Consider the source S has a sequence of data packets {m1 , m 2 , " m n } to send to the destination D, where mi contains the monotone increasing packet sequence number i ( 1 ≤ i ≤ n ). We assume S and D share a secret key K SD . We also assume neighboring nodes can establish pair-wise link keys using, e.g., a public-key infrastructure (PKI). We use the following notation: E K (x) denotes encryption of message x using secret key K. [ y || HMAC K ] stands for a concatenation of message y and its authentication tag, computed by applying an HMAC (keyed-hash message authentication code [3]) function on the message y, using secret key K. packet # denotes the sequence number of data packets. 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 h1 , and the initial commitment. • S selects two random ACK nonce n1 and n2 , for the purpose of authenticating destination ACK of packets m1 and m2 . S then encrypts ( m1 , n1 ) and ( m 2 , n 2 ), and appends an authentication tag by applying HMAC function [3] on the encrypted message together with the address information, using the secret key K SD that it shares with the destination, and generates M 1 = [addr _ S , addr _ D, E K (m1 , n1 ) || HMAC K ] and SD

SD

M 2 = [addr _ S , addr _ D, E K ( m 2 , n 2 ) || HMAC K ] , where addr_S SD

SD

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 packet: Msg 1 = [ packet # = 1, M 1 , h1 , H ( n1 ), Sig S ( M 1 , h1 , H ( n 1 )), H ( M 2 , h 2 , H ( n 2 ))],

where Sig S ( M 1 , h1 , H (n1 )) is the digital signature of the source, which authenticates M 1 , h1 , and the hashed nonce H ( n1 ) to every down stream router. Msg 1 also includes a one-time hash tag commitment H ( M 2 , h2 , H (n 2 )) that binds the next message M 2 and H (n 2 ) to the second hash chain element h2 , so that they can be authenticated upon the release of the correct value of h2 . According to its hop count to the destination, S then sets a timeout to receive either a destination ACK or an FA from a downstream router for this packet. • With the knowledge of the public key of S, each downstream node can verify that the content of [ M 1 , h1 , H ( n1 ) ] is not modified during transmission. A downstream router then creates a packet forwarding entry ( packet # = 1, e11 , e 12 , e 31 ) associated with the source S and the destination D, in which it stores the authenticated hashed nonce H (n1 ) , as e12 = H (n1 ) , which will be used to authenticate the destination ACK for Msg 1 . It also stores the authenticated hash chain element h1 , as e11 = h1 , and the commitment e31 = H ( M 2 , h2 , H (n 2 )) , which

together will be used to authenticate the message to be sent in the second round. After forwarding the packet, the intermediate router sets a timeout to receive either a destination ACK or an FA from its next hop for packet Msg 1 . • When the destination D receives Msg 1 , it verifies the authentication tag HMAC K SD contained in M 1 . If the check succeeds, it decrypts the message and obtains the first data packet m1 and the nonce n1 . The destination then schedules an acknowledgement packet ACK 1 for transmission along the reverse of the path that the packet Msg 1 traversed. ACK 1 reflects the packet sequence number. The destination also appends n1 as an authentication tag to ACK 1 . • When an upstream router receives ACK 1 , it verifies its authenticity and that a timeout is pending for the corresponding packet Msg 1 . The router validates the authenticity of ACK 1 by applying the hash function H on the authentication tag n1 attached in the ACK packet, and verifies if the result H ( n1 ) is the same as e12 stored in the packet forwarding entry. If any check fails, it drops ACK1 . Otherwise it cancels the timeout and further forwards ACK 1 upstream. If the source receives ACK 1 with valid nonce n1 , it assumes successful delivery of the packet m1 , since only the destination can correctly decrypt the nonce n1 . The second round: After receiving a valid ACK 1 from the destination, the source randomly selects a new nonce n3 , and forwards the second packet: Msg 2 = [ packet # = 2, M 2 , h2 , H ( n2 ), H ( M 3 , h3 , H (n3 ))] to downstream routers, where M 3 = [addr _ S , addr _ D, E K (m3 , n3 ) || HMAC K ] . In Msg 2 , the source reveals SD

SD

the second hash chain element h2 to authenticate the current packet sequence number. h2 is also used, together with the

3526

1st Step: Initialization

Msg 1 = [ packet # = 1, M 1 , h1 , H (n1 ),

Downstream Router

Sig S ( M 1 , h1 , H ( n1 )), H ( M 2 , h2 , H (n 2 ))],

Source S

…

M 1 = [ addr _ S , addr _ D , E K ( m1 , n1 ) || HMAC K ]

Verify Sig S ( M 1 , h1 , H (n1 ))

M 2 = [ addr _ S , addr _ D , E K ( m2 , n2 ) || HMAC K ]

Drop Msg1 if authentication fails Otherwise, Store packet # = 1, e11 , e 12 , e13

SD

SD

SD

SD

Set timeout to receive destination ACK or FA

Destination D Msg1 Check M1 Verify HMACK EK−1 (m1 , n1 )

e11 = h1 , e12 = H (n1 ), e31 = H ( M 2 , h2 , H (n2 ))

SD

Set timer for ACK or FA Verify n1 If true, assume m1 successful

Yes, Cancel timer, Forward Upstream ACK1 || n1

ACK 1 || n1

Verify H (n1 ) = e ? 1 2

…

ACK 1 || n1

No, drop ACK1

kth Round: k ≥ 2

Msg k = [ packet # = k , M k , h k , H ( n k ), H ( M k +1 , h k +1 , H ( n k +1 ))]

Source S

Destination D

Downstream Router

Msgk

…

Verify if H (hk ) = e1k −1 , H ( M k , hk , H (nk )) = e3k −1 SD

Check Mk Verify HMACK

Drop Msgk if authentication fails Otherwise, Store packet # = k , e1k , e2k , e3k

M k +1 = [ addr _ S , addr _ D , E K ( mk +1 , nk +1 ) || HMAC K ] SD

Set timeout to receive destination ACK or FA

Msgk

SD

E K−1 (mk , nk )

e1k = hk , e2k = H (nk ), e3k = H ( M k +1 , hk +1 , H (nk +1 ))

SD

Set timer for ACK or FA

Verify nk

Yes, Cancel timer, Forward Upstream ACK k || nk

Verify H ( nk ) = e ? k 2

If true, assume mk successful

ACK k || n k

…

ACK k || nk

No, drop ACKk

Fig.1. The authentication process of the data and ACK packets.

previously released commitment tag H ( M 2 , h2 , H (n 2 )) , to authenticate the current message M 2 and H (n 2 ) . A new commitment H ( M 3 , h3 , H (n 3 )) is included to authenticate the messages to be sent in round three. Each downstream router can verify h2 by validating if H (h2 ) is equal to e11 = h1 stored in the packet forwarding entry

associated with S and D. It then applies the hash function H on the received message [ M 2 , h2 , H (n 2 ) ], and calculates if the result is equivalent to the previous stored commitment e31 . If both checks succeed, the router verifies that the content of [ M 2 , h2 , H (n 2 ) ] has not been modified. Next, it updates the corresponding packet forwarding entry as packet#= 2 , e12 = h2 , e 22 = H (n2 ),

e32 = H (M 3 , h3 , H (n3 )) . The packet Msg 2 is then

scheduled for transmission to the next hop and a timeout is set to receive either a destination ACK or FA. When the destination receives Msg 2 , it verifies HMACK SD contained in M 2 . It drops Msg 2 if the authentication fails. Otherwise, it decrypts the data packet m 2 , the nonce n 2 , and

then sends ACK 2 back to the source. ACK 2 reflects sequence number packet # = 2 and bears n 2 as its authentication tag. Upstream routers accept ACK 2 and cancel their timers for Msg 2 only if H (n 2 ) is the same as the stored commitment e 22

in their packet forwarding entries. The source sends out the third packet upon the reception of a valid ACK 2 . Fig. 1 illustrates the authentication process of data and ACK packets. In summary, the source initially uses digital signature to bootstrap the first hash chain element h1 . At each round of the protocol, the source commits a string consisting of the next message, the next hash chain element, and a hash of the next ACK 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 knowledge of the next hash chain element and, thus, authenticating the next message. This chaining authentication mechanism enables efficient packet verification, as only the first step requires digital signature computations, and all the subsequent rounds only involve simple hash computations.

3527

SD

D. Fault Detection If the timeout at an intermediate node expires, it schedules for transmission to the source an FA for the first downstream link. The FA reflects the sequence number of the failed packet. Suppose that the FA is only protected by an HMAC computed with the secret key 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 attack, we use the feedback mechanism proposed by Awerbuch et al. [4], by incorporating the onion encryption [5] method in the FA propagation process. Furthermore, transmission of the FA packets between each pair of nodes is protected by an HMAC computed using the secret key shared by the transmitter and the receiver (i.e., the next upstream hop of the transmitter), so that the receiver can verify the FA packet is indeed from its downstream hop. The reason is explained in Section III. Pseudo-code for the FA forwarding process is given in Fig. 2. When an intermediate router receives an FA, it verifies that the FA is forwarded from its downstream link and that a timeout is pending for the corresponding data packet. It then cancels the timeout and propagates to its upstream a new FA, which contains its node address, the sequence number of the failed packet, the encrypted FA packet received from its first downstream hop, and an HMAC of the new FA. Both the encryption and the HMAC are computed using the secret key that it shares with the source. If the source timeout expires, it marks its first downstream link as faulty. Upon the reception of an FA, the source S checks the FA from each intermediate node by successively verifying the HMACs and decrypting the next FA. Following the last valid FA, S discovers a faulty link. S then performs the secure route discovery to find a new path to the destination. E .Having Multiple Outstanding Packets and Tolerating Packet Losses In the SDF protocol, we require that the source forwards the next message only after it receives the destination ACK for the previous one. This is to ensure that the previous packet has been received by all downstream nodes, since the authentication of each packet depends on the commitment contained in the previous one. However, we notice that the requirement to wait for the previous ACK before transmitting the next message may cause delayed processing of the data packet. Furthermore, if a data packet 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 packet. 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 packets until their receipt by the destination is acknowledged in combination with a mechanism to detect the locations where retransmitted packets 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 intermediate(source, packet#) cancel_timeout (packet#); enc= this_node. first_downstream_link; transmitter = this_node; FA= [source, packet#, transmitter, enc, Hmac((source + packet# + transmitter + enc), source.key)]; send (FA, Hmac(FA, this_node.prevhop.key)); // This function is called when an intermediate router receives an FA intermediate(FA) if (Hmac(FA, this_node.nexthop.key) is valid) { if (timeout_pending (FA.packet#)) { cancel_timeout (FA.packet#); enc=Encrypt ((FA.transmitter + FA.enc + FA.Hmac), FA.source.key); transmitter = this_node; FA= [FA.source, FA.packet#, transmitter, enc, Hmac( (FA.source +FA.packet#+ transmitter +enc), FA.source.key))]; send (FA, Hmac(FA, this_node.prevhop.key)); } } // This function is called at the source when receiving an FA source(FA) if (timeout_pending (FA.packet#)) { cancel_timeout (FA.packet#); source = FA.source; faulty_link.start = this_node; while (FA.enc != FA. transmitter. first_downstream_link) { if (FA.Hmac != Hmac((source + FA.packet# + FA. transmitter + FA.enc), FA. transmitter.key)) { faulty_link.end = FA. transmitter; Report_faulty_link (faulty_link.start, faulty_link.end); Return; } faulty_link_start = FA. transmitter; FA. transmitter, FA.enc, FA.Hmac = Decrypt (FA.enc, FA. transmitter.key); } Report_faulty_link (FA.enc); } Fig.2. Pseudo-code for the FA propogation process.

F. Secure Route Discovery Since link failure problems are often due to non-malicious causes (congestion, node movement, etc.), a reasonable first step after identifying a faulty link is to route around it. The source can notify downstream routers of the problem, and try to discover a new route that does not include the detected faulty link. If repeated attempts of rerouting are of no avail, then it becomes more likely that an attacker is responsible for the link failure problem. An out-of-band action, such as human intervention, can be taken to solve the problem. The source that discovers a faulty link during the data forwarding process needs to initiate a route request (RREQ) packet in order to find a new path to the destination. A secure route discovery protocol [7-10] must be used in conjunction with SDF to enhance the robustness of the overall data transmission process. In the RREQ, the source specifies and signs any faulty link that it detected. Other nodes in the network would then take the faulty link information into account in deciding whether to forward or suppress a route request, and try to route around the specified faulty link. However, other nodes should not use this information to alter their own exclusion link list, so as to prevent the adversary from incriminating innocent nodes.

3528

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 block 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 packets. This bit is turned on only if the source cannot obtain a RREP packet 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 packet that they forward to the next hop an HMAC computed using pair-wise link keys, so that the receiver can verify identity of the transmitter. This requirement guarantees correct neighboring hop information and prevents attackers from incriminating non-faulty links by impersonation. III. SECURITY ANALYSIS The security of the authentication mechanism used in SDF protocol follows inductively. Assuming faithful execution up to round k, and an attacker has intercepted the kth message and obtained the string M k , h k , H ( n k ), H ( M k +1 , hk +1 , H (n k +1 )) . He cannot modify M k , H ( nk ) as the commitment H (M k , hk , H (nk )) which was sent in the previous round contains them; he cannot change the current commitment H ( M k +1 , hk +1 , H (nk +1 )) either, as it contains as an input hk +1 which he does not know, but which is committed by hk ; and if he forwards anything other than the correct value of hk , then this will fail to verify against the previous hash chain element hk −1 . With any modification to M k , H ( nk ) or hk , which are protected by the previous commitment and the hash chain, the current packet will be dropped by the adversary's next hop. Modifying the current commitment H ( M k +1 , hk +1 , H (nk +1 )) is equivalent to dropping the next packet. In either case, the adversary will eventually be detected by its upstream hop. Authenticating the hashed value of the ACK nonce H ( nk ) during the packet propagation process enables easy verification of the corresponding ACK k from the destination. Since only the destination can decrypt the nonce, the reception of a valid ACK with the correct nonce implies successful delivery of the packet to the destination. The onion encryption of FA prevents the adversary from incriminating non-faulty links by modifying the FA packet or generating false FA. Such misbehaviors can be detected by the source during its successive verification of the HMAC contained in the FA from each intermediate node. FA transmission is protected with an HMAC computed with a link key 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 packet. 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 ACK or FA since it has cancelled the timer for this packet. The consequence is that the source will detect the non-faulty link that is incident on the afore-mentioned non-faulty router as faulty. Moreover, we request the transmission of data packets is authenticated by an HMAC computed with a link key shared between the transmitter and receiver, so that the receiver only accepts data packets coming from its upstream hop on the data forwarding path. This is to prevent the wormhole attackers [11] from incriminating non-faulty links. Suppose W1 and W2 are two attackers which form a wormhole by establishing a path and tunnel packets from one to another. Assuming in the kth round, W1 has intercepted the kth message and obtained the string M k , h k , H ( n k ), H ( M k +1 , hk +1 , H (n k +1 )) . W1 can tunnel it to W2, which modifies the content of H ( M k +1 , hk +1 , H (n k +1 )) , and sends M k , h k , H ( n k ), H ' ( M k +1 , hk +1 , H (n k +1 )) to its nearby node B on the packet forwarding path. If B has no means to authenticate the transmitter, it will accept the modified packet and stores H ' ( M k +1 , hk +1 , H (n k +1 )) as the commitment for the next message, since the authentication of M k , hk , H ( n k ) succeeds. W1 then sends the unmodified message downstream. When B receives the correct kth message forwarded by its previous hop A, it will drop the packet, since it has already forwarded ‘this message’ with the same sequence number. In the next round, when A forwards to B the (k+1)th message M k +1 , hk +1 , H (nk +1 ), H (M k + 2 , hk + 2 , H (nk + 2 )) , B is going to drop it, as it fails to verify against the false commitment H ' ( M k +1 , hk +1 , H (n k +1 )) that B obtained in the previous round from W2. Eventually, A will generate an FA to report the non-faulty link AB. However, by verifying the transmitter’s identity, B will reject the modified message sent from W2, since it is not in its upstream hop on the data forwarding path. Being a malicious source, the adversary may generate an invalid HMACK SD for the destination, and attach a valid signature on the packet. The downstream nodes cannot verify HMACK SD except the destination, which will then drop the packet. Such an attempt causes the previous hop of the destination to generate an FA with regard to the non-faulty link 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. PERFORMANCE ANALYSIS Our protocol enables efficient security processing of data and control packets 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 SDF to discover and maintain routes for delivery of data packets, we used ns-2 with CMU mobility extensions [12] to simulate its operation and compare it with the AODV protocol.

3529

We used the 802.11 MAC 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 [12]: it starts at a random position, travels to another random location with a velocity uniformly chosen between 0 and vmax 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 1, 5, 10, 15 and 20 m/s, with a pause time fixed at 30 seconds. Each source forwards 4 CBR packets per second and the application data payload size is 512 bytes. We modeled an enhanced version of SDF by utilizing 4 hash chains and independently applying our protocol to four partitions of the sequence number space, which enables 4 outstanding packets simultaneously. We modified the ns-2 AODV model in several ways. We increased the packet sizes to incorporate additional fields that are necessary for authenticating the packets. We added another packet type for FA. In our simulation, we used a digital signature of 160 bits (e.g. ECPVS digital signature [13]) and a hash of 160 bits. In addition, a signature generation delay of 2 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 Mobile Pentium III (856 MHz) processor. Furthermore, we measured 20µs on average to compute an HMAC for 512 byte packet using the SHA-1 hash function. In order to compare the performance of the SDF-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 packets and local repair of routes. Link layer feedback was enabled. Table II shows the comparison results that compare the SDF-enhanced AODV protocol with the plain AODV protocol. Each data point is the average of 10 simulation runs with identical configuration but different randomly generated mobility patterns. We computed three metrics for each simulation run: Packet Delivery Ratio (PDR): Adding the security features in SDF reduces the PDR by 1.33% on average and by no more than 3% at any moving speed, which suggests that the SDFenhanced AODV is still highly effective in discovering and maintaining routes for delivery of data packets. 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 SDF-enhanced AODV is significantly higher than plain AODV, due to the authentication byte overhead in routing and data control packets, including signatures, hash tags, FAs and ACKs. We notice that the byte overhead of SDFenhanced AODV reduces at higher mobility. This is because fewer packets are delivered, and hence less hash tags and ACKs are transmitted. Although the number of routing packets increases at higher mobility, since the number of route discoveries is a small fraction of the number of packets and ACKs delivered, the overall byte overhead is reduced.

TABLE I PARAMETERS FOR SDF SIMULATIONS Number of Nodes

50

Pause Time

30 seconds

Space Size

1000 m x 1000 m

Node Transmission Range

250 m

Number of Source-Destination Pairs

10

Source Data Pattern

4 packets/second

Application Data Payload Size

512 bytes/packet

ECPVS Signature Length

160 bits

Hash Length

160 bits

TABLE II PERFORMANCE RESULTS COMPARING SDF-ENHANCED AODV AND AODV

v max

PDR (%)

Byte Overhead

Delay (seconds)

1 m/s 5 m/s 10 m/s

AODV 99.67 99.05 97.10

SDF 98.94 96.64 95.36

AODV 0.0435 0.0408 0.0772

SDF 0.4575 0.4855 0.3472

AODV 0.0305 0.0412 0.0398

SDF 0.0414 0.0474 0.0456

15 m/s 20 m/s

94.86 93.88

93.85 93.12

0.0860 0.1271

0.3615 0.3545

0.0609 0.1176

0.0668 0.1280

Average End-to-End Delay of Data Packets: The data packet latency for SDF-enhanced AODV protocol is only slightly higher than plain AODV, with additional 7.8 ms delay on average. This is due to the digital signature generation and verification for each route discovery process. The authentication of data packets only requires signature verification at the first step. The following steps use efficient hash verification, which takes less than 20µs. Therefore, the security processing of the SDF 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 packet forwarding. For example, it requires the scheduling of a timeout for every valid received packet. However, this state does not impose a significant overhead primarily because of the limited depth of the pipelines that are available in ad hoc networks due to the limited available bandwidth, the shared medium, and the physical characteristics of wireless broadcast channels. In this section we evaluated the performance of the SDF protocol in a non-adversarial setting. The security properties of our protocol were discussed in Section III. The validation of the recovery capabilities of SDF by simulation is a topic of current investigation. V. RELATED WORK The earliest work on fault-tolerant forwarding was done by Radia Perlman [14]. Perlman designed the Network-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 packet forwarding the use

3530

of multipath routing was proposed by Perlman. In contrast, in this paper, we are addressing the detection of data packet forwarding misbehavior at the link 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. Multipath routing and misbehavior detection at the path level were also investigated in [15]. Awerbuch et al. [4] propose a protocol that detects faulty links by using adaptive probing techniques and routes around faults. SDF 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 (MAC) and encrypt the probing information with the secret key that it shares with probing nodes and, therefore, it cannot be used with distance vector protocols. Padmanabhan and Simon’s Secure Traceroute [16] uses signed probe packets targeting intermediate routers, which enable end hosts or routers to adaptively detect and locate the source of routing misbehaviors. Our recent paper [17,18] 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 packets requires the computation of MACs and hashes. The MAC 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 networks, for example, in [19, 20]. One-time signature was first introduced by Lamport [2]. Anderson et al. [21] present the Guy Fawkes protocol which provides stream authentication between two parties. By making signatures interactive, their protocol constructs digital signatures that require only a small number of hash function computations each. However, the scheme cannot tolerate packet loss and does not scale to a large number of receivers. Perrig et al. proposed a stream authentication protocol called TESLA [22], which provides authenticated broadcast based on efficient MAC computation and delayed disclosure of the authentication key, without the limitations of the Guy Fawkes protocol. TESLA employs a chain of authentication keys linked 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 key to authenticate the received packet. In our case of Byzantine detection, a source wants to reliably unicast a sequence of packets to one destination, and locates faults on the packet forwarding path if any. Since the packet forwarding is not a broadcast process, we use a chaining mechanism similar to the Guy Fawks protocol, and save the overhead of performing synchronization among the network nodes. To overcome the limitation of packet loss, we adopt the key chain idea in TESLA that lets us bind a hash chain to a sequence of messages. Other work in secure routing [7-10] is concerned with protecting route discovery. SDF, on the other hand, targets at

securing the data forwarding process. SDF 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 SDF protocol, which provides a solution for secure data forwarding in wireless ad hoc networks. The protocol can detect and locate faulty links on a per packet basis so that an appropriate action can be taken. SDF provides authentication using efficient hash chains and one-time hash tag commitments. The simulation results show that the SDF-enhanced AODV is as efficient as the plain AODV in discovering and maintaining routes for delivery of data packets, at the cost of using larger routing packets and adding data control packets which result in a higher overall bytes overhead, and in exchange for a slightly higher packet delivery latency because of the cryptographic computation incurred. REFERENCES [1] C. Perkins and E. Royer, “Ad-Hoc On-Demand Distance Vector Routing,” Proc. IEEE WMCSA, 1999. [2] L Lamport, “Constructing Digital Signature Based on a Conventional Encryption Function,” SRI TR CSL 98 (1979). [3] The Keyed-Hash Message Authentication Code (HMAC), No. FIPS 198, National Institute for Standards and Technology (NIST), 2002. [4] B. Awerbuch, D. Holmer, C. Nita-Rotaru, H. Rubens, “An On-Demand Secure Routing Protocol Resilient to Byzantine Failures,” Proc. ACM Wise, 2002. [5] P. F. Syverson, D. M. Goldschlag, and M. G. Reed, “Anonymous connections and onion routing,” Proc. IEEE Symposium on Security and Privacy, 1997. [6] I. Avramopoulos, H. Kobayashi, A. Krishnamurthy, and R. Wang, “Opt and Vent: An Efficient Protocol for Byzantine Detection in Wireless Ad Hoc Network Routing,” Technical Report TR-709-4, Princeton University, Dept. of Computer Science, Oct. 2004. [7] K. Sanzgiri, B. Dahill, B. N. Levine, C. Shields, and E. M. Belding-Royer, “A Secure Routing Protocol for Ad Hoc Networks,” Proc. IEEE ICNP 2002. [8] Y. C. Hu, D. Johnson, and A. Perrig, “SEAD: Secure efficient distance vector routing for mobile wireless ad hoc networks,” Proc. IEEE WMCSA, 2002. [9] Yih-Chun Hu, Adrian Perrig, David B. Johnson, “Ariadne: A secure On-Demand Routing Protocol for Ad hoc Networks,” Proc. ACM MobiCom 2002. [10] P. Papadimitratos and Z. Haas, “Secure Routing for Mobile Ad Hoc Networks,” Proc. SCS Communication Networks and Distributed Systems Modeling and Simulation Conference, 2002. [11] Yih-Chun Hu, Adrian Perrig, and David B. Johnson, “Packet Leashes: A Defense against Wormhole Attacks in Wireless Ad Hoc Networks,” in Proc. of Infocom 2003. [12] J. Broch, D. A. Maltz, D. B. Johnson, Y. C. Hu, and J. Jetcheva, “A performance comparison of multi-hop wireless ad hoc network routing protocols,” Proc. ACM Mobicom1998. [13] “Elliptic Curve Pintsov Vanstone Signature,” IEEE P1363: Standard Specifications for Public-Key Cryptography. [14] R. Perlman, “Network Layer Protocols with Byzantine Robustness,” PhD thesis, MIT LCS TR-429, October 1988. [15] P. Papadimitratos and Z. Haas, “Secure Message Transmission in Mobile Ad Hoc Networks,” Elsevier Ad Hoc Networks Journal, 1(1), 2003. [16] V. N. Padmanabhan and D. R. Simon, “Secure traceroute to detect faulty or malicious routing,” Computer Communications Review, 33(1):77–82, 2003. [17] I. Avramopoulos, H. Kobayashi, R. Wang, and A. Krishnamurthy, “Highly Secure and Efficient Routing,” Proc. IEEE Infocom, March 2004. [18] I. Avramopoulos, H. Kobayashi, R. Wang, and A. Krishnamurthy, “Amendment to: Highly Secure and Efficient Routing,” amendment to [14], Feb. 2004. [19] A. Mizrak, K. Marzullo, and S. Savage, “Fault-Tolerant Forwarding in the Face of Malicious Routers,” Proc. 2nd Bertinoro Workshop on Future Directions in Distributed Computing, 2004. [20] A. Mizrak, K. Marzullo, and S. Savage, “Detecting Malicious Routers,” Technical Report CS2004-0789, University of San Diego, Dept. of Computer Science, 2004. [21] R. Anderson, F. Bergadano, B. Crispo, J.-H. Lee, C. Manifavas and R. Needham, “A New Family of Authentication Protocols,” ACMOSR: ACM Operating Systems Review, vol. 32, 1998. [22] A. Perrig, R. Canetti, D. Song, and D. Tygar, “Efficient authentication and signing of multicast streams over lossy channels,” Proc.IEEE Security and Privacy Symposium, May 2000.

3531