Secure routing in mobile wireless ad hoc networks

Ad Hoc Networks 1 (2003) 151–174 www.elsevier.com/locate/adhoc

Secure routing in mobile wireless ad hoc networks Siddhartha Gupte *, Mukesh Singhal Department of Computer Science, University of Kentucky, Lexington, KY 40508, USA

Abstract We discuss several well known contemporary protocols aimed at securing routing in mobile wireless ad hoc networks. We analyze each of these protocols against requirements of ad hoc routing and in some cases identify fallibilities and make recommendations to overcome these problems so as to improve the overall efficacy of these protocols in securing ad hoc routing, without adding any significant computational or communication overhead. Ó 2003 Published by Elsevier B.V. Keywords: Active attacks; Passive attacks; Wormhole attack; Byzantine failures; Secure routing; Ad hoc networks

1. Introduction A wireless ad hoc network is a collection of peer nodes coming together and forming a network onthe-fly. These types of networks do not have a well established centralized infrastructure, and individual member nodes communicate with other nodes within the radio range over a wireless channel and with those outside the radio range using other nodes as intermediaries. In an ad hoc network, neither the network topology nor the membership is fixed, i.e., the nodes keep on moving around and they also come and go from the network. Thus the traditional wired network routing protocols cannot be deployed for this ad hoc paradigm. Taking into consideration both changing topology as well as changing membership, in addition to route establishment or discovery, ad hoc routing protocols need to

*

Corresponding author. E-mail addresses: [email protected] (S. Gupte), [email protected] (M. Singhal). 1570-8705/$ - see front matter Ó 2003 Published by Elsevier B.V. doi:10.1016/S1570-8705(03)00017-9

incorporate ‘‘route maintenance’’, in order to provide for the broken routes in case of member node in the route moving out of the range or leaving the network. This renders route maintenance quintessential for ad hoc paradigm. The wireless medium as well as non-infrastructure nature of the ad hoc networks makes them increasingly vulnerable to a number of attacks. Unlike wired networks where the attacker needs to gain access to the physical medium to launch any kind of attack, in wireless case, an intruder can easily eavesdrop on the on-going traffic. As there is not any centralized infrastructure, it is very difficult to have a key distribution center or a trusted certification authority to provide cryptographic keys and digital certificates to help nodes authenticate themselves. Next, we briefly discuss two routing protocols, namely, AODV and DSR. Most of the secure routing protocols (SRPs) we discuss are based on these two routing protocols. The ad hoc routing protocols can be classified into two types, viz., reactive protocols and proactive protocols. In reactive protocols like AODV

152

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

and DSR, the route discovery is initiated whenever data packets need to be sent, whereas in proactive protocols like DSDV, nodes proactively maintain routes even if no data packets need to be currently sent. In DSR [12], the sender node determines the path along which a packet needs to be forwarded for a particular destination. This path is listed in the data packet header and is referred to as the Ôsource routeÕ. Every node in the network stores route to other nodes in the network by maintaining a dynamic route cache. A node learns routes to other nodes in one out of two ways––when it itself initiates a route to a particular destination or when the node lies on an active path to that destination. In addition to these, a node may also learn a route by overhearing transmissions along the routes of which it is not a part. This is referred to as the promiscuous listening. When a node needs to send a packet to another node, it first checks if an entry for the source route to that destination exists in the route cache. If such an entry already exists, the node inserts the source route into the header of the data packet. The source routes into the list of nodes along which the packet needs to be forwarded in order to reach the destination. The sender forwards the packet to the first node on the route list. This intermediate node in turn forwards the packet to the next node in the list and this continues till the packet reaches the intended destination. If the sender does not have a cache entry with the source route for that destination, DSR route discovery process is initiated for that destination node. The sender broadcasts a ÔROUTE REQUESTÕ. This route request is uniquely identified by the source address, the destination address and the request id. When a node receives this route request, it checks if it itself is the target or if it has a source route cache entry for the intended destination. If either of the above two cases holds, the node responds with a route reply packet to the sender. The route reply consists of a Ôroute recordÕ, which is a list of nodes forming the path from the sender to the destination. If the node does not have a source route cache entry to that destination, it checks if it has already processed this request by checking the source address, destination address

and request id which uniquely identify a request. If it has already handled this request, it is dropped. Otherwise, the node appends its address to the Ôroute recordÕ in the route request packet and forward broadcasts the packet. In the reactive protocol AODV [11], a node discovers or maintains route to a destination if and only if it is the initiator of the route to that destination or is an intermediate node on an active route to that destination. Otherwise, it does not maintain routing information to that destination (no promiscuous listening in AODV). AODV maintains loop-free routes, even when the local connectivity for a node on the route changes. This is achieved by maintaining a counter for each node, called a sequence number. This sequence number of a node is incremented every time the local connectivity of the node changes. In AODV, the route discovery is initiated by the source by generating and broadcasting a route request packet RREQ. The RREQ packet contains sequence numbers for both source as well as destination nodes, called source_sequence_num and destination_sequence_num, respectively. When a node receives a RREQ packet, if the node is itself the destination or it has a valid route to that destination, it determines the freshness of its route table entry (provided such an entry exists) for that destination by comparing the destination_sequence_num in the RREQ with that of its route table entry. The node then either responds with a route reply RREP (if it itself is the destination or has a fresh route to that destination) or rebroadcasts the RREQ to its neighbors. The node makes an entry for this route request in the route table and stores the address of the node from which it received this request as the next hop in the route to the source of this request packet. Similarly when a node receives a response RREP for the request it stores the address of the node from which it received the response RREP as the next hop in the route to that destination. As the RREP travels back to the source, the intermediate nodes forwarding the RREP, update their routing tables with a route to the destination. The RREP has a field for destination_sequence_num. The rest of the paper is organized as follows: In Section 2, we discuss different possible attacks on

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

the routing protocols and in Sections 4–12, we analyze contemporary SRPs with respect to prevention of these attacks.

2. Possible attacks on routing protocols In this paper, we are primarily concerned with the attacks targeting the routing protocols. These attacks can be broadly classified into two main categories: 1. Passive attacks and 2. Active attacks. 2.1. Passive attacks Passive attacks are the attacks in which an attacker does not actively participate in bringing the network down. An attacker just eavesdrops on the network traffic as to determine which nodes are trying to establish routes to which nodes or which nodes are pivotal to proper operation of the network and hence can be potential candidates for subversion and launching denial of service attacks. The attacker can then forward this information to an accomplice who in turn can use it to launch attacks to bring down the network. 2.2. Active attacks Active attacks are the attacks in which an attacker actively participates in disrupting the normal operation of the network services. The attacker drops packets, modifies packets, replays packets, fabricates messages or impersonates as some other nodes, nodes rush packets or tunnel them over high-speed private networks to an accomplice in other part of the network, etc. 2.2.1. Attacks by dropping packets In this type of attack, an attacker either selectively or completely drops packets and so succeeds in disrupting the normal operation of the network. Depending on the pattern by which the attacker drops packets, this attack can be further classified into two types:

153

(i) Black holes: The attacker drops all types of packets both control as well as data. This attack can be prevented by establishing routes free of the black holes or by precluding such type of nodes from existing routes. (ii) Gray holes: The attacker is selective in dropping packets (drops data packets but not control messages). This is not so simple attack to detect. There needs to be some kind of a promiscuous mode of operation in place within the routing protocol wherein nodes can listen to the transmissions of the nodes within the radio range. If a node is found to exhibit such a gray hole behavior, then other nodes need to be alerted about it. Again some kind of trust hierarchy needs to be in place such that the reporting node has to have some trust standing, otherwise, it becomes a basis of yet another attack called blackmail attack where a malicious node may report a benign node to be misbehaving, thereby launching a denial of service attack against that node. 2.2.2. Attacks using modification of protocol messages fields Current routing protocols assume that nodes do not alter the protocol fields of messages passed among nodes. Routing protocol packets carry important control information that governs the behavior of data transmission in ad hoc networks. Since the level of trust in a traditional ad hoc network cannot be measured or enforced, malicious nodes or compromised nodes may participate directly in the route discovery and may intercept and filter routing protocol packets to disrupt communication. Malicious nodes can easily cause redirection of network traffic and DOS attacks by simply altering these fields [7]. For example, in the network illustrated in Fig. 1a, a malicious node M could keep traffic from

A

B

C

D

X

S

A

B

M

M : Bidirectional link

(a)

: Bidirectional link

(b) Fig. 1. Bidirectional link.

C

D

X

154

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

