ARM: Anonymous Routing Protocol for Mobile Ad Hoc Networks

8/12/2019 ARM: Anonymous Routing Protocol for Mobile Ad Hoc Networks

1/11

ARM: Anonymous RoutingProtocol for Mobile Ad HocNetworks

S. Seys*SCD/COSIC,Department Electrical Engineering (ESAT),Faculty of Engineering, K. U. Leuven, BelgiumE-mail: [email protected]*Corresponding author

B. Preneel

SCD/COSIC,Department Electrical Engineering (ESAT),Faculty of Engineering, K. U. Leuven, BelgiumE-mail: [email protected]

Abstract: In this paper we describe a novel anonymous on demand routing protocolfor wireless mobile ad hoc networks (MANETs) that is secure against both nodesthat actively participate in the network and a passive global adversary who monitorsallnetwork traffic. Finally, we provided a detailed analysis of the privacy offered byhiding routes in limited broadcast groups, and padding messages.

Keywords: anonymity; routing protocol; ad hoc networks; cryptography.

Reference

Biographical notes:Stefaan Seys received the degree of Master in Electrical Engi-neering (Burgerlijk Ingenieur Elektrotechniek) from the Katholieke Universiteit Leu-ven (Belgium) in 2000. In August 2000, Stefaan started working in the research groupCOSIC (Computer Security and Industrial Cryptography) at the Department of Elec-trical Engineering (ESAT) of the Katholieke Universiteit Leuven. He completed hisDoctorate in Applied Sciences in May 2006. His research interests include cryptogra-phy, wireless security and computer security.

Bart Preneel received the Electrical Engineering degree and the Doctorate in AppliedSciences from the Katholieke Universiteit Leuven (Belgium). He is currently full pro-fessor at the Katholieke Universiteit Leuven and visiting professor at the T.U.Graz inAustria. He was visiting professor at several universities in Europe. His main researchinterests are cryptography and information security. He has authored and co-authored

more than 200 scientific publications. He is vice president of the IACR (InternationalAssociation for Cryptologic Research) and a member of the Editorial Board of theJournal of Cryptology and of the IEEE Transactions on Forensics and InformationSecurity. He has participated to several research pro jects sponsored by the EuropeanCommission, for four of these as project manager. He has been program chair of sixinternational conferences (including Eurocrypt 2000, SAC 2005 and ISC 2006) and hehas been been invited speaker at 20 conferences.

1 INTRODUCTION

The wireless links that are used to connect nodes in a mo-bile ad hoc network (MANET) are vulnerable to both ac-

tive and passive attacks. Wireless transmissions are in-herently easy to capture remotely and undetected, whilethe lack of central network management makes ad hoc

networks susceptible to active attacks (e.g., an adversaryinstalling rogue software on one or more victim nodes).Therefore, providing security solutions for ad hoc networksis of primary importance for future large scale deployment.

Many researchers have engaged in designing protocols

Copyright c 200x Inderscience Enterprises Ltd.

1


2/11

for diverse security related tasks, such as key management,authentication, confidentiality, etc. Recently, researchershave also tackled the problem of anonymous routing in adhoc networks (see related work in Sect. 2). Due to the na-ture of MANETs, the privacy of the users is at a greater

risk than in traditional wired networks such as the Inter-net. In traditional networks, the amount of traffic a normaluser can capture (in addition to his own traffic) is limited tohis broadcast domain. For most access technologies (e.g.,Asymmetric Digital Subscriber Line (ADSL) or cable) yourbroadcast domain is limited to your home network. Whenconnected to a Local Area Network (LAN), your broad-cast domain is extended to all users connected to this LAN.This means that, in practice, the real privacy threat comesfrom the Internet Service Providers (ISPs). In MANETs,where mobile nodes exchange data with other nodes with-out continuous supervision of the user, your broadcast do-main is unknown and changes continuously. This means

that personal data (including the location of a user) nowbecomes available to many other users that you dont knowor trust.

In this paper we describe a novel anonymous on demandrouting protocol for MANETs that is secure against bothnodes that actively participate in the network and a passiveglobal adversary that monitors all network traffic.

1.1 Adversary model and privacy goals

In this paper we assume two distinct adversaries. The firstadversary is an external global passive adversarywho canobserve all possible communications between all nodes inthe network at all time. The goal of our protocol towardsthis adversary is to (1) prevent him from learning the des-tination of these messages, and (2) prevent him from learn-ing which nodes are part of the path from the source tothe destination.

The second adversary we assume is a corrupted nodeinside the network. This means that we assume that everynode that is part of the network is a potential adversary.The goals of our protocol towards this adversary are (1)a node should not be able to determine whether anothernode in the network is the sender or the destination of

a particular message, (2) a node should not be able todetermine whether another node is part of a path betweentwo nodes.

1.2 Outline

We start by presenting and evaluating related work inSect. 2. Next, we explain our anonymous routing protocolARM in detail. We describe the use of a trapdoor iden-tifier, the route discovery, route reply and data forwardingprotocols. In Sect. 4 we evaluate the anonymity offered bythe time-to-live and padding scheme we use in the ARM

routing protocol. Finally, in Sect. 5 we give an analysisof the route hiding and efficiency properties of the ARMprotocol.

2 RELATED WORK

2.1 ANODR

Kong and Hong (2003) proposed ANODR, one of the first

anonymous routing schemes for mobile ad hoc networks.ANODR assumes that the source S and destination Dshare a secret key kSD . This secret key is used by thesource S to generate a trapdoor identifier of the formEkSD [dest] where dest is a public binary string that in-dicates that you are the destination. Obviously, onlythe destination D who has knowledge of the key kSD canopen this identifier. Route Requests (RREQs) have thefollowing format: seq,EkSD [dest], pubi,TBOi, with seqaunique sequence number, and TBO (Trapdoor BoomerangOnion) is an onion-like structure of the following form:

