1

SAT: A Security Architecture AchievingAnonymity and Traceability in Wireless Mesh

NetworksJinyuan Sun∗, Chi Zhang∗, Yanchao Zhang†, and Yuguang Fang∗

∗Department of Electrical and Computer EngineeringUniversity of Florida, Gainesville, FL 32611

Email: {stellas@, zhangchi@, fang@ece.}ufl.edu†Department of Electrical and Computer Engineering

New Jersey Institute of Technology, Newark, NJ 07102Email: {yczhang@njit.edu}

F

Abstract—Anonymity has received increasing attention in the literaturedue to the users’ awareness of their privacy nowadays. Anonymityprovides protection for users to enjoy network services without beingtraced. While anonymity related issues have been extensively studied inpayment-based systems such as e-cash [1] and peer-to-peer (P2P) [2]systems, little effort has been devoted to wireless mesh networks(WMNs). On the other hand, the network authority requires conditionalanonymity such that misbehaving entities in the network remain trace-able. In this paper, we propose a security architecture to ensure uncondi-tional anonymity for honest users and traceability of misbehaving usersfor network authorities in WMNs. The proposed architecture strives toresolve the conflicts between the anonymity and traceability objectives,in addition to guaranteeing fundamental security requirements includingauthentication, confidentiality, data integrity, and non-repudiation [3].Further security enhancements can be incorporated, rendering theproposed architecture conditionally anonymous in terms of networkaccess activities, location information, and communication paths.

Index Terms—Anonymity, Traceability, Pseudonym, Misbehavior, Revo-cation, Wireless Mesh Network (WMN).

1 INTRODUCTION

Wireless Mesh Network (WMN) is a promising technol-ogy and is expected to be widespread due to its low-investment feature and the wireless broadband servicesit supports, attractive to both service providers andusers. However, security issues inherent in WMNs orany wireless networks need be considered before thedeployment and proliferation of these networks, since itis unappealing to subscribers to obtain services withoutsecurity and privacy guarantees. Wireless security hasbeen the hot topic in the literature for various networktechnologies such as cellular networks [4], wireless localarea networks (WLAN) [5], wireless sensor networks [6],[7], mobile ad hoc networks (MANETs) [8], [9], andvehicular ad hoc networks (VANETs) [10]. Recently, newproposals on WMN security [11], [12] have emerged.In [11], the authors describe the specifics of WMNs and

identify three fundamental network operations that needto be secured. We [12] propose an attack-resilient securityarchitecture (ARSA) for WMNs, addressing countermea-sures to a wide range of attacks in WMNs. Due tothe fact that security in WMNs is still in its infancyas very little attention has been devoted so far [11], amajority of security issues have not been addressed andare surveyed in [13].

Anonymity and privacy issues have gained consider-able research effort in the literature [1], [2], [10], [12] [14]-[22], which have focused on investigating anonymityin different context or application scenarios. One re-quirement for anonymity is to unlink a user’s identityto his or her specific activities, such as the anonymityfulfilled in the untraceable e-cash systems [1], [14] andthe P2P payment systems [2], [15], where the paymentscannot be linked to the identity of a payer by thebank or broker. Anonymity is also required to hide thelocation information of a user to prevent movementtracing, as is important in mobile networks [16]- [18]and VANETs [10]. In wireless communication systems,it is easier for a global observer to mount traffic analysisattack by following the packet forwarding path than inwired networks. Thus, routing anonymity [19]- [22] isindispensable which conceals the confidential communi-cation relationship of two parties by building an anony-mous path between them. Nevertheless, unconditionalanonymity may incur insider attacks since misbehavingusers are no longer traceable. Therefore, traceability ishighly desirable such as in e-cash systems [1], [14] whereit is used for detecting and tracing double-spenders.

We have proposed the initial design of our security ar-chitecture in [23], where the feasibility and applicabilityof the architecture were not fully understood. As a result,we provide detailed efficiency analysis in terms of stor-age, communication and computation in this paper, to

2

show that our SAT is a practically viable solution to theapplication scenario of interest. We are motivated by re-solving the above security conflicts, namely, anonymityand traceability, in the emerging WMN communicationsystems. Our system borrows the blind signature tech-nique from payment systems [1], [2], [15], [24] and hencecan achieve the anonymity of unlinking user identitiesfrom activities, as well as the traceability of misbehavingusers. Furthermore, the proposed pseudonym techniquerenders user location information unexposed. Our workdiffers from previous work in that, WMNs have uniquehierarchical topologies and rely heavily on wireless links,which have to be considered in the anonymity design. Asa result, the original anonymity scheme for payment sys-tems among bank, customer, and store cannot be directlyapplied. In addition to the anonymity scheme, othersecurity issues such as authentication, key establishment,and revocation are also critical in WMNs to ensure thecorrect application of the anonymity scheme. Moreover,although we employ the widely used pseudonym ap-proach to ensure network access anonymity and locationprivacy, our pseudonym generation does not rely on acentral authority, e.g., the broker in [12], the domainauthority in [16], the transportation authority or themanufacturer in [10], the trusted authority in [19], etc.,who can derive the user’s identity from his pseudonymsand illegally trace an honest user. Note that our systemis not intended for achieving routing anonymity, whichcan be incorporated as an enhancement.

Specifically, our major contributions in this paper in-clude: 1) design of a ticket-based anonymity systemwith traceability property; 2) bind of the ticket andpseudonym which guarantees anonymous access control(i.e., anonymously authenticating a user at the accesspoint) and simplified revocation process; 3) adoption ofthe hierarchical identity-based cryptography (HIBC) forinter-domain authentication avoiding domain parametercertification.

The rest of this paper is organized as follows. Sec-tion 2 introduces some preliminaries. The system modelincluding network architecture and trust model is de-scribed in Section 3. Section 4 elaborates on the ticket-based anonymity scheme which is the key componentof our security architecture. Security analysis, efficiencyanalysis and possible enhancements pertinent to theproposed architecture are presented in Sections 5, 6 and7, respectively. Section 8 concludes the paper.

2 PRELIMINARIES

2.1 IBC from Bilinear PairingsID-based cryptography (IBC) allows the public key of anentity to be derived from its public identity informationsuch as name, email address, etc., which avoids the useof certificates for public key verification in the conven-tional PKI (public key infrastructure) [25]. Boneh andFranklin [26] introduced the first functional and efficientID-based encryption scheme based on bilinear pairings

on elliptic curves. Specifically, let G1 and G2 be anadditive group and a multiplicative group, respectively,of the same prime order p. Discrete logarithm problem(DLP) is assumed to be hard in both G1 and G2. Let Pdenote a random generator of G1 and e : G1 ×G1 → G2

denote a bilinear map constructed by modified Weil orTate pairing with the following properties:

1) Bilinear: e(aP, bQ) = e(P, Q)ab, ∀P,Q ∈ G1 and∀a, b ∈ Z∗p , where Z∗p denotes the multiplicativegroup of Zp, the integers modulo p. In particular,Z∗p = {x | 1 ≤ x ≤ p− 1} since p is prime.

2) Non-degenerate: ∃P, Q ∈ G1 such that e(P, Q) 6= 1.3) Computable: there exists an efficient algorithm to

compute e(P, Q), ∀P,Q ∈ G1.

2.2 Blind SignatureBlind signature is first introduced by Chaum [24]. Ingeneral, a blind signature scheme allows a receiver toobtain a signature on a message such that both themessage and the resulting signature remain unknownto the signer. We refer the readers to [27] for a formaldefinition of a blind signature scheme, which shouldbear the properties of verifiability, unlinkability, andunforgeability according to [24].

Brands [28] developed the first restrictive blind sig-nature scheme, where the restrictiveness property isincorporated into the blind signature scheme such thatthe message being signed must contain encoded infor-mation. As the name suggests, this property restrictsthe user in the blind signature scheme to embed someaccount related secret information into what is beingsigned by the bank (otherwise the signing will be un-successful), such that this secret can be recovered bythe bank to identify a user if and only if he double-spends. The restrictiveness property is essentially theguarantee for traceability in the restrictive blind signa-ture systems. Partial blind signature schemes [29], [30]allow the resulting signature to convey publicly visibleinformation on common agreements between the signerand the signee. This is useful when certain informationin the signature needs to be reviewed by a third party.One example is the common agreements, the visibility ofwhich enables the intermediate parties who examine thesignature, to first check the compliance of the signee tothe items specified in the agreements, before proceedingto the verification of the signature and other operations.Restrictive partially blind signature schemes [31]–[33]were derived from the aforementioned work. They areessentially blind signature schemes with restrictivenessand partial blindness properties. In the restrictive par-tially blind signature schemes [32], [33] that serve as abuilding block for our architecture, the two key concepts,namely, restrictiveness and partial blindness, are definedbased on [1], [29]:

Restrictiveness: Let a message m be such that thereceiver knows a representation (a1, · · · , ak) of m withrespect to a generator tuple (g1, · · · , gk) at the begin-ning of a blind signature protocol. Let (b1, · · · , bk) be

3

the representation the receiver knows of the blindedmessage m′ of m after the completion of the proto-col. If there exists two functions I1 and I2 such thatI1(a1, · · · , ak) = I2(b1, · · · , bk), regardless of m and theblinding transformations applied by the receiver, thenthe protocol is called a restrictive blind signature proto-col. The functions I1 and I2 are called blinding-invariantfunctions of the protocol with respect to (g1, · · · , gk).

