1916 ieee journal on selected areas in …

1916 IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 24, NO. 10, OCTOBER 2006

ARSA: An Attack-Resilient Security Architecture forMultihop Wireless Mesh NetworksYanchao Zhang, Member, IEEE, and Yuguang Fang, Senior Member, IEEE

Abstract—Multihop wireless mesh networks (WMNs) arefinding ever-growing acceptance as a viable and effective solutionto ubiquitous broadband Internet access. This paper addressesthe security of WMNs, which is a key impediment to wide-scaledeployment of WMNs, but thus far receives little attention. Wefirst thoroughly identify the unique security requirements ofWMNs for the first time in the literature. We then propose ARSA,an attack-resilient security architecture for WMNs. In contrast toa conventional cellular-like solution, ARSA eliminates the need forestablishing bilateral roaming agreements and having real-timeinteractions between potentially numerous WMN operators. WithARSA in place, each user is no longer bound to any specificnetwork operator, as he or she ought to do in current cellularnetworks. Instead, he or she acquires a universal pass from athird-party broker whereby to realize seamless roaming acrossWMN domains administrated by different operators. ARSAsupports efficient mutual authentication and key agreement bothbetween a user and a serving WMN domain and between usersserved by the same WMN domain. In addition, ARSA is designedto be resilient to a wide range of attacks. We also discuss otherimportant issues such as incontestable billing.

Index Terms—Authentication, denial-of-service (DoS), keyagreement, roaming, security, wireless mesh networks (WMNs).

I. INTRODUCTION

MULTIHOP wireless mesh networks (WMNs) are in-creasingly recognized as ideal solutions to ubiquitous

last-mile high-speed Internet access. A typical WMN has alayered structure, as shown in Fig. 1. The first layer consists ofaccess points (APs) which are high-speed wired Internet entrypoints. At the second layer, stationary mesh routers form a mul-tihop backbone via long-range high-speed wireless techniquessuch as WiMAX [1]. The wireless backbone connects to wiredAPs at some mesh routers through high-speed wireless links. Itprovides multihop wireless backhaul between wired APs andmesh clients (i.e., end users) at the lowest layer.1 Mesh clients,while at rest or in motion, can assess the network either by adirect wireless link to a nearby mesh router or by a chain ofother clients to a mesh router out of reach. WMNs represent

Manuscript received September 15, 2005; revised March 30, 2006. This workwas supported in part by the U.S. Office of Naval Research under Young Inves-tigator Award N000140210464, and in part by the U.S. National Science Foun-dation under Grant ANI-0093241 (CAREER Award) and Grant DBI-0529012.

Y. Zhang is with the Department of Electrical and Computer Engineering,New Jersey Institute of Technology, Newark, NJ 07102 USA (e-mail:[email protected]).

Y. Fang is with the Department of Electrical and Computer Engineering, Uni-versity of Florida, Gainesville, FL 32611 USA (e-mail: [email protected]).

Digital Object Identifier 10.1109/JSAC.2006.877223

1We use “client” and “user” as synonyms throughout the paper. We will notdistinguish the user and the device either.

Fig. 1. A typical three-tiered WMN architecture.

a unique marriage of the ubiquitous coverage of wide-areacellular networks with the ease and the speed of local-areaWi-Fi networks. Other notable advantages of WMNs includelow deployment costs, self-configuration and self-maintenance,good scalability, high robustness, and so on [2]. Consequently,WMNs have sparkled a surge of research, development, andstandardization activities, of which we refer to [2] for a com-prehensive survey.

Security is one of the main barriers to wide-scale deploymentof WMNs, but has gained little attention so far. The necessityfor security in large-scale WMNs can be best illustrated by thefollowing example. Suppose David wishes to retrieve some im-portant documents from his corporate network back in Miamivia a local WMN in Philadelphia, where he is on a businessstay. On the one hand, the serving WMN has to corroborate theidentity of David to avert fraudulent use of network resources;on the other hand, David might as well want to authenticate theserving WMN to prevent an attacker from impersonating a legit-imate WMN to obtain confidential information from him. Othersecurity concerns may include the location privacy of David,passive eavesdropping, denial-of-service (DoS) attacks, and soforth. We will dwell on the security requirements of WMNs inSection II-A.

The security of nomadic users and the serving wirelessnetworks has been studied extensively in the past. Elegantsolutions are available in the contexts of Global System for

0733-8716/$20.00 © 2006 IEEE

ZHANG AND FANG: ARSA: AN ATTACK-RESILIENT SECURITY ARCHITECTURE FOR MULTIHOP WMNS 1917

Mobile Communications (GSM) [3], Personal CommunicationSystems (PCSs) [4], Universal Mobile TelecommunicationSystem (UMTS) [5], [6], and Mobile IP networks [7], amongothers. Despite their differences in specifics, these schemes alldepend on a home/foreign-domain model. Specifically, eachuser has a home network domain, where he2 is registered on along-term basis and account information is maintained. Eachtime the user roams into a foreign network domain, his homedomain is contacted for his credentials to authenticate him.Subsequently, the foreign domain reports the amount of serviceassessed by the user to his home domain which, in turn, pays theforeign domain and charges the user an amount commensuratewith his usage. We argue that such solutions are less suitable forfuture large-scale WMNs due to at least the following reasons.

First, a bilateral service level agreement (SLA) has to beset up between each pair of network operators to permit userroaming between them. Establishing such SLAs may be a rel-atively easy task in cellular networks, where the operators arecomparatively limited in number. Due to the easy-deploymentnature of WMNs, however, the future large-scale WMNs areexpected to comprise numerous WMN domains, each adminis-trated by an independent operator [2]. Unlike a cellular operatoroften of a nationwide or larger scale, a WMN operator may beon a community, section, metro, or larger scale. Consequently,the number of WMN operators will be much larger than thatof cellular operators. This renders it less feasible to establishpairwise bilateral SLAs among them.

Second, the above solutions all involve a potentially time-consuming and expensive execution of an authentication pro-tocol among a user, his home domain and the foreign domain.As the user base grows large, the overall network authenticationsignaling overhead would be significant. In addition, in view ofthe high-speed wireless link, the authentication latency may beunacceptable for some short-lived data applications. Assume,for example, that a mesh client connects to a mesh router via an802.11 a/g link with a raw rate up to 54 Mb/s. It may take theclient just a couple of seconds to download several tens of MP3music files. This makes it highly desirable to minimize the au-thentication delay.

Third, under conventional solutions, mesh routers will be-come very attractive targets and network entry points for DoS ordistributed DoS (DDoS) attacks. For example, an attacker con-tinuously sends fake authentication requests to a mesh routerwhich, in turn, has to contact the home domains of the imper-sonated or even nonexistent users. If lots of collusive attackerslaunch this type of attack simultaneously, the resulting authen-tication signaling traffic will severely interfere with normal net-work signaling and data traffic.

Finally, conventional solutions fail to take into considerationthe multihop communication paradigm featured by WMNs, aswell as the communication security among mesh clients withinthe coverage of a same mesh router.

The limitations of conventional solutions necessitate the de-velopment of a brand-new security architecture to cope withthe unique requirements of WMNs. In this paper, we answerthis important open question affirmatively by proposing ARSA,

2No gender implication.

an attack-resilient security architecture for large-scale WMNs.ARSA stems from an all-too-familiar scenario in real life. A userfirst applies for a credit card with a bank whereby to buy goodsat any merchant accepting credit cards. Merchants need not es-tablish agreements with each other, but just need to have a trustrelationship with one or a few banks that accept payments fromcredit-card users and pay merchants. If we regard each merchantas a distinct WMN domain, the consumption of a user at dif-ferent merchants can be viewed as his roaming across variousWMN domains. This natural analogy motivates us to adopt thesophisticated credit-card-based business model while designingARSA.