TBOi = Ek

ini, Ek

i1ni1 . . . E k

S [src].

Here,srcis a public binary string that indicates you arethe source. Every forwarding node Ni adds one layer tothe onion using a fresh secret key ki and nonce ni knownonly to node Ni (see Fig. 1). The forwarding node storesthese parameters together with the sequence number intheir routing table. Every forwarding node also includesa one-time public key pubi in the RREQ message beforeforwarding it (replacing the public key pubi1 of the pre-vious hop). The public key of the previous hop is stored inthe routing table. These public keys will be used to setup

a secret channel for the future Route Reply (RREP) mes-sages. The sourceSstores the pair (EkS

[src], D) in a tablein order to recognize future RREP messages it receives inanswer to this RREQ message.

The RREP message transmitted by nodeNi to node Ni1 has the following format:Pubi1 (ki),Eki[TBOi1 ]. It consists of a freshlink key ki encrypted with the public key pubi1 of nodeNi1. This link key is used to encrypt TBOi1. NodeNi1 uses its private key to decrypt Pubi1(ki) containedin the RREP message it received, and uses ki to decryptthe boomerang onion TBOi1. It can now verify whetherthis RREP message was intended for it or not by trying

to open TBOi1 using ki1 and ni1 stored in its RREQtable. It strips away one layer of the boomerang onion,creates the RREP message and transmits it to node Ni2.Node Ni1 also stores the link key that was retrievedfrom the RREP message in its routing table. Note thata RREP message does not contain a unique identifier.The original source S of the route request recognizesitself as the source because it sees the fixed string srcafter decrypting the received boomerang onion. ANODRuses padding in RREQ and RREP messages to hide thenumber of hops these messages have traveled.

Data packets are routed using the key kishared between

two consecutive hops. This key is used to encrypt the pay-load and to generate a pseudo-random route pseudonymof the form fj(ki) for the j th packet that is forwarded.

2


3/11

N1 N2S D

EkS [src] Ek2

n2, Ek1 [n1, EkS [src]]

Ek1 [n1, EkS [src]]

Figure 1: Trapdoor Boomerang Onion used in ANODR. Every node adds a layer to the onion when forwarding RREQmessages. It removes this layer again when forwarding RREP messages.

2.2 ASR

The functionality of the ASR protocol proposed by Zhuet al. (2004) is essentially the same as that of ANODRwithout the use of TBOs. ASR makes no use of onions thatare built up as the RREQ progresses through the network,but instead relies on state information that is kept at theforwarding nodes. As in ANODR, every forwarding node

includes a one-time public keypub i in the RREQ messageand stores the public key of the previous hop in its routingtable.

The RREP message forwarded by node Ni consists of afresh link key ki encrypted with the public key pubi1 ofnode Ni1. This link key is used to encrypt the sequencenumber contained in the RREQ message. Every node thatreceives such a RREP message verifies whether it is tar-geted at it or not using its list of current one-time privatekeys. Finally, node Ni stores the link key it received fromnode Ni+1 and the link key it generated for the next

1 hopNi1 in its routing table.

Data transmission in ASR uses the secret key ki sharedbetween two consecutive hops on the path. Data packetsare encrypted hop-by-hop and are identified using a smallTAG. This TAG is of the form N,MACki[N] with N anon-decreasing number.

2.3 MASK

In MASK (Zhang et al. (2005)), nodes use differentpseudonyms Nymi when moving to a new location andestablish a shared secret keykABwith each of their neigh-bors. This key establishment is based on pairing (Barretoet al. (2002); Boneh and Franklin (2001)) and is a simple

adaptation of the scheme of Balfanzet al.(2003) to the mo-bile setting. Using this shared key, neighboring nodes AandB compute pairs of shared session keys LinkKey

AB

and link identifiers LinkIDAB

. Each node keeps a neigh-bor table in which each entry contains the pseudonym ofa neighbor, the pairwise shared session keys and link iden-tifiers (LinkKey,LinkID) and the index of the pairthat is currently in use. These pairs are used in sequence,i.e., the index is increased for every message transmit-ted and received. New pairs are generated in batches ofsize as required. A RREQ message contains a uniqueidentifier seq, the identity of the destination D and thecurrent pseudonym Nym

iof the node forwarding or initi-

ating the RREQ message. The forwarding node stores the

1Next in the order of the RREP message.

pseudonym contained in the RREQ message it receivedfrom the previous hop in its reverse route table.

Upon reception of a RREQ message, the destination Dprepares a RREP message consisting of the current linkidentifierLinkIDcorresponding to the pre-hop-pseudonymcontained in the RREQ. The RREP also contains the iden-tity of the destination encrypted with the current ses-sion key LinkKey shared between D and the receivingnode. Forwarding nodes regenerate this RREP messagewith their own link keys and identifiers and store the re-ceived link identifiers in their forwarding route table. Theidentity D of the destination is used to link RREQ andRREP messages (i.e., to locate to link identity to be usedto forward the RREP message). Finally nodes also keepa table with link identifiers for which they are the finaldestination.

Data forwarding is based on the link identifiers and cor-responding keys in the forwarding route tables. A datapacket is reencrypted at every hop.

2.4 SDAR

In contrast to the previously presented protocols, Bouk-erche et al. (2004) do not use temporary or continuouslychanging identities. Instead SDAR uses a single fixedidentity for every node. Every intermediate node in-serts its identity as the source address of every messageit broadcasts. The source S first generates a fresh pub-lic/private key pair pubT/privT and a session key ksess.It uses this session key to encrypt information that willonly be disclosed to the destination D: the source iden-tity S, its public key pubS, the one-time public/privatekey pair pub

T

/privT

, a sequence number seqS