reaching X by consistently advertising to B a shorter route to X than the route to X , which C is advertising. The attacks can be classified as remote redirection attacks and denial of service attacks. Next we look at these attacks. (i) Remote redirection with modified route sequence number: In remote redirection attacks a malicious node uses routing protocol to advertise itself as the shortest path to nodes whose packets it wants to intercept. Protocols such as AODV instantiate and maintain routes by assigning monotonically increasing sequence numbers to routes towards a specific destination. In AODV, any node may divert traffic through itself by advertising a route to a node with a destination sequence number greater than the authentic value. Fig. 1a illustrates an example an ad hoc network. Suppose a malicious node, M, receives the RREQ that originated from S for destination X after it is rebroadcast by B during route discovery. M redirects traffic towards itself by unicasting to B a RREP containing a significantly higher destination sequence number for X than the authentic value last advertised by X . (ii) Redirection with modified hop count: In protocols such as AODV, the route length is represented in the messages by the hop count field. A malicious node can succeed in diverting all the traffic to a particular destination through itself by advertising a shortest route (very low hop count) to that destination. Once the malicious node has been able to insert itself between two communicating nodes, it is able to do anything with the packets passing between them. It can choose to drop packets to perform a denial of service attack, or alternatively use its place on the route as the first step in a man-in-themiddle attack. (iii) Denial of service with modified source routes: DSR routing protocol explicitly states routes in data packets referred to as the source route. In the absence of any integrity checks on this source route, a malicious node can modify this source route and thereby succeed in creating loops in the network or launching a simple denial of service attack.

2.2.3. Attacks using impersonation This type of attack using impersonation [7] could be launched by an attacker node masquerading as another node. The attacker node achieves this by misrepresenting its identity by changing its own IP or MAC address to that of some other node, thereby, masquerading as that node (also referred to as spoofing). This type of an attack could easily be ameliorated by the use of a stronger authentication primitives. 2.2.4. Attacks using fabrication Generation of false routing messages is termed as fabrication of messages. Such attacks are difficult to detect. Such type of attacks can be broadly classified into following three types [7]: (i) Falsifying route error messages: AODV and DSR both have maintenance measures to salvage broken routes when constituent nodes move or fail. If the destination node or an intermediate node along an active path moves or fails, the node which precedes the broken link broadcasts a route error message to all active neighbors which precede the broken link. The nodes then invalidate the route for this destination in their routing table. A malicious node can succeed in launching a denial of service attack against a benign node by sending false route error messages against this benign node. Suppose node S has a route to node X via nodes A, B, and C, as in Fig. 1b. A malicious node M can launch a denial of service attack against X by continually sending route error messages to B spoofing node C, indicating a broken link between nodes C and X . B receives the spoofed route error message thinking that it came from C. B deletes its routing table entry for X and forwards the route error message on to A, who then also deletes its routing table entry. If M listens and broadcasts spoofed route error messages whenever a route is established from S to X , M can successfully prevent data traffic between S and X . This type of an attack could be thwarted by having stronger authentication schemes in place wherein the veracity of route error messages can be authenticated. (ii) Route cache poisoning in DSR: In DSR, a node can learn routing information by overhearing transmissions on routes of which it is not a con-

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

stituent. The node adds this routing information to its own cache. The vulnerability is that an attacker could easily exploit this method of learning routes and poison route caches. If a malicious node M wants to launch a denial of service attack on node X , it would simply broadcast spoofed packets with source routes to X via itself. Any neighboring nodes that overhear the packet transmission may add the route to their route cache. (iii) Routing table overflow attack: A malicious node may attempt to overwhelm the protocol by initiating route discovery to non-existent nodes. The rationale behind this attack is to create so many routes that no further routes could be created as the routing tables of nodes are already overflowing. Proactive routing algorithms attempt to discover routing information even before they are needed, while reactive algorithms create only when they are needed. This makes proactive algorithms more vulnerable to table overflow attacks. 2.2.5. Wormhole attacks A wormhole is a theoretical distortion of spacetime in a network that would link one part of the network with another through a path that is shorter in distance or duration than would otherwise be expected. In wormhole attacks [15], the attacker receives packets at one point in the network and tunnels them to another part of the network and replays them into the network from that point onwards. This form of attack does not require the attacker to have any knowledge of the cryptographic keys. In case of reactive protocols like DSR and AODV, this attack could be launched by tunneling every REQUEST to the target destination node directly. When the destinationÕs neighboring nodes hear this REQUEST packet, they follow normal protocol operation to rebroadcast that REQUEST packet and then discard any other REQUESTS for the same route discovery. Thus this prevents discovery of any routes other than those through the wormhole. This puts the attacker in a position from where any attack can be launched on the network as it practically controls all the routes discovered after the wormhole.

155

In case of proactive routing protocols like DSDV, where nodes detect neighbors by sending HELLO packets, an attacker could tunnel a HELLO packet from A to B and from B to A leading A and B to believe that they are neighbors and when in reality they are not. This could lead to no route being established because of wrong neighborhood perception. The wormhole attacks can be thwarted by using a notion of packet leashes. A leash is any information added to a packet to limit the packetÕs maximum allowed transmission distance. A geographical leash ensures that the recipient of the packet is within a certain distance from the sender. A temporal leash ensures that the packet has an upper bound on its lifetime, thus outing an upper bound on the distance it can travel, since the speed of packet cannot be more than that of light. Any of these leashes can thwart a wormhole attack, as they allow the receiver to detect if the packet has traveled more distance than the leash allows.

3. Desired properties of a secure routing protocol A SRP should be able to create routes between any source destination pair of nodes, even in the presence of malicious nodes. It should have some provisions to detect misbehaving node or group of nodes working in collusion with each other. Once such misbehaving node/s are detected, their misbehavior should be reported to all other legitimate nodes in the network. So that other nodes who have routes containing these bad nodes can revoke these routes and use alternate routes which do not contain these bad nodes. There should also be some kind of a trust hierarchy among the member nodes, so that a group of malicious nodes do not launch a blackmail attack against a legitimate node by forwarding false misbehavior reports about this good node. In addition to these, the SRP should be prepared to handle situation when malicious nodes do in fact enter an uncompromised route or succeed in subverting a benign node on a route. In case of such a subversion, the protocol should be able to

156

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

single out the subverted node and preclude it from all existing routes. The protocol should be able to maintain confidentiality of the network topology. It should prevent an attacker from knowing which nodes are bottlenecks in the network or which nodes are crucial for successful transmission along existing routes. Otherwise such an attacker could succeed in launching denial of service attacks by subverting these crucial nodes.

4. Security aware ad hoc routing protocol (SAR) The main idea behind the security aware ad hoc routing protocol [3] is to protect the route establishment itself, so that no node with questionable trust level becomes a part of the route. This protocol introduces the notion of a Trust Hierarchy, where member nodes of the network are classified into different trust levels and these trust levels are immutable, i.e., a node with a lower trust level cannot change to a higher trust level on-the-fly. The initiator of the route includes a security metric in the route request. This security metric can be the minimum security/trust level of the node required to participate in the route discovery, suggesting that only those nodes that have this minimum security level can take part in the route discovery and other nodes that do not have the necessary trust level drop the request packets. This ensures that security aware ad hoc routing finds a route with quantifiable guarantee of security. This can be realized by having nodes of a trust level share a key. So a node that does not have a particular trust level will not possess the key for that level and hence will not be able to decrypt the packets encrypted using the key of that level and hence would be left with no alternative but to drop the packet thereby precluding itself from the route establishment. As shown in Fig. 2, the route discovered using security aware ad hoc routing protocol may not necessarily be the shortest route between a source destination pair. But the discovered route is the most secure in terms of trust levels of the component nodes of the route.

Shortest Route

Secure Route

Fig. 2. Route formation in security aware ad hoc routing: (d) secure node with the required keys; ( ) other nodes in the network.




The protocol is not very scalable especially when there are many levels of trust. These many levels of trust mean those many keys have to be generated and distributed to nodes. Furthermore, when a node of a particular trust level receives a route request packet of a particular trust level, the receiving node has no idea as to what level the packet belongs to, so it has to try decrypting the packet with all the available keys. If the packet does not decrypt with any of the available keys, the node assumes that it does not have the necessary key and hence the necessary trust level and drops the packet. As the route request packets are flooded and this scenario happens at all the nodes, a considerable computational overhead is incurred. If a node does not have the necessary trust privilege, it wastes quintessential CPU cycles on worthless computation. An obvious solution to this problem is to append a plaintext the trust level of the request packet, thereby the nodes do not have to spend crucial CPU cycles in decrypting the packet with the available key set. All they got to do is to read this plaintext and make the decision accordingly whether they can decrypt this packet and hence participate in the route establishment. The security aware ad hoc routing protocol can be easily deployed on the top of any of the existing routing protocols. We now discuss SAODV [5], a variant of this security aware protocol deployed on the top of AODV routing protocol. Changes are made to the route discovery stage of the AODV

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

protocol in the form of additional fields to the RREQ and RREP packets. Both RREQ and RREP packets have two additional fields, viz., RQ_ SEC_REQUIREMENT (RP_SEC_REQUIREMENT is the corresponding one in RREP) and RQ_SEC_GUARANTEE (RP_SEC_GUARANTEE is the corresponding one for RREP). RQ_SEC_REQUIREMENT value in the RREQ is set by the route initiator and is immutable, i.e., no intermediate node can change this field in transit. This value indicates the minimum security rating that an intermediate node should possess in order to be part of the route. When an intermediate node receives a RREQ packet, it checks the RQ_SEC_REQUIREMENT field and compares the value to its own security rating (i.e., the trust level). If the nodeÕs security rating is more than RQ_SEC_REQUIREMENT, the node forwards the packet, otherwise the node drops the packet. When an intermediate node decides to forward the request, the RQ_SEC_GUARANTEE is set to a value which indicates the maximum security level afforded by the discovered paths. This field is useful in the case where route discovery comes up with a route which is more secure than the one requested by the initiator. Since the security aware ad hoc routing protocol tries to implement the trust level among nodes by having a key for every trust level, another cause for concern is the nature of ad hoc networks, where membership keeps on changing, i.e., nodes come and go regularly. Hence fresh keys have to be generated and distributed every time any new node comes in or a node goes out, thus augmenting the computational overhead. If the keys are not generated afresh when a member node leaves the network, there is a likelihood that this node might give the keys to a malicious node or give a higher trust level keys to a node with a lower trust level.