The players in ARSA are brokers, users, and WMN opera-tors whose relationship is analogous to that among a bank, acredit-card user, and a merchant. Each user acquires a universalpass from a broker whereby to enjoy ubiquitous WMN access.Once authenticating a pass, a WMN operator can grant access tothe pass holder without fear of not being paid later. As comparedwith conventional home/foreign-domain solutions, ARSA doesnot require WMN operators to establish pairwise bilateral SLAs.Rather, each WMN operator merely needs to have an agreementwith one or a few brokers whose number is considered muchsmaller than that of global WMN operators. In addition, mu-tual authentication and key agreement (AKA) between a meshclient and the serving WMN domain just involve local inter-actions without the real-time involvement of the correspondingbroker. This is particularly beneficial for reducing authentica-tion signaling overhead and latency. Furthermore, ARSA sup-ports efficient pairwise AKA among mesh clients present in thesame WMN domain. ARSA is also designed to be resilient tovarious attacks, including the location privacy attack, the de-nial-of-access attack, the bogus-beacon flooding attack, and thebandwidth-exhaustion attack.

As far as we know, our ARSA is the first attempt to addressthe security of WMNs. It provides a solid foundation on whichto solve other security issues in WMNs such as secure routingand medium access control (MAC). Since the research and de-velopment of WMNs are still in their very early stage, we be-lieve that ARSA has a high potential of becoming an importantcomponent of future large-scale WMNs.

The rest of this paper is organized as follows. Section II de-scribes the unique security requirements of WMNs and the ba-sics of ID-based cryptography (IBC) on which we build ARSA.Next, we present the network architecture and some systemmodels, followed by a detailed illustration of the AKA process.In Section V, we identify a few severe attacks against WMNsand provide the related countermeasures. We then discuss sev-eral other important issues in Section VI and end with conclu-sion and future work.

II. PRELIMINARIES

A. Security Requirements of WMNs

Throughout this paper, we refer to the combination of themultihop wireless backbone, the wired APs, and any otherWMN operator equipments, as the infrastructure. We also usethe term “mesh” to indicate a subnet comprising a mesh router


and its covered mesh clients. From a high-level point of view,we identify the following security requirements of WMNs.

• Infrastructure security: This means the security of sig-naling and data traffic transmitted over the infrastructure.

• Network access security: This indicates the communica-tion security between a mesh client and a mesh router. Itmay also involve the communication security among meshclients served by the same mesh router, if the route betweena client and a router is in multiple hops.

• Application security: This refers to the security of meshclients’ concrete data applications.

Among them, infrastructure security is relatively easy toachieve since the infrastructure is under the full control of aWMN operator and the network elements of the infrastructureare typically stationary. Application security can also be easilyachieved via high-layer security mechanisms such as IPsec,TLS, or VPNs. By contrast, network access security is muchmore difficult to ensure than the other two. One major reason isthat mesh routers are designed to accept open access requestsby most likely unknown mesh clients. Other notable causesinclude open access to the wireless channels and the dynamicnetwork topology caused by the mobility of mesh clients. Forlack of space, we focus on investigating network access securityin this work, and leave the exploration of the other issues asfuture work.

With respect to network access security, we recognize the fol-lowing specific requirements, which are, however, not neces-sarily a complete list.

1) Router-client authentication: A mesh router should au-thenticate a requesting client to prevent unauthorizednetwork access. The client should also authenticate therouter to shun bogus mesh routers of attackers.

2) Router-client key agreement: The mesh router and theclient should establish a shared key to encrypt and authen-ticate radio messages transmitted between them.

3) Client–client authentication: This is required when oneclient forwards another’s traffic to and from the meshrouter. In general, each client should only help otherlegitimate ones to get proper remuneration later.

4) Client–client key agreement: If needed, two mesh clientsshould establish a shared key whereby to encrypt and au-thenticate the traffic between them.

5) Location privacy: No entity other than a mesh client him-self and a responsible location management authority (ifany) should know both the real identity and the current lo-cation of the mesh client.

6) Signaling authentication: The signaling data broadcast bya mesh router should always be authenticated to be distin-guishable from those announced by an attacker.

7) Service availability: A mesh router must be protected fromDoS attacks and offer always available services.

8) Incontestable billing: A mesh client should just pay whathe ought to pay, while a WMN operator, as well as thoseclients forwarding traffic for others, receives the amountcommensurate with the offered service.

9) Secure routing: The routing protocol used inside a meshshould be secured against attacks.

10) Secure MAC: The MAC protocol employed within a meshmust be resilient to attacks.

We do not have the ambition in this paper to satisfactorily ad-dress all these requirements. Rather, we concentrate on solvingthe first seven issues and will outline a feasible billing schemein Section VI. These efforts will offer a solid foundation for ad-dressing the rest two issues.

B. Basics of IBC

As the cryptographic foundation of ARSA, IBC [8] is re-ceiving extensive attention as a powerful alternative to tradi-tional certificate-based cryptography (CBC). Its main idea is tomake an entity’s public key directly derivable from his publiclyknown identity information such as his e-mail address. IBC thuscompletely eliminates the need for public-key distribution real-ized via conventional public-key certificates. The recently rapiddevelopment of IBC is made possible by the application of anintriguing pairing technique outlined below.

Let denote a cyclic additive group of some large primeorder and a cyclic multiplicative group of the same order.Assume that the discrete logarithm problem (DLP) is hard3 inboth and . For us, a pairing is a mapsuch that for all and all

(1)

Note that is also symmetric, i.e., for all, which follows immediately from the bilinearity of

and the cyclicity of . Typically, the map will be derivedfrom either the Weil or Tate pairing on an elliptic curve over afinite field. We refer to [9] and [10] for a more comprehensivedescription of how the pairing parameters should be chosen inpractice for both efficiency and security.

III. SYSTEM MODELS AND NOTATION

In this section, we present the network, trust, and pass modelsadopted in our ARSA, as well as the notation used.

A. Network Model

Future large-scale WMNs are expected to consist of a largenumber of WMN domains of different scales. Each WMN do-main is operated by an independent operator and composed ofa certain number of meshes, either physically adjacent or non-adjacent. For example, a WMN operator may own meshes inmultiple cities or only in one city section. WMN domains mayoverlap with each other, and whether or not neighboring do-mains are connected solely depends on operator policies.

In general, a mesh router has much more powerful com-putation and communication capacities and abundant otherresources than regular mesh clients. It is, therefore, reasonableto assume that a mesh router sends packets in one hop to allmesh clients in its coverage. By contrast, a mesh client maytransmit packets in one hop or multiple hops to a mesh routerwithin or beyond his transmission range. As noted in [11],a single-hop downlink can be highly beneficial. First, meshclients can save their scarce energy, as there is no need to relay

3It is computationally infeasible to extract the integer x 2 = fi j 1 �i � q � 1g, given P;Q 2 (respectively, P;Q 2 ) such that Q = xP

(respectively, Q = P ).


downlink packets. Second, a single-hop downlink can greatlyfacilitate the transmissions of control signaling packets fromthe mesh router to all mesh clients. Last, it renders the radioresource allocation performed by the mesh router much easierto implement. Note that, however, our ARSA can be easilyextended for use in symmetric WMNs with both multihopuplinks and downlinks.

It is worth pointing out that communications to and from amesh router will be the major traffic pattern within a mesh. Thisis in line with the target use of WMNs, namely, relaying endusers’ traffic to and from the wired Internet. Such a unique trafficpattern would significantly reduce the routing complexity frommesh clients’ point of view. The reason is that they only need tomaintain a route to the mesh router instead of one route to eachother client in the same mesh.

To make ARSA independent of the underlying network im-plementations, we do not specify the MAC and routing proto-cols in use. Interested readers are referred to [2] for a detailedsurvey of candidate schemes.

B. Trust Model

The trust model of our ARSA is composed of a number oftrust domains, each managed by a broker or WMN operator. Toenjoy ubiquitous WMN access, each mesh client has to first reg-ister with at least one broker which, in turn, issues an electronicuniversal pass to the client. If enrolling in more than one broker,a client may accordingly own multiple passes. Each WMN op-erator is also required to have a trust relationship with one or afew brokers. It will grant network access to mesh clients holdingvalid passes issued by its trustable broker(s). In fact, one mayview brokers as regular banks with which both mesh clients andWMN operators have opened accounts. We assume that brokersare fully trustable by both clients and operators, but a client andan operator usually do not play full trust on each other.