generatedby S and finally a signature on all this data. SDARuses a trapdoor identifier of the formPubD(D, ksess) whichonly D can open. A forwarding node Ni simply ap-pends the following information to the RREQ it received:PubT(idi, ki, seqi,Sign(idi, ki, seqi)). Here idi is the iden-tity of nodeNi,kiis a fresh link key, and seqiis a sequencenumber. The forwarding node stores the sequence number,the link key and the identity of the previous hop (i.e., thenode it received the RREQ from) in its RREQ table. Thedestination opens the trapdoor identifier using his privatekey and retrieves the session key ksess. With this key Ddecrypts the third part of the RREQ message and retrieves

the one-time private key privT.Using this private key, D can now open all data ap-

pended by the forwarding nodes and use this data to gener-

3


4/11

ate the RREP message. This RREP message has an onion-like structure with the outer-layer decryptable by the lastforwarding node, etc. The inner-most layer is decryptableby the sourceSof the corresponding RREQ message. Thelayer intended for the source contains all sequence num-

bers and link keys of all intermediate nodes. As the RREPmessage traverses the network back to node S, every for-warding node adds the identity of the node it received theRREP message from in its routing table. Random paddingin the RREQ messages prevents insiders from learning thenumber of hops the RREQ messages have traversed.

Data packets are onions generated by the source usingthe keys and sequence numbers it retrieved from the RREPmessage. Forwarding nodes strip one layer of encryptionand forward the message to the next node according toidnext found in its routing table.

2.5 Comparison and evaluationSDAR is by far the least efficient protocol as it requiresboth a public key decryption (in order to open the trapdooridentifier), a public key encryption and signature genera-tion every time a node needs to process a RREQ message.ANODR and ASR do not require encryption or decryp-tion, but require that every node that processes a RREQmessage generates a fresh public key pair. As RREQs areflooded over the entire network, every node in the net-work needs to perform these public key operations for everyRREQ that is released in the network. In MASK no pub-lic key operations are required during route establishment,

instead a similar cost is paid because of the continuousprocess of establishing keys within a nodes neighborhood.

ANODR and ASR require a public key encryption anddecryption for every RREP a node processes. This cost ismultiplied by the number of key pairs in a nodes routingtable, as the RREP messages contain no identifier that canbe linked to the RREQ messages. This means that a nodehas to decrypt the received RREP message with all privatekeys in its routing table.

With respect to privacy protection, none of the describedprotocols offers any protection against an external globalpassive adversary as this adversary can trivially trace bothRREP packets and all consecutive DATA packets as theytraverse the network. Although these packets alter theirappearance at every hop (because of the onion structureor because they are reencrypted at every hop), the flowof these messages can be traced with high probability.This means that the attacker is able to correlate educatedguesses on the path and quickly discover source-destinationrelationships by observing the message flows.

The use of mixing techniques and dummy traffic at everyhop will improve the privacy properties of these protocols,but these techniques can be applied independent of therouting protocol that is used and are not considered partof the routing protocol. Moreover, mixing techniques are

most effective with large traffic densities. Ad hoc routingprotocols often try to achieve a flat routing distributionover all nodes in the network and thus make mixing a less

effective measure.In the protocol we propose in the next section, we solve

all the problems we just mentioned. More specifically, wepropose an anonymous routing protocol that allows all par-ticipating nodes to recognize messages with a minimum ef-

fort, that hides the identity and location of all participatingnodes from both insiders and a global adversary, and thatshift the largest part of the computational burden to thedestination of a RREQ message (instead of spreading inover all potentially participating nodes that forward theseRREQ messages).

3 OUR PROPOSAL: ARM

ARM is an on demand routing protocol for MANETs thatachieves all the anonymity goals stated in Sect. 1.1 whiletrying to be as efficient as possible. To achieve this we fol-lowed a design strategy that builds on the strengths of theprotocols described in Sect. 2 and avoids the weaknesses.We also add new ideas that make the protocol more robustagainst external global passive adversaries.

3.1 Assumptions

We assume that every node in the network has a permanentidentity that is known by the other nodes in the networkthat wish to communicate with this node.

Next, we assume that the sourceSand the targeted des-tinationD share a secret keykSD and a secret pseudonym.

The source will include this pseudonym in RREQ messagestargeted at this specific destination. The destination willhave a list of its pseudonyms (used by different sources)in memory such that he can quickly verify whether a mes-sage is targeted at it or not. This pseudonym can onlybe used once (i.e., for a single RREQ). Different mech-anisms can be used to synchronize the pseudonyms usedbetween source and destination (for example an encryptedsynchronized counter). The destination needs to store twoconsecutive pseudonyms, the Nymi that is currently usedand the nextNymi+1. The destination advances this win-dow when it receives a RREQ identified with Nymi+1. In

order for our protocol to be efficient, we assume that nodeswill only share secret keys and pseudonyms with a limitedset of other nodes.

Next, we assume that every node has established abroadcast key with its 1-hop neighborhood. This broadcastkey will be used to encrypt the RREP messages. Thesebroadcast keys could be established using a similar schemeas the one proposed by Zhang et al. (2005), adapted tosupport broadcast keys instead of point-to-point link keys.

We further assume that wireless links between nodes aresymmetric.

3.2 Trapdoor identifier

As we mentioned in Sect. 2, ANODR and ASR useRREQ messages with a trapdoor identifier of the form

4


5/11

EkSD [dest, x], while the trapdoor identifier in SDAR hasthe form PubD(D, x). In both cases x is data that is gen-erated by the source of the RREQ. This results in a per-formance penalty since every node that receives a RREQmessage needs to decrypt this identifier with all keys it

shares with other nodes or with its private key.We propose to use a trapdoor identifier that can be com-puted byboththe sender and destination beforethe RREQmessage arrives at the destination. This trapdoor identi-fier can be thought of as a one-time pseudonym NymSDshared between nodes S and D. Every node keeps a listof pseudonyms it shares with every node it also shares asecret key kSD with. Different mechanisms can be usedto synchronize the pseudonym shared between source anddestination. One example is the use of a synchronizedcounter c that is used to compute the valid pseudonymas NymSD = EkSD [c]. This counter is incremented bythe source with every RREQ it initiates. The destination