157

mation and can discard such malevolent replies. This is realized through the existence of a security association (SA) between the pair of end nodes, i.e., source and destination without the intermediate nodes having to cryptographically validate the control traffic. Such a security association is assumed to exist priori to the route initiation. This protocol assumes that this SA can be achieved through a shared key KST between the source S and target T . This is a strong assumption given the nature of ad hoc networks. It is as good as assuming a SA through a shared secret among two strangers. The source S initiates the route discovery by putting together a route request packet as shown in Fig. 3. The SRP adds an additional header called SRP header to the underlying routing protocol packet. The SRP header is as shown in Fig. 4. The query sequence number, QSEQ , is a monotonically increasing 32 bit sequence number maintained by the source node S for each destination T it has a security association with. It increases monotonically for every route request generated by S for T , thus allowing T to detect outdated/replayed requests. QSEQ is initialized at the establishment of the SA and is generally not allowed to wrap around.

0123456789

0123456789 0123456789

TYPE

01234567890

RESERVED QUERY QUERY

IDENTIFIER

SEQUENCE SRP

NUMBER MAC

Fig. 3. Route request packet.

0123456789012345678901234567890 IP HEADER

5. Secure routing protocol BASIC ROUTING PROTOCOL PACKET

The SRP [2] attempts to guarantee that the node initiating the route discovery will be able to differentiate between the legitimate replies and the replies meant to provide false topological infor-

SRP HEADER

Fig. 4. SRP header.

158

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

The query identifier QID is a random 32 bit identifier generated by S and is used by the intermediate nodes as a means to identify the request. Since QID is an output of a secure pseudo-random number generator and is unpredictable by an adversary, it providing protection against attackers who fabricate requests only to cause subsequent requests to be dropped. SRP MAC is a 96 bit value calculated using the shared key KST over IP addresses of the source S and target T and the two identifiers QSEQ and QID . It not only validates the integrity of the request but also authenticates the origin of the packet to the target, as the MAC could have been calculated by the node that has the knowledge of KST and knowledge of KST is only with the node that has security association with the target. When an intermediate node receives such a route request, it checks if an SRP header is present or not. If not present, the packet is discarded, otherwise the node extracts the IP address of the source and destination as well as the QID from the request and creates an entry for the request in the query table. If an entry already exists for the request that source destination pair with the same QID , the request is dropped by the node. Otherwise, the node appends its IP address to the request and rebroadcasts the request. Thus IP addresses of the intermediate nodes keep on accumulating on the route request. The above situation warrants that the QID should be sufficiently random and an adversary with finite computation capacity should not be able to predict it. Otherwise, the attacker can prevent route from being established between the given source destination pair, as it would fabricate request packets with this QID and the intermediate nodes will not forward the legitimate requests when they get to them as an entry already exists in the query table for that particular QID . When the target T receives this request packet, it verifies that the packet has originated from the node with which it has SA. QSEQ is then compared with SMAX , the maximum query sequence number received from S. If QSEQ 6 SMAX , the request is considered to be outdated/replayed and is discarded. Else the keyed hash of the request field is calculated and matched against the SRP MAC.

The equality validates the integrity of the request as well as the authenticity of the sender. The destination broadcasts a route reply to its one hop neighbors in order to thwart a potentially malicious neighbor from controlling multiple replies. For each valid request, the destination puts the accumulated route in the form of IP addresses of intermediate nodes into the route reply packet. The QSEQ and QID fields from the route request are copied into the corresponding fields of the reply packet. MAC is calculated to preserve the integrity of the packet in transit. The QSEQ and QID fields verify the freshness of the packet to the source. When the source S receives the route reply packet, it checks source and destination addresses, QID and QSEQ and discards the reply if it does not correspond to the currently pending query. Otherwise, it compares the reply IP source-route with the reverse of the route carried in the reply payload. If the two routes match, MAC is calculated using the replied route the SRP header fields and KST . The successful verification confirms that the request did indeed reach the intended destination T and the reply was not corrupted on the way back from T to S. Furthermore, since the reply packet has been routed and successfully received over the reverse of the route it carries, the routing information has not been compromised during the request propagation. Intermediate nodes also measure the frequency of queries received from their neighbors. Intermediate nodes maintain a priority ranking of their neighbors––highest priority to nodes generating requests at the lowest rate and the lowest rating for those with highest rate. In case when two packets arrive at the same time, the neighbor whose ranking is high, is given a priority in routing over the one with the lower ranking. This SRP guarantees the discovery of a correct route, even in the presence of malicious nodes. The protocol obviates the need of a certification authority, thereby suiting itself to the ad hoc paradigm. The protocol also does not necessitate the knowledge of keys of all member nodes. The only requirement of this protocol is that there should be a prior security association between the two nodes that need to communicate with each other. This kind of a security association is realized through

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

shared secret keys between any two pair of nodes. However, when malicious nodes succeed in subverting benign nodes, the malicious nodes could easily gain access to the shared secret keys. The malicious node can then masquerade as the subverted good node and initiate communication with other good node with whom the subverted good node has a security association.

6. Routing using pre-deployed security infrastructure We assume the existence of certain amount of security infrastructure. The type of ad hoc environment that we are dealing with here is called managed-open environment. A managed-open environment assumes that there is an opportunity for pre-deployment. That is nodes wishing to communicate can exchange initialization parameters beforehand, perhaps within the security of an infrastructured network where session keys may be exchanged or through a trusted third party like a certification authority. 6.1. ARAN protocol in managed-open environment ARAN or authenticated routing for ad hoc networks [7] detects and protects against malicious actions by third parties and peers in ad hoc environment. ARAN introduces authentication, message integrity and non-repudiation to an ad hoc environment. ARAN is composed of two distinct stages. The first stage is simple and requires little extra work from peers beyond traditional ad hoc protocols. Nodes that perform the optional second stage increase the security of their route, but incur additional cost for their ad hoc peers who may not comply (e.g., if they are low on battery resources). ARAN makes use of cryptographic certificates for the purposes of authentication and non-repudiation. 6.1.1. Stage 1 Stage 1 contains a preliminary certification stage and a mandatory end–end authentication

159

stage. It is a lightweight stage and does not demand too many resources. 6.1.1.1. Preliminary certification. ARAN uses a trusted certificate server T . Before entering the ad hoc network, each node has to request a certificate from T . In case of node A, the certificate looks as shown below: T ! A : CertA ¼ ½IPA ; KAþ ; t; eKT  The certificate contains the IP address of A, the public key of A, a timestamp t of when the certificate was created, and a time e at which the certificate expires. These variables are concatenated and signed by T . All nodes must maintain fresh certificates with the trusted server and must know T Õs public key. 6.1.1.2. End-to-end authentication. End-to-end authentication verifies whether the intended destination was reached. In this stage, the source trusts the destination to choose the return path. (i) Source node: The source node A broadcasts a route discovery packet (RDP) and thus initiates the route discovery to destination X . A ! broadcast : ½RDP; IPX ; CertA ; NA ; tKA The RDP includes a packet type identifier (‘‘RDP’’), the IP address of the destination (IPx ), AÕs certificate (CertA ), a nonce NA , and the current time t, all signed with AÕs private key. Each time node A performs route discovery, it monotonically increases the nonce. Nodes store the nonce they have last seen with its timestamp. (ii) Intermediate node: Each node keeps track of the predecessor node from which it received the RDP packet. It then forwards the RDP to each of its neighbors, signing the contents of the message. This signature prevents spoofing attacks that may alter the route or form loops. Let AÕs neighbor be B. B ! broadcast : ½½RDP; IPX ; CertA ; NA ; tKA KB ; CertB If a node has already seen the (NA , IPA ) tuple, it drops the RDP packet. Otherwise, it forwards the packet to its neighbors. Upon receiving the broadcast, BÕs neighbor C validates the signature with the given certificate. C then rebroadcasts the RDP to its neighbors, first removing BÕs signature.

160

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

C ! broadcast : ½½RDP; IPX ; CertA ; NA ; tKA KC ; CertC (iii) Destination node: Eventually the message reaches the destination X . The destination then replies to the first RDP for a given source and nonce pair. It unicasts a reply (REP) back to the source along the reverse path. The route discovered in such a manner may not be the shortest route. X ! D : ½REP; IPA ; CertX ; NA ; tKX  (iv) Intermediate node for REP: Intermediate nodes keep track of the predecessor node or the node from which it received the RDP. So that when the intermediate node receives an REP for the same source-nonce pair, it knows where to route the REP packet. D ! C : ½½REP; IPA ; CertX ; NA ; tKX  KD ; CertD C validates DÕs signature, removes the signature, and then signs the contents of the message before unicasting the RDP to B. C ! B : ½½REP; IPA ; CertX ; NA ; tKX  KC ; CertC A node checks the signature of the previous hop as the REP is returned to the source. This avoids attacks where malicious nodes instantiate routes by impersonation and replay of X Õs message. (v) Source node: When the source receives the REP, it verifies that the correct nonce was returned by the destination as well as the destinationÕs signature. Only the destination can answer an RDP packet. Other nodes that already have paths to the destination cannot reply for the destination. Because only the destination can send REPs, loop freedom is guaranteed. ARAN requires that nodes keep one routing table entry per source–destination pair that is currently active. This is certainly more costly than per-destination entries in non-secure ad hoc routing protocols. 6.1.2. Stage 2 Stage 2 starts only after Stage 1 is over. This is because the destination certificate is required in Stage 2. This stage is primarily used for discovery of shortest path in a secure fashion.