The above trust model fits in well with ubiquitous Internetaccess via WMNs. Mesh clients see the advantage of beingable to get on-demand network access by any WMN operator.The operators are relived from the heavy burden of establishingpairwise bilateral SLAs with potentially many other operators.Instead, each of them just needs to have a trust relationship withcertain broker(s) whose number is considered much smallerthan that of WMN operators. Furthermore, the operators haveall mesh clients as potential customers, which is in contrastto the home/foreign-domain model, where a user is locked toa specific operator once signing an agreement. The brokerscan make profits by deducing fees from an operator’s credit oradding fees to a client’s charge. They may also impose entry orsubscription fees to mesh clients and operators for participationin their trust systems.

C. Notation

We denote by and the th broker and WMN operator,respectively. We use to indicate the unique identifier ofclient enrolled in . Typically, is of a standard format“userName@brokerName” [12]. In addition, refers tothe unique identifer of mesh router of , which is of thesame format “routerName@operatorName.” We indicate byPASS the pass of and by a pass-based key

(pass-key for short), both issued by to . Likewise,PASS and are used to denote the router pass and thepass-key, respectively, which obtains from operator .Furthermore, PASS refers to a temporary client(pass, pass-key) pair that issues to a served client .

We will also use the following cryptographic primitives.refers to the keyed message integrity code (MIC) of

message under key , where indicates a fast one-way hashfunction such as SHA-1 [13]; means encrypting mes-sage under key via a symmetric-key algorithm;denotes an IBC encryption operation of message with publickey ; indicates message with its IBC signatureunder private key . We refer to [14] for a number of elegantIBC encryption and signature schemes.

D. Trust-Domain Initialization

A crucial issue in ARSA is the design of passes, throughwhich a mesh client and a serving WMN can achieve mutualAKA. It is natural to consider using digital certificates as passes.The most commonly-used X.509 certificate [15] is, however,about 1 KB in length, which might translate to a significantbandwidth overhead incurred in transmitting them. To make asshort a pass as possible, we propose to utilize the emerging IBC.For this purpose, we require the administrator of each trust do-main to perform the following domain-initialization operations.

1) Generate the pairing parameters ,where is a generator of , and is a hash functionmapping given strings to nonzero elements in .

2) Pick a random as the domain secret wherebyto compute a domain public key as .

We define the public trust-domain parameters as follows:

domain params

group params, domain public key

The domain administrator must keep confidential, whilemaking domain params publicly known. As Diffe–Hellmangroup parameters used in IPsec [16], group params canbe standardized by such organizations as IETF. This wouldmake it possible to use a well-known short index in place ofgroup params. In contrast, and should be uniqueto each trust domain. Also, note that it is computationallyinfeasible to deduce from the pair because of thedifficulty of solving the DLP in (cf. Section II-B).

It is a prerequisite in an IBC cryptosystem that twocommunication entities use the same domain params.This poses the demand for an assurance on the legiti-macy of domain params, which is satisfied in ARSAvia domain params certificates. In particular, we assumethat there is a trusted third party (TTP) with well-knowndomain params and a pri-vate domain secret . The TTP, for instance, canpublish its domain params through its website. Uponrequest of a certificate for domain params, the TTPcomputes domain params and returns it to therequesting domain administrator. We refer to such adomain params domain params pair as a


domain params certificate. For ease of presentation,we indicate by domain cert and domain cert thedomain params certificate of operator and broker ,respectively.

To validate a domain cert, one just needs to check whether

domain params

domain params (2)

The equation should hold for an authentic domain certbecause

domain params

domain params

by the bilinearity of (cf. Section II-B) and .Our method of certifying domain params is an application

of the provably secure ID-based short-signature scheme byBoneh et al. [17]. Another way to certify domain paramsis to rely on conventional public-key certificates [18]. Suchdomain params certificates can be stored at some publicdirectory from which they can be retrieved as needed. Analternative way is to use the Domain Name System (DNS),where the domain cert of each trust domain is stored anddistributed as part of its DNS record [19]. Also note that, inreality, the root TTP may be replaced by a hierarchy of TTPs,similar to the traditional public-key infrastructure (PKI), inwhich a higher-level TTP certifies domain params of eachTTP at the adjacent lower level. In this scenario, a conven-tional certificate-chain method [20] can be used for verifyingdomain params certificates generated by different TTPs. Forclarity and ease of presentation, however, we will just discussthe single TTP case in the rest of this paper.

E. Pass Model

There are three types of passes in ARSA: router passes(R-PASSes) issued by a WMN operator to its mesh routers,client passes (C-PASSes) provided by a broker to the regis-tered clients, and temporary client passes (T-PASSes) givenby a WMN operator to mesh clients present in its domain. Inthis subsection, we focus on the issuance of R-PASSes andC-PASSes, and defer the discussion on T-PASSes to Section IV.

1) Issuance of R-PASSes: We take operator as an exampleto explain the issuance of R-PASSes. Prior to network deploy-ment, issues to each controlled router an R-PASSPASS expiry time , as well as a pass-key

PASS which keeps secret. Here,is operator ’s domain secret, and is the hash

function specified in domain params . The freshness ofPASS is controlled by the expiry time field. shouldsend to a new PASS pair via a secure channelbefore its current one expires. Depending on ’s securitypolicies, PASS may be updated hourly, daily,weekly, or even monthly. New pairs can be sent along withother domain-related control signaling traffic to minimize thecommunication overhead.

In essence, PASS is a standard ID-based publicand private key pair in an IBC cryptosystem. Alternatively,

PASS can be designed as a conventional public-key certifi-cate and as the corresponding private key. As comparedwith a typical X.509 certificate of about 1 KB, our ID-basedPASS has at most a few tens of bytes in size. The mainreason is that it retains the entity identifier and expiry timeparts of a certificate, while dumping the most space-consumingfields, namely, a public key and the digital signature of a cer-tification authority (CA). The merits of such ID-based passesin facilitating efficient entity AKA will be seen more clearly inSection IV.

2) Issuance of C-PASSes: To enjoy ubiquitous WMN access,each client has to first register with a desired broker, similar toapplying for a credit card with a bank. Consider broker as anexample. Upon a registration request from client usuallyneeds to validate the client’s personal data such as his driver’slicence or social security number (SSN), as well as checking hiscredit status. may also ask for a security deposit as requiredby its registration policy. Subsequently, assigns to the appli-cant an identifier and a C-PASS in the form of

PASS expiry time,otherTerms

Here, expiry time specifies the expiry time of PASS be-fore which has to renew it if desiring to stay with . Broker

may use the otherTerms field to name other terms and con-ditions should comply with. For instance, it may specifythe per-day spending limit of at any WMN domain, or thelist of WMN domains is allowed to visit, which have coop-erative agreements with .

In addition to PASS , the broker issues to apass-key PASS , where is ’sdomain secret and is the hash function specified indomain params . Likewise, PASS is a stan-dard ID-based public and private key pair. As an R-PASS,PASS is much shorter than a conventional certificaterealizing the same functionalities, namely, having the sameotherTerms field.

3) Protection and Revocation of C-PASSes: Since routerpasses can be easily protected, here we only concentrate onprotecting and revoking user passes. Client may storePASS in his often-used mobile device or on a

USB drive to use it on multiple devices if any. PASS canbe made publicly known, while must be kept confidentialto himself. There are many possible ways to protect .An all-too-familiar method is to ask to enter a personalidentification number (PIN) for per access to .