Partial Blindness: A signature scheme is partially blindif, for all probabilistic polynomial-time algorithm A, Awins the game in the signature issuing protocol withprobability at most 1

2 + 1kε for sufficiently large k and

some constant ε. The probability is taken over coin flipsof KG, U0, U1, and A, where KG is the key generationfunction defined in [33], U0 and U1 are two honest usersfollowing the signature issuing protocol. Due to thespace limitation, refer to [33] for complete descriptionof the game in the signature issuing protocol.

3 SYSTEM MODEL

3.1 Notation and Definitions

First, we give a list of notation and definitions that arefrequently used in this paper.

3.1.1 Notation

• →, →→, and ‖: denote single-hop communications,multi-hop communications, and concatenation, re-spectively.

• CL, MR, GW, and TA: abbreviations for client, meshrouter, gateway, and trusted authority, respectively.

• IDx: the real identity of an entity x in our WMNsystem.

• PSx: the pseudonym self-generated by a client x byusing his real identity IDx.

• H1(M) and H ′1(M): {0, 1}∗ → G1, cryptographic

hash functions mapping an arbitrary string M toG1.

• H2: a cryptographic secure hash function: G31×G5

2 →Z∗p .

• H3: a cryptographic secure hash function: G2×G2×IDGW × date/time → Z∗p .

• H1(IDx)/Γx and H1(IDTx)/ψx: the public/privatekey pairs assigned to an entity x in the standard IBCand HIBC, respectively.

• PSx/Γx and PSTx/ψx: the self-generatedpseudonym/ private key pairs based on theabove public/private key pairs.

• SIGΓx(m): the ID-based signature on a message musing the signer x’s private key Γx.

• VER(SIG): the verification process of the abovesignature which returns “accept” or “reject”.

• HIDSψx,sx(m): the hierarchical ID-based signatureon a message m generated by the signer x usingits secret point ψx and secret number sx for inter-domain authentication.

• HVER(HIDS, QT ): the verification process usingthe above HIDS and QT which returns “accept”or “reject”.

• SKEκ(D): the symmetric key encryption on plain-text D using the shared secret key κ.

• HMACκ(m): the keyed-hash message authentica-tion code on a message m using cryptographic hashfunctions and the symmetric key κ.

3.1.2 Definitions• Anonymity (Untraceability): The anonymity of a legit-

imate client refers to the untraceability of the client’snetwork access activities. The client is said to beanonymous if the TA or the gateway, or even thecollusion of the two cannot link the client’s networkaccess activities to his real identity.

• Traceability: A legitimate client is said to be traceableif the TA is able to link the client’s network accessactivities to the client’s real identity if and only if theclient misbehaves, i.e., one or both of the followingoccurs: ticket-reuse and multiple-deposit.

• Ticket-reuse: one type of misbehavior of a legitimateclient that refers to the client’s use of a depletedticket (val=0).

• Multiple-deposit: one type of misbehavior of a legiti-mate client that refers to the client’s disclosure of hisvalid ticket and associated secrets to unauthorizedentities or clients with misbehavior history, so thatthese coalescing clients can gain network accessfrom different gateways simultaneously.

• Collusion: the colluding of malicious TA and gate-way to trace a legitimate client’s network accessactivities in the TA’s domain (i.e., to compromisethe client’s anonymity).

• Framing: a type of attack mounted by a maliciousTA in order to revoke a legitimate client’s networkaccess privilege. In this attack, the TA can generatea false account number and associate it with theclient’s identity. The TA can then create valid ticketsbased on the false account number and commitfraud (i.e., misbehave). By doing so, the TA is ableto falsely accuse the client to have misbehaved andto revoke his access right.

3.2 Network ArchitectureConsider the network topology of a typical WMN de-picted in Fig. 1. The wireless mesh backbone consists ofmesh routers and gateways interconnected by ordinarywireless links (shown as dotted curves). Mesh routersand gateways serve as the access points of the WMNand the last resorts to the Internet, respectively. Thehospital, campus, enterprise and residential buildingsare instances of individual WMN domains subscribingto the Internet services from upstream service providers,shown as the Internet cloud in Fig. 1. Each WMNdomain, or trust domain (to be used interchangeably)is managed by a domain administrator that serves as

4

Internet

TA1

TA2

GW3

GW2

GW1

GW1

GW2

MR MR

MR

MR

MR

MR

MR

MR

MR

MR

MR

MR

MR

CL

Fig. 1. Network Topology of A Typical WMN.

a trusted authority (TA), e.g., the central server of acampus WMN. The TA and associated gateways areconnected by high speed wired or wireless links, dis-played as solid and bold dashed lines, respectively. TAsand gateways are assumed to be capable of handlingcomputationally intensive tasks. In addition, they areassumed to be protected in private places and cannot beeasily compromised due to their important roles in theWMN. The WMNs of interest here are those where theTA provides free Internet access but requires the clientsto be authorized and affiliated members generally for along term, as the employees or students in the case ofenterprise and hospital WMNs or campus WMNs. Suchindividual WMN domains can be building blocks of aneven larger metropolitan WMN domain.

3.3 Trust Model

3.3.1 Trust Relationship

In general, the TA is trusted within the WMN domain.There is no direct trust relationship between the clientand the gateway/mesh router. We will use standardIBC for authentication and secure communications bothat the backbone and during network access inside atrust domain (i.e., intra-domain). We further assume theexistence of pre-shared keys and secure communicationchannels between entities (TAs, gateways, mesh routers)at the backbone and will solely consider the authentica-tion and key establishment during the network access ofthe clients.

The client presents his ID upon registration at theTA, which assigns a private key associated with theclient’s ID. The client selects a unique account number Acomputed by a randomly chosen secret number u1 (cf.Section 4.1.1). The account number is stored with theclient’s ID at the TA. The TA also assigns an ID/privatekey pair to each gateway and mesh router in its trustdomain before deployment. Advantages of this generaltrust relationship with the TA stem from the directauthentication of the clients traveling amongst gate-ways/mesh routers in the same domain, which reduces

network access latency and communication overhead,which is expected to be overwhelming in future WMNsdue to the large user population and high mobility.

In accordance with the natural hierarchical architec-ture of the WMNs considered in this paper, we adoptthe hierarchical ID-based signature scheme (HIDS) forinter-domain authentication that occurs when a clientaffiliated with the home TA visits neighboring foreignTAs. Note that the basic HIDS [34] is suitable when thelevel m of the signer in the hierarchical tree (HT) isclose to the root at level 0, since the number of pairingoperations and the size of the signature are determinedby the signer’s absolute location m. If m is relatively high(i.e., the signer is located deep down the HT), the basicHIDS can be very inefficient in terms of computationand communication. In this case, Dual-HIDS [34] ismore suitable if the signer and verifier share a commonancestor at level l below the root, since the numberof pairing operations and the size of the signature aredetermined by the signer’s relative location m− l, to thecommon ancestor. For instance, the two TAs in Fig. 1 canbe the domain administrators of neighboring campusesor hospitals directly managed by the state departmentof education (SDE), or the state department of health(SDH), etc. For the ease of demonstration, we use thebasic HIDS for inter-domain authentication in this paper.Let the SDE (or SDH) be the root at level 0 in the HT ofthe campus (or hospital) WMN. All the TAs in the SDE’sdomain are at level 1 and all gateways, mesh routersand clients in each TA’s domain are at level 2. Note thatin reality, the campus (or hospital) WMN may be partof the HT of a larger WMN (i.e., the SDE or SDH is achild at level n below the root). However, as long as thesigner’s relative location to the common ancestor of thesigner/verifier pair in the HT remains unchanged, theDual-HIDS scheme can be employed instead.

In the WMN architecture in [12], we handled a sim-ilar inter-domain authentication issue with a differentapproach. When a client roams to a foreign TA’s domain(FTD) with a different master secret, we propose to getthe foreign TA’s domain parameters certified by a trustedthird party (TTP). The domain parameter certificate(DPC) issued by the TTP is then included in the inter-domain authentication for verifying the authenticity ofthe domain parameters, which will later be utilized toverify the signature from the entities in FTD. Comparedto that approach, the adopted HIDS scheme eliminatesthe requirement for the TTP and the DPCs. Furthermore,since we are concerned with the computation power ofthe clients, using the level assignment (levels 0-2) men-tioned in the example above, the client need compute4 pairings for verifying the signature from the accesspoint (mesh router or gateway). In [12], the client needalso compute 4 pairings, 2 for DPC validation and 2for verifying the signature from the access point if theefficient Hess’s ID-based signature [35] is used. Thus, theadopted HIDS scheme does not compromise the compu-tation efficiency while avoiding the TTP and DPCs. We

5

argue that the computational complexity of HIDS for theWMN architecture considered here is acceptable sincethe client is most frequently roaming within the homedomain where the standard IBC is used.

3.3.2 Trust Domain Initialization

We apply the domain initialization of the hierarchicalIBC [34]. Specifically, the root PKG (public key generator)at level 0 in the HT performs the following domain ini-tialization algorithm when the network is bootstrapped,where P0 is a generator of G1.

1) Input security parameter ξ ∈ Z+ into domainparameter generator PG and output the parametertuple (p, G1, G2, e, P0,H1).

2) Randomly select a domain master secret s0 ∈ Z∗pand calculate the domain public key Ppub = s0P0.