needs to store two consecutive pseudonyms, theNymithatis currently used and the next Nymi+1. The destinationadvances this window when it receives a RREQ identifiedwith Nymi+1. Another example is to assume a synchro-nized clock between source and destination and use thisclock to compute new pseudonyms after a certain time in-terval in a similar fashion as with the counter. Note thatthe pseudonym can be shortened as no decryption is re-quired. For example, when using the AES for encryption,the length of the resulting pseudonyms would be 256 bits(the block size of AES). These large pseudonyms can betruncated to fit a sufficient length, for example, 80-bits.

3.3 Route discovery

First,Sgenerates a fresh asymmetric key pairprivD/pubDand a secret key kpr. Next, S generates a datagram infoDthat can only be opened by node D that has knowledge ofthe secret key kSD :

infoD =EkSD [D, kpr, privD, ttlinit], Ekpr [NymSD ] .

Here, ttlinit is the initial value of the TTL field. Next,Sgenerates a random pair of link identifiers (nS, kS) =(n0, k0) that will later on be used to recognize RREPmessages. Finally, S encrypts the pair of link identifierswith pubD and broadcasts the following RREQ message(NymSD also serves as a unique identifier for this RREQmessage):

S * : NymSD , ttlinit, pubD, infoD,PubD(nS, kS) .

Each node Ni that receives a RREQ message first checkswhether it is the targeted destination of the receivedRREQ by verifying whether NymSD is in its current listof valid pseudonyms. If so, Ni tries to decrypt infoD andverifies whether the first part of the decryption is equal toits global identifier Ni. If this fails, the node was not the

targeted destination.IfNi is not the targeted destination, the node checks

whether NymSD has been recorded in its routing table.

DN1

N2

S

Figure 2: Hidden route from sourceS to destination D.The full arrow indicates an actual route between S andD, while the dashed arrows indicates fake broadcasts thathide the actual path.

If so, the node discards the RREQ message. Otherwise,Ni stores (NymSD , ni1, ki1, Ekpr[NymSD ]) in its routingtable. If the received ttl > 1 then the node decrements

ttl, and generates a random pair of link identifiers (ni, ki),appends these to the already received encrypted link iden-tifiers, encrypts everything with pubD, and broadcasts thefollowing RREQ message (if the received ttl= 1, no mes-sage is broadcast):

Ni * : NymSD , ttl, pubD, infoD,PubD(. . . (PubD(ni1, ki1), ni, ki)) .

If Ni is the targeted destination, it stores the completeRREQ in memory and performs the same steps as if itwas not the targeted destination. This means that thedestinationD behaves exactly the same as all other nodesin the network. After it has forwarded one or more RREQmessages, the destination can prepare its reply message.

3.3.1 Design motivation

The RREQ message is designed with the following goal inmind. The cost for the intermediate nodes is minimizedby moving the bulk of the computational cost to the des-tination. This seems only fair as the two communicatingend points are the only beneficiaries and the intermediatehops are providing a service to them. Also, the destinationcan use theNymSDto identify the source and opt to ignore

the RREQ if it is not interested in communicating with thesource. When this happens, the cost for the intermediatenodes is minimal. The choice of public key cryptosystemoffers two options:

1. By using the Rabin public key cryptosystem, the com-putation cost for the intermediate nodes is minimizedas they are only required to perform a public key en-cryption (Rabin encryption is essentially a modularsquaring (Menezes et al. (1997))).

2. By using ECIES, the communication cost for the in-termediate nodes is minimized as ECIES offers very

short cryptograms (320 bits compared to 1024 bits forRSA or Rabin).

5


6/11

3.4 Route reply

Assume that the destination D has collected a number ofRREQ messages that were targeted at it. First it decryptsthe infoD field contained in one of these RREQs (they allcontain the same infoD) and obtainskpr,privD andttlinit.

NodeD computes the number of hops a RREQ has tra-versed ash = ttlinitttl. This hop count is useful to selectthe shortest route and to help with the decryption of thelink identifiers when padding is used (see Sect. 3.6).

UsingprivD, nodeD decrypts the link identifiers (ki, ni)for 0 i n(with (k0, n0) = (kS, nS)) that are containedwithin the received RREQs and selects a route it wishesto use (for example based on the hop count). Since thedestination itself has also forwarded RREQ messages, itshould discard routes that include link identifiers that weregenerated by D itself in order to ensure loop-free routes.

For every route for which D wishes to generate a RREP

message,D repeats the following tasks:FirstD generates n+ 1 link keys si for 0 i n withs0= sS. Link key si will be shared between nodesNi andNi+1. Together with the link identifiers (ki, ni), node Dconstructs a route reply onion of the following form:

On = Ekn

nn, sn, sn1, kpr, Ekn1

nn1, sn1, sn2, kpr,

. . . E kS [nS, sS, kpr].

After the construction of the reply onion, nodeDgeneratesa random ttl(see Sect. 3.6) and broadcasts the followingRREP message (Nym

SD, serves as a unique identifier

for this RREP message; the index is used to distinguishRREP messages that contain the sameNymSD):

* D : EkD [NymSD , , ttl],On

When only a single RREP is generated, the index is notrequired. The identifier and TTL field (i.e., the header) ofthe RREP message are encrypted with the current broad-cast keykD of nodeD to hide them from a global passiveadversary.