It is possible that a careless client loses his (pass, pass-key)pair unprotected using the PIN method. This occurs, for in-stance, when the client loses the mobile device or the USB drivestoring his secret pair. In that case, the client should report itimmediately to the broker and his liability should be limitedaccordingly, as it is for credit-card loss. However, it should benoted that the loss of a client (pass, pass-key) pair would causemuch less severe consequences or financial loss than that of acredit card. The principle reason is that C-PASSes are not de-signed for purchasing regular goods of possibly high values, butspecifically for buying Internet access services whose rates arebecoming more and more lower.


A broker can take further measures to minimize its financialrisk. For example, if a client repeatedly reports a (pass, pass-key)loss, it may refuse to issue him new secret pairs. The broker mayalso specify a carefully designed spending-limit in a C-PASS.Moreover, the broker may use a short C-PASS validity period,say one day, and send to a client (e.g., via e-mail) a new se-cret pair at the early morning of each day that is only validfor that day. Furthermore, the broker can maintain a hot list ofC-PASSes whose holders have reported losses, or which are oth-erwise problematic. WMN operators can periodically downloadthe host lists from the brokers during idle hours, and refuse toserve mesh clients whose presented C-PASSes are on the hostlists. Although the last measure requires certain interactions be-tween WMN operators and brokers, it is an offline method andstill considered much more lightweight than a conventional cel-lular-like method, where the foreign operator has to performreal-time checking with a roaming user’s home operator abouthis account status.

IV. AUTHENTICATION AND KEY AGREEMENT (AKA)

In this section, we illustrate how to utilize R-PASSes andC-PASSes to realize both router-client and client–client AKA.We also distinguish interdomain AKA and intradomain AKA.The former occurs when a client migrates from one WMN do-main to another, and the latter happens while a client makes hisway from one mesh to another of the same WMN domain. Inaddition, we make the usual assumption that interdomain mi-grations happen less frequently than intradomain ones. So doesinterdomain AKA than intradomain AKA.

A. Interdomain AKA

Without loss of generality, we take client and meshrouter as an example to explain the interdomain AKAprotocol, which works in the following three steps:

PASS domain cert

PASS

PASS PASS

Router periodically broadcasts a beacon (A.1) via thesingle-hop downlink to announce its presence. The beaconshould at least include PASS domain cert , and afresh timestamp signed with its pass-key and used todefend against message replay attacks [20]. The beacon mayalso contain other network service information such as thecurrent network access fee of .

The beacon can be received by all mesh clients in router’s coverage. Assume that client is currently served by

a WMN domain other than . Upon receipt of (A.1), he maychoose to switch to under certain conditions. For example,he may do so if has a much stronger signal strength thanthe serving router, or the access fee of is lower than that ofthe serving operator. Supposing that is the case, performsthe following operations in sequence.

1) Check whether the difference between and his localclock time is within an acceptance window.4

2) Make sure that PASS has not expired by examiningits expiry time field.

3) Validate domain cert1

according to (2).4) Use domain params to verify

with PASS as the public key.We need to stress that just needs to execute step 3once for operator . In other words, knowing the authenticdomain params enables him to verify the signatures ofany router of . If any of the checks fails, considersthe beacon bogus and ignores it. Otherwise, he regardsas a legitimate router of , and then forms message (A.2),including PASS and a timestamp signed under .

As for the uplink transmission of (A.2) to , there are twocases deserving consideration. If is within direct reach,

simply sends (A.2) to via the single-hop uplink. Themore challenging case is when is out of ’s transmis-sion range. A naive solution is for to ask clients betweenhimself and , which have achieved mutual authenticationwith and known a uplink route to , to help relay (A.2) to

in a hop-by-hop fashion. This measure is, however, notquite realistic since intermediate clients are generally reluctantto forward (A.2) because of the uncertainty of getting later re-muneration from the as-yet unauthenticated . It may alsointroduce room for a special type of DoS attack, in which anattacker continuously sends lots of faked versions of (A.2) viainnocent intermediate clients to .

Fortunately, we can deal with the second case by harnessingthe transmit power control capability of many mobile devices,i.e., the ability to vary the transmit power in steps. In particular,the radio module of should be able to automatically bootthe transmit power just enough to send (A.2) to in one hop.During the postauthentication stage, the transmit power can bereduced back to the normal level so that may send packetsto in multiple hops. In doing so, he cannot only save hisbattery power, but also help increase spatial concurrency andfrequency reuse, as is shown in [21].

Since brokers are relatively fewer in number, it is rea-sonable to assume that can acquire and verify thedomain params certificates of all the brokers (including

) in advance. An alternative solution is to let ap-pend domain cert to (A.2). Once learning the authenticdomain params , router shall be able to verify thesignatures by all the registered clients of . Upon receiving(A.2), first checks that PASS is not on the hot list of

(cf. Section III-E3). It then carries out actions analogousto what did. If all the inspections are successful,determines that is a legitimate registered client of broker

it trusts.After authentication of , router contacts its domain

administrator to acquire the following data:

PASS expiry time

PASS

4This can be a fixed-size time interval, e.g., 10 ms or 20 s, preset to accountfor the maximum message transit and processing time, plus clock skew.


PASS will be the temporary pass (T-PASS) ofin domain , where is his temporary identifier andexpiry time indicates the expiry time of PASS . Next,

sends PASS in plaintext and pass-key en-crypted under public-key PASS to in message (A.3).

Upon receipt of (A.3), first decrypts usinghis pass-key , and then checks that the equation

PASS holds. Here,

and are extracted from domain params .

The check should succeed for a valid PASSpair due to the following equations:

PASS

PASS

PASS

The second line is due to the bilinearity of , and the thirdline holds because . After a successful check,

saves PASS for subsequent use as his tem-porary credential in domain . Router and its domainadministrator may record the mapping between PASS andPASS if needed. We will soon show the usefulness of suchtemporary credentials in both intradomain client-router authen-tication and client–client authentication.

After a successful three-way handshake, and canestablish a shared key as

PASS

PASS PASS

PASS PASS

PASS (3)

The above equations hold by the bilinearity and symmetryof (cf. Section II-B). Here, (respectively, )derives the shared key using the first line (respectively, fourthline) pairing computation. This key agreement method is firstpresented in [22], which shows that the shared key will beexclusively known to the two entities establishing it. and

can then use the shared key to secure subsequent trafficbetween them via efficient symmetric-key algorithms.

B. Intradomain AKA

Intradomain authentication occurs when client movesout of the coverage area of into that of another router of

, say . The naive reuse of the interdomain AKA pro-tocol is less efficient because the established trust relationshipbetween and is not exploited. Another option is tolet hand over the shared key to via a se-cure channel. The purpose is to allow and to authenti-cate each other through a classical symmetric-key challenge-re-sponse technique [20] based on . Such an approach

would cause non-negligible processing burden and communi-cation overhead on mesh routers, especially when the user baseis growing large. It is also insecure to constantly useor session keys derived from it to secure the communication be-tween and multiple or even all mesh routers of .

Fortunately, possession of PASS enablesto fulfill AKA with by the following efficient protocol:

PASS domain cert

PASS

Similar to (A.1), message (B.1) is a beacon periodically broad-cast by to its coverage area. Upon receipt of it, client

learns from PASS that is possibly anotherrouter of . He corroborates this by carrying out operationsanalogous to what he did in the interdomain AKA protocol.If all the inspections succeed, regards as a legit-imate router of broker , and then derives a shared key

PASS . Then, he com-putes a MIC and sends it together with

PASS and to in message (B.2). Here, is a freshtimestamp and indicates concatenation. Transmission of (B.2)can be realized in a way similar to that of (A.2).

Upon receiving (B.2), first checks that PASS hasnot expired and is fresh enough. If so, it then computes ashared key as PASS .According to (3), only if both and arelegitimate, are and equal to

PASS PASS . Routercan make sure of this by computing a MIC .If the result matches with what sent, it thinks of as alegitimate client who has been authenticated by a peer router.

The intradomain AKA protocol is more efficient than the in-terdomain one in both computation and communication. Thisis desirable because intradomain AKA needs to be done muchmore frequently than interdomain AKA. Note that, if PASShas expired, has to execute the interdomain AKA protocolwith .