The root PKG (e.g., the SDE or SDH) publishes thedomain parameters (p,G1, G2, e, P0,H1, Ppub) and main-tains s0 confidential. Suppose a child CHj is located atlevel j. The lower-level setup is performed by the parentas follows.

1) Compute Kj = H1(ID1, ..., IDj);2) Compute CHj ’s private keys ψj = ψj−1+sj−1Kj =∑j

i=1 si−1Ki, Γj = πH1(IDj);3) Distribute QT = {Ql : 1 ≤ l < j} to CHj , where

Ql = slP0.

In the above private key assignment, (ID1, ..., IDi) for1 ≤ i ≤ j is the ID tuple of CHj ’s ancestor at level i.The private keys ψj and Γj are generated for the inter-domain and intra-domain authentication, respectively,where sj−1 is the parent’s secret and π is the mastersecret of the trust domain manager (i.e., TA in thispaper). In Fig. 1, TA1 is the parent of all the entitiesin its domain which is located at level 1. The entities(gateways, mesh routers, clients) are TA1’s children atlevel 2. Similarly, the SDE or SDH (root PKG in oursimple illustration) at level 0 is the parent of TA1. Notethat due to the hardness of DLP, it is not possible to solvefor sj−1 or π given any private key calculated from themwith non-negligible probability.

4 SAT SECURITY ARCHITECTURE

4.1 Ticket-Based Security Architecture

First, we restrict our discussion to within the homedomain. The inter-domain protocols in our security ar-chitecture, which are executed when the client roamsoutside his home domain, will be presented in Section4.1.5. The ticket-based security architecture consists ofticket issuance, ticket deposit, fraud detection, and ticketrevocation protocols. In what follows, we will describethese protocols in detail, together with the fulfillment ofauthentication, data integrity, and confidential commu-nications that may take place during the execution ofthese protocols.

4.1.1 Ticket Issuance

In order to maintain fairness among clients and securityof the network against attacks, the home TA may controlthe access of each client by issuing tickets based onthe misbehavior history of the client which reflects theTA’s confidence about the client to act properly. Ticketissuance occurs when the client initially attempts toaccess the network or when all previously issued ticketsare depleted. The client need reveal his real ID to theTA in order to obtain a ticket since the TA has to ensurethe authenticity of this client. Moreover, the TA shouldbe unable to link the ticket it issued to the clients’real identities. The client thus employs some blindingtechnique to transform the ticket to be unlinkable to aspecific execution of the ticket generation algorithm (thecore of ticket issuance protocol), while maintaining theverifiability of the ticket. The ticket generation algorithm,which can be any restrictive partially blind signaturescheme in the literature, takes as input the client’s andTA’s secret numbers, the common agreement c, andsome public parameters, and generates a valid ticketticket = {TN ,W, c, (U ′, V ′, X ′, ρ, σ′1, σ

′2)} at the output,

where TN is the unique serial number of the ticketwhich can be represented by the client’s account numberA, (U ′, V ′, X ′, ρ, σ′1, σ

′2) is the signature on (TN ,W, c)

where W is necessary for verifying the validity of thesignature in the ticket deposit protocol. We opt for apartially restrictive blind signature scheme with twodesired features: partial blindness and restrictiveness(cf. Section 2.2), for the proposed WMN framework.Partially blind signatures alone allow the blind signa-ture to carry explicit information on commonly agreedterms (i.e., ticket value, expiry date, misbehavior, etc.)which remains publicly visible regardless of the blindingprocess. Restrictive blind signatures place restrictions onthe client’s selection of messages being signed whichcontain encoded identity information (in TN ) instead ofcompletely random numbers, allowing the TA to recoverthe client’s identity by computing A if and only if misbe-havior is detected. As a result, the anonymity of an honestclient is unconditionally ensured. Restrictive partiallyblind signature schemes [32], [33] can be adopted as thebuilding block of the ticket generation algorithm in ourticket issuance protocol.

The TA publishes the domain parametersto be used within its trust domain as(p,G1, G2, e, P, P1, P2,H1,H2,H3, Ppub) using thestandard IBC domain initialization, where (P, P1, P2)are random generators of G1, and Ppub = πP . Sincethe scheme of [33] is selected for demonstration,G1 here should be a Gap Diffie-Hellman (GDH)group [36] where the computational Diffie-Hellmanproblem (CDHP) [36] is assumed to be intractable.In addition, the TA chooses r ∈R Z∗p and Q ∈R G1,and the client chooses α, β, γ, τ, λ, µ, ρ ∈R Z∗p . Notethat if the scheme of [32] is adopted, the TA publishes(p,G1, G2, e, g, g1, g2,H, H0,H1), where G1 should be a

6

GDH in which the RCDHP (reversion CDHP) is assumedto be intractable (refer to [32] for detailed definitions).We will demonstrate the following protocols based onthe scheme of [33]. The application of the scheme in [32]to our protocols is straightforward following a similarprocedure. The ticket issuance protocol is demonstratedas:

1) CL →→ TA: IDCL,m, t1, HMACκ(m ‖ t1);2) TA →→ CL: IDTA, X = e(m,ΓTA), Y = e(P, Q),

Z = e(m,Q), U = rH1(IDTA), V = rP , t2,HMACκ(X ‖ Y ‖ Z ‖ U ‖ V ‖ t2);

3) CL →→ TA: IDCL, B = 1λH2(m′ ‖ U ′ ‖ V ′ ‖ R ‖

W ‖ X ′ ‖ Y ′ ‖ Z ′) + µ, t3, HMACκ(B ‖ t3);4) TA →→ CL: IDTA, σ1 = Q + BΓTA, σ2 = (r +

B)ΓTA + rH1(c), t4, HMACκ(σ1 ‖ σ2 ‖ t4).

At the end, the client checks if the following equalitieshold: e(P, σ1) = yBY and e(m,σ1) = XBZ, wherey = e(Ppub,H1(IDTA)). If the verification succeeds, theclient calculates σ′1 = γσ1 + τH1(IDTA), σ′2 = λσ2,ρ = γB, and outputs the signature (U ′, V ′, X ′, ρ, σ′1, σ

′2)

on (TN ,W, c), where TN = m′. In Step 3) above, m =u1P1 + u2P2 = A + u2P2 6= 0 where u1 ∈R Z∗p andu2 = 1, m′ = αm, U ′ = λU + λµH1(IDTA) − βH1(c),V ′ = λV + βPpub, R = e(m′,H1(IDTA)), W = gv1

1 gv22

where g1 = e(P1,H1(IDTA)), g2 = e(P2,H1(IDTA)),and v1, v2 ∈R Z∗p , X ′ = Xα, Y ′ = Y γgτ where g =e(P, H1(IDTA)), Z ′ = ZαγRτ . In the above protocol, theTA and the client can locally derive a symmetric keyκ = e(ΓTA,H1(IDCL)), and κ = e(H1(IDTA), ΓCL) [37],respectively, assuming that IDTA is known to all entitiesin the TA’s domain. A timestamp ti is included ineach message exchanged to prevent the message replayattack [3]. Note that some pairings such as the those forg1, g2 and g in the above procedure can be pre-computedonce and stored for all future use, thus alleviating thecomputation burden of the client.

A design issue to be pointed out is the com-monly agreed information c negotiated at the begin-ning of the ticket generation algorithm. We define c as(val, exp,misb) where val, exp and misb denote the ticketvalue, expiry date/time, and the client’s misbehaviorlevel, respectively. The ticket value confines the totalamount of traffic that the client is allowed to generateand receive before the expiry date of the ticket. Ticketsbear different values. The value val is issued by the TAand will be deducted by the gateway in the ticket depositprotocol. The client’s misb field conveys information onthe misbehavior history of the client in the network.This information is summarized at the TA by performingthe fraud detection based on the ticket records reportedby gateways that have serviced this client. By placingthe misbehavior information in c, the TA successfullyinforms gateways about the client’s past misbehaviorwhen the ticket is deposited. Note that the presence ofmisbehavior information in c will not leak the client’sidentity to any entity in the network, since misb isjust a quantitative level indicating the severity of the

misbehavior and is not specific to a particular client.The incorporation of the misb field has several merits.One possible merit would be to punish clients withmisbehavior history by higher network access latency.The gateway may intend to service well-behaved clientsimmediately upon receiving the ticket, and report ticketrecords to the TA at a later time. If the client appears tohave misbehaved previously and thus may cast a threaton network operations, the gateway will first report theticket record to the TA and will service the client only ifthe TA returns positive feedback (i.e., the TA performsticket fraud detection to check if this ticket has beendeposited before). Since we assume an offline TA in ourscheme, the network access delay cannot be boundedand depends on the work load of the TA. Moreover, theTA may decrease the value of the issued tickets or reducethe frequency of approving the client’s ticket requestsbased on the misbehavior level indicated in misb.

4.1.2 Ticket DepositAfter obtaining a valid ticket, the client may deposit itanytime the network service is desired before the ticketexpires, using the ticket deposit protocol shown below.Our scheme restricts the ticket to be deposited only onceat the first encountered gateway that provides networkaccess services to the client according to val before exp.

1) CL →→ GW : PSCL, m′, W , c, σ =(U ′, V ′, X ′, ρ, σ′1, σ

′2), t5, SIG

ΓCL(m′ ‖ W ‖

c ‖ σ ‖ t5);2) GW →→ CL: IDGW , d = H3(R ‖ W ‖ IDGW ‖ T ),