Each node Ni that receives a RREP message will per-form one of two actions (a) or (b) (see below). Note thatboth actions are implemented in such a way that they bothrequire an equal amount of time (in order to prevent tim-ing analysis). The RREP contains identifierNymSD andindex. First it verifies whether it has forwarded aRouteRequest with identifier NymSD . If not, it proceeds withaction (b). Otherwise, the node checks whether it alreadyreceived aRoute Replywith the same identifier and index.If so, it again proceeds with action (b). If this is the firsttime that it has seen a RREP with this particular index,that has the same identifier as a RREQ it forwarded ear-lier, it decrypts the reply onion using kiand checks whetherthe first part of the decryption is equal to ni. If so, nodeNi is on the anonymous route. Node Ni now validates theproof of the destination by verifying that the decryption

ofEkpr[NymSD ] (using kpr retrieved from the RREP) isequal to NymSD . Note that node Ni uses NymSD to re-trieve ni, ki,Ekpr[NymSD ] from its routing table. If the

proof is valid, node Ni proceeds with action (a); otherwiseit discards the message.

(a) Node Ni strips one layer from the reply onion, gener-ates a new random TTL value ttl and broadcasts theRREP message, encrypting the new header with itscurrent broadcast key. NodeNi stores the secret keys(si, si1) in its routing table. The first element is a se-cret key it shares with the next hopNi+1in the route,while the second element is shares with the previoushopNi1 in the route. We will use the notation kprevand knext, respectively, to denote these keys.

(b) Node Ni replaces the reply onion by random data ofappropriate length, decrementsttland broadcasts theRREP message, encrypting the header with its currentbroadcast key.

3.4.1 Design motivation

Onion creation is efficient as it only requires symmet-ric encryption.

It is efficient for an intermediate node to check wetheran onion is intended for it or not.

We use a limited broadcast to hide the real route in acloud of messages. The time-to-live value can be usedto select the size of this cloud.

The time-to-live value is encrypted with a nodes

broadcast key. This is only necessary to protectagainst an external global passive adversary.

3.5 Data forwarding

Every RREP message with an identifier NymSD that ar-rives at the source S contains a route to the destinationD. When the RREP messages arrive at the sourceS, theyhave the following form:

* N1 : EkN1

[NymSD , , ttl], EkS [nS, sS]

Index is used to indicate those fields that may differfor the different RREP messages that return in responseto a single RREQ message broadcast by the source withidentifierNymSD . Every link key s

Srepresents a different

route to the destination D .

Similar to sending RREQ messages, DATA messages willhave a one-time identifier attached to them. This identifierallows a node on the route to recognize the fact that it isthe next hop and that it should forward the message. Theone-time identifier is computed using the secret key sharedbetween consecutive hops in the route and the counters cand c that are incremented per message received or senton this route. The routing table of a nodeNi consists of

the following elements:

kprev knext idprev= Ekprev [c] idnext= Eknext [c]

6


7/11

Nodes that receive a message that is identified with one oftheidprevs in their routing table replace this identifier withidnext, reset the TTL field using the scheme in Sect. 3.6,and forward the message. After forwarding the messagethe nodes increment the counters c and c. In order to

change the appearance of the messages as they traversethe network, the identifier and TTL field are encryptedusing the nodes broadcast keys (similar to the forward-ing of RREP messages), while the payload is re-encryptedat every hop using kprev for decryption and knext for en-cryption. The length of every data message is fixed (themessage is padded at the source if necessary).

Nodes that receive a message with an identifier that doesnot appear in their routing table replace the identifier andthe message payload with a random number, decrementthe TTL field and forward the message. Again the messageidentifier and TTL field are encrypted using the nodesbroadcast key.

3.6 Padding and time-to-live schemes

Without randomized padding and time-to-live values, thelength of routing messages and the TTL value they containreveals information to both the global adversary and toinside nodes participating in the routing process. We nowpropose a possible strategy for both padding and time-to-live value selection. In the next section we analyze theprivacy our scheme offers.

3.6.1 Time-to-live

For Route Request messages we propose not to use aTTL field for small networks. For large networks, the costof network-wide broadcast can be cut down by using ansafe estimatettlest of the hop distance between source anddestination. If nodes have a clear idea of the hop distanceto other nodes, then they should randomize the TTL valueby adding a random value between zero and some maxi-mum to the required TTL size in order to reach the desti-nation (ttlinit=ttlest+ttlrand with 0 ttlrand tmax).

The TTL field in Route Replyand DATAmessages isrequired in order to hide the actual path followed by thesemessages. Using a fixed TTL value would reveal the pathto nodes inside the network that receive RREP or DATAmessages from their neighbors (as only nodes on the pathwill set the TTL value to this fixed value and all othernodes decrement this value). We propose the followingpadding scheme to prevent this.

Every node on the path chooses a TTL value accordingto the probability distribution in Fig. 4. This distributionhas two important properties: (1) small TTL values arefavored, and (2) the probability rapidly decreases to reachzero at some maximum TTL value ttlmax. Similar to thediscussion on RREQ padding lengths, nodeB that receivesa RREP or DATA message from node A with a certain

TTL value can compute the probability that it originatedat nodeA. The probability that it did notoriginate at thenodeA is related to the surface of the area underneath the

probability distribution at the right side of the TTL valueit received. We see that using the distribution functionwe propose in Fig. 4, with high probability a node willselect a TTL value that has a large area to the right ofit, while choosing a large TTL value (providing limited

anonymity) is unlikely. We set a minimum TTL value inorder to hide the path to a global passive adversary. Nodesreceiving RREP or DATA messages that are not part of thepath decrement the TTL before forwarding the message,as described in Sect. 3.4 and Sect. 3.5.

3.6.2 Padding

Without padding the length of a Route Reply messagewould continuously decrease and hence reveal the numberof hops the RREP still needs to travel in order to reach itstargetS. In order to prevent this, node D (the source ofthe RREP message) adds padding bits to the RREP before

transmitting it. The lengthl of this padding is selected us-ing a uniform probability distribution (lmin l lmax).Nodes forwarding a RREP message keep the length of themessage constant by right padding the RREP message be-fore forwarding it to compensate for length reduction cre-ated by the peeled off layer.