(i) Source: The source begins by broadcasting a Shortest Path Confirmation (SPC) message to its neighbors (the same variables are used as in stage 1). A ! broadcast : SPC; IPX ; CertX ; ½½IPX ; CertA ; NA ; tKA KX þ The SPC message begins with the SPC packet identifier (‘‘SPC’’), X Õs IP address and certificate. The source concatenates a signed message containing the IP address of X , its certificate, a nonce and timestamp. This signed message is encrypted with X Õs public key so that other nodes cannot modify the contents. (ii) Intermediate node: A neighbor B that receives the message, rebroadcasts the message after including its own cryptographic credentials on the top of already accumulated cryptographic credentials (onion signing). B signs the encrypted portion of the received SPC, includes its own certificate, and re-encrypts with the public key of X . This public key can be obtained in the certificate forwarded by A. B ! broadcast : SPC; IPX ; CertX ; ½½½½IPX ; CertA ; NA ; tKA KX þ KB ; CertB KX þ Nodes receiving the SPC packet create an entry in their routing table for that particular source-nonce pair in order to duplicate packets. The entry also serves to route the reply packet from the destination along the reverse path. (iii) Destination node: Once the destination X receives the SPC, it checks that all the signatures are valid. X replies to the first SPC it receives and also any SPC with a shorter recorded path. X sends a Recorded Shortest Path (RSP) message to the source through its predecessor D. The onionlike signing of messages tells the destination which path is the shortest. However, the overhead is more as the destination has to store all the SPCs in order to decide which one is the shortest. X ! D : ½RSP; IPA ; CertX ; NA ; routeKX  The source eventually receives the packet and verifies that the nonce corresponds to the SPC it originally generated.

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

The onion-like signing of messages prevents nodes in the middle from changing the path in several ways. First, to increase the path length of the SPC, malicious nodes require an additional valid certificate. Second, malicious nodes cannot decrease the recorded path length or alter it because doing so would break the integrity of the encrypted data. 6.2. Route maintenance ARAN is an on-demand protocol. Nodes keep track of whether routes are active. When no traffic has occurred on an existing route for that routeÕs lifetime, the route is simply de-activated in the route table. Data received on an inactive route causes nodes to generate an Error (ERR) message that travels the reverse path towards the source. Nodes also use ERR messages to report links in active routes that are broken due to node movement. All ERR message must be signed. For a route between source A and destination X , a node B generates the ERR message for its neighbor C as follows: B ! C : ½ERR; IPA ; IPX ; CertC ; NB ; tKB This message is forwarded along the path towards the source without modification. A nonce and timestamp ensures the ERR message is fresh. Because messages are signed, malicious nodes cannot generate ERR messages for other nodes. Nonrepudiation provided by the signed ERR message allows a node to be verified as the source of each ERR message that it sends. A node which transmits a large number of ERR messages, whether the ERR messages are valid or fabricated, should be avoided.

161

T ! broadcast : ½revoke; CertR KT  Any node receiving this message rebroadcasts it to its neighbors. Revocation notices need to be stored until the revoked certificate would have expired normally. Any neighbor of the node with the revoked certificate needs to reform routing as necessary to avoid transmission through the now untrusted node. This method is not fail-safe. If an untrusted node, whose certificate is being revoked, is the only link between two parts of an ad hoc network, it may not propagate the revocation message to the other part––leading to a partitioned network. To detect this situation and to hasten the propagation of revocation notices, when a node meets a new neighbor, it can exchange a summary of its revocation notices with that neighbor. If these summaries do not match, the actual signed notices can be forwarded and rebroadcast to restart propagation of the notice.

7. Mitigating routing misbehavior Misbehaving nodes can disrupt normal operation of the network and thus reduce network throughput and result in poor robustness. Marti et al. [8] propose a technique to identify and isolate such nodes by installing a watchdog and a pathrater on each node in the ad hoc network. The protocol assumes support for promiscuous mode of operation for the nodes. This helps the nodes supervise each others operation. The other assumption is that the underlying ad hoc routing protocol is DSR. It is possible to extend the mechanism to other routing protocols as well. 7.1. Mechanism

6.3. Key revocation ARAN attempts a best effort key revocation that is backed up with limited time certificates. In the event that a certificate needs to be revoked, the trusted certificate server, T , sends a broadcast message to the ad hoc group that announces the revocation. Calling the revoked certificate CertR , the transmission appears as:

The watchdog identifies misbehaving nodes, while the pathrater avoids routing packets through these nodes. When a node forwards a packet, the nodeÕs watchdog verifies that the next node in the path also forwards the packet. The watchdog does this by listening promiscuously to the next nodeÕs transmissions. If the next node does not forward the packet, then it is considered to be misbehaving.

162

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

The pathrater uses this knowledge of misbehaving nodes to choose the network path that is most likely to deliver packets or in other words avoids selecting routes having misbehaving nodes.

S

A

B

1

D

Fig. 6. Ambiguous collisions. X: packets arriving simultaneously (collisions).

7.2. Watchdog The watchdog attempts to detect misbehaving nodes. Fig. 5 illustrates the operation of the watchdog works. Node A cannot directly send packets to node C, but it can send the packets to B and then listen in on node BÕs traffic. Thus, when A transmits a packet for B to be forwarded to C, A can often tell if B really transmitted the packet to node C. If encryption is not performed separately for each link, then A can also tell if B has tampered with the payload or the header. The watchdog maintains a buffer of recently sent packets and comparing each overheard packet with the packet in the buffer to see if there is a match. If so, the packet in the buffer is removed and forgotten by the watchdog, since it has been forwarded. If the packet has remained in the buffer for longer than a certain timeout, the watchdog increments a failure tally for the node responsible for forwarding the packet. If the tally exceeds a certain threshold, it infers that the node is misbehaving and sends a message to the source notifying it of the misbehaving node. The watchdog might not detect misbehaving nodes in presence of (1) ambiguous collisions, (2) receiver collisions, (3) limited transmission power, (4) false misbehavior, (5) collusion between neighboring nodes and (6) partial dropping. 7.3. Analysis of watchdog’s weaknesses 7.3.1. Ambiguous collision The ambiguous collision problem prevents A from overhearing transmissions from B. As Fig. 6 illustrates, a packet collision occurs at A while it is

S

1 2

A

B

listening to B to forward a packet. A does not know if the collision was caused by forwarding a packet as it should or if B never forwarded the packet and the collision was caused by other nodes in AÕs neighborhood. Because of this uncertainty, A should instead continue to watch B over a period of time. 7.3.2. Receiver collision In the receiver collision problem, node A can only tell whether B sends the packet to C, but it cannot tell if C receives it. If a collision occurs at C when B first forwards the packet, A only sees B forwarding the packet and assumes that C successfully receives it. Thus, B could skip retransmitting the packet and evade detection as shown in Fig. 7. 7.3.3. False misbehavior False misbehavior can occur when nodes falsely report other nodes as misbehaving. A malicious node could attempt to partition the network by claiming that some nodes following it in the path are misbehaving. For instance, node A could report that node B is not forwarding packets when in fact it is. This will cause S to mark B as misbehaving when A is the culprit. This behavior, however, will be detected eventually. Since A is passing messages onto B (as verified by source S), then any acknowledgements from D to S will go through A to S, and S will wonder why it receives replies from D when supposedly B dropped packets in the forward direction. In addition, if A drops acknowledgements to hide them from S, the node B will

D S

A

B

Promiscuous listening

Fig. 5. Operation of watchdog.

Fig. 7. Receiver collision.

C

D

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

detect this misbehavior and will report it to destination D. 7.3.4. Limited transmission power A misbehaving node that can control its transmission power can circumvent the watchdog. A node could limit its transmission power such that the signal is strong enough to be overheard by the previous node but too weak to be received by the true recipient. 7.3.5. Multiple colluding nodes Multiple nodes in collusion can mount a more sophisticated attack. For example, B and C from Fig. 5 could collude to cause mischief. In this case, B forwards a packet to C but it does not report to A when C drops the packet. Because of its limitation, it may be necessary to disallow two consecutive untrusted nodes in a routing path. 7.3.6. Partial dropping A node can circumvent the watchdog by dropping packets at a lower rate than the watchdogÕs minimum misbehavior threshold. 7.4. Pathrater In addition to the watchdog, each node also runs a pathrater. It combines the knowledge of misbehaving nodes with link reliability data to pick the most reliable route. Each node maintains a rating for every other node it knows about in the network. It calculates a path metric by averaging the node ratings in the path. This metric is chosen because it gives a comparison of the overall reliability of different paths and allows pathrater to emulate the shortest length path algorithm when no reliability information has been collected, as explained below. If there are multiple paths to the same destination, the path with the highest metric is chosen. Since the pathrater depends on knowing the exact path a packet has traversed, it must be implemented on the top of a source routing protocol. The pathrater assigns ratings to nodes according to the following algorithm. When a node in the network becomes known to the pathrater (through route discovery), the pathrater assigns it a ‘‘neutral’’ rating of 0.5. A node always rates itself with a