t6, HMACκ′(d ‖ t6);3) CL →→ GW : PSCL, r1 = d(u1α)+v1, r2 = dα+v2,

t7, HMACκ′(r1 ‖ r2 ‖ t7);4) GW →→ CL: IDGW , misb, exp, t8,

SIGΓGW(PSCL ‖ IDGW ‖ misb ‖ exp ‖ t8);

At the end, the gateway checks if the equality gr11 gr2

2 =RdW holds. At the end of Step 1), the gateway willperform VER(σ) before Steps 2) and 3) can be proceeded,and R can be derived as R = e(m′,H1(IDTA)) fromthe received information. T is the date/time the ticketis deposited. A symmetric key κ′ can be derived locallyby the gateway and the client as κ′ = e(ΓGW , PSCL),and κ′ = e(H1(IDGW ), ΓCL), respectively, after learningeach other’s ID (or pseudonym). The generation of thepseudonym will be discussed in Section 4.2.

The ticket is deemed valid if both the signature verifi-cation and the above equality check succeed. The depositgateway (DGW), where the ticket is initially depositedwill then generate a signature on the client’s pseudonym,the DGW’s ID, and the associated misb and exp valuesextracted from c. The signature is required to be presentin order for other access points in the trust domain todetermine whether and where to forward the client’saccess requests, if the deposited ticket will be furtherused from other access points. This is the reason whythe client is not allowed to change his pseudonym whilestill using a deposited ticket to which the pseudonym is

7

associated, since the DGW will refuse to offer access ser-vices to the client if the present pseudonym mismatchesthe one recorded with the ticket. As a result, the ticketvalue need be set to a relatively small quantity in orderto allow frequent update of the pseudonym if the clienthas high requirement on his anonymity [10], [18]. It willnot place extra signaling overhead into the system sincethe TA can grant a batch of small-valued tickets duringone single ticket issuance protocol. Due to the limitedticket value, the client is expected to have minimal mo-bility during the usage of the deposited ticket. However,there are also cases where the client moves to othergateways after the ticket is deposited. To address thisissue, possible decision making functionalities may beincorporated into gateways. For instance, if the clienttemporarily moves to a new gateway in the DGW’svicinity, the new gateway can merely forward all thetraffic of this client to the DGW which then servicesthe client based on the deposited ticket. If the clientpermanently moves to a new gateway, the new gatewaymay request the DGW to transfer the ticket record so thatthe new gateway can directly service the client. We donot intend to further address this issue. Instead, a simpleand efficient solution can be employed to abandon theusage of the remaining ticket and deposits a new one atthe new gateway since the ticket value is generally notlarge. This solution is also effective when the ongoingservice is disrupted due to channel impairments, routefailures, or mobility, as well as when the client tries toavoid mistaken multiple-deposit. Adopting this solution,Step 4) in the above procedure can be omitted. On theother hand, if anonymity is not strictly required by theclient, he can request tickets with higher values that canbe used for longer time under a same pseudonym.

The DGW then creates a record for the depositedticket as: record = (ticket, r1, r2, T, rem, log), where remand log denote the remaining value of the ticket andthe logged data of the client’s non-compliant behavior,respectively. The value of rem is initially set to val. Whenthe client uses the ticket to gain network access, theDGW initiates a traffic counter and decreases it based onthe amount of traffic the client has injected and received.The remaining ticket value rem defines the amount ofnetwork access service the client will be offered beforethe ticket is depleted. The DGW essentially leveragesrem to make sure that the client’s traffic or access activitydoes not exceed the allowed amount defined in val. Wedo not constrain the number of tickets the client canrequest or the request frequency in the proposed scheme,rendering the opportunity for clients to inject a largeamount of traffic or even to launch DoS (Denial of Ser-vice) attack, by gaining a considerable number of ticketsin hand. Therefore, the log field is created to record suchnon-compliant behavior so that the DGW will be ableto apply certain constraints on the client’s bandwidthallocation based on the logged data in log. Note that thenon-compliant behavior is different from misbehaviorwhich solely refers to ticket-reuse and multiple-deposit.

The ticket record will be deleted from the DGW’s data-base once the ticket has expired (by checking c) and themost recent record (excluding rem) has been reportedto the TA. Note that the DGW will maintain the recordfor the depleted tickets that have not expired in order toprevent the client from re-depositing such tickets at thisDGW. For clients with satisfactory misb values, the ticketrecord is sent to the TA periodically, while it is sent to theTA before any network access service can be offered forclients with inferior misb values, as mentioned before.These values are obtained and updated by the frauddetection protocol discussed next.

Note that the real ID of a client can be learned bythe home TA at the time of ticket issuance due to therequirement for client authorization. However, this IDcan be hidden from the access point unless this accesspoint colludes with the home TA. The client simplydeposits a ticket (using the ticket deposit protocol) forobtaining new tickets, in which the ticket request issent to the home TA in ciphertext. This activity canbe exposed when the above collusion is present, whichshould not be a concern because it does not result infuture exposure of activities performed under the newtickets. Furthermore, since a batch of tickets can beissued each time and the client may hold unused tickets,the deposit time of a specific ticket cannot be deducedby the timing analysis attack (i.e., estimating the timingrelationship between ticket issuance and deposit).

4.1.3 Fraud DetectionFraud is used interchangeably with misbehavior in thispaper, which is essentially an insider attack. Ticket-reusegenerally results from the client’s inability to obtaintickets from the TA when network access is desired,primarily due to the client’s past misbehavior whichcauses the TA to constrain his ticket requests. Multiple-deposit can also be termed client coalition, which isbeneficial when the coalescing parties are unauthorizedusers or clients with misbehavior history having diffi-culty in acquiring tickets from the TA. Note howeverthat, since a client is able to obtain multiple tickets inone ticket issuance protocol and self-generate multiplepseudonyms (cf. Section 4.2), he can distribute thesepseudonym/ticket pairs to other clients without beingtraced as long as each ticket is deposited only once. Apossible remedy to this situation is to specify the non-overlapping active period of a ticket instead of merelythe expiry date/time, such that each time only one ticketcan be valid. This approach in general requires synchro-nization. Another solution is to adopt the tamper-proofsecure module so that a client cannot disclose his secretsto other parties since the secure module is assumed tobe expensive and impractical to access or manipulate.This approach will eliminate the multiple-deposit fraudbut requires the deployment of secure modules. In thefollowing discussion, we will still consider multiple-deposit as a possible type of fraud (e.g., in case securemodules are unavailable).

8

These two types of fraud share a common feature,that is, a same ticket (depleted or valid) is depositedmore than once which violates our one-time deposit rule.This is where the restrictiveness of the blind signaturealgorithm takes effect on revealing the real identity ofthe misbehaving client. Specifically, when the TA detectsduplicate deposits using the ticket records reported bygateways, the TA will have the view of at least two dif-ferent challenges from gateways and two correspondingsets of responses from the same client. By solving theequation sets below based on these challenges and re-sponses, the TA is able to obtain the identity informationencoded in the message and hence the real identity ofthe misbehaving client. The fraud detection protocol isshown as:

GW → TA: IDGW , m′, W , c, σ =(U ′, V ′, X ′, ρ, σ′1, σ

′2), r1, r2, T , t9, HMACκ′′(m′ ‖

W ‖ c ‖ σ ‖ r1 ‖ r2 ‖ T ‖ t9),

where κ′′ is the pre-shared symmetric key between thegateway and the TA, which we have assumed for theWMN backbone. At the end, the TA performs VER(σ).If the signature can be successfully verified, the TAchecks if m′ (or the ticket serial number TN ) has beenstored. If m′ is not stored, the TA will store the followinginformation: m′, c, T , r1, r2 for future fraud detection.If m′ has been stored, the TA will first compute thechallenge d = H3(R ‖ W ‖ IDGW ‖ T ) and willaccuse the gateway if d is the same as the stored one.If d is different, the TA can conclude that misbehaviorhas occurred and will reveal the identity information byconstructing the following two sets of equations fromtwo different views of the ticket records received fromgateways:

r1 = d(u1α) + v1, r2 = dα + v2 (1)

r′1 = d′(u1α) + v1, r′2 = d′α + v2 (2)

The TA can solve for u1 = r1−r′1r2−r′2

and obtain the accountnumber A = u1P1 to reveal the associated identity IDCL.At this point, it is clear that the client-chosen secret u1 ∈R

Z∗p in ticket issuance serves as the embedded clue fortracing misbehaving clients.

By far, we have presented the techniques to resolvethe conflicts between anonymity and traceability. As longas the client is a well-behaved user in this network, hisanonymity can be fully guaranteed. This is achieved bythe blinding process of the ticket issuance protocol whichbreaks the linkage between the ticket and the identity,i.e., the TA knows the client’s real ID but does not knowwhich ticket/pseudonym pairs belong to this client,while the gateway knows the linkage between the ticketand the pseudonym but learns no information on the realidentity of the owner of these pairs. On the other hand,if the client misbehaves (i.e., fraud occurs), the client’sanonymity can no longer be guaranteed since the TAmay tend to identify this client, and subsequently punishhim possibly by revoking the client’s network access

privilege, leveraging the traceability property offered byour security architecture. In addition, our system enablesauthentication at the access points and meets the accesscontrol security requirement that is not satisfied in [17],where no authentication of the client is performed at theaccess point in the controlled connection protocol.