DATA messages are chopped into packets of equallength. The last packet is padded if necessary.

The length ofRoute Request messages grows as theytraverse the network. Without additional padding, thelength of a RREQ message discloses the distance the mes-sage has traveled. Moreover, the length of a fresh RREQ

message broadcast by the source Sis known to all nodesin the network (in contrast to the initial length of a RouteReply message, which can vary).

We use a similar design philosophy for the paddingscheme for RREQ as we used for the time-to-live scheme forRREP messages. The source randomly selects a paddinglength according to the probability distribution in Fig. 5.Note that a padding length of 5 means that the sourceadds random bits such that it seems that the RREQ mes-sage has already traveled 5 hops. NodeB that receives aRREQ message from nodeAwith a certain length can nowcompute the probability that it originated at node A. Theprobability that it didnotoriginate at the nodeA is equalto the surface of the area underneath the probability distri-bution left of the actual length of the packet. We see thatusing the distribution function we propose in Fig. 5, withhigh probability a node will select a padding length thathas a large area to the left of it, while choosing a paddinglength close to zero (providing limited anonymity) is un-likely. Note that large padding lengths offer higher privacyat a higher cost (since the message becomes larger andneeds to be encrypted at every forwarding hop). Nodesforwarding the RREQ messages do not add any padding.

3.7 Variations

The first variation is to use no broadcast encryption forthe RREP and DATA packets. The resulting scheme still

7


8/11

hides the real route from insiders, but no longer hides theroute from an external global passive adversary. This isbecause a global adversary can trace the route using theTTL values (all nodes broadcasting packets with the high-est TTL value are on the route, the other nodes are just

forwarding packets). Because of the limited view of theinsiders, they cannot make this analysis.The second variation is to also drop the use of the limited

broadcast of RREP and DATA packets (set the time-to-liveto zero). This is obviously the most efficient version, butnow routes are also visible to insiders neighboring the route(as only they will receive the DATA and RREP packets).

4 PADDING AND TTL SELECTION

4.1 Privacy offered by random TTL selection

We will now investigate how much privacy is offered byTTL value selection according to a given probability dis-tribution. Suppose that nodeB receives a message with aTTL value t from its neighbor node A (see Fig. 3). Theadversary in this case is nodeB that has received the mes-sage from node A.

Let Pbe the discrete probability distribution of the TTLvalue selection, with values pt, where pt is the probabilitythat a node selects an initial TTL value t (1 t tmax).

Assume that the adversary has a priori knowledge of theprobabilities that some node was the originator of the mes-sage that traverses route R. Let Sbe this discrete proba-

bility distribution with valuessR

Ni , wheresR

Ni is the a prioriprobability that node Ni is the originator of the messagethat traverses route R. This probability distribution canvary for every message the adversary observes.

Definition 4.1 (Privacy offered by a TTL value equal tot). We define the privacy of nodeA towards nodeB asthe probability that nodeA was not the originator of themessage with TTL value equal to t.

The probability that a message with a TTL value oftdidoriginate at nodeA is given by the conditional probabilityP(A|B) with:

A: node A generates a message with TTL value t;

B: node B receives a message with TTL value t.

Using Bayes theorem we can rewrite P(A|B) asP(B|A)P(A)/P(B). One can easily verify thatP(B|A) =1. The probabilityP(A) thatA generates a message withTTL equal tot is equal to the product of the probability ofA generating the message and the probability that it hasa TTL value oft:

P(A) = sApt with sA=R

sRA . (1)

We sum over all possible routes since all messages A sendswill be received by its neighbor node B .

The probability P(B) is the probability that some nodein the network generated a message that resulted in a TTLvaluet when it reached node B . This can be expressed as

P(B) =

|NiB|Rtmaxt

Ni,R

sNipt+h1 with h= |NiB|R . (2)

Here, |AB|R is the hop distance between nodes A and Busing route R. Note that the hop distance between twonodes depends on the route R the message follows. Thesummation goes over all nodes and all routes that originateat these nodes that pass through nodeA. The hop distanceis limited since the TTL value a node can select is limitedtotmax.

Using Eq. (1) and Eq. (2) we can compute the privacyoffered by a TTL value equal to t as

Privt = 1 P(A)

P(B) =P(B) P(A)

P(B) . (3)

This privacy depends on the probability distributions Pand S. The former is a system parameter, while the latteris the a priori knowledge the adversary has of the network(number of nodes, possible routes, probability of sendingmessages, etc.). At design time the a priori knowledge ofthe adversary is not known and we need to make someassumptions to select the optimal probability distributionP.

We can now compute the average privacy of a node thatgenerates messages with TTL values selected according to

the probability distribution P as

Priv(P) =

tmaxt=1

ptPrivt . (4)

Equivalent to the average privacy, we can also computethe average cost of a TTL distribution as (f(t) is func-tion that indicates how fast the number of nodes, that willforward a message originating from node A with a TTLvaluet, grows).

Cost(P) =

tmax

t=1

ptf(t) . (5)

The optimaldistribution for the TTL value selection isthe distribution that maximizes Priv(P)/Cost(P).

4.1.1 SelectingP

In order to be able to evaluate Eq. 4 and Eq. 5, we have tomake some assumptions. The first assumption we make isthat all nodes are equally likely to generate a message atany time. The second assumption we make is that routeswith shortest path length are selected amongst all possi-ble routes. This last assumption means that a node with

shortest hop distance h from node B has to generate amessage with a TTL value equal to t+h 1 in order forthis message to arrive at node B with a TTL value of t.

8


9/11

B A

pad = l

ttl = t ttl = t + 1

pad = l 1

ttl = t+ 2

pad = l 2

k1 k2 . . .

. . .

Figure 3: Evolution of padding and TTL values of a message. Node A receives a RREQ message with padding lengthl, or a RREP or DATA message with TTL value t. This message could have originated from node A or from nodesfurther away.