C. Client–Client AKA

One significant advantage of WMNs over wireless LANs liesin the multihop communication paradigm extending the net-work coverage. This, however, poses the demand for mutualauthentication among mesh clients present in the same mesh.By client-client authentication, we mean that two mesh clientsascertain that each other is served by the same WMN domain.This is important, for example, because each client should onlyforward packets to the mesh router for those legitimate. Oth-erwise, he might get unpaid for his packet forwarding servicewhich consumes his precious battery power. Two clients mightas well wish to set up a shared key whereby to secure the dataand signaling traffic between them.

The introduction of temporary client credentials greatlyeases client-client AKA. The reason is that possession of anauthentic temporary credential can serve as the proof that theholder has been authenticated by the current WMN domain.


Consider, for example, clients and which are regis-tered with brokers and , respectively. Suppose both havefinished interdomain AKA with the same or different routersof operator . As a result, has PASS and

owns PASS . Once actively exchangingor passively learning (e.g., from routing messages) theT-PASS of each other, they can derive the same shared key

PASS PASS ,similar to what and did in (3). Subsequently, theycan fulfill mutual authentication with many classical sym-metric-key challenge-response authentication techniques [20].For instance, can send to a challenge encryptedwith . If can report a correct response, say

declares the authentication of successful. Inmuch a similar way, can authenticate .

Owning an authentic temporary credential permits a clientto achieve mutual AKA with all the other clients served by thesame WMN domain. Also note that, unlike router-client AKA,client–client AKA can be done on demand, e.g., when twoclients become neighbors, or one is helping the other delivertraffic to the mesh router. In addition, client–client AKA isexpected to occur even more frequently than intradomain AKA.This is mainly due to the dynamic client join to and leave froma mesh, as well as the frequent uplink route changes caused bymobility of mesh clients or many other reasons. In light of this,our ID-based T-PASSes clearly have substantial advantagesover their much longer certificate-based alternatives whosetransmissions may incur a significant communication overhead.

V. SECURITY ENHANCEMENTS

Up to now, we have detailed the router-client and client–clientAKA procedures based on router and client passes. The pro-tocols presented are perfectly secure against both client androuter impersonation attacks. In this section, we describe sev-eral other severe attacks against WMN access and present cor-responding countermeasures. These defense mechanisms alsoserve as answers to security requirements five to seven intro-duced in Section II-A.

A. Location Privacy Attack

Anonymity and location privacy are of growing concern toend users [23]. In particular, mesh clients would usually preferto travel incognito, thereby remaining anonymous to both vis-ited WMN domains and potential eavesdroppers. In our ARSA,if a mesh client uses a fixed C-PASS while roaming, it will bepossible for some attackers or vicious WMN operators to trackhis movements and whereabouts. We refer to such an attack asthe location privacy attack.

Constancy and uniqueness of client identifiers are the rootcause of the location privacy attack. Consider client as anexample. As mentioned in Section III-C, is a standard net-work access identifier (NAI) [12] of format . Todefend against the location privacy attack, we obviously have toensure the confidentiality of client-name that is unique indomain . A straightforward solution would be to use dynami-cally changing aliases in place of the fixed . One may thinkof also hiding the identity of broker , i.e., broker-name ,

as a higher-level anonymity requirement. A serving WMN do-main, however, often needs to know the enrolling broker of aclient. This conflict renders it unlikely to have a lightweight so-lution to ensuring broker anonymity. As far as we know, theonly possible solution appears in [23]. In this approach, thereexists a central clearinghouse or a mix network trusted by allbrokers and WMN operators. Aliases are assigned to brokers sothat a mesh client can reference his enrolling broker by an alias;it is then left up to the central clearinghouse to resolve brokeraliases. Considering the infrastructure complexity related to thisproposal, we currently do not feel it worthwhile to guarantee theanonymity of brokers. What we need is merely an efficient wayto generate unlinkable aliases for mesh clients.

Again, we use as an example to explain our so-lution. We require that broker have a long-enoughkey which it keeps secret. The alias it generatesfor client is of an encrypted form alias

, where rand de-notes a random number. Consequently, PASS takes a newform, alias expiry time,otherTerms . Hereafter,we refer to such a C-PASS as an alias C-PASS and the corre-sponding pass-key as an alias pass-key. Upon registration with

, client is armed with multiple alias (C-PASS, pass-key)pairs, which he uses in a random fashion while roaming acrossWMN domains.

The use of random numbers in encryption results in unlink-able aliases. In particular, aliases for the same client are al-ways different and an alias discloses no information about thetrue identity of the client. In addition, compromise of a client’salias neither compromises aliases of others nor reveals previousaliases of the same client. Therefore, the alias method providesadequate protection against the location privacy attack. It is alsoa stateless solution in that a broker need not book the aliases itgenerated. To make sure of the true identity of a client, it merelyneeds to perform one simple decryption of a presented alias, aswell as a MIC check.

It is a must to periodically issue new alias (C-PASS, pass-key)pairs to client . For this purpose, broker gives a sharedkey to during his registration. Subsequently,it uses the shared key to encrypt new alias (C-PASS, pass-key)pairs for who, in turn, can decrypt them for subsequent use.As for the alias update frequency, there is a tradeoff betweendegree of location privacy protection and alias update overhead.On the one hand, if each alias (C-PASS, pass-key) pair is usedonly once, we can achieve a high level of resilience to the lo-cation privacy attack. This, however, is achieved at the cost ofdemand for very frequent alias updates, which translate to greatcommunication and computation overhead, vice versa. In prac-tice, a good balance should be made between these two com-peting factors.

B. Bogus-Beacon Flooding Attack

Beacons periodically broadcast by a mesh router and pro-cessed by mesh clients place a fundamental role in ensuring theproper operation of a mesh. It is, therefore, important to guar-antee the authenticity of beacons. Otherwise, an attacker maylaunch the bogus-beacon flooding attack by flooding a meshwith a lot of bogus beacons for all kinds of vicious motives. In


previous intradomain and interdomain AKA protocols, a meshrouter digitally sign all the beacons before sending them out toprovide an assurance about their authenticity. Since beacons areusually sent in very short intervals (e.g., every 100 ms as in theIEEE 802.11b), performing continuous signature verificationswill be too great a burden for common mesh clients with limitedcomputational resources. This serves as motivation for a morelightweight yet effective solution.

We deal with this attack by a hierarchical one-way hash-chaintechnique, which is a modified version of the well-known Lam-port’s one-time-password scheme [24]. Consider router asan example. Assume that it broadcasts a beacon every ms. Wealso define a super beacon interval as a time period lastingms, where and are both positive integers. With our tech-nique in place, each beacon (A.1) from will take the fol-lowing new form:

PASS domain cert

Here, indicates the starting time of a super beacon interval;and are both integers such that and

for each , where is pickedby at random; for each and

, where each is randomly chosen by .Due to the one-way feature of the hash function , if ischosen randomly, given it is computationally infeasible tofind , while given , it is computationally efficient toderive . Therefore, we can use the chain of values

as one-time keys. The same argument applies to eachchain , where is used to compute akeyed MIC of beacon of a super beacon interval.By contrast, is used to calculate a keyed MIC of the initialvalue to guarantee its authenticity. To help understanding,Fig. 2 illustrates a 5-by-5 hierarchical hash chain.

Suppose client hears such a beacon. Let us first con-sider the case that has not fulfilled mutual authenticationwith router . first needs to authenticate by per-forming the operations given in Section IV-A. Note that the re-quired timestamp , i.e., the beacon sending time, can be easilydeduced as . If all the checks suc-ceed, then verifies that , wheremeans applying the hash function iteratively to message for

times and . If so, he calculates com-pared with what is in the beacon. If the two values match, heproceeds to check the equality of to . If they areequal, uses to computed a keyed MIC of proper beaconfields and, if the result matches what he received, considers thebeacon authentic. Finally, he stores the superinterval parametertriplet , and sets , and

for later use. Other operations remain the same asthose of the aforementioned interdomain or intradomain AKAprotocol.