4.1.4 Ticket RevocationTicket revocation is necessary when a client is com-promised and thus all his secrets are disclosed to theadversary. In our system, the adversary is motivated bygaining network services using tickets once the ticket-associated secrets are obtained from the compromisedclients. Therefore, the compromised client need be ableto revoke the ticket and prevent the adversary fromacquiring benefits. The compromised client and the ad-versary are the only two parties that are in possession ofthe ticket-related secrets, a valid revocation request mustbe sent by the compromised client for genuine revocationpurpose since the adversary gains nothing in doing so.The ticket revocation protocol consists of two cases:

1) Revocation of new tickets: the client may storea number of unused tickets, as mentioned previ-ously. When revoking these tickets that have notbeen deposited, the client sends PSCL, TN , t10,SIG

ΓCL(TN ‖ t10) in the revocation request to any

encountered gateway. This gateway authenticatesthe client using PSCL and records the ticket serialnumber TN as revoked.

2) Revocation of deposited tickets: the client simplysends PSCL, IDDGW , t11, SIG

ΓCL(IDDGW ‖ t11)

in the revocation request to the DGW. The DGWauthenticates the client and marks the associatedticket revoked.

When gateways have records in the revocation database,they immediately report the revocations to the home TAwhich will update and distribute the revocation list forall gateways in the trust domain to reference.

4.1.5 Accessing The Network From Foreign DomainsThe access services the visiting (foreign) trust domainprovides in the ticket-based security architecture cantake place in two ways including:• A foreign mesh router MR (or foreign access point)

forwards the client’s new ticket request to the homedomain when there is no available ticket for access-ing the network from the foreign domain:

1) CL →→ MR: PSTCL, aP0, t12,HIDSψCL,sCL

(H ′1(PSTCL ‖ aP0 ‖ t12));

2) MR → CL: IDTMR, bP0, t13,HIDSψ

MR,s

MR(H ′

1(IDTMR ‖ bP0 ‖ t13));3) CL →→ MR: PSTCL, PSCL, SKEκ(IDCL ‖

m), t14, HMACκ(PSCL ‖ SKE ‖ t14).• MR (or an access point) forwards the client’s ticket

deposit request to the home domain when theclient owns available new tickets issued by thehome TA. The first two steps of the procedure are

9

exactly the same as the above. The last step in thiscase will be:CL →→ MR: PSTCL, PSCL, ticket, t15,HMACκ(PSCL ‖ ticket ‖ t15).

At the end, MR will forward the network access requestconsisting of (PSCL,SKEκ(IDCL ‖ m)) with κ thesymmetric key between the client and his home TA, or(PSCL, ticket), to an access point (a gateway or meshrouter) in the client’s home domain, if HVER(HIDS ‖QT ) outputs “accept” in Steps 1) and 2). The symmetrickey between the client and MR is κ = abP0, wherea, b ∈R Z∗p and P0 is the public domain parameter ofthe root PKG (cf. Section 3.3).

It is noted that the above triangular traffic forward-ing via the home domain can be cumbersome if theclient will stay at a foreign domain for a long term(e.g., not temporarily visiting). It is recommended thatthe client registers with the foreign TA to become anaffiliated user of the foreign domain. Consequently, allthe network access related operations including ticketissuance, deposit, revocation and fraud detection willfollow the same procedures as in the home domain case,which greatly reduces the communication overhead inthe system.

4.2 Pseudonym Generation and RevocationThe use of pseudonyms has been shown in the ticket-based protocols. This section copes with the pseudonymgeneration technique and the related revocation issue.The pseudonym is used to replace the real ID in theauthentication which is necessary for both anonymousnetwork access and location privacy. In the intra-domainauthentication in our system, the client generates hisown pseudonym by selecting a secret number $ ∈R Z∗pand computing the pseudonym PSCL = $H1(IDCL).The corresponding private key can be derived as ΓCL =$ΓCL = $πH1(IDCL) = π · PSCL, in a similar wayto that of [38]. Compared to [10], [12], [16] where abatch of pseudonyms are assigned to each client bythe TA, the self-generation method vastly reduces thecommunication overhead in the system. Moreover, theclient is able to frequently update his pseudonyms (withtickets) to enhance anonymity by using this inexpensivemethod.

When accessing the network from a foreign domain,suppose a client CLj residing at level j is requestingnetwork access from a foreign mesh router MR in avisiting trust domain. After obtaining the private keyψj associated with the ID tuple IDTj = (ID1, ..., IDj)as ψj = ψj−1 + sj−1H1(IDTj) from the parent (i.e.,the home TA), the client CLj derives the self-generatedpseudonym tuples {PSTi : 1 ≤ i ≤ j} as follows:CLj selects a random secret $ ∈ Z∗p and computesthe pseudonym tuples PSTi = $Ki = $H1(IDTi)(1 ≤ i ≤ j). The associated private key can be computedas ψj = $ψj = $

∑ji=1 si−1Ki =

∑ji=1 si−1$Ki =∑j

i=1 si−1$H1(IDTi) =∑j

i=1 si−1 · PSTi. Substitute

PSTj/ψj for H1(IDTj)/ψj in the HIDS scheme [34], thesigning and verification can be correctly performed.

As a final note on the self-generation algorithm, itwould render the pseudonym revocation impossible byusing the pseudonym alone. The reason is that anyadversary who has compromised a client can generatevalid pseudonym/key pairs that are only known tothe adversary by running the self-generation algorithm.However, this pseudonym self-generation technique isappropriate in our system because the pseudonym revo-cation can be realized via revoking the associated ticketsince the pseudonym is active only when its associatedticket is actively in use (deposited and not depleted).Therefore, the revocation process described in Section4.1.4 for ticket revocation automatically revokes ticket-bound pseudonyms. If we employ the pseudonym as-signment as in [10], [12], [16], in addition to the ticket-related operations, the TA will be required to generateand update the pool of pseudonyms for the client andto distribute the revocation list for revoking all effectivepseudonyms in the active pool during a specific period,which induces significantly higher signaling overhead.The TA will also be able to derive the real identity cor-responding to the assigned pseudonyms, which destroysthe anonymity for honest clients.

5 SECURITY ANALYSIS

In this section, we analyze the security requirements oursystem can achieve as follows. Again, we use theoremsin [33] for demonstration and the analysis using theo-rems in [32] can be carried out in a similar fashion.

Fundamental security objectives-It is trivial to show thatour security architecture satisfies the security require-ments for authentication, data integrity and confiden-tiality, which follows directly from the employment ofthe standard cryptographic primitives, namely, digitalsignature, message authentication code, and encryption,in our system. We are only left with the proof of non-repudiation in this category. A fraud can be repudiatedonly if the client can provide a different representation(u1, u2) he knows of m from what is derived by the TA. Ifthe client has misbehaved, the representation he knowswill be the same as the one derived by the TA whichensures non-repudiation.

Anonymity-First of all, it can be easily shown that agateway cannot link a client’s network access activitiesto his real identity. Due to the use of pseudonyms inauthentication which reveals no information on the realID, the gateway learns nothing about the identity of theclient requesting network access. Since the pseudonym isgenerated by the client using his secret number, solvingfor the real identity from the pseudonym is equivalentto solving the DLP. Furthermore, the client’s depositgateway (DGW) cannot deduce the client’s ID from thedeposited ticket which has been blinded by the clientand does not reveal any identification information unlessmisbehavior occurs.

10

Next, we will show that the client’s home TA can-not perform such linking either which follows di-rectly from Theorem 3 of [33] that the restrictivepartially blind signature scheme used as a buildingblock for our security architecture is partially blind.Specifically, any view of the ticket issuance protocol(U, V,X, Y, Z, B, σ1, σ2, m) is unlinkable to any validsignature (U ′, V ′, X ′, ρ, σ′1, σ

′2,m

′) because it is provenin [33] that the blinding factors (α, γ, τ, λ, µ, β) al-ways exist which maps (U, V, X, Y, Z, B, σ1, σ2,m) to(U ′, V ′, X ′, ρ, σ′1, σ

′2,m

′). Therefore, even an infinitelypowerful S∗ wins the game with probability 1

2 (see [33])which is equivalent to random guessing.

Finally, we show that even the collusion of the homeTA and the DGW cannot carry out the linking. It isobvious that by collusion, the TA can learn no morefrom the gateway than the client’s pseudonym usedin association with a deposited ticket. The hardness ofdeducing a real identity from a pseudonym has beenmentioned above. On the other hand, the gateway canlearn the following from the TA: the private key, theaccount number, and the view of the ticket issuanceprotocol (U, V, X, Y, Z,B, σ1, σ2,m) of a randomly chosentarget IDCL. Thus, the maximal amount of informationthe TA and gateway can exploit by collusion is 1)from the gateway: a ticket m′,W, c, (U ′, V ′, X ′, ρ, σ′1, σ

′2)

deposited by some client with an unknown-yet-authenticpseudonym for network access; 2) from the TA: a ran-domly chosen target identity, its associated private key,account number, and the view (U, V, X, Y, Z,B, σ1, σ2,m)of the ticket issuance protocol. It is straightforward thatbecause of the partial blindness of the adopted signaturescheme and the hardness of solving DLP as shownabove, the information pieces in 1) and 2) are unlinkableother than random guessing.