This also means that nodes that are closer to B than tonode A will never select a route that first passes A andthenB . This also means that the messageB receives fromAcould not have originated from a node within B s range(besides node A, obviously). These assumptions are de-picted in Fig. 3. We further assume that the density ofnodes is constant throughout the network. This meansthat the numbe of nodes ki at a certain hop distance igrows linearly with i: ki =C(2i 1) for i 1. This alsomeans that f(t) = t2 in Eq. 4. Note that this is true fornodes that are scattered on a flat surface; if the nodes areloacted within a three dimensional space, then the numberof nodes at at specific hop distance grows quadraticallywith the distance and f(t) =t3 in Eq. 4.

Using these assumptions, we can evaluate the averageprivacy and cost offered by a certain probability distribu-tion Pfor TTL value selection. Table 1 shows these valuesfor two different classes of probability distributions: expo-nential and linear. The node density was fixed atC= 12andtmax= 5. The normalization factor needs to be chosensuch that

ipi = 1. We see that the exponential distrib-

ution offers the highest attainable privacy and the highestattainable privacy/cost ratio. For growing values of tmaxboth the linear and the exponential distribution offer largermaximum privacy values, but at a lower privacy/cost ra-tio. For the linear distribution, the maximum privacy/cost

ratio decreases whentmaxgrows. In contrast, the exponen-tial distribution offers a constant maximum privacy/costratio, independent oftmax. This maximum is attained fora parameter selection a = 0.22. The node density C ofthe network has a positive influence on the privacy perfor-mance of the scheme as it lowers the probability that nodeAwas the originator of the message.

Figure 4 shows the probability pi that a certain TTLvalue is selected, the privacy Privi and the (normalized)costCostioffered by this selection, and the average privacyoffered by the exponential probability distribution P :pi =ai witha = 0.35. We see that (except for the last couple

of TTL values) the privacy offered is independent of theTTL value that is selected. We also see that the mostlikely TTL values have the lowest cost.

Table 1: Average privacy and privacy/cost ratio of two

probability distributions P for TTL value selection. Thenumbers in boldface indicate maximal attainable values (is a normalization factor).

P Param a Priv(P) Priv(P)Cost(P)

Exponential 0.22 0.56 0.28

pi= ai 0.59 0.82 0.15

0 0.72 0.066Linear

-0.1 0.74 0.15pi= + ai -0.071 0.81 0.12

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1 2 3 4 5 6 7 8 9 10

pi

,

Priv

i

,

Cost

i

,

Priv(P)

ttl value

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1 2 3 4 5 6 7 8 9 10

pi

,

Priv

i

,

Cost

i

,

Priv(P)

ttl value

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1 2 3 4 5 6 7 8 9 10

pi

,

Priv

i

,

Cost

i

,

Priv(P)

ttl value

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1 2 3 4 5 6 7 8 9 10

pi

,

Priv

i

,

Cost

i

,

Priv(P)

ttl value

Figure 4: Privacy and cost of an exponential probabil-ity distribution for TTL value selection (pi = a

i witha = 0.35). The first bar is the probability a TTL is se-lected, the second the privacy offered and the third thecost. The horizontal line is the average privacy offered bythe distribution.

4.2 Privacy offered by random padding length se-

lection

The evaluation of the privacy offered by random padding

selection is very similar to the evaluation of the privacy of-fered by random time-to-live value selection. Assume thesame situation as in Sect. 4.1, but now node B receives a

9


10/11

message from nodeAwith a lengthl. The term lengthindicates how many hops this message seems to have trav-eled from the source. A message broadcast by the source Swithout any padding has length l = 0. A message that hastraveled one hop from the source, or has padding length

1, has a total length of 1, etc. With these definitions, theeventsA and Bbecome:

A: node A generates a message with length l;

B: node B receives a message with length l .

Let P be the discrete probability distribution of thepadding length selection, with values pl, where pl is theprobability that a node selects a padding lengthl (0 l lmax).

Definition 4.2 (Privacy offered by a padding length l).We define the privacy of nodeA towards nodeB as the

probability that nodeA was not the originator of the mes-sage with padding length l.

Analogous to Sect. 4.1 we can derive equations forP(A),P(B), Privl, Priv(P), Costl and Cost(P). If we assumethat the density of nodes is constant troughout the net-work, then

Cost(P) =

lmaxl=0

pl(1 + l).

Here, is the ratio of the true length of a single paddingblock (in bits) to the length of a RREQ without padding as

it leaves the source. The length of a single padding block isapproximately 1024 bits when using RSA, while the lengthof an unpadded RREQ is approximately 3530 bits whenusing AES and |D| = 64, |k| = 80, |NymSD = 64|, and|ttl| = 10. This results in 0.3. Note that the cost onlygrows linearly with the padding length l; this is becausethis padding is only added once at the source.

Table 2 shows numerical results for exponential and lin-ear probability distributions. The number of 1-hop neigh-bors is fixed at C = 6 and lmax = 4. We see that theexponential distribution offers the highest attainable pri-vacy. For growing values of tmax both the linear and theexponential distribution offer larger maximum privacy val-ues, but at a lower privacy/cost ratio. The node densityC of the network has a positive influence on the privacyperformance of the scheme as it lowers the probability thatnode A was the originator of the message.

Figure 5 shows the probabilitypithat a certain paddinglength is selected, the privacy Privi and the (normalized)cost Costi offered by this selection, and the average pri-vacy offered by the exponential probability distributionP : pi = a

i with a = 1/0.35. We see that (except forthe first couple of padding lengths) the privacy offered isindependent of the padding length that is selected. Wealso see that the most likely padding values have the high-

est cost (in contrast to the TTL scheme). Fortunately, thepadding scheme is only used for RREQ messages and notfor the more common DATA packets.