Now, we consider the case that and have authenti-cated each other. This means that has known an authenticsuperinterval parameter triplet of . Upon receiving abeacon, first checks that the contained superintervalparameter triplet is different from what it stores, which might

Fig. 2. An exemplary 5-by-5 hierarchical one-way hash chain.

be possible if he loses track of beacons. If so, he does theoperations described above to first verify the superintervalparameters, and then authenticate the beacon. Otherwise, hefirst checks that and , and then that the differencebetween and his local clock timeis within an acceptance window. These checks are necessaryfor withstanding beacon replay attacks. If they are successful,

further distinguishes two cases. If , he merelychecks that and, if so, sets and

. Otherwise, he needs to verify in sequence thatis equal to the MIC in the beacon,

and . If all the checks succeed, he computesa keyed MIC over proper beacon fields using . Only whenthe result matches what is in the beacon, does he consider thebeacon authentic and update , and

.A new super beacon interval begins either when has used

or when it has updated its PASS pair.5 Ineither case, it selects a random and ’s for all ,based on which to compute a new signaturebroadcast in the next beacon.

The hash-chain technique greatly reduces the computationalload of both mesh routers and clients because moderately ex-pensive signature operations are replaced with hash operationswhich are usually several orders of magnitude faster. In partic-ular, just needs to generate a signature at the start of eachsuper beacon interval, rather than each time sending a beacon;each client accordingly merely performs a signature verificationper super beacon interval instead of for each received beacon.The concrete performance gains are closely related to the hash-

5The latter case usually occurs much less frequently than the former.


chain-length parameters , which, in turn, are constrainedby the maximum memory the router allocates for this purpose.Generally speaking, the larger and , the more performancegains we can have, and vice versa. For instance, assume that thebeacon interval is ms, and , meaninga super beacon interval of about 67 min. It takes the router onesignature generation andhash operations in total to generate one-time keys and keyedMICs in beacons. This is in contrast to the 40 000 IBC signaturegenerations if the hash-chain technique is not used. In practice,a mesh router will have enough space to allow for much larger

values, hence meaning potentially more substantial perfor-mance gains.

In addition, the generation of can bedeferred until the values of are almostused up. This may be desirable for lowering the storage com-plexity. For and each ,there is a computation-storage tradeoff with respect to hash-chain traversal. One may envision two extreme approaches forthis problem, i.e., storing either only the hash-chain seed (or ) or the entire chain. The first one has a relatively largeonline computational cost for generating each hash value, asthe same sequence of values is repetitively computed. By con-trast, the second method substantially reduces the computationalcomplexity at the cost of high storage complexity. Researchershave recently investigated ways to optimize this computation-storage tradeoff. Interested readers are referred to [25] and [26]for a thorough treatment of this issue.

C. Denial-of-Access (DoA) Attack

A denial-of-access (DoA) attack is one in which an attackersends a large number of bogus authentication responses like(A.2) or (B.2) to a mesh router. The purpose is to exhaust its re-sources and render it less capable of serving legitimate clients.The router is, however, assumed to at least be able to rejectbogus authentication responses and send out packets.

The client-puzzle approach [27], [28] is a promising counter-measure against the DoA attack. The idea is quite simple. Whenthere is no evidence of attack, a router processes authenticationreplies normally. Under a suspected DoA attack, the router re-quires that a solution to a cryptographic puzzle be attached toeach authentication response. Only when the solution is correctwill the router commit resources to process the response, whichinvolves moderately expensive public-key operations. Typically,solving a client puzzle requires a brute-force search in the so-lution space, while solution verification is trivial. Therefore, anattacker must have access to abundant resources to be able toquickly compute a large enough number of puzzle solutions inline with his sending rate of bogus authentication responses. Bycontrast, although puzzles slightly increase legitimate clients’computational load when the router is under attack, they arestill able to obtain network access as if there were no DoA at-tack. The commonly used puzzles include CPU-bound puzzles[27], [28] and memory-bound puzzles [29]. The former imposea number of computational steps to generate a solution, whilethe latter aim to impose similar puzzle-solving delays on clientswith even different computation power. Due to space limita-tions, we will just demonstrate the use of CPU-bound puzzles

because they are relatively easy to generate and understand. Weleave the exploration of memory-bound puzzles as our futurework.

With the client-puzzle approach and the aforementionedhash-chain technique, the interdomain AKA protocol given inSection IV-A is modified as follows:

PASS domain cert

PASS

PASS PASS

The puzzle we use is similar to that of [28], consisting ofand sent in beacon ( ). is a random nonce cre-ated and changed by periodically. We refer to such a pe-riod as a puzzle interval. is a 1-byte value and called thepuzzle indicator. Only when there is evidence of the DoA at-tack does set the highest bit of to ask for puzzle so-lutions. In that case, the rest of the seven bits of , denotedby , determines the puzzle difficulty.

Upon receipt of the beacon, if the highest bit of iszero, client just performs the operations described before.Otherwise, he has to additionally derive a solution to the pre-sented puzzle. He does so by first generating a random clientnonce , and then performing a brute-force search for astring , such that the bits of the hash result

PASS PASS are zeros. Thepair is a puzzle solution and returned to router

in message ( ). If is a good one-way hash functionsuch as SHA-1 [13], the average number of hash operations forfinding a puzzle solution is . It is also worth notingthat, since router and client passes are used in solving thepuzzle, it is unlikely that the same puzzle solution can be usedfor other routers and clients.

After receiving ( ), router first checks that clienthas not previously submitted a correct puzzle solution with thesame under the same . Message ( ) is simplydumped if containing a replayed puzzle solution. Otherwise,

verifies the puzzle solution by recomputing the hash to seeif the bits of the result are all zeros. Only if the solu-tion is correct, does it continue processing ( ) according tothe previous description.

Now, we discuss the choice of puzzle parameters. To pre-vent an attacker from precomputing puzzle solutions, the routernonce must be random enough to be unpredictable. Webelieve that a 64-bit is long enough for this purpose. Also,the nonce interval should be relatively short, say one minute,to lower the risk that an attacker precomputes solutions for thesame and , but not be too short so as to leave a clientenough time to solve the puzzle. It is possible that a legitimateclient submits a solution for a puzzle interval that just ended. Toallow this, there should be a short overlap between two adjacentpuzzle intervals, during which the router accepts correct puzzlesolutions for both intervals. Router can dynamically ad-just the puzzle difficulty whose reasonable values liebetween 1 and 64. The basic rule of thumb is to set


larger when there is evidence of heavy attack and smaller oth-erwise. Finally, the length of a client nonce like can gener-ally be shorter than that of a router nonce, but should still be longenough, say 24 bits. This is necessary to prevent an attacker fromquickly exhausting all possible client nonces in the same puzzleinterval with the purpose of making a router treat the puzzle so-lutions submitted by legitimate clients as replayed ones.

Likewise, the intradomain AKA protocol given inSection IV-B is modified as follows:

PASS domain cert

PASS

The protocol illustration is omitted here for lack of space.

D. Bandwidth-Exhaustion Attack

In a bandwidth-exhaustion attack, an attacker continuouslysends data packets destined for a mesh router at a high datarate. Without precaution, innocent intermediate clients willwaste significant resources in forwarding the attacker’s packets.The attacker’s traffic may also consume a significant portionof available network bandwidth, as well as interfering withlegitimate clients’ traffic to and from the mesh router.

We use an -hop uplink route, starting from attackerthrough legitimate clients to router , toillustrate our countermeasures. Assume that all the clientsincluding have finished mutual authentication withand owned an authentic temporary credential accordingly. Asa result, pairwise shared keys can be established among allthe clients and router [cf. eq. (3)]. For simplicity, wefurther assume that attacker sends out IP packets of format

, where data may contain the ultimatedestination to which should forward this packet and otherupper-layer information.

An intuitive solution to the above attack is to require toattach to each packet keyed MICs, computed with hispairwise keys shared with intermediate clients and . Morespecifically, each packet sent by takes a new form,6