Traceability (conditional anonymity)-According to its de-finition, this requirement is two-fold: 1) Anonymity forhonest clients is unconditional, which can be proven fol-lowing Propositions 10 and 13 of [28]; 2) A misbehavingclient is traceable where the identity can be revealed.The proof of 2) follows from Theorem 2 of [33] thatthe adopted restrictive partially blind signature schemein our security architecture achieves restrictiveness. Inother words, 2) says that the client can only obtainsignatures on messages of which the client knows arepresentation for which the structure in the representa-tion (where the identity information is encoded) remains,proven by using Proposition 12 of [28] and two extrarequirements on the representations the client knows ofm and m′ (see [28] for detailed description of the tworequirements).

Framing resistance-If the client is honest, with over-whelming probability, the representation (u1, u2) heknows is different from that the malicious TA falselygenerated. Since the client could not have come up withthis representation by himself, it proves that the TAattempts to frame the client. Therefore, innocent clientscan exculpate themselves to prevent malicious TAs from

revoking their network access privilege.Unforgeability-The proof of unforgeability (formally

defined in [33]) is essentially the proof of Theorem 4of [33] that the adopted restrictive partially blind signa-ture scheme is existential unforgeable against adaptivelychosen message and ID attacks under the assumption ofthe intractability of CDHP in G1 and the random oracle.

We conclude that: The proposed security architecturesatisfies the security requirements for anonymity, traceability,framing-resistance, and unforgeability, in addition to the fun-damental objectives including authentication, data integrity,confidentiality and non-repudiation, under the assumptionthat CDHP in G1 is hard and the random oracle.

6 EFFICIENCY ANALYSIS

Most pairing-based cryptosystems need to work in: 1)a subgroup of the elliptic curve E(Fq) of sufficientlylarge prime order p, and 2) a sufficiently large finitefield Fqk , where q is the size of the field over whichthe curve is defined and k is the embedding degree.For current minimum levels of security, we require thatp > 2160 and qk > 21024 [39] to ensure the hardness ofthe DLP in G1 and G2. To improve the computation andcommunication efficiency when working with E(Fq), wetend to keep q small while maintaining the security withlarger values of k. According to [39], a popular choice isto work with points in E(Fq) where q ≈ 2170, and to havea curve with embedding degree k = 6 so that qk ≈ 21024.In the following analysis, we will use the parametervalues given above, resulting in the elements in G1 andG2 to be roughly 171-bit (using point compression) and1024-bit, respectively. We further assume SHA-1 [40] isused to compute the keyed-hash message authenticationcode (HMAC), which yields a 160-bit output.

We have mentioned that the inter-domain access sce-nario described in Section 4.1.5 is expected to occurinfrequently. The corresponding overhead is thus not amajor concern and is discussed here briefly. Recall thatthe inter-domain access is enabled by the hierarchicalID-based cryptosystem, the implementation of whichlargely determines the efficiency of the inter-domainaccess. The communication and computation efficiencyis best achieved using the Dual-HIDS introduced inSection 3.3. The client transmits approximately 148 bytes(5× |G1|element + 160bit HMAC output) and 446 bytes(5 × |G1|element + 2 × |G2|element + 160bit HMACoutput), respectively, for a new ticket request and a ticketdeposit request. They correspond to the transmissiontime of 1.18ms and 3.57ms, respectively. In the new ticketrequest, the client needs to perform an HIDS signingand verification, a symmetric-key encryption, and anHMAC, among which the HIDS operations dominatethe computation costs. The signing involves only 4 pointmultiplications (3 for HIDS and 1 for deriving the sym-metric key), 1 point addition, and 1 hash evaluation, andcan be efficiently carried out. The verification howeverrequires 4 pairing operations, which are more expensive

11

than signing but still acceptable given the advances inelliptic curve arithmetics (to be discussed in Section6.3. In the ticket deposit request, the client is requiredto perform an HMAC and no more complex compu-tations. The dominating storage overhead results fromthe hierarchical-system-related parameters, specifically,the ID tuple and associated private key, and the derivedpseudonym tuple and private key. The client stores anID tuple/private key pair of (3j + |G1|element) bytes(assuming each ID is represented by 3 bytes which yieldsa system capacity of 16 million users, including clients,gateways and mesh routers), where j is the level theclient resides in the hierarchical tree. The client furtherstores pre-generated pseudonym tuple/private key pairsfor future use. Each such pair takes a storage spaceof 2 × |G1|element ≈ 43 bytes. The storage overheadexperienced in the inter-domain scenario is thus quitetrivial compared to that in the intra-domain scenariowhich is demonstrated next.

In the rest of this section, we will elaborate on theoverhead incurred in the intra-domain based protocols,namely, ticket issuance, ticket deposit, fraud detection,and ticket revocation.

6.1 Communication

Our ticket-based security architecture consists of fourintra-domain protocols, in which ticket deposit involvesonly clients and gateways. This protocol is distributedin nature and thus the communication cost incurred ismore affordable. In contrast, protocols involving interac-tions with the centralized TA contributes largely to theexpensive communication costs in the system. In frauddetection protocol, gateways report accumulated ticketrecords to the TA periodically instead of in real time.Report from gateways can be scheduled at different timeintervals, avoiding a sudden increase in the communi-cation overhead caused by simultaneous transmissions.For each record, a gateway transmits roughly 443 bytes,including five G1 elements, two G2 elements, and four160-bit elements. Other parameters in the record trans-mission are negligible compared to the above elements.Assume the communication channel between gatewaysand the TA has a bandwidth of 10Mbps, each recordtakes 0.35ms to be transmitted.

Ticket issuance and revocation may take place in realtime. The associated communication overhead dependson how frequent: 1) the clients use up issued tickets, and2) the clients misbehave. One can expect minimal real-time interaction with the TA for systems where ticketissuance is based on the client’s usage trend (such thatticket requests other than scheduled will be infrequent)and there is a well-behaving majority. Since multipletickets are issued to the client at each scheduled interval,the average communication cost can be further reducedbecause some parameters need only be transmitted once.In a single ticket issuance, the client sends roughly 60bytes (i.e., three 160-bit elements) to the TA. The TA

sends to the client approximately 128 bytes (i.e., four G1

elements and two 160-bit HMACs). Note that we haveexcluded the information that need only be transmittedonce. In the ticket revocation protocol, the gateway sendsrevocations in real time to the TA to ensure a timelyupdate and distribution of the ticket revocation list.However, a small amount of communication overhead isincurred in this real-time interaction, which involves thegateway transmitting the 171-bit ticket serial number TN

and a 160-bit HMAC for each revoked ticket (not shownin the paper).

Note that in our protocols, symmetric keys are derivedlocally and hence no extra communication overheaddue to key agreement is introduced to the system. Inaddition, the role of TA may be split into several serversin reality. The communication overhead in our ticket-based system is considered acceptable.

6.2 Storage

As mentioned above, the TA may consist of severalservers to store necessary information from all clientsduring protocol executions. The storage capability ofthese high-end servers is usually not a concern andtherefore we focus on the storage overhead encounteredat the low-end client side. Compared to the TA andclients, the storage requirements for gateways and meshrouters are not stringent given the distribution of a largenumber of them in the system. We thus omit the analysisof storage overhead encountered by gateways and meshrouters. Note that there is a tradeoff between storageand computation overhead. In our protocols, the clienthas to perform pairing computations frequently which isimpractical due to the high cost of pairings and limitedpower of clients. Fortunately, many pairing operations inthe protocols can be computed once and stored for fu-ture use. Furthermore, some stored information remainsunchanged for all instances of protocol execution (e.g.,all tickets issued in the ticket issuance protocol). As aresult, we need merely take into account the effectivestorage overhead (i.e., information that is changed andhas to be stored at each protocol instance).

In ticket issuance, the client stores for each proto-col instance, 621 bytes pre-computed information (3 ×|G1|element + 4 × |G2|element + |Z∗p |element) and 43bytes (2 × |G1|element) after-protocol information forfuture use. Information such as the symmetric key κ,and other protocol parameters m, X , Y , Z, g, g1, g2, etc.,will only be stored once by the client for all protocolinstances. The ticket issuance protocol contributes tomost of the storage overhead at the client side, sinceall ticket-related information necessary for the remainingprotocols will be stored by the end of ticket issuance.The only requirement left for intra-domain protocols isthe storage of the 43-byte pseudonym/private key pairand the corresponding symmetric keys (128 bytes each)with gateways and mesh routers. The size of this storagedepends on the frequency of the client’s pseudonym

12

update. The tradeoff between storage and computationoverhead arises again where the symmetric key storagecan be eliminated if digital signatures replace HMAC forintegrity check in our protocols.

A large portion of storage overhead is due to para-meters with size of |G2| element, which in our case isroughly 128 bytes. Although techniques in [41] can beemployed to compress the size by a factor of three, itadds computation complication to the client. Whetherto sacrifice storage or computation in a real scenariodepends on the design goals and is a common practicefor system designers.

6.3 ComputationFollowing the claims from the storage analysis, we aremainly interested in the computation overhead expe-rienced at the client side, and will count solely theeffective overhead (i.e., the overhead that is varyingfor each protocol instance or cannot be pre-computed).The computation tasks for clients include pairing op-erations (basic pairing and finite field exponentiation),point multiplications and additions, hash operations,etc., among which pairing operations are undoubtedlythe most time-consuming task. An example can be foundin Tables 4.3 and 5.2 of [42] where pairing operationscount for all the high computation costs.