163

Table 1 Maximum and minimum network throughput with both watchdog and pathrater on 0 s pause time 60 s pause time

Maximum

Minimum

88.6 95.0

75.2 73.9

1.0. This ensures that when calculating path rates, if all other nodes are neutral nodes (rather than suspected misbehaving nodes), the pathrater picks the shortest length path. The pathrater increments the ratings of nodes on all actively used paths by 0.01 at periodic intervals of 200 ms. An actively used path is one on which the node has sent a packet within the previous rate increment interval. The maximum value a neutral node can attain is 0.8. We decrement a nodeÕs rating by 0.05 when we detect a link break (a node not forwarding packets) during packet forwarding and the node becomes unreachable. The lower bound rating of a ‘‘neutral’’ node is 0.0. The pathrater does not modify the ratings of nodes that are not currently in active use. In the simulations [8], a highly negative value (say 100) is assigned to nodes suspected of misbehaving by the watchdog mechanism. Some of the results of the simulations are as shown in the table given below. When the pathrater calculates the path metric, negative path values indicate the existence of one or more suspected misbehaving nodes in the path. If a node is marked as misbehaving due to a temporary malfunction or incorrect accusation, it would be preferable if it were not permanently excluded from routing. Therefore, nodes that have negative ratings should have their ratings slowly increased or set back to a nonnegative value after a long timeout. As shown in Table 1, the pause time of zero indicates that the nodes are in a constant motion and there is no pause time before and in between node movement. However, a pause time of 60 s indicates that there is a pause time of 60 s before and in between node movement. 8. Self-securing ad hoc wireless networks Since wireless ad hoc networks are devoid of any fixed infrastructure, it is cumbersome to have

164

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

any third party trusted certification authority in place. However this problem is overcome by distributing the onus of certification on individual member nodes [10]. The protocol suggests a localized trust model to distribute the function of a trusted third party Certification Authority (CA) to individual member nodes within the network. In the localized trust model, a node is trusted if any k (threshold) trusted entities claim so within a certain time period. These certifying entities are generally the nodeÕs one-hop neighbors. Once a node is trusted by its local community, it is globally accepted as a trusted node; otherwise it is considered untrustworthy in the entire network. If a node could not find k neighbors in certain location, it may roam to meet more nodes or wait for new nodes to move in. The certificate signing key SK is distributed to each node of the network. Each node carries a partial certificate signed with its share of certificate signing key SK . A valid certificate signed by SK is obtained by combining together partial certificate shares from k (threshold) number of nodes. A node trying to establish route with some other node should have a valid certificate. Nodes without valid certificates are treated as adversaries and are precluded from using network resources. A node Vi requests new certificate from any coalition of k (threshold) nodes, typically among its one hop neighbors. When any node receives this request, it checks its records on Vi . A record typically consists of a distributed Certificate Revocation list (CRL) and/or direct monitoring data available on Vi . If the node is found to be legitimate, the neighboring node responds with a partial certificate by applying its share of SK . Otherwise, the request for certificate is dropped. The requesting node Vi then combines the k partial certificates that it receives to generate a complete certificate. These certificates carry expiration time, after which a node has to acquire a new certificate because the old one is not valid any more. A broken or a misbehaving node that is detected by its neighbor will not be able to get its certificate renewed, once it current certificate expires. If a particular node has no record (neither good nor bad) for node, according to this architecture, it should not respond with its share of the certificate.

However, it is always possible that the node is new and it does not have any record for a particular node. For such a situation, it is suggested that the node should not send its share of the certificate to the requesting node since it does not have any record on the requesting node. If the requesting node is not able to garner the certificate shares from the threshold number of other nodes in its one-hop vicinity, it should move to a new location where it is likely to get the certificate shares. But mobility may not always be possible given the nature of the wireless ad hoc networks, that the network might be deployed in a hostile environment. The assumption ‘‘ It is not very difficult to detect misbehaving nodes within the radio range ’’, given the nature of the technology available, viz., Watchdog and Global Intrusion detection, cannot always be possible. It has been shown that the watchdog solution of operating the node in promiscuous mode falls apart when two or more misbehaving nodes are working in collusion. When a node perceives that an intrusion is in progress on itself, only then it will issue a request for other nodes to detect if a similar nature of intrusion is taking place on them as well. A misbehaving node could easily deny an intrusion in itself thereby thwarting any global intrusion mitigation procedure.

9. ARIADNE ARIADNE [1] prevents attackers/compromised nodes from disrupting uncompromised routes comprising of benign nodes. The motive behind this protocol is to thwart active attackers who inject packets into the network and who also eavesdrop. The active attackers are classified as active-n-m, where n is the number of nodes it has compromised and m is the number of nodes it owns, e.g., active-0-1 (owns 1 node), active0-x (owns x nodes), active-1-x (compromised 1 node and distributes cryptographic information like secret key to x  1 other nodes). A node trusts only itself for acquiring information as to which all nodes in the network are malicious, thus thwarting any blackmail attacks where an attacker fabricates information making a benign node appear malicious.

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

It is assumed that the sender trusts the destination with which it communicates, with responsibility of authenticating intermediate nodes. Thus enabling the destination to launch blackmail attacks against intermediate nodes, so the sender maintains a separate blacklist on all destinations it is communicating with. The ARIADNE protocol makes use of TESLA broadcast authentication protocol which is discussed next. 9.1. TESLA When TESLA [1] is used for authentication, each sender chooses a random initial key KN and generates a one-way key chain by repeated computation of a one-way hash function H , KN being the starting value of the function such that, KN 1 ¼ H ½KN ;

KN 2 ¼ H ½KN 1 ; . . . ;

Ki ¼ H ½Kiþ1  ¼ HN i ½KN  To compute any previous key from key Ki where j < i a node uses the equation Kj ¼ Hij ½Ki  The above mentioned equation is used by any node to authenticate any received value on the hash chain. If the computed value matches previous known authentic key value then the received key is authentic. Each node discloses each key of its one-way key chain in a particular order, which is exactly reverse of the order in which the keys were generated. For example if the keys were generated by a node in the order KN ; KN 1 ; . . . ; K1 ; K0 then the node discloses them in the order K0 ; K1 ; . . . ; KN . The rationale behind having the key disclosure schedule to be reverse of the key generation schedule is that KN of a node is known to all other nodes and in such a situation they should be able to authenticate any subsequent keys that are disclosed. The use of oneway hash function allows K0 ; K1 ; . . . ; KN 1 to be authenticated using KN but KN cannot be authenticated using any other key value. Hence the key disclosure schedule and key generation schedule should be reverse. The TESLA to a fair extent relies on the receiverÕs ability to determine which keys a sender

165