Table 2: Average privacy and privacy/cost ratio of twoprobability distributions P for padding length selection.The numbers in boldface indicate maximal attainable val-ues ( is a normalization factor).

P Param a Priv(P) Priv(P)Cost

(P)Exponential 1.16 0.77 0.46

pi= ai 1.70 ( 10.59

) 0.82 0.44

0 0.72 0.45Linear

0.032 0.77 0.46pi= + ai

0.071 0.81 0.44

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 1 2 3 4 5 6 7 8 9

pi

,

Priv

i

,

Costi

,

Priv(P)

padding length

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 1 2 3 4 5 6 7 8 9

pi

,

Priv

i

,

Costi

,

Priv(P)

padding length

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 1 2 3 4 5 6 7 8 9

pi

,

Priv

i

,

Costi

,

Priv(P)

padding length

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 1 2 3 4 5 6 7 8 9

pi

,

Priv

i

,

Costi

,

Priv(P)

padding length

Figure 5: Privacy and cost of an exponential probabilitydistribution for padding length selection (pi = a

i witha = 1/0.35). The first bar is the probability a padding

length is selected, the second the privacy offered and thethird the cost. The horizontal line is the average privacyoffered by the distribution.

5 ANALYSIS OF THE PROTOCOL

5.1 Route Hiding

Our protocol effectively hides routes between sources anddestinations, both against a passive global adversary andnodes inside the network. Because of the probabilisticpadding and TTL scheme we use, nodes inside the net-work will not be able to determine whether the node theyreceived a message from is the source of this message orforwarding it. Nor can they tell which nodes are part of aroute between two nodes. Nodes on a route are not able totell which node is communicating with which other nodeby inspecting the messages they are forwarding. A pas-sive global adversary will be able to learn which nodes arethe sources of fresh messages, but he will not be able totrace this message and learn which nodes are forwardingthe message and which node is the final destination. Theprobabilistic TTL scheme hides the actual path betweensource and destination in a cloud of possible paths as

this message is forwarded by every node that receives it(whether the node is on the path or not) until the TTLfield finally reaches zero (see Fig. 2). Note that this scheme

10


11/11

only works in networks where every node is surrounded bymultiple neighbors. In very sparse networks, hiding routesis very difficult, as there are only a limited number of pos-sible routes an actual message could have followed.

5.2 Efficiency

Our protocol requires no cryptographic operations in orderfor nodes to be able to recognize whether a message istargeted at them or not. Next to this, participating inthe forwarding of a RREQ message only requires nodes toperform a single public key encryption. When using Rabin,this can be implemented very efficiently (Menezes et al.(1997)). Our probabilistic TTL scheme makes it possibleto hide the path between source and destination withoutflooding the entire network. Nodes that only participatein the hiding process only need to decrypt and encrypt theshort message header using their broadcast keys.

6 CONCLUSIONS

Anonymity is an important part of the overall security ar-chitecture for mobile ad hoc networks. Without sufficientmeasures to protect the privacy, users will leave a digi-tal trace of all their actions (including there location). Inthis paper we first give an analysis of the current state ofthe art in anonymous ad hoc routing protocols and indi-cate the strenghts and weaknesses. We proposed a novelanonymous routing protocol, clearly indicating our designmotivations. Finally, we provided a detailed analysis ofthe privacy offered by hiding routes in limited broadcastgroups, and padding messages.

ACKNOWLEDGMENT

This work presented in this paper was supported inpart by the Concerted Research Action (GOA) Ambior-ics 2005/11 of the Flemish Government and in part bythe Interdisciplinary institute for BroadBand Technology(IBBT) of the Flemish Government.

REFERENCES

D. Balfanz, G. Durfee, N. Shankar, D. K. Smetters,J. Staddon, and H. C. Wong, Secret handshakesfrom pairing-based key agreements, in Proceedings ofthe 2003 IEEE Symposium on Security and Privacy,pp. 180196, IEEE, 2003.

P. S. L. M. Barreto, H. Y. Kim, B. Lynn, and M. Scott,Efficient algorithms for pairing-based cryptosystems,

in Advances in Cryptology - CRYPTO 2002, vol. 2442of Lecture Notes in Computer Science, pp. 354368,Springer-Verlag, 2002.

D. Boneh and M. K. Franklin, Identity-based encryp-tion from the Weil pairing, in Advances in Cryptology -CRYPTO 2001, vol. 2139 ofLecture Notes in ComputerScience, pp. 213229, Springer-Verlag, 2001.

A. Boukerche, K. El-Khatib, L. Xu, and L. Korba, A

novel solution for achieving anonymity in wireless ad hocnetworks, in Proceedings of the 1st ACM InternationalWorkshop on Performance Evaluation of Wireless Adhoc, Sensor, and Ubiquitous Networks, pp. 3038, ACMPress, 2004.

J. Kong and X. Hong, ANODR: anonymous on demandrouting with untraceable routes for mobile ad-hoc net-works, in Proceedings of the 4th ACM InternationalSymposium on Mobile Ad hoc Networking and Comput-ing (MOBIHOC 2003), pp. 291302, ACM Press, 2003.

A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone,

Handbook of Applied Cryptography. CRC Press, 1997.

Y. Zhang, W. Liu, and W. Lou, Anonymous communi-cations in mobile ad hoc networks, in Proceedings ofthe 24th Annual Joint Conference of the IEEE Com-puter and Communications Societies (INFOCOM 2005),vol. 3, pp. 19401951, IEEE, 2005.

B. Zhu, Z. Wan, M. S. Kankanhalli, F. Bao, and R. H.Deng, Anonymous secure routing in mobile ad-hocnetworks, in Proceedings of the 29th Annual IEEEInternational Conference on Local Computer Networks(LCN 2004), pp. 102108, IEEE, 2004.

11

Documents

ARM: Anonymous Routing Protocol for Mobile Ad Hoc Networks