.Upon receipt of such a packet, each intermediate client for

can verify the MIC beforeforwarding it to the next hop. Finally, router verifies

before processing the packet. This methodcan withstand the bandwidth-exhaustion attack by an attackernot authenticated by the serving WMN domain, as his packetswill not carry correct keyed MICs. In addition, if anauthenticated attacker like follows the process correctly,router can slow down his traffic by economic means.Particularly, regards as a normal client with ahigh bandwidth demand and charges him a large amountcommensurate with his traffic rate. However, the economicmeans fails if always inserts into each packet incorrectkeyed MICs only for the last few hops. In doing so, his packets

6There are ways to shorten the packet, which are ignored for brevity.

will always be dropped by intermediate clients before reaching, thus has no way of charging . However,

can still effectively achieve the vicious goal of consumingnetwork and legitimate clients’ resources.

A complementary way to mitigate the bandwidth-ex-haustion attack is through the aforementioned client-puzzleapproach. It utilizes the fact that each served client ofcan hear the puzzle , and is thus able tovalidate puzzle solutions. In this approach, needs toprovide with a puzzle solutionsatisfying the aforementioned constraint. He also has tooffer a solution for each intermediateclient , which should satisfy that the bits of

PASS PASS are allzeros. Each such solution can be individually validated by theintended client.

If suspecting the presence of the bandwidth-exhaustion at-tack, router sets the highest bit of to instruct allclients within coverage to perform validations of puzzle solu-tions. If this occurs, each packet source like needs to sendpuzzle solutions along with data packets at a rate in line with histraffic rate. We use the well-known token-bucket approach to re-alize this objective. In particular, each intermediate clientmaintains a token bucket for , essentially an integer counterof sufficient length, say 4 bytes. He adds tokens to the bucketeach time provides a correct puzzle solution. Each tokencorresponds to a traffic unit, say 1 KB, and only when there areenough tokens in the bucket, will forward ’s packetsto the next hop after doing a MIC check. The rate-control pa-rameter can be dynamically adjusted to cope with the currentnetwork traffic load. Specifically, it should be set smaller whenthe traffic load is heavy and larger otherwise. can eithercentrally decide conveyed to mesh clients in beacons, or leteach client determine by himself.

VI. DISCUSSION

In this section, we discuss other issues relevant to ARSA.

A. Incontestable Billing

Billing of mobile users is conventionally realized in a waythat the foreign domain reports the amount of service accessedby the user to his home domain which, in turn, bills the userand pays the foreign domain. This approach does not ensurebilling incontestability, as the foreign domain may overstatethe amount of service the user actually used, while the usermay deny the service he requested. Under our ARSA, it ispromising to achieve incontestable billing of mesh clientsvia an intriguing lightweight micropayment approach [30].Consider router and client as an example. To pay

in return for network access, creates a chain ofhash tokens, , where is chosen at randomand for all . Each hash tokenis associated with a monetary value . Initially, sends asigned payment commitment to which, inturn, verifies and saves the commitment. At each subsequentpredetermined interval, releases a hash token in sequence.

can authenticate the token by checking that it can hash toafter a few hash operations. When the session terminates,


keeps the triplet as a billingrecord, where indicates the highest token index from .Later, operator sends the billing record to ’s enrollingbroker which, after verifying and token

, pays monetary units and charges the sameamount. In this approach, operator cannot overcharge client

because it is unable to fake correct tokens hashing tocannot deny the bill since he has signed the payment

commitment and no one else can provide correct hash tokens.A thorough investigation on this issue can be found in [18].

B. Stimulating Packet Forwarding

Generally speaking, mutually strange mesh clients are un-willing to forward others’ traffic to and from the mesh router tosave their own resources. We thus must research how to motivatecooperation in packet forwarding to enable the highly beneficialmultihop communication paradigm. This issue has been studiedextensively in mobile ad hoc networks (MANETs), see, for ex-ample [31]. The existing solutions are not directly applicable toWMNs and our ARSA. We believe that it is rather feasible toreward packet forwarding also by the micropayment approach.The idea is quite simple. Each client pays the router what therouter and all intermediate clients should get. The router, in turn,rewards mesh clients for forwarding all others’ traffic by gener-ating a unique chain of hash tokens for each of them. This ap-proach is lightweight from mesh clients’ viewpoint, as they justneed to have a payment relationship with the router instead ofeach of others. Please refer to [18] for a full exploration of thisissue.

C. Incremental Deployment

One of the main barriers to wide deployment and use ofWMNs is the lack of a sound business model. Our ARSAaffirmatively answers this problem and is highly advantageousfor WMN operators, mesh clients, and brokers. As the develop-ment of the credit card system, we expect ARSA to be deployedincrementally along with WMNs. Initially, there might beonly one broker, which might be an enterprising regular bankor emerging electronic money transmitter like PayPal, a fewWMN operators, and a limited number of mesh clients. As timegoes on, the shown benefits of ARSA would attract more andmore operators to built WMNs and users to use WMN services,and increasing brokers (though still limited in number) to actas trust intermediaries.

VII. CONCLUSION

For the first time in the literature, this paper identifies and sat-isfies a number of unique security requirements of the emergingmultihop WMNs. We present an attack-resilient security archi-tecture, called ARSA, for large-scale WMNs. In contrast to aconventional cellular-like solution, ARSA is more practical andlightweight because it does not require a WMN operator to es-tablish pairwise bilateral SLAs and interact in real-time with po-tentially numerous other WMN operators. ARSA is also a home-less solution in which each user, instead of being bound to anyspecific WMN operator, can get ubiquitous network access bya universal pass issued by a third-party broker. ARSA providesefficient mutual AKA not only between a user and a serving

WMN domain but also between users served by the same WMNdomain. In addition, it is designed to be resistant to various at-tacks against WMN access.

REFERENCES

[1] The WiMAX Forum. [Online]. Available: http://www.wimax-forum.org

[2] I. Akyildiz, X. Wang, and W. Wang, “Wireless mesh networks: Asurvey,” Comput. Netw., vol. 47, no. 4, pp. 445–487, Mar. 2005.

[3] European Telecommunications Standards Institute (ETSI), “GSM2.09: Security Aspects.” Jun. 1993.

[4] H. Lin and L. Harn, “Authentication protocols for personal communi-cation systems,” in Proc. ACM SIGCOMM, Cambridge, MA, Aug./Sep.1995, pp. 256–261.

[5] 3GPP, TS 21.102, 3rd Generation Partnership Project (3GPP); Tech-nical Specification Group (TSG) SA; 3G Security; Security Architec-ture, version 4.2.0, Release 4, 2001.

[6] Y. Lin and Y. Chen, “Reducing authentication signalling traffic inthird-generation mobile network,” IEEE Trans. Wireless Commun.,vol. 2, no. 3, pp. 493–501, May 2003.

[7] C. Perkins, “IP mobility support for iPv4,” IETF, RFC 3344, Aug. 2002.[8] A. Shamir, “Identity based cryptosystems and signature schemes,”

in Lecture Notes in Computer Science. Berlin, Germany:Springer-Verlag, 1984, vol. 196, Proc. CRYPTO, pp. 47–53.

[9] D. Boneh and M. Franklin, “Identify-based encryption from the Weilpairing,” in Lecture Notes in Computer Science. Berlin, Germany:Springer-Verlag, 2001, vol. 2139, Proc. CRYPTO, pp. 213–229.

[10] P. Barreto, H. Kim, B. Bynn, and M. Scott, “Efficient algorithmsfor pairing-based cryptosystems,” in Lecture Notes in ComputerScience. Berlin, Germany: Springer-Verlag, 2002, vol. 2442, Proc.CRYPTO, pp. 354–368.

[11] M. Jakobsson, J.-P. Hubaux, and L. Buttyan, “A micro-paymentscheme encouraging collaboration in multi-hop cellular networks,” inProc. 7th Int. Conf. Financial Cryptography, Gosier, Guadeloupe, Jan.2003, pp. 15–33.