may have already disclosed, based on loose time synchronization between nodes. Let D be the maximum time synchronization error between any two nodes and this value must be known to all nodes. When a packet authenticated with TESLA is received, the receiver first verifies the TESLA security condition that the key Ki used to authenticate this packet cannot yet have been disclosed. If the packet arrival time at the receiver is tr , and the receiver knows that the earliest time the sender discloses the key Ki is t0 þ i  t where t0 is the time when K0 is disclosed by the sender. The receiver needs to verify that for TESLA time interval t, tr ( ðt0 þ i  t  DÞ, thus implying that Ki has not yet been published. Otherwise, sender may have already disclosed Ki and some attacker may have forged the packet contents, and hence the packet is discarded. If the check is successful the receiver buffers the packet and waits for the sender to disclose Ki . When the receiver receives Ki , it first authenticates Ki and then authenticates the stored packets. This ARIADNE protocol makes an assumption that the initiator S who performs a route discovery to target D shares secret keys KSD and KDS respectively, for message authentication in each direction. The design of this ARIADNE protocol can be divided into three stages. 9.2. ARIADNE protocol 9.2.1. Target authenticates ROUTE REQUESTS To communicate with some destination node D in the network, the initiator node S generates and floods ROUTE REQUEST packets throughout the network. In order to enable target D to authenticate sender S, S includes a MAC computed over a timestamp with KSD , into the route request packet. The target can then verify authenticity and freshness of the request. 9.2.2. Authentication of data in ROUTE REQUESTS and ROUTE REPLIES using TESLA Every node has a TESLA one-way hash chain and that all other nodes know an authentic key of the TESLA chain of every other node. The route request packet consists of eight fields (ROUTE

166

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

REQUEST, initiator, target, id, time interval, hash chain, node list, MAC list). Initiator and Target being set to addresses of source and destination, respectively. ÔIdÕ is set to an identifier that has not been recently used in route discovery. The ÔTime IntervalÕ is set to TESLA time interval at the pessimistic arrival time of the request at the target, with maximum possible clock offset/skew and maximum transmission delay. The hash chain field is initialized by the initiator to the MACKSD calculated over initiator, target, id, time interval. Node list and MAC list are left uninitialized, to be initialized later by the intermediate and target nodes. When an intermediate node A receives a ROUTE REQUEST, the node checks its local table (initiator, id). If it finds an entry for the same route discovery, it discards the REQUEST, else the node A verifies the time interval of the REQUEST. If the time interval is too much in the future or the key corresponding to it has been disclosed, the REQUEST is discarded. Else the node appends its address A to the node list in the REQUEST, the hash chain field is replaced by H (A, old hash chain). The node then appends a MAC of the entire request to the MAC list. The MAC is calculated using key Ki where ÔiÕ is the time interval mentioned in the REQUEST. The node then rebroadcasts the modified REQUEST. When the target node receives the REQUEST, it determines whether the keys corresponding to the time interval mentioned in the REQUEST have not been disclosed yet, and the hash chain field is equal to H ½gn ; H ½gn1 ; H ½. . . ; H ½g1 ; MACKsd ðinitiator target; id; time intervalÞ . . . gi : node address of node at position i and n: number of nodes in the node list If above two conditions are satisfied, the REQUEST is deemed valid and the target constructs a REPLY to the initiator. The REPLY consists of following fields: target, initiator, time interval, node list, MAC list fields are set to the corresponding fields from the received REQUEST.

Target MAC is a MAC calculated over above five fields with the key KDS . Key list is left empty to be initialized by the intermediate nodes. The REPLY is then returned to the initiator along the source route which is the reverse of the sequence of hops in the node list in the REQUEST. The node forwarding the route REPLY waits until it is able to disclose the key for the specified time interval. It has to store the REPLY in a buffer till then. The node then appends the key to the key list field in the REPLY and forwards the packet according to the source route in the packet. The waiting delays do not add significant computation overhead but adds storage overheads. Given the limited memory resources available on the ad hoc nodes such storage overhead is a cause of concern. When the initiator receives the REPLY, it checks if the keys in the key list are valid, target MAC is valid and each MAC in the MAC list is valid. If all these are valid only then will it accept the route REPLY. 9.2.3. Per-hop hashing An attacker could attempt to remove a node from the node list in the REQUEST. One-way hash functions ensure that no hop is omitted, hence called per-hop hashing. To change or remove a previous hop, the attacker must be able to invert the one-way hash function which is computationally infeasible given the limited computational capacity of nodes in mobile wireless ad hoc networks. We have seen in the previous section, when an intermediate node A receives a ROUTE REQUEST, it appends its address A to the node list in the REQUEST, the hash chain field is replaced by H (A, old hash chain), where H is the one-way hash function and A is the address of the node A. Since it is computationally almost impossible to invert this one-way hash function, a malicious node who might succeed in removing the address of any previous node from the node list, it would not be able to remove that nodeÕs address from the hash chain field. In this way the attacker would be thwarted as the computed hash chain field would not be the same as the hash chain in the field and hence the REQUEST would be discarded.

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

9.3. Route maintenance in ARIADNE An intermediate node attempting to forward a packet to the next hop along the source route will return a route ERROR to the original sender if and only if it is unable to deliver the packet to the next hop after a fixed finite number of retransmissions. In order to prevent unauthorized nodes from sending false ERROR messages, the protocol requires the original sender to authenticate the ERROR messages using TESLA. The protocol however does not guard against attackers not sending ERRORs in case of a genuinely broken route. ARIADNE does not guard against passive attackers eavesdropping on the network traffic. ARIADNE does not prevent an attacker from inserting data packets. ARIADNE is vulnerable to active-1-1 attacker that lies along the discovered route, who does not forward packets and does not generate ERROR if it encounters a broken link.

10. On demand secure routing protocol resilient to Byzantine failures In this protocol [6], the emphasis is on survivability of routes under situations where an intermediate node or group of nodes are known to be malicious and may attempt ‘‘Byzantine’’ attacks such as creation of routing loops, misrouting of packets along non-optimal (unnecessarily long) paths or selective dropping of packets (black or gray holes). Instead of laying the blame of a route failure on a single misbehaving node, the protocol [6] inculpates a link and thus the two nodes forming the link. This can ameliorate routing misbehaviors wherein two adjacent nodes are colluding with each other and dropping packets. Every link between two adjacent nodes has certain weight associated with it. When a link is found to be faulty, the weight associated with that link is multiplicatively increased. When multiple routes are discovered for a particular destination, the initiating node selects the route whose sum of link weights is

167

the least, thus, discovering the route which has least likelihood of having a faulty link in it. The protocol consists of the following three phases: (i) Route discovery with fault avoidance, (ii) Byzantine fault detection, (iii) Link weight management.

10.1. Route discovery with fault avoidance In the route discovery both the route REQUEST and RESPONSE are flooded. The RESPONSE is flooded in order to prevent any single adversary from stopping route establishment. Digital signatures are used to authenticate the source so that malicious nodes do not initiate route discovery and consume valuable network resources. The source creates the route REQUEST and signs it. The request consists of source, destination, a sequence number and link weight list. There is no route caching. When an intermediate node receives a route request, it checks its valid request list to see if there is a matching request in the list for the same source. If there is no matching request and the sourceÕs signature is valid, it rebroadcasts the request, else the request is dropped. When the destination receives a request from the source for the first time, it checks the source signature on the request. It then constructs and signs the response consisting of source, destination, a response sequence number and the weight list from the request packet. When an intermediate node receives a response, it computes the total weight of the path by summing weights of all the links that constitute the path. If the total weight is less than any of the previous responses for that particular request, it checks the signature on the response header and every hop listed on the packet. If the whole of the packet is verified, the node appends its identifier to the end of the packet signs the new packet and broadcasts it. When the source receives the response, the verifications performed are the same as those at intermediate nodes. If the path is better than the

168

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

and does not disconnect nodes so the threat of false positives is neutralized. When the losses exceed the threshold, the protocol attempts to locate the faulty link. Source specifies a dynamic list of intermediate nodes on the route, each of which must send an ack for the successfully received packet, in addition to the destination. These nodes are called probes. The probes divide the route into nonoverlapping continuous intervals. When a fault is detected on an interval, a new probe is inserted in between that interval. This probe insertion and interval subdivision continues till the faulty interval narrows down to a single faulty link. Due to binary search, the faulty link is detected after log n faults occur n being the total number of nodes on the route. We illustrate the fault detection mechanism with the help of Fig. 8a–c. As shown in Fig. 8a, suppose a faulty link exists at ÔX Õ. When fault rate exceeds the threshold level, the source node S invokes the fault detection mechanism. S arbitrarily selects probes P 1 and P 2 along the route to destination D, thereby diving the route into intervals S–P 1, P 1–P 2, P 2–D. Both the probes P 1 and P 2 are supposed to send ÔacksÕ to the source. S receives ack from P 1 but does not get the ack from P 2 as there is a broken link between P 1 and P 2. Since S does not receive ack from P 2, it assumes that the faulty link exists between the interval P 1– P 2. So S inserts new probe P 3 along the interval P 1–P 2 as shown in Fig. 8b. S now receives acks from P 1 and P 3 but not from P 2 as the faulty link lies in the P 3–P 2 interval. So S assumes that a

best path received so far, the source updates the route used to send packets to the particular destination. This type of route discovery attempts to find the route having lowest sum of link weights, thereby selecting a route which is least likely to have a faulty link on it. Faulty links have more link weight and get automatically precluded from route discovery. In spite of this fault avoiding route discovery, if a faulty link happens to be a part of a route may be because no alternate routes with lower link weights were discovered, a fault detection mechanism will be invoked after log n faults where n is the length of the route.

10.2. Byzantine fault detection This Byzantine fault detection uses adaptive probing technique which identifies a faulty link after log n faults have occurred where n is the length of the route. The protocol requires the destination to return an ack to the source for every successfully received data packet. If no valid acks received during the time out, it assumes that the packets were lost in transit (malicious or non-malicious). Loss rate less than a fixed threshold is tolerable and may vary with every route and is chosen by the source. Source keeps track of number of losses on the path. If this number exceeds the threshold, a binary search on the path is initialized, assuming a faulty link exists on the source–destination route. Protocol avoids loss

S

D

(a)

P1

P2

S

(b)

D P1

P3

P2

S

(c)

D P1

P3

P4

P2

Fig. 8. (a) Step 1: Fault on P 1–P 2 interval. P 1 and P 2––probes; X ––faulty link. (b) Step 2: P 3––new inserted probe; P 3–P 2––faulty interval. (c) Step 3: P 4––new inserted probe; P 3–P 4––faulty link.

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

faulty link exists on the interval P 3–P 2 and inserts a new probe P 4 in the P 3–P 2 interval as shown in Fig. 8c. Now S receives acks from P 1 and P 3 but not from P 4 and P 2, so S assumes that a broken link exists along P 3–P 4. However P 3–P 4 is a single link with P 3 and P 4 being adjacent nodes, P 3–P 4 link is faulty. This link is sent as input to link weight management mechanism.

10.3. Link weight management When a faulty link is detected, a multiplicative increase scheme is used to double its weight. More is the weight, less is the probability of that link being on any further routes. So far we have looked at secured routing protocols for reactive or on-demand protocols. We now discuss a SRP for proactive protocols.

11. Securing distance vector routing protocol using SEAD Distance vector routing protocol [14] finds shortest route between nodes of a network using distributed implementation of Bellman–Ford algorithm. In this protocol, each router maintains a routing table having an entry for every possible destination within the network. Each entry in the routing table holds a destination identifier, the distance to the destination in terms of hop count, also referred to as metric and the identity of the next hop neighbor router on this shortest route to the destination. When a packet needs to be routed to a destination node, the table entry for the corresponding destination is looked up and the packet is routed to the first hop neighbor router on that route. The neighbor router in turn looks up its entry for the corresponding destination and routes the packet to its first hop neighbor on the route to that destination and so on. In order to maintain the consistency and freshness of the routing tables on each individual nodes, each node periodically transmits a routing update to each of its neighbor routers, having data from its routing table. Each router in turn uses this

169

data advertised by its neighbor router to update its own table in such a way that its route for every destination uses as the next hop the router which advertises the smallest metric for that destination. The router then sets the metric in its table entry for that destination to one more than the metric from that neighbor routerÕs update. In order to dispense fresh routing information through the network without delay, a concept of ‘‘triggered’’ updates was introduced. In a triggered update, a router transmits a new update as soon as the metric in its table entry for a destination changes. It does not wait for its next scheduled periodic update. As an adaptation to the wireless ad hoc paradigm, DSDV [13] a sequence number is added to the table entry. The sequence number prevents the formation of loops caused by out of order updates. Every node maintains an even sequence number in its routing table entry and includes it in every update it sends. This sequence number is the most recent one the node knows for that destination. Whenever a routing update is received, the newly advertised route for a destination is preferred if the sequence number for the destination in the update is more than the corresponding one in the routing table entry for that destination. Else if the sequence numbers are equal and the new metric is lower than the corresponding metric in the routing table, the routing table entry corresponding to that destination is updated to reflect the new route with lower metric else the update for that destination is ignored. Whenever a broken link to a neighbor is encountered, the node sets the metric for that neighbor as a destination to infinity in the corresponding entry and the sequence number is set to the next odd sequence number and a new route update is created to advertise this information. DSDV sends updates both periodically as well as triggered. These updates can be either the whole routing table (full dump) or only those table entries which correspond to the destinations for which route has changed since the last full dump. A triggered update is sent when either the metric for a destination changes or when the sequence number changes. In the later case, it is called DSDV-SQ. A malicious node may send updates advertising lower hop count for certain destinations to its

170

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

neighboring nodes. The neighbors would be fooled into believing that this malicious node has the shortest path to those destinations, and so they would make this malicious node as the first hop for routes to those destinations. Thus this malicious node would be able to launch denial of service attacks against those destinations by having all routes to them through itself. It can then selectively drop packets and wreak a havoc in the network. This is prevented by SEAD which is discussed next.

11.1. SEAD In SEAD [4], the receiver of the routing update authenticates the sender. One-way hash functions are used to secure routing in SEAD, since they are computationally efficient as compared to public key cryptography or secret key paradigms. When a node sends a routing update about itself (metric 0), it uses a single next element from its hash chain. An attacker cannot generate any value in the hash chain of the node which the node is going to use in the future as it is impossible to invert a one-way hash function. Another node can only increase the metric in the routing update but cannot decrease it. For each entry in the routing update for a route to some other destination, the hash chain of that destination allows the metric in that entry to be authenticated by the receiving nodes. SEAD, through authentication secures the lower bound on the metric in each update. It is assumed that an upper bound can be placed on the diameter of the ad hoc network, and let this bound be denoted my m  1. Thus all metrics in any routing update are less than m. If a nodeÕs hash chain sequence is as follows h0 ; h1 ; h2 ; h3 ; . . . ; hn , and n is divisible by m, then for a sequence number i in routing update entry, let k ¼ n=m  i. If the metric of the route update entry is j, 0 6 j < m, then the element hkmþj from the hash chain list is used to authenticate the routing table entry for that sequence number and that metric. Suppose an attacker receives a routing update having metric j for a particular entry. The attacker decides to decrease the metric for that entry to say j  1 then the attacker will have to

authenticate the entry with hash chain element hkmþj1 . However, this hash chain element is not known to the attacker as it is not released yet and it cannot be calculated from hkmþj as the hash function cannot be inverted. Hence any attempt to decrease the metric of a particular routing table entry would be thwarted as the attacker will not have the necessary hash chain element to authenticate the resulting metric. When a node in SEAD sends a routing update, the node includes one hash value with every entry in that update. In case of an entry for itself, the node sets the address to its own node address, metric to zero, the sequence number to its own sequence number and the hash value to the first element in the group of its own hash chain elements corresponding to that sequence number. If a node lists an entry for some other destination in its update, it sets the destination address to that nodeÕs address, the metric and the sequence number to the corresponding values in its routing table for that destination node and the hash value is set to the hash of the hash value of the routing update entry from which it learned the route to that destination. The role played by sequence number and metric in selecting the hash value for routing update entry prevents any node from advertising a route to a destination claiming a greater sequence number than that destinationÕs current sequence number due to one-way hash functions. When a node receives a routing update, depending upon the sequence number and metric in the received entry and the sequence number and metric of the prior authentic hash value for that destination, it decides how many times the hash value in the newly received update entry needs to be hashed so that it should be same as the prior authentic hash value. If the two hash values are found to be equal, the entry is authentic and gets processed else it is dropped. SEAD, however, cannot prevent the same distance attack where a node receives an advertisement for a particular sequence number and metric and then it readvertises the same sequence number and metric. This is because SEAD only secures the lower bound on the metric ensuring the node does not reduce the metric.

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

12. An optimized inter-router authentication scheme Lakshmi and Agrawal [18] present another classification of attacks on routing protocols––internal and external attacks. External attacks are launched by nodes which do not belong to the network and the internal attacks are launched by the nodes belonging to the network which have been compromised. Lakshmi and Agrawal [18] introduce a low overhead authentication scheme among ad hoc network nodes, that are being part of an active route. The scheme relies on public key cryptography. The scheme assumes the existence of a centralized governing authority, which is responsible for creation of the ad hoc network and is the only entity that has the system private key. Each node in the network is given a private/public key pair by the governing authority along with the systemÕs public key. The governing body stores the system private key securely and uses it to sign the public keys of member nodes. The governing authority is not mobile and is considered to be more trustworthy by the member nodes. The authentication scheme is discussed with respect to the ad hoc on demand routing protocol, AODV. The authentication scheme is applied only to the response messages RREP. This effectively reduces the overhead as the response is not flooded but follows only a particular path from the destination to the source. This path or route is called the authenticated route. This scheme is a three-way communication between adjacent nodes on the authenticated route as shown in Fig. 9. A node sends a pre-reply to its neighbor indicating that it wishes to send a reply to the neighbor node. The pre-reply contains a challenge for the neighbor. This challenge is a random string. The

Pre-Reply + challenge 1 S

Encrypt(challenge 1) + challenge 2

D

Reply + Encrypt(challenge 2)

Fig. 9. Three-way communication during route reply.

171

neighbor on receiving this challenge, generates a new challenge for the node which sent it the prereply. This new challenge along with the string obtained by encrypting the earlier challenge is sent by the neighboring node to the node that sent the challenge. If the nodes are interacting for the first time, then certified public keys are also exchanged. The node then sends the reply and the encrypted new challenge. The authentication would fail if any of the constituent nodes of the route fails to prove its network membership, i.e., prove the knowledge of the private key whose counterpart public key is certified by the governing authority. If the authentication fails, then the node which discovers an intruder sends a purgereplyroute message to all members of the route to erase all entries for this particular route from their route table.

13. Conclusions We have analytically discussed contemporary SRPs for wireless mobile ad hoc networks. A summary of the key attributes of these protocols is presented in Table 2. We have identified areas where some further work needs to be done. Especially the problem of tracking and eliminating misbehaving nodes that are part of an already existing route and the problem of preventing partitioning of the network. These problems assume monumental proportions especially in the case of ad hoc networks as there is no central governing authority. In ad hoc networks, individual nodes act as routers, forwarding packets to the nodes in their radio range. If a node is compromised or fails, then the routes through that node are in jeopardy. There is a need for a mechanism to salvage the routes in case of node failure or node subversion. The nodes in an ad hoc are moving and if a node which is constituent of a number of routes moves from its position rendering the routes broken, resulting in partitioning of the network where one part of the network is not accessible from the other. The future research in the field of secure routing should be directed towards ameliorating the above two problems.

172

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

Table 2 A summary of secure routing protocols Name of protocol

Features

Security aware ad hoc routing

(a) Classifies nodes into different immutable trust levels. (b) Route Initiator specifies minimum trust level for a route and only the nodes with that trust level or higher can participate in the route. (c) Can be implemented by distributing keys for each trust level. (d) Not very scalable but has the potential of, precluding malicious nodes from route discovery.

Secure routing protocol

(a) This protocol assumes a security association between source and destination nodes. (b) Intermediate nodes do not need to cryptographically validate the control traffic. (c) Adds a SRP header to the base routing protocol (DSR or AODV) request packet. SRP header has three important fields––QSEQ which helps prevent replay of old outdated requests, QID a random number which helps prevent fabrication of requests, and a SRP MAC which ensures integrity of the packets in transit.

ARAN

(a) Assumes managed-open environment, where there is a possibility for pre-deployment of infrastructure. Consists of two distinct stages. (b) The first stage is the certification and end-to-end authentication stage. Here the source gets a certificate from the trusted certification server, and then using this certificate, signs the request packet. Each intermediate node in turn signs the request with its certificate. The destination then verifies each of the certificates, thus the source gets authenticated and so do the intermediate nodes. The destination node then sends the reply along the route reverse to the one in the request, reply signed using the certificate of the destination. (c) The second stage is a non-mandatory stage used to discover the shortest path to the destination, but this stage is computationally expensive.

Watchdog and pathrater

(a) Watchdog is a component run on each node. It makes the nodes operate in promiscuous mode which makes them listen to the transmissions of their one-hop neighbors. Thereby a node can keep track of which packets were successfully transmitted by the subsequent node and which were not. So that it can retransmit them. However if the node is dropping all the packets, then it is considered malicious and its behavior is reported to the ÔpathraterÕ. (b) Watchdog has some obvious disadvantages. Most obvious of them are––watchdog can be deceived by two neighboring nodes colluding together and the other being the need of a buffer to store the transmitted packets until they are transmitted by the subsequent node in the route. (c) Pathrater is a component running on each node, which maintains a rating for every other node in the network. These ratings are used as metrics while selecting a path for data transmission.

ARIADNE

(a) ARIADNE prevents attackers/compromised nodes from disrupting uncompromised routes comprising of benign nodes. (b) Uses highly efficient symmetric key cryptography. (c) ARIADNE does not guard against passive attackers eavesdropping on the network traffic. (d) ARIADNE does not prevent an attacker from inserting data packets. (e) ARIADNE is vulnerable to active-1-1 attacker that lies along the discovered route, who does not forward packets and does not generate ERROR if it encounters a broken link.

Secure on-demand routing protocol

(a) This protocol attempts to ensure survivability of routes under situations where intermediate node or group of nodes are known to be malicious. (b) Instead of laying the blame of a route failure on a single misbehaving node, the protocol inculpates a link and thus the two nodes forming the link. (c) Fault detection is carried out through insertion of probes. When a fault is encountered on a route, the initiator arbitrarily chooses few nodes along the route to be probes. Now these probes are sent a control message to which they need to send an ÔackÕ. The probe beyond which the acks do not come through, the interval between this particular probe and the subsequent probe on the route is considered to be faulty and one more probe is inserted in between this interval. Again the control messages are sent and again the probes got to send acks. This whole process repeats till the faulty interval is reduced to a link between two nodes.

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174

173

Table 2 (continued) Name of protocol

Features

Self securing ad hoc networks

(a) The function of a trusted third party certification authority is distributed to individual. (b) In the localized trust model, a node is trusted if any k (threshold) trusted entities claim so within a certain time period. These certifying entities are generally the nodeÕs one-hop neighbors. Once a node is trusted by its local community, it is globally accepted as a trusted node, otherwise, considered untrustworthy in the entire network.

SEAD

(a) One-way hash functions are used to secure routing in SEAD, since they are computationally efficient as compared to public key cryptography or secret key paradigms. (b) An attacker cannot generate any value in the hash chain of the node which the node is going to use in the future as it is impossible to invert a one-way hash function. (c) Another node can only increase the metric in the routing update but cannot decrease it. (d) When a node in SEAD sends a routing update, the node includes one hash value with every entry in that update.

14. Uncited references [9,16,17].

[9] [10]

References [11] [1] Y.-C. Hu, A. Perrig, D.B. Johnson, ARIADNE: a secure ondemand routing protocol for ad hoc networks, in: MobiCom 2002, Atlanta, GA, USA, September 23–28, 2002. [2] P. Papadimitratos, Z.J. Haas, Secure routing for mobile ad hoc networks, in: SCS Communication Networks and Distributed Systems Modeling and Simulation Conference (CNDS 2002), San Antonio, TX, January 27–31, 2002. [3] S. Yi, P. Naldurg, R. Kravets, A security-aware ad hoc routing protocol for wireless networks, in: The 6th World Multi-Conference on Systemics, Cybernetics and Informatics (SCI 2002), 2002. [4] Y.-C. Hu, D.B. Johnson, A. Perrig, SEAD: secure efficient distance vector routing for mobile wireless ad hoc networks, in: Proceedings of the 4th IEEE Workshop on Mobile Computing Systems & Applications (WMCSA 2002), IEEE, Calicoon, NY, June 2002, pp. 3–13. [5] M.G. Zapata, Secure Ad hoc On-Demand Distance Vector (SAODV) Routing, Internet-Draft draft-guerrero-manetsaodv-00.txt, August 2002. First published in the IETF MANET Mailing List (October 8, 2001). [6] B. Awerbuch, D. Holmer, C. Nita-Rotaru, H. Rubens, An on-demand secure routing protocol resilent to Byzantine failures, in: ACM Workshop on Wireless Security (WiSe), Atlanta, GA, September 28, 2002. [7] K. Sanzgiri, B. Dahill, B.N. Levine, C. Shields, E.M. Belding-Royer, A secure routing protocol for ad hoc networks, in: Proceedings of 2002 IEEE International Conference on Network Protocols (ICNP), November 2002. [8] S. Marti, T.J. Giuli, K. Lai, M. Baker, Mitigating routing misbehavior in mobile ad hoc networks, in: Proceedings of

[12]

[13]

[14]

[15]

[16]

[17]

[18]

the 6th Annual ACM/IEEE International Conference on Mobile Computing and Networking, August 2000. L. Zhou, Z.J. Haas, Securing ad hoc networks, IEEE Networks, Special Issue on Network Security 13 (6) (1999) 24–30. H. Luo, J. Kong, P. Zerfos, S. Lu, L. Zhang, Self-securing ad hoc wireless networks, in: Seventh IEEE Symposium on Computers and Communications (ISCCÕ02), in press. C.E. Perkins, E.M. Royer, Ad-hoc on-demand distance vector (AODV) routing, in: The Second IEEE Workshop on Mobile Computing Systems and Applications, New Orleans, LA, USA, February 1999. J. Broch, D.B. Johnson, The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks, IETF Internet Draft, October 1999. C. Perkins, P. Bhagwat, A highly dynamic destinationsequenced distance vector routing (DSDV) for mobile computers, in: ACM SIGCOMM 1994 Conference on Communications Architectures, Protocols and Applications, 1994, pp. 234–244. R.V. Boppana, S. Konduru, An adaptive distance vector routing algorithm for mobile, ad hoc networks, in: Proceedings of the Twentieth Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM 2001), 2001, pp. 1753–1762. Y.-C. Hu, A. Perrig, D.B. Johnson, Wormhole detection in wireless ad hoc networks, Technical Report TR01-384, Rice University, Department of Computer Science. A. Perrig, R. Canetti, J.D. Tygar, D. Song, Efficient authentication and signing of multicast streams over lossy channels, in: IEEE Symposium for Security and Privacy, May 2000, pp. 56–73. A. Perrig, R. Canetti, D. Song, J.D. Tygar, Efficient and secure source authentication for multicast, in: Network and Distributed Security Symposium, NDSS Õ01, February 2001, pp. 35–46. V. Lakshmi, D.P. Agrawal, An optimized inter-router authentication scheme for ad hoc networks, in: Proceedings of the 13th International Conference of Wireless Communications, Calgary, Canada, 9–11 July 2001, pp. 129–146.