In ticket issuance, the client only computes two basicpairings in real time for each protocol instance. The re-maining pairing operations can either be computed onceor be pre-computed and stored for all protocol instances.Several HMAC operations also need be performed inreal time, which is considered computationally efficient.In ticket deposit, one signing, one verification, and twoHMAC operations are performed in real time by theclient for each ticket deposited. All pairings involved inthis protocol can be pre-computed except one for theverification. A finite field exponentiation is needed forthe signing. Similarly, in ticket revocation, a client hasto compute one signature in real time for each revokedticket, which requires no basic pairings but a finite fieldexponentiation. If Tate pairing is used for the basic pair-ing operation, it is shown in [43] that the time taken forcomputing a Tate pairing is 20ms, 23ms, and 26ms, in theunderlying base field of Fp (where |p| = 512-bit), F2271 ,and F397 , respectively. The first two fields have similarlevels of security to 1024-bit RSA while the last field haseffective 922-bit security. Recent progress [44] shows thatthe computation time of Tate pairing on elliptic curvesin characteristic 2 and 3 has been significantly improved,rendering pairing-based cryptosystems more realistic insecurity applications. We conclude from the analysis thatthe real-time computation intensity in our protocol istotally acceptable even on the low-end mobile device.

7 SECURITY ENHANCEMENTS

In addressing privacy and anonymity on the Internet,Dingledine [45] argues that cryptography alone will

not hide the existence of confidential communicationrelationships and implemented an anonymous commu-nication overlay network, Tor [22], based on the anony-mous routing protocol, i.e., the onion routing [21]. Inaddressing the privacy preserving issue in vehicular adhoc networks (VANETs) where the vehicles enjoy variousVANET applications, Raya and Hubaux [10] claim thatall vehicle identifiers, in particular the MAC and IPaddresses, must change over time, in addition to thefrequent update of the anonymous keys (pseudonyms).Analogously, the proposed ticket-based anonymity sys-tem relies on effective anonymous routing protocols toconstruct anonymous communication paths and guar-antee anonymity for the clients across the entire WMNsystem. For instance, if the network ID (i.e., IP address,MAC address) of a client’s device is fixed and exposedin packet forwarding, the anonymity property of theproposed system will be undermined. By incorporatinganonymous routing protocols [19], [20] into our system,the real network ID, if used in communications, willbe effectively concealed in traffic forwarding involvingthe client, which renders it difficult for the attackerto trace the packet forwarding path and subsequentlydiscover the confidential relationship of the communi-cating parties. The anonymous routing schemes exten-sively proposed for mobile ad hoc networks (MANETs),such as [19], [20] and the references therein, can bereadily employed in WMNs. Specifically, WMNs canbe considered as a special type of MANETs. This canbe illustrated using Fig. 1, where all connections couldrely on wireless links. In our WMN, the TAs, gateways(GWs), and mesh routers (MRs) are usually fixed inlocation, whereas in typical MANETs, all nodes in thenetwork can be mobile. However, this difference in themobility of certain nodes does not affect the applicationof MANET routing schemes in WMNs.

Another possible enhancement is to incorporate peer-to-peer cooperation. In the WMNs considered here, theuplink from the client to the mesh router may rely onmulti-hop communications. Peer clients act as relayingnodes to forward each other’s traffic to the mesh router,which forms a P2P network. The notorious problemcommon in P2P communication systems is the free-riding, where some peers take advantage of the systemby providing little or no service to other peers or byleaving the system immediately after the service needsare satisfied. Peer cooperation is thus the fundamentalrequirement for P2P systems to operate properly. Sincepeers are assumed to be selfish, incentive mechanismsbecome essential to promote peer cooperation in terms ofboth cooperativeness and availability [15]. Typical incen-tive mechanisms for promoting cooperativeness includereputation-based [46], [47] and payment-based [48], [49]approaches. In the reputation-based systems, peers arepunished or rewarded based on the observed behavior.However, low availability remains an unobservable be-havior [15] in such systems which hinders the feasibilityof the reputation-based mechanism in improving peer

13

availability. By contrast, the payment-based approachprovides sufficient incentives for enhancing both co-operativeness and availability, and thus is ideal to beemployed in multi-hop uplink communications amongpeer clients in our WMN system.

8 CONCLUSION

In this paper, we propose a security architecture, SAT,mainly consisting of the ticket-based protocols which canbe considered as application-layer protocols, that resolvethe conflicting security requirements of unconditionalanonymity for honest users, and traceability of mis-behaving users. By utilizing the tickets, self-generatedpseudonyms, and the hierarchical identity-based cryp-tography, the proposed architecture is demonstrated toachieve desired security objectives and efficiency.

ACKNOWLEDGMENT

This work was supported in part by the U.S. NationalScience Foundation under grants CNS-0721744, CNS-0716450, CNS-0626881 and CNS-0716302. The work ofFang was also supported in part by the National ScienceCouncil (NSC), R.O.C., under the NSC Visiting Profes-sorship with contract number NSC-96-2811-E-002-010.

The authors would like to thank Kenneth G. Patersonfor helpful discussions and suggestions.

REFERENCES[1] S. Brands, “Untraceable off-line cash in wallets with observers,”

in Proc. CRYPTO’93, 13th Annual Int’l Cryptology Conf. on Advancesin Cyptology, pp. 302–318, Aug. 1993.

[2] K. Wei, Y. R. Chen, A. J. Smith, and B. Vo, “Whopay: A scalableand anonymous payment system for peer-to-peer environments,”Proc. IEEE Intl. Conf. on Distributed Computing Systems, ICDCS, July2006.

[3] A. Menezes, P. V. Oorschot, and S. Vanston, Handbook of AppliedCryptography, Boca Raton, CRC Press, 1996.

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

[5] P. Kyasanur and N. H. Vaidya, “Selfish MAC layer misbehaviorin wireless networks,” IEEE Trans. Mobile Computing, vol. 4, no.5, pp. 502–516, Sept. 2005.

[6] A. Perrig, J. Stankovic, and D. Wagner, “Security in wirelesssensor networks,” Comm. of the ACM, vol. 47, no. 6, pp. 53–57,2004.

[7] S. Zhu, S. Setia, and S. Jajodia, “LEAP+: Efficient securitymechanisms for large-scale distributed sensor networks,” ACMTrans. Sensor Networks, vol. 2, no. 4, pp. 500–528, Nov. 2006.

[8] W. Lou and Y. Fang, A Survey on Wireless Security in Mobile AdHoc Networks: Challenges and Possible Solutions, edited by X. Chen,X. Huang and D.-Z. Du, Kluwer Academic Publishers/Springer,2004.

[9] L. Zhou and Z. J. Haas, “Securing ad hoc networks,” IEEE NetworkMagazine, vol. 13, no. 6, pp. 24–30, Dec. 1999.

[10] M. Raya and J-P. Hubaux, “Securing vehicular ad hoc networks,”Journal of Computer Security, Special Issue on Security of Ad Hoc andSensor Networks, vol. 15, no. 1, pp. 39–68, 2007.

[11] N. B. Salem and J-P. Hubaux, “Securing wireless mesh networks,”IEEE Wireless Communications, vol. 13, no. 2, Apr. 2006.

[12] Y. Zhang and Y. Fang, “ARSA: An attack-resilient securityarchitecture for multihop wireless mesh networks,” IEEE J. Select.Areas Communications, vol. 24, no. 10, pp. 1916–1928, Oct. 2006.

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

[14] D. Chaum, A. Fiat, and M. Naor, Untraceable electronic cash, inProc. on Advances in Cryptology (CRYPTO’88), 2002.

[15] D. Figueiredo, J. Shapiro, and D. Towsley, “Incentives to promoteavailability in peer-to-peer anonymity systems,” in Proc. IEEE Int’lConf. on Network Protocols, ICNP, pp. 110–121, Nov. 2005.

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

[17] Q. He, D. Wu, and P. Khosla, “Quest for personal control overmobile location privacy,” IEEE Communications Magazine, vol. 42,no. 5, pp. 130–136, May 2004.

[18] A. R. Beresford and F. Stajano, “Location privacy in pervasivecomputing,” IEEE Pervasive Computing, vol. 2, pp. 46–55, 2003.

[19] Y. Zhang, W. Liu, W. Lou, and Y. Fang, “MASK: Anonymous on-demand routing in mobile ad hoc networks,” IEEE Trans. WirelessCommunications, vol. 5, no. 9, pp. 2376–2385, Sept. 2006.

[20] S. Seys and B. Preneel, “ARM: Anonymous routing protocolfor mobile ad hoc networks,” Proc. 20th Int’l Conf. on AdvancedInformation Networking and Applications, AINA, pp. 133–137, Apr.2006.

[21] M. G. Reed, P. F. Syverson, and D. M. Goldschlag, “Anonymousconnections and onion routing,” IEEE J. Select. Areas Communica-tions, vol. 16, no. 4, pp. 482494, May 1998.

[22] R. Dingledine, N. Mathewson, and P. Syverson, “Tor: The second-generation onion router,” in Proc. The 13th USENIX SecuritySymposium, pp. 303–320, Aug. 2004.

[23] J. Sun, C. Zhang, and Y. Fang, “A security architecture achievinganonymity and traceability in wireless mesh networks,” IEEEConf. on Computer Communications (INFOCOM), pp. 1687–1695,Apr. 2008.