[12] B. Aboda and M. Beadles, “The network access identifier,” IETF, RFC2486, Jan. 1999.

[13] Digital Hash Standard, Federal Information Processing Standards Pub-lication 180-1, NIST, Apr. 1995.

[14] R. Dutta, R. Barua, and P. Sarkar, “Pairing-based cryptography: Asurvey,” Cryptology ePrint Archive Rep. 2004/064, 2004.

[15] Authentication Framework, ITU-T Recommendations X.509, ITU,Geneva, 1989.

[16] D. Harkins and D. Carrel, “The Internet key exchange (IKE),” IETF,RFC 2409, Nov. 2003.

[17] D. Boneh, B. Lynn, and H. Shacham, “Short signature from the Weilpairing,” in Proc. ASIACRYPT, Gold Coast, Australia, Dec. 2001, pp.514–532.

[18] Y. Zhang and Y. Fang, “A secure authentication and billing architec-ture for wireless mesh networks,” Wireless Netw. [Online]. Available:http://winet.ece.ufl.edu/~zhang/mesh-WINET.pdf, to be published

[19] D. Smetters and G. Durfee, “Domain-based administration of identity-based cryptosystems for secure email and ipsec,” in Proc. 12th USENIXSecurity Symp., Washington, DC, Aug. 2003, pp. 215–229.

[20] A. Menezes, P. van Oorschot, and S. Vanston, Handbook of AppliedCryptography. Boca Raton, FL: CRC Press, 1996.

[21] P. Gupta and P. Kumar, “The capacity of wireless networks,” IEEETrans. Inf. Theory, vol. 46, no. 2, pp. 388–404, Mar. 2000.

[22] R. Sakai, K. Ohgishi, and M. Kasahara, “Cryptosystems based onpairing,” in Proc. Symp. Cryptography Inf. Security, Okinawa, Japan,Jan. 2000, pp. 26–28.

[23] G. Ateniese, A. Herzberg, H. Krawczyk, and G. Tsudik, “Untraceablemobility or how to travel incognito,” Comput. Netw., vol. 31, no. 8, pp.871–884, Apr. 1999.

[24] L. Lamport, “Password authentication with insecure communication,”Commun. ACM, vol. 24, no. 11, pp. 770–772, Nov. 1981.

[25] D. Coppersmith and M. Jakobsson, “Almost optimal hash sequencetraversal,” in Proc. Financial Cryptography, Southampton, Bermuda,Mar. 2002, pp. 102–119.

[26] Y. Sella, “On the computation-storage trade-offs of hash chain tra-versal,” in Proc. Financial Cryptography, Guadeloupe, French WestIndies, Jan. 2003, pp. 270–285.


[27] A. Juels and J. Brainard, “Client puzzles: A cryptographic countermea-sure against connection depletion attacks,” in Proc. 6th Annu. Netw.Distrib. Syst. Security Symp., San Diego, CA, Feb. 1999, pp. 151–165.

[28] T. Aura, P. Nikander, and J. Leiwo, “DoS-resistant authentication withclient puzzles,” in Proc. 8th Int. Workshop Security Protocols, Cam-bridge, U.K., Apr. 2000, pp. 178–181.

[29] M. Abadi, M. Burrows, M. Manasse, and T. Wobber, “Moderately hard,memory-bound functions,” in Proc. 10th Annu. Netw. Distrib. Syst. Se-curity Symp., San Diego, CA, Feb. 2003, pp. 25–39.

[30] R. Rivest and A. Shamir, “Payword and micromint: Two simple mi-cropayment schemes,” in Lecture Notes in Computer Science. Berlin,Germany: Springer-Verlag, vol. 1189, Proc. Int. Workshop SecurityProtocols, pp. 69–87.

[31] Y. Zhang, W. Lou, and Y. Fang, “A secure incentive protocol for mo-bile ad hoc networks,” Wireless Netw. [Online]. Available: http://winet.ece.ufl.edu/~zhang/sip-WINET.pdf, to be published

Yanchao Zhang (S’03–M’06) received the B.E.degree in computer communications from NanjingUniversity of Posts and Telecommunications,Nanjing, China, in July 1999, the M.E. degree incomputer applications from Beijing University ofPosts and Telecommunications, Beijing, China,in April 2002, and the Ph.D. degree in electricaland computer engineering from the University ofFlorida, Gainesville, in August 2006.

Since September 2006, he has been an AssistantProfession in the Department of Electrical and Com-

puter Engineering, New Jersey Institute of Technology, Newark. His researchinterest include wireless and Internet security, wireless networking, and mobilecomputing.

Yuguang Fang (S’92–M’93–SM’99) received theB.S. and M.S. degrees in mathematics from QufuNormal University, Qufu, Shandong, China, in 1984and 1987, respectively, the Ph.D. degree in systemsand control engineering from the Department ofSystems, Control and Industrial Engineering, CaseWestern Reserve University, Cleveland, OH, inJanuary 1994, and the Ph.D. degree in electricalengineering from the Department of Electrical andComputer Engineering, Boston University, Boston,MA, in May 1997.

From 1987 to 1988, he held research and teaching positions in both the De-partment of Mathematics and the Institute of Automation, Qufu Normal Univer-sity. From September 1989 to December 1993, he was a Teaching/Research As-sistant in the Department of Systems, Control and Industrial Engineering, wherehe held a Research Associate position from January 1994 to May 1994. Heheld a Postdoctoral position in the Department of Electrical and Computer En-gineering, Boston University from June 1994 to August 1995. From September1995 to May 1997, he was a Research Assistant in the Department of Elec-trical and Computer Engineering, Boston University. From June 1997 to July1998, he was a Visiting Assistant Professor in the Department of ElectricalEngineering, University of Texas at Dallas. From July 1998 to May 2000, hewas an Assistant Professor in the Department of Electrical and Computer Engi-neering, New Jersey Institute of Technology, Newark. In May 2000, he joinedthe Department of Electrical and Computer Engineering, University of Florida,Gainesville, where he received early promotion to Associate Professor withtenure in August 2003, and to Full Professor in August 2005. He has publishedover 150 papers in refereed professional journals and conferences. His researchinterests span many areas including wireless networks, mobile computing, mo-bile communications, wireless security, automatic control, and neural networks.

Dr. Fang received the National Science Foundation Faculty Early CareerAward in 2001 and the Office of Naval Research Young Investigator Awardin 2002. He also received the 2001 CAST Academic Award. He is listed inMarquis Who’s Who in Science and Engineering, Who’s Who in America,and Who’s Who in World. He has been actively engaged in many professionalactivities. He is a member of the Association for Computing Machinery (ACM).He is an Editor for the IEEE TRANSACTIONS ON COMMUNICATIONS, an Editorfor the IEEE TRANSACTIONS ON WIRELESS COMMUNICATIONS, an Editor forthe IEEE TRANSACTIONS ON MOBILE COMPUTING, an Editor for ACM WirelessNetworks, and an Editor for the IEEE WIRELESS COMMUNICATIONS. He wasan Editor for the IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS

(Wireless Communications Series), an Area Editor for the ACM MobileComputing and Communications Review, an Editor for the Wiley InternationalJournal on Wireless Communications and Mobile Computing, and Feature Ed-itor for Scanning the Literature in the IEEE Personal Communications. He hasalso been actively involved with many professional conferences such as ACMMobiCom’02 (Committee Co-Chair for Student Travel Award), MobiCom’0l,IEEE INFOCOM’06, INFOCOM’05 (Vice-Chair for Technical ProgramCommittee), INFOCOM’04, INFOCOM’03, INFOCOM’00, INFOCOM’98,IEEE WCNC’04, WCNC’02, WCNC’00 (Technical Program Vice-Chair),WCNC’99, IEEE Globecom’04 (Symposium Co-Chair), Globecom’02, andthe International Conference on Computer Communications and Networking(IC3N) (Technical Program Vice-Chair).

1916 ieee journal on selected areas in …

Documents