174

S. Gupte, M. Singhal / Ad Hoc Networks 1 (2003) 151–174 Siddhartha Gupte is currently pursuing Ph.D. degree in Computer Science at University of Kentucky. His research interests include wireless networks security, distributed computing and computer security. He finished his Bachelor of Engineering with high first class from University of Mumbai in June 1999. He finished his Master of Computer and Information Science from Cleveland State University in December 2000.

Mukesh Singhal is a Full Professor and Gartener Group Endowed Chair in Network Engineering in the Department of Computer Science at The University of Kentucky, Lexington. From 1986 to 2001, he was a faculty in Computer and Information Science at The Ohio State University. He received a Bachelor of Engineering degree in Electronics and Communication Engineering with high distinction from Indian Institute of Technology, Roorkee, India, in 1980 and a Ph.D. degree in Computer Science from University of Maryland, College Park, in May 1986. His current research interests include distributed systems, mo-

bile computing, computer networks, computer security, and performance evaluation. He has published over 160 refereed articles in these areas. He has co-authored three books titled ‘‘Data and Computer Communications: Networking and Internetworking’’, CRC Press, 2001, ‘‘Advanced Concepts in Operating Systems’’, McGraw-Hill, New York, 1994 and ‘‘Readings in Distributed Computing Systems’’, IEEE Computer Society Press, 1993. He is a Fellow of IEEE. He is currently serving in the editorial board of ‘‘IEEE Transactions on Knowledge and Data Engineering’’ and ‘‘IEEE Transactions on Computers’’. From 1998 to 2001, he served as the Program Director of Operating Systems and Compilers Program at National Science Foundation.