[24] D. Chaum, Blind signatures for untraceable payments, Advances inCryptology - Crypto ’82, pp. 199-203, Springer-Verlag, 1982.

[25] Y. Zhang, W. Liu, W. Lou, and Y. Fang, “Securing mobile ad hocnetworks with certificateless public keys,” IEEE Trans. Dependableand Secure Computing, vol. 3, no. 4, pp. 386–399, Oct. 2006.

[26] D. Boneh and M. Franklin, Identity-based encryption from the weilpairings, Advances in Cryptology-Asiacrypt 2001, LNCS 2248, pp.514-532, Springer-Verlag, 2001.

[27] A. Juels, M. Luby, and R. Ostrovsky, Security of blind digitalsignatures, Advances in Cryptology - CRYPTO ’97, LNCS 1294,pp. 150-164, Springer-Verlag, 1997.

[28] S. Brands, An efficient off-line electronic cash system based on therepresentation problem, CWI Technical Report CS-R9323, 1993.

[29] M. Abe and T. Okamoto, Provably secure partially blind signatures,Advances in Cryptology - Crypto 2000, LNCS 1880, pp. 271-286,Springer-Verlag, 2000.

[30] S. M. Chow, C. K. Hui, S. M. Yiu, and K. P. Chow, Two improvedpartially blind signature schemes from bilinear pairings, ACISP 2005,LNCS 3574, pp. 316-328, Springer-Verlag, 2005.

[31] G. Maitland and C. Boyd, A provably secure restrictive partially blindsignature scheme, LNCS 2274, pp. 99-114, Springer-Verlag, 2002.

[32] X. Chen, F. Zhang, Y. Mu, and W. Susilo, “Efficient provably se-cure restrictive partially blind signatures from bilinear pairings,”in Proc. 10th Conf. on Financial Cryptography and Data Security, FC2006, pp. 251–265, Feb. 2006.

[33] X. Chen, F. Zhang, and S. Liu, “ID-based restrictive partially blindsignatures and applications,” Journal of Systems and Software, vol.80, no. 2, pp. 164–171, Feb. 2007.

[34] C. Gentry and A. Silverberg, “Hierarchical id-based cryptogra-phy,” Proc. ASIACRYPT, pp. 548–556, Dec. 2002.

[35] F. Hess, Efficient identity-based signature schemes based on pairings,SAC 2002, LNCS 2595, pp. 310-324, Springer-Verlag, 2002.

[36] R. Dutta, R. Barua, and P. Sarkar, Pairing-based cryptography: asurvey, Cryptology ePrint Archive, Report 2004/064, available athttp://eprint.iacr.org/2004/064.pdf, 2004.

[37] R. Sakai, K. Ohgishi, and M. Kasahara, “Cryptosystems basedon pairing,” in Proc. Symposium on Cryptography and InformationSecurity (SCIS), Jan. 2000.

[38] S. M. M. Rahman, A. Inomata, T. Okamoto, M. Mambo, andE. Okamoto, “Anonymous secure communication in wirelessmobile ad-hoc networks,” in Proc. 1st Intl. Conf. on UbiquitousConvergence Technology, pp. 131–140, Dec. 2006.

[39] S. D. Galbraith, “Pairings. In I. F. Blake, G. Seroussi, andN. P. Smart, editors,” Chapter 9 of Advances in Elliptic CurveCryptography, pp. 183–213, 2005.

[40] NIST, Digital Hash Standard, Federal Information ProcessingStandards (FIPS) Publication 180-1, Apr. 1995.

14

[41] R. Granger, D. Page, and M. Stam, “A comparison of CEILIDHand XTR,” in Algorithm Number Theory, 6th International Sympo-sium, ANTS-VI, pp. 235–249, 2004.

[42] H. W. Lim, On the Application of Identity-Based Cryptography inGrid Security, Ph.D thesis, University of London, 2006.

[43] P. S. L. M. Barreto, H. Y. Kim, B. Lynn, and M. Scott, “Efficientalgorithms for pairing-based cryptosystems,” CRYPTO 2002,Springer-Verlag, LNCS 2442, pp. 354–368, 2002.

[44] P. S. L. M. Barreto, S. D. Galbraith, C. OhEigeartaigh, andM. Scott, Efficient pairing computation on supersingular abelianvarieties, Cryptology ePrint Archive, Report 2004/375, availableat http://eprint.iacr.org/2004/375.pdf, Sept. 2005.

[45] R. Dingledine, “Tor: An anonymous internet communicationsystem,” Workshop on Vanishing Anonymity, The 15th Conf. onComputers, Freedom, and Privacy, Apr. 2005.

[46] S. Buchegger and J. L. Boudec, “The effect of rumor spreadingin reputation systems for mobile ad-hoc networks,” in Proc.WiOpt’03, Mar. 2003.

[47] Y. Zhang and Y. Fang, “A fine-grained reputation system forreliable service selection in peer-to-peer networks,” To Appear inIEEE Transactions on Parallel and Distributed Systems.

[48] S. Zhong, J. Chen, and Y. Yang, “Sprite: A simple, cheat-proof,credit-based system for mobile ad hoc networks,” IEEE Conf. onComputer Communications (INFOCOM), vol. 3, pp. 1987–1997, Apr.2003.

[49] Y. Zhang, W. Lou, W. Liu, and Y. Fang, “A secure incentiveprotocol for mobile ad hoc networks,” To Appear in ACM WirelessNetworks.

Jinyuan Sun received the M.A.Sc. degree incomputer networks from Ryerson University,Canada, in 2005. She received the B.S. degreein computer information systems from BeijingInformation Technology Institute, China, in 2003.She was a Network Test Developer at Rugged-Com Inc., Ontario, Canada, 2005-2006. She iscurrently working towards the Ph.D. degree inthe University of Florida. Her research interestsare in the security protocol and architecturedesign of wireless networks. She is a student

member of the IEEE.

Chi Zhang received the B.E. and M.E. degreesin Electrical Engineering from Huazhong Univer-sity of Science and Technology, Wuhan, China,in July 1999 and January 2002, respectively.Since September 2004, he has been workingtowards the Ph.D. degree in the Departmentof Electrical and Computer Engineering at theUniversity of Florida, Gainesville, Florida, USA.His research interests are network and distrib-uted system security, wireless networking, andmobile computing, with emphasis on mobile ad

hoc networks, wireless sensor networks, wireless mesh networks, andheterogeneous wired/wireless networks.

Yanchao Zhang received the B.E. degree incomputer communications from Nanjing Uni-versity of Posts and Telecommunications, Nan-jing, 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 Universityof Florida, Gainesville, in August 2006. SinceSeptember 2006, he has been an AssistantProfessor in the Department of Electrical and

Computer Engineering, New Jersey Institute of Technology, Newark.His research interest include wireless and Internet security, wirelessnetworking, and mobile computing. He is a member of the IEEE andACM.

Yuguang Fang received the PhD degree insystems, control and industrial engineering fromCase Western Reserve University in January1994 and the PhD degree in electrical engineer-ing from Boston University in May 1997. Heheld a postdoctoral position in the Department ofElectrical and Computer Engineering at BostonUniversity from June 1994 to August 1995. FromJune 1997 to July 1998, he was a visiting as-sistant professor in the Department of Elec-trical Engineering at the University of Texas at

Dallas. From July 1998 to May 2000, he was an assistant professorin the Department of Electrical and Computer Engineering at the NewJersey Institute of Technology. In May 2000, he joined the Departmentof Electrical and Computer Engineering at the University of Florida,Gainesville, where he received early promotion to associate professorwith tenure in August 2003 and to full professor in August 2005. He holdsa University of Florida Research Foundation (UFRF) Professorshipfrom 2006 to 2009. His research interests span many areas, includingwireless networks, mobile computing, mobile communications, wirelesssecurity, automatic con-trol, and neural networks. He has publishedmore than 100 papers in refereed professional journals and more than100 papers in refereed professional conferences. He received the USNational Science Foundation Faculty Early Career Award in 2001 andthe Office of Naval Research Young Investigator Award in 2002. Hewas the recipient of the Best Paper Award at the IEEE InternationalConference on Network Protocols (ICNP) in 2006 and the recipient ofthe IEEE TCGN Best Paper Award at the IEEE High-Speed NetworksSymposium, IEEE Globecom in 2002. Dr. Fang has actively engaged inmany professional activities. He is an editor for several journals, includ-ing the IEEE Transactions on Communications, the IEEE Transactionson Wireless Communications, the IEEE Transactions on Mobile Comput-ing, ACM Wireless Networks,and the Journal of Computer Science andTechnology, and a technical editor for IEEE Wireless CommunicationsMagazine. He was also an editor of the IEEE Journal on Selected Areasin Communications: Wireless Communications Series, an area editor ofthe ACM Mobile Computing and Communications Review, an editor ofWireless Communications and Mobile Computing, and a feature editorfor ”Scanning the Literature” in IEEE Personal Communications. Healso served on the Technical Program Committee of many professionalconferences, such as ACM MobiCom ’02 (committee cochair for StudentTravel Award), MobiCom ’01, IEEE INFOCOM ’08, IEEE INFOCOM’07, 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 cochair), Globecom’02, and the International Conference on Computer Communicationsand Networking (IC3N, technical program vice-chair). He is a fellow ofthe IEEE.