Computer Communications 31 (2008) 3662–3671

Contents lists available at ScienceDirect

Computer Communications

journal homepage: www.elsevier .com/locate /comcom

Protocols for purpose-restricted anonymous communications in IP-basedwireless networks

Hanane Fathi a,*, SeongHan Shin a, Kazukuni Kobara a, Hideki Imai a,b

a National Institute of Advanced Industrial Science and Technology, Research Center for Information Security, Akihabara Daibiru, 1-18-13 Sotokanda,Chiyoda-ku, Tokyo 101-0021, Japanb Chuo University, 1-13-27 Kasuga, Bunkyo-ku, Tokyo 112-8551, Japan

a r t i c l e i n f o a b s t r a c t

Article history:Received 13 April 2007Received in revised form 25 June 2008Accepted 30 June 2008Available online 13 July 2008

Keywords:Anonymous communicationSender anonymityAnonymous authenticationPassword-based authenticated key exchangeIP address assignment

0140-3664/$ - see front matter � 2008 Elsevier B.V. Adoi:10.1016/j.comcom.2008.06.026

* Corresponding author. Tel.: +81 3 5298 4723.E-mail address: hanane.fathi@aist.go.jp (H. Fathi).

Anonymity and specifically sender anonymity have become essential requirements for many privacy-related applications (e.g. net counselling and whistle blowing). On the other hand, anonymity may beabused for various malicious activities (e.g. redistribution of copyrighted contents and illegal drug trad-ing). In this paper, we address both by proposing protocols for authenticated anonymous communica-tions channels. In such channels, the client can authenticate the authentication server while the lattercan only authenticate the fact that the client is one of the qualified members that are eligible to usethe wireless network (e.g. WLAN hot spots, WiMAX). Our protocols are based on an efficient anonymouspassword-based authenticated key exchange protocol and on an anonymous IP address assignment. Theproposed protocols have the following advantages: (1) they can restrict the usage of the establishedanonymous channels to certain fair purposes; (2) they do not involve rerouting of the packets througha chain of intermediate nodes; (3) they are available right after registration of a normal password toan authentication server as for a classical non-anonymous authentication (e.g. EAP-TTLS and PEAP) anddo not require any special registration procedures that would reveal initially to the authentication serverthat the client belongs to a small list of users of anonymous services. However, each scheme has differentfeatures with respect to the changes required of the DHCP standard, the controlled and adaptive IPaddress assignment, the compatibility to authentication frameworks used for wireless networks, thescalability and the number of messages involved.

� 2008 Elsevier B.V. All rights reserved.

1. Introduction

Anonymity has become an essential requirement for manyprivacy-related applications such as net counselling, whistleblowing and many others. Sender anonymity that protects theidentity of the sender is the most demanded in the currentapplications.

One approach to provide sender anonymity is to route allmessages to the destination through several intermediate hopsin order to hide the identity of the sender (i.e. its IP address).Many re-routing protocols with different path selection strate-gies have been proposed. Also another approach for anonymouscommunication that does not involve re-routing but lacksscalability has been proposed: the dining cryptographersnetworks [1].

In the re-routing category, anonymizer [2] provides anonymouscommunication services using a web proxy server (anonymizerserver) that takes out the crucial headers and source addresses

ll rights reserved.

from web browser requests. Instead of the user identity which isthe IP address for instance, a web server can only get the identityof the anonymizer server. In this approach, all rerouting paths havea single intermediate node, which is the anonymizer server. Mixes[3] are another technique that provides anonymity by routing eachmessage over a series of independent stations. A mix is a store-and-forward station that accepts a number of fixed-length mes-sages from different sources, performs cryptographic transforma-tion on the messages, and then outputs the message to the nextstation in a different order.

Onion Routing [4–7] and Crowds [8] protocol provide anony-mous Internet services using a rerouting path within a networkof onion routers or crowd members. Onion Routing performsanonymous communication within a network of onion routersthat can be considered as real-time mixes. In Onion Routing,the whole path called onion can be considered as a recursivelylayered data structure that is constructed by the sender in theconnection setup. After the connection is established, the datapacket is broken into fixed-size blocks and each block is en-crypted multiple times along the path (once for each onion routeron the path). Thus, each onion router removes one layer of

1 Semantic security of session keys is guaranteed if an active attacker cannot geany information about the session keys shared between the legitimate partiesinvolved. Specifically, the attacker cannot distinguish a real session key from arandom one, chosen from the same key space, in the security definition for moredetails, see [14,15].

H. Fathi et al. / Computer Communications 31 (2008) 3662–3671 3663

encryption so that the plaintext blocks can be obtained success-fully at the destination. It is assumed that the sender knows theidentity and the public keys of the onion routers used.

Like Onion Routing, the Crowds protocol [8] uses a series ofcooperating proxies to maintain anonymity within the group. Un-like Onion Routing, the sender does not determine the whole pathbefore sending a message. Instead, each hop chooses randomly thenext hop. Each crowd member receiving a packet decides based onthe forwarding probability whether to send the packet directly tothe destination or to forward it to another randomly chosen crowdmember.

But all these re-routing protocols do not prevent against theabuse of anonymity for illegal activities (e.g. redistribution ofcopy-righted contents, illegal drug trading and so on). Moreoverthey introduce extra delay and increase the amount of trafficdue to longer routing paths. The main contribution of this paperis to propose protocols for authenticated anonymous communica-tions in IP-based wireless networks. Our goal is to provideauthenticated anonymity at the IP layer to avoid the abuse ofanonymity while keeping the communication cost as low aspossible.

In this paper, we address these issues through anonymousauthentication and anonymous stateful IP address assignmentto clients. As the anonymity is provided at the stateful IP addressassignment stage using the dynamic host configuration protocol(DHCP) [9], the source IP address can be revealed to the destina-tion and there is no need to re-route the messages in order tohide the sender’s address. The assigned IP address does not linkback or give any information about the sender’s identity. Ourprotocols avoid the time-consuming rerouting procedurethrough different routers and the processing involved. Each pro-tocol is designed for a specific scenario and has different fea-tures with respect to the changes required in the DHCPstandard [9], the controlled and adaptive IP address assignment,the compatibility to other authentication frameworks, and thenumber of messages involved. Our protocols aim at providinganonymity over wireless hotspots such as Wifi hotspots and Wi-max hotspots.

Anonymous authentication of authorized clients is fundamen-tal in our approach in order to prevent the abuse of the anony-mous communication channels by clients willing to performattacks or illegal activities. The authentication relies on an effi-cient anonymous password-authenticated key exchange (PAKE)protocol proposed in [10]. This protocol is more efficient thanthe PAKE proposed in [11] in terms of computational and com-munication cost. The security goal of our framework is to estab-lish anonymous communication channels with usage restrictedto fair and legal activities performed by authorized users. Ourproposals provide anonymity for authorized users wishing to con-nect to a server providing anonymous services such as netcounselling.

The rest of the paper is organized as follows: in Section 2 theefficient anonymous PAKE is described. In Section 3, we proposea set of new protocols for authenticated anonymous communica-tions. The security analysis of the proposed framework is givenin Section 4. In Section 5, we discuss the advantages of our ap-proach over existing ones. The concluding remarks are given inthe last section.

2. Efficient anonymous PAKE protocol

In this section, we describe the efficient anonymous PAKE(E-APAKE) protocol [10] that significantly reduces computationalcost for both client and server as well as communication cost com-pared to [11]. More details of the computational and communica-tion efficiency are given in Section 2.4.

2.1. Security goal

The security goal of the efficient anonymous PAKE (E-APAKE)is to provide semantic security1 of session keys as well asanonymity against a passive server who follows the protocol hon-estly, but is curious about identity of a client involved with theprotocol.

2.2. Preliminary

We give some notations to be used. Let G be a finite, cyclicgroup of prime order q and g be a generator of G (quadratic resi-dues modulo p where p = aq + 1) where the Diffie–Hellman prob-lem is hard. Let h be another generator of G so that its discretelogarithm problem with g (i.e., computing b = loggh) should behard. These parameters are given as public information. From hereon, X � gx mod[p] means that the value of modular exponentiation(i.e., computing the base g to the x in modulo p) is assigned to avariable X. If expression of modular exponentiation in modular pis clear, we omit ‘‘mod[p]” in the expression.

Let l denote the security parameter for hash functions (i.e. thesize of the range). Let N be a dictionary size of passwords. Let{0,1}* denote the set of finite binary strings and {0,1}l the set of bin-ary strings of length l. If D is a set, then d R D indicates the processof selecting d at random and uniformly over D. Let ‘‘k” denote theconcatenation of bit strings in {0,1}w. Let ‘‘�” denote the exclu-sive-OR (XOR) operation of bit strings. The hash function F is afull-domain hash function, mapping {0,1}w to ZH

q . The other hashfunctions are denoted G;Hk : f0;1gH ! f0;1gl for k = 1, 2 and 3,where Hk are distinct secure one-way hash functions (e.g., SHA-256 or RIPEMD-160) from one another. Let C and S be the identitiesof a set of clients and authentication server, respectively, with eachID 2 {0,1}w.

2.3. The execution of the protocol

Here we assume that each client Ci of the set C has registered apassword pwCi

to an authentication server AS and the latter main-tains a database of clients’ passwords pwCj

ð1 6 j 6 nÞ. For simplic-ity, we assign the clients consecutive integer i (1 6 i 6 n) where Ci

can be regarded as the ith client.When client Ci wants to share a session key securely with ser-

ver AS without revealing its identity, it first chooses a randomnumber x from ZH

q and computes the Diffie–Hellman public valueX � gx. The latter is masked in a way of the product of the publicvalue with the verification data Wi, where Wi � hpwi and pwi isthe output of Fði; pwCi

Þ. Then, the resultant value is sent to theserver in a masked message (MM) together with the set of clients’identities. On the other hand, server AS chooses a random numbery from ZH

q and a random master-secret MS from {0,1}l, and com-putes its Diffie–Hellman public value Y � gy. With the messageMM from client Ci, the server computes Xj, by dividing the re-ceived masked public value with each of the verification data,and {Zj} that is derived from XORing MS and the hash of each Dif-fie–Hellman key. Also server AS generates an authenticator and asession key, both of which are just the hash of some values andthe master-secret MS, and then sends in server authenticatormessage (SA) its identity, the Diffie–Hellman public value,{Zj}16j6n and the authenticator. After computing MS from Y andZj in an obvious way, client Ci verifies the received authenticator

t

Fig. 1. An efficient anonymous PAKE protocol.

Table 1Comparison of the efficiency of E-APAKE and of [11] where the figures in theparentheses are the remaining number of modular exponentiations after pre-computation

Protocols The number of modularexponentiations

Communicationbandwidth (bytes)

Client Ci Auth. Server

APAKE [11] 6 (4) 42 (31) 1822E-APAKE 3 (2) 21 (20) 542

3664 H. Fathi et al. / Computer Communications 31 (2008) 3662–3671

VS prior to generating its session key.2 In order to avoid so-calledpartition attacks [12,13], both client and authentication servershould check the subgroup order of Y and X*, respectively:Yq � (X*)q � 1. Fig. 1 illustrates the whole protocol.

Note that mutual authentication can be achieved by sending aclient authenticator VCi

¼H3ðCkSkX�kYkfZjg16j6nkMSÞ to theauthentication server.

2.4. Efficiency

In general, the number of modular exponentiations is a majorfactor to evaluate efficiency of a cryptographic protocol becausethat is the most power-consuming operation. So we count thenumber of modular exponentiations as computation costs of clientCi and server AS.

With respect to computation costs in the E-APAKE protocol,client Ci (resp., server AS) is required to compute 3 (resp., 2n + 1)modular exponentiations. When pre-computation is allowed, theremaining costs of client Ci (resp., server AS) are 2 (resp., 2n) mod-ular exponentiations.

With respect to communication bandwidth, the E-APAKE proto-col requires a bandwidth of ððnþ 1ÞjHkj þ 2jpjÞ-bits except thelength of identities C and S.

In order to compare the E-APAKE protocol with its only compet-itor [11], we set n = 10, jCij = 48 bits, jSj = 48 bits, and use the min-imum security parameters recommended in practice (i.e.,jpj = 1024 bits and jHkj ¼ 160 bits). The numerical comparisonbetween E-APAKE and [11] is given in Table 1.

As shown in Table 1, the E-APAKE protocol is around 50%more efficient than [11] in terms of computational cost for bothclient and server. The larger the client set C is, the more the ano-nymity of a client can be guaranteed (i.e. the harder it is for aserver to be dishonest and retrieve a client’s identity). At thesame time, the E-APAKE protocol becomes inefficient linearlyto C. Depending on the upper layer applications, efficiency andanonymity of the E-APAKE protocol can be selected as atrade-off.

2 The output of H1 cannot be used as a session key because it is sent in plain formand used as ‘‘authenticator” between client and server. So, applying H2 is necessary inorder to generate a session key (an alternative is to use the output of H1 after adding adifferent index to the input message (refer to [15]).

3. Protocols for authenticated anonymous communications

As illustrated in Fig. 2, the architecture considered here involvesa DHCP server (DS) and a firewall (FW) in the same local area net-work as the client; an authentication server (AS) and an applicationserver (S) authorized to provide anonymous services both locatedin the other networks. The client is connected wirelessly to thecore network and the infrastructure.

We propose five protocols that have different features with re-spect to the changes required of the DHCP standard, the controlledand adaptive IP address assignment, the compatibility to authenti-cation frameworks used for wireless networks, the scalability andthe number of messages involved.

3.1. Assumptions

For all protocols, we assume that the authentication serverand the firewall share a symmetric key so that the authentica-tion server can transmit securely at the firewall the keying infor-mation used for the client–server (C–S) communications via thefirewall.

First, we propose three protocols that correspond to three sce-narios to be considered in the case of controlled IP address assign-ment (adaptive IP address assignment, PANA compatible, and802.1� compatible). For the following three protocols, we assumethat the authentication server and the DHCP server share a sym-metric key so that the authentication server can update securelyat the DHCP server the keying information used for the client–DHCP server (C–D) communications. The fourth and fifth protocoldo not hold such assumption, and do not provide control overthe assignment of IP addresses.

Fig. 2. Architecture.

H. Fathi et al. / Computer Communications 31 (2008) 3662–3671 3665

For the first four protocols, we assume that:

Assumption 1: the authentication server and the application ser-ver S providing anonymous services have established a pre-shared key. This key is used to transmit securely at the applica-tion server S the keying information used for the C–Scommunications.Assumption 2: the DHCP server and the firewall have a pre-shared session key.

Though assumption 1 seems strong, it is natural and practicalfor a service provider to have special agreements with operatorsto deliver a requested anonymous service to its clients. As it isfor a roaming service between different networks where eachcontrolling server already has security associations with its peerin a different administrative domain, these associations are oftenestablished off-line during the negotiation of the roaming agree-ment. However, it does have an impact on and limits the scalabil-ity of these first four protocol. The fifth protocol provides fullscalability (Section 3.7 ). For the full scalability, we use PKI (Pub-lic-Key Infrastructures) between the different entities. This makesthe overall system more complex. In general, the servers and thefirewall are considered more secure (physically) than client (e.g.,terminal, PDAs, or mobile phones) so it is not a heavy task forthem to manage a different set of security associations.

3.2. Anonymity at the link and network layer

To guarantee complete anonymity, the MAC and IP addressesused during the communications should not link back to a specificuser equipment. To achieve this, the client generates at first a pseu-

do-random 48-bits sequence that it uses as its source MAC addressin all the MAC frames generated for the establishment of the anon-ymous channel and for the anonymous data communication. Astrong hash function outputs a hash value of size N bits (e.g.N = 256 in the case of SHA-256) that can be used to generate a ran-dom sequence of a fixed length m 6 N by truncating appropriately.Thus, we can obtain our randomized MAC address by using the 48first MSB’s of the output of SHA-256. A different example on howto do so with MD5 is given in [16,17]. If the sequence is truly ran-dom, its length of 48 bits makes collisions extremely unlikely tohappen in a local area network. In practice, to avoid collision,MAC duplicate address detection (DAD) can be used by broadcast-ing a query to the chosen address and waiting for a response to en-sure the uniqueness of this address in a local network. For moredetails, refer to [18].

The various protocols proposed here involve an anonymousassignment of IP addresses. In IPv4 networks, stateful IP addressassignment is usually performed by the DHCP Protocol [9]. DHCPis built on a client–server model where designated DHCP serversallocate network addresses and deliver configuration parame-ters. There are three mechanisms supported by DHCP for IP ad-dress allocation: automatic allocation where DHCP assigns apermanent IP address, dynamic allocation where DHCP assignsan IP address to a client for a limited period of time, and manualallocation where DHCP conveys to a client the IP address thatwas previously assigned to it by the network administrator. Herewe consider only the dynamic allocation of IP addresses. Toguarantee anonymous assignment, the DHCP requests sent bythe client contain its randomly generated MAC address.

The DHCP server can assign IP addresses to be used for anony-mous communication adaptively: (1) from a pool of IP addressesexclusively dedicated to anonymous communication, (2) fromthe whole range of IP addresses available (as it would be donefor any other communication). An operator may choose to allocatean IP address for anonymous communication only to authorizedclients in order to prevent the depletion of IP addresses by an at-tacker. We therefore elaborate protocols with both controlledand uncontrolled assignment of IP addresses used during the anon-ymous communication.

3.3. Protocols with limited scalability and controlled post-authentication IP address assignment (Protocol 1)

This protocol permits the assignment of post-authentication IPaddresses to authorized clients. As shown in Fig. 3, first the clientobtains anonymously a temporary IP address restricted to authen-tication purposes, then performs the anonymous authentication,and if the authentication is successful, it can obtain an IP addressfrom the DHCP server to communicate anonymously with theapplication server S.

3.3.1. Anonymous assignment of temporary pre-authentication IPaddress

When first connecting to the network, the client needs to obtaina temporary IP address so that it can perform anonymous authen-tication with the AS. To keep the anonymity of the client, theassignment of this temporary IP address has to be performed anon-ymously in the following way. The client first broadcasts a DHCP-DISCOVER message containing the randomly generated MACaddress with ‘‘anonymous” put in the option field. The DHCP serversupporting anonymous assignment responds with a DHCPOFFERmessage that includes an available IP address chosen from the poolof IP addresses dedicated exclusively to access the AS. The FW is gi-ven initially this pool of IP addresses by the DHCP server to checkwhether packets with a source IP address from this pool are des-tined to the AS. If they are not, the packet is discarded by the

Fig. 3. Protocol with Stateful pre-authentication IP address assignment andcontrolled post-authentication IP address assignment (Protocol 1).

3666 H. Fathi et al. / Computer Communications 31 (2008) 3662–3671

FW.3 The client sends a DHCPREQUEST message that includes the‘‘requested IP address” taken from the DHCPOFFER message. TheDHCP server commits the binding for the client for a limited time(i.e. time of the authentication with AS) and responds with a DHC-PACK message.

Note that this procedure ‘‘Anonymous Assignment of Tempo-rary Pre-authentication IP Address” can be skipped if the clientuses an IP address from a set of static IP addresses that have beenpre-configured by the AS in an initialization phase (off-line) and arereserved for authentication purposes with the AS. The AS shouldgive to the firewall this set of IP addresses in an initialization phaseso that the firewall can allow packets originating from theseaddresses to be destined to the AS only. However, this practice isnot encouraged.

3.3.2. Anonymous authentication and key distributionThe client and the server AS perform the authentication and the

session key generation by exchanging the MM and SA. Once theanonymous authentication is performed successfully, the authenti-cation server and the client share a common session key SK1. Thiskey is sent securely along with the key identity KEY_ID4 using therespective security associations in the keying material message(KMM) to the firewall, to the DHCP server, and to the application ser-ver S. The authentication server then derives from SK1 the sessionkey to be used in each entity in communication with the client inthe following way:

3 If the IP address is chosen from the whole range of available IP addresses, at theend of the DHCP process the DHCP server should send a message to the FW containingthe IP address assigned and the mention ‘‘authentication only”.

4 The key identity is used by the firewall, the DHCP server and the applicationserver S to choose the corresponding key to process the client’s messages.

SKC�fF;D;Sg ¼ HashðSK1kindexikindexjÞ; ð1Þ

where indexi and indexj are fixed and unique for each association.The authentication server distributes the keys SKC�{F, D,S} securelyto each entity. This way prevents each entity (i.e., the DHCP ser-ver/firewall/server providing anonymous services) from eavesdrop-ping the other entities’ messages because these messages areencrypted with the pairwise session keys, shared between the ASand the client.

Each entity then keeps the binding [session key – KEY_ID] forfurther communications with the client.

In parallel, the client derives in the same way the following setof keys:

� the session key to be used by the client for communicationswith the DHCP server: SKC–D,� the session key to be used by the client for communications

with the firewall: SKC–F,� the session key to be used by the client for communications

with the server providing anonymous services: SKC–S.

The authentication server may send then to the client in theauthentication response message (AuthResp) the key identityKEY_ID and the address of the DHCP server providing anonymousIP address assignment in the same subnetwork. This message isencrypted with the session SK1 generated at the end of the E-APA-KE protocol. The client can then proceed to the next step which isthe anonymous IP address assignment.

3.3.3. Anonymous assignment of post-authentication IP address foranonymous communication

To perform anonymous and controlled IP address assignment,the DHCP messages exchanged between the client and the DHCPserver are encrypted with SKC–S. This guarantees that only autho-rized clients are assigned IP addresses. The client first sends aDHCPDISCOVER message encrypted with SKC–S containing the ran-domly generated MAC address with’anonymous’ and KEY_ID put inthe option field to the DHCP server address given by the authenti-cation server. The DHCP server responds with a DHCPOFFER mes-sage, encrypted with SKC–S, that includes an available IP addressfrom the pool of addresses dedicated to anonymous communica-tion or from the whole range of IP addresses available. The clientsends a DHCPREQUEST message, encrypted with SKC–S, that in-cludes the ‘‘requested IP address” taken from the DHCPOFFER mes-sage. The DHCP server commits the binding for the client andresponds with a DHCPACK message, encrypted with SKC–S, contain-ing the configuration parameters for the requesting client.

3.3.4. Controlling anonymous communicationThe DS should forward the binding [IP address – MAC address

– KEY_ID] to the FW in a filtering information message (FIM)encrypted with their pre-shared session key. The FW binds theseinformation with the corresponding key SKC–F, thanks to the KEY_ID. The messages from the client to the application server S provid-ing anonymous services contain the KEY_ID in a transport headeroption and are encrypted at the transport layer with the sessionkey SKC–S and appended a message authentication code generatedwith SKC–F at the network layer. When a packet is received at theFW, its source IP address permits the FW to verify the messageauthentication code with the appropriate key and to allow thepacket to leave the network. The FW also has the list of IP addressesof servers authorized to provide anonymous services to the clientsbehind the FW. The FW can then control the inbound and outboundauthorized flows. When a packet is received at the applicationserver S, the KEY_ID in a transport header option permits to theapplication server S to decrypt the packet with the appropriate key.

H. Fathi et al. / Computer Communications 31 (2008) 3662–3671 3667

The firewall plays the role of an enforcement point and allowspoint-to-point anonymous communication channels to be estab-lished with a single destination (the application server S, ‘‘certified”by the AS) if the sender has successfully, as a legitimate member,generated the session keys.

3.4. Protocol with limited scalability and authenticated stateful IPaddress assignment (Protocol 2)

The assumptions are same as in previous section.This protocol embeds the authentication procedure into the

DHCP assignment in order to achieve authentication and con-trolled IP address assignment in time-efficient manner. The mes-sage flow for this protocol is illustrated in Fig. 4.

When first connecting to the network, the client obtains an IPaddress and performs the anonymous authentication with the AS.To preserve the full anonymity of the client and keep the time-effi-ciency, the IP address must also be assigned anonymously in thefollowing way. The client first broadcasts a DHCPDISCOVER mes-sage containing the randomly generated MAC address with ‘‘anon-ymous” put in the option field. The DHCP server supportinganonymous assignment responds with a DHCPOFFER message thatincludes an available IP address chosen among the pool of IP ad-dresses dedicated to anonymous communications. The client usesthis IP address only to perform anonymous authentication withAS following the efficient anonymous PAKE protocol described inSection 2. Such control is performed at the FW. The FW checkswhether packets with a source IP address from this pool of IPaddresses are destined to the AS. If they are not, the packet isdiscarded by the FW. The client and the server AS perform theauthentication and the session key generation by exchanging theMM and SA message.

As in the previous protocol, after the anonymous authenticationis performed successfully, the authentication server distributes thekeying material (SKC–{F,D,S} and KEY_ID) in the KMM message to the

Fig. 4. Protocol for authenticated Stateful IP address assignment (Protocol 2).

firewall, to the DHCP server, and to the application server S. Eachentity then obtains its session key to be used with the client.

While the authentication server sends the keying material tothe different entities, the client derives the same set of keys andcompletes the DHCP process. It sends to the DHCP server a DHCP-REQUEST message, encrypted with SKC–S that includes the’re-quested IP address’ taken from the DHCPOFFER message. If theDHCP server is able to decrypt the message properly, it commitsthe binding for the client, responds with a DHCPACK message en-crypted with SKC–S containing the configuration parameters forthe requesting client, and forwards the binding [IP address –MAC address – KEY_ID] to the firewall in a FIM message encryptedwith their pre-shared session key. The FW thus allows the mes-sages from this IP address to other destination than the AS if theyare appended a message authentication code generated with theappropriate SKC–F.

As in the previous protocol, the communication between theapplication server S providing anonymous services and the clientis encrypted with the session key SKC–S at the transport layer andmessages include the KEY_ID in the option header.

3.5. Protocol for IEEE802.1� with limited scalability and controlled IPaddress assignment (Protocol 3)

The assumptions are same as in previous section.This protocol is designed to fit in the IEEE802.1� protocol that is

used to perform the E-APAKE protocol described above. The clientplays the role of the supplicant, and the extensible authenticationprotocol (EAP) carries E-APAKE messages.

As illustrated in Fig. 5, the client first sends a EAPOL Start mes-sage to the access point (AP). The AP consequently requests itsidentity to the client. The client starts then the E-APAKE processand sends the masked message MM encapsulated in an EAP Re-sponse to the AP that forwards the masked message to the AS withits IP address as source address of the packet. The AS replies withthe server authenticator message SA that is forwarded by the APin an EAP message to the client. Once the anonymous authentica-tion is performed successfully, the AS and the client share a com-mon session key SK1. The AS then derives from SK1 the sessionkeys SKC–{F,D,S} to be used by each entity with the client as in

Fig. 5. Protocol for IEEE802.1� framework with limited scalability and controlled IPaddress assignment (Protocol 3).

Fig. 6. Protocol with limited scalabitliy and uncontrolled IP address assignment(Protocol 4).

5 This IP address is used by the firewall to choose the corresponding key to processthe client’s messages.

3668 H. Fathi et al. / Computer Communications 31 (2008) 3662–3671

Eq. 1 while the client derives its own set of keys to be used for com-municating securely with the DHCP server, with the firewall andwith the application server S. The keys SKC–{F,D,S} are sent, each sep-arately, along with their key identity KEY_ID in the keying materialmessage KMM message securely using the respective security asso-ciations to the DS, to the FW, and to the application server S. Eachentity then keeps the binding [session key – KEY_ID] for furthercommunications with the client. The client is then authorized bythe AP to proceed to the anonymous IP address assignment.

To perform the anonymous IP address assignment, the clientbroadcasts a DHCPDISCOVER message encrypted with SKC–S con-taining the randomly generated MAC address with ‘‘anonymous”and KEY_ID put in the option field. The DS supporting anonymousassignment is the only DS able to decrypt the DHCPDISCOVER mes-sage. If it decrypts the message successfully, it responds to the cli-ent with a DHCPOFFER message, encrypted with SKC–S, thatincludes an available IP address chosen among the pool of IPaddresses dedicated to anonymous communications or fromthe whole range of IP addresses available. The client sends aDHCPREQUEST message, encrypted with SKC–S, that includes the‘‘requested IP address” taken from the DHCPOFFER message. TheDS commits the binding for the client and responds with aDHCPACK message, encrypted with SKC–S, containing the con-figuration parameters for the requesting client.

The DHCP server should forward the binding [IP address – MACaddress – KEY_ID] to the firewall in a FIM message encrypted withtheir pre-shared session key.

As in the previous schemes, the messages exchanged betweenthe application server S providing anonymous services and the cli-ent include the KEY_ID in the option header, are encrypted at thetransport layer with the session key SKC–S and appended a messageauthentication code generated with SKC–F.

3.6. Protocol with limited scalability and uncontrolled stateful IPaddress assignment (Protocol 4)

This protocol is designed for the case of a provider that does notrequire to control that the IP addresses are assigned to clients. Themessage flow for this protocol is illustrated in Fig. 6.

When first connecting to the network, the client should obtainan IP address to perform anonymous authentication with the AS.The same address is to be used for the anonymous communica-tions with application server S. The assignment of this IP addressis performed anonymously in the following way. The client firstbroadcasts a DHCPDISCOVER message containing the randomlychosen MAC address (with ‘‘anonymous” put in the option field).A DHCP server responds with a DHCPOFFER message that includesan available IP address selected from the whole available range (ora reserved pool if ‘‘anonymous” is stated in the option field). Theclient sends a DHCPREQUEST message that includes the ‘‘requestedIP address” taken from the DHCPOFFER message. The DHCP servercommits the binding for the client and responds with a DHCPACKmessage.

The client then performs the E-APAKE protocol with the AS, byexchanging the MM and SA message. After a successful authentica-tion, the authentication server and the client share a common ses-sion key SK1. The AS sends the session keys SKC–{F,S} to be used bythe FW and the application server S. The keys are sent by the ASseparately and along with the IP address of the client to the FWand the server S in a KMM message that is encrypted using theirpre-shared keys. The FW thus derives SKC–F as it is done in all theprevious protocols. This permits to the FW to check the packetsoriginating for the client’s IP address and to allow them only if theyare appended a message authentication code generated with SKC–F.The application server receiving the message KMM thus decryptthe messages sent by the client.

3.7. Protocol with full scalability and uncontrolled stateful IP addressassignment (Protocol 5)

Here, we assume a public key infrastructure with registrationauthority, certification authority and certificate repository, thatmanages the certificates. The certificates are data structures thatbind public keys to entities in an authentic way. We introduce inthe application servers’ certificates the concept of level of security.It is defined in [19] as a key piece of information within a securityprofile used to determine whether an entity is allowed to obtainuser data. In this paper, the level of security is used by the firewallto determine if an application server can be authorized to deliver aservice to a requesting client.

Once the IP address assigned anonymously, the client followsthe protocol illustrated in Fig. 7. The client performs anonymousauthentication with the authentication server (AS) following theefficient anonymous PAKE protocol that is described in Section 2.The firewall authorizes the E-APAKE packets if they are destinedto the authentication server.

Once the anonymous authentication is performed successfully,the resulting session key SKC–F derived from Eq. 1 is sent by theAS securely along with the client’s global IP address5 to the firewallin the KMM using a pre-established security association. The firewallthen derives from SK1 its session key to be used with the client. Thefirewall then keeps the binding [session key SKC–F – IP address] forfurther communications with this client. In parallel, the clientderives in the same way the session key SKC–F to be used by the clientfor communications via the firewall. All messages from the client toany application server S providing anonymous services are appended

Fig. 7. Protocol for establishing purpose-restricted anonymous communicationschannels with a scalable set of application servers (Protocol 5).

H. Fathi et al. / Computer Communications 31 (2008) 3662–3671 3669

a message authentication code generated with SKC–F at the networklayer. When a client packet is received at the firewall, its source IPaddress permits the firewall to verify the message authenticationcode with the appropriate key and to allow the packet to leave thenetwork if the verification is successful.

The client sends then a public key request message (PKReq) tothe application server. This message is appended a messageauthentication code generated with SKC–F at the network layer.The firewall verifies the message authentication code, and if theverification is successful, it appends its digital signature generatedwith its private key and forwards the PKReq to the application ser-ver S. The latter verifies the signature with the firewall’s public key(for which the validity has been previously verified by the applica-tion server S with a certificate authority). If the verification is suc-cessful, the server S sends back its certificate containing its publickey PKS and its level of security in a public key response message(PKResp). The firewall verifies the validity of the public key andthe legitimacy of the application server using the level of securityobtained from PKResp with the certificate authority that keeps anupdated list of certified application servers. If the verification issuccessful, it sets the application server’s IP address as an autho-rized source/destination address for incoming/outgoing flows andforwards the PKResp message to the client.

The client then sends a session key SKC–S to the application ser-ver S in a KMM encrypted at the application layer with the applica-tion server’s public key PKS, appended at the network layer amessage authentication code generated with SKC–F. The firewallverifies the latter message authentication code and appends itsdigital signature. The application server S receiving this KMM mes-

Table 2Comparison of all protocols characteristics

Protocol 1 Protocol 2

Change in the DHCP standard Low LowControlled IP address assignment Yes YesAdaptive IP address assignment Yes NoPANA compatible Yes No802.1x compatible No NoNumber of messages 14 10Scalability Limited Limited

sage verifies the signature, and if the latter is valid, it decrypts themessage to retrieve the session key SKC–S to be used with the client.This key is then used to protect the confidentiality and integrity ofthe subsequent messages exchanged between the application ser-ver and the client.

After this key establishment, the client can send secure anony-mous messages to server S encrypted with SKC–S at the applicationlayer, and append a message authentication generated with SKC–F

at the network layer for the reasons mentioned above. The mes-sages sent by the application server to the client are secured usingthe session key SKC–S.

At the end of this protocol, the firewall has control over the in-bound and outbound flows, which provides purpose-restriction ofthe anonymous communications.

3.8. Comparison of protocols characteristics

The protocols presented above are compared with respect to thechanges required in the DHCP standard, the controlled and adap-tive assignment of IP address, the compatibility to the protocolfor carrying authentication for network access (PANA) frameworkor to the IEEE802.1x framework, and the number of messages in-volved. Table 2 gives this comparison between the protocols.

Concerning the change in the DHCP standard, protocols 1 to 3require the DHCP process to be encrypted and to add in the optionfield ‘‘anonymous” and the key identity.

Concerning the control of IP address assignment, the DHCP ser-ver assigns post-authentication IP addresses only to clients thathave been previously authenticated and are thus able to sendDHCP messages encrypted with the appropriate key. All protocolsexcept protocols 4 and 5 support this feature.

In all protocols except protocol 2, we discussed the possibility ofadaptive IP address assignment: assigning IP addresses either froma pool of addresses dedicated to anonymous communications orfrom the whole range of available IP addresses. As protocol 2 em-beds the authentication in the DHCP process and the client uses anIP address that is offered and not assigned to perform authentica-tion, the DHCP server cannot take the initiative to send a FIM mes-sage to the FW containing the IP address chosen from the wholerange of available addresses and the mention ‘‘authentication only”before the DHCP process is completed so that the FW can allow theauthentication messages to the AS. The addresses have therefore tobe taken from a pool of addresses that is known by the FW as well.It is thus not possible for protocol 2 to offer the choice of an adap-tive IP address assignment.

Concerning the compatibility to PANA framework, PANArequires that the client holds an IP address before the PANAmessage exchange takes place. Protocols 2 does no fit with thePANA framework as in this protocol the IP address for anonymouscommunications is assigned after the authentication is performed.Protocol 3 is based on 802.1� framework. Protocols 1, 2 and 5 arecompatible with PANA. In the PANA framework, there are twoentities needed: an enforcement point that is in charge of allowingaccess of authorized clients, and a PANA authentication agent that

Protocol 3 Protocol 4 Protocol 5

Low No NoYes No NoYes Yes YesNo Yes YesYes No No12 8 10Limited Limited Full

3670 H. Fathi et al. / Computer Communications 31 (2008) 3662–3671

is in charge of interfacing with the client and the authenticationserver. In protocols 1, 4 and 5, the firewall could play the role ofthe enforcement point and an access router between the clientand the authentication server could play the role of the PANAauthentication agent to forward the authentication messages.

For the compatibility to 802.1� framework, only protocol 3follows the 802.1� framework: the AP plays the role to the authen-ticator requesting the identity and dealing with a back-endauthentication server and the client is the supplicant.

4. Security analysis

Let us consider an attacker who has ability to eavesdrop, modifyand insert the messages exchanged by parties.

We mainly discuss here the anonymity of the proposed proto-cols. The anonymity is provided by the E-APAKE protocol, by thesymmetric-key encryptions used by the client with the DHCP ser-ver, the firewall and the application server S.

As the session keys used in the above mentioned symmetric-key encryption are derived from keying material provided by theauthentication server to the other entities, the secrecy of these ses-sion keys depends on the security associations of the authentica-tion server AS with the DHCP server, with the firewall and withthe application server S. These are based on a symmetric keyencryption with keys that have been pre-shared in a secure initial-ization phase.

As symmetric key encryption is considered secure, the anonym-ity of the proposed approach relies mainly on the E-APAKEprotocol.

Theorem 1. The E-APAKE protocol provides client’s anonymityagainst a passive authentication server in an information-theoreticsense.

Proof. Let v[a] denote entropy of a and let v[ajb] denote condi-tional entropy of a on b. Since we are dealing with a passiveauthentication server, the AS follows the protocol honestly, but itis curious about the identity of client Ci involved with the E-APAKE

protocol. Now, the client’s anonymity against the AS is proved in aninformation-theoretic sense since

v½C� ¼ v½CjX��: ð2Þ

X* is a unique discrete logarithm of g so that it has a uniform distri-bution over G. In other words, the authentication server does notgain any stronger exhaustive search power from the obtention ofthe initial message sent by the client containing the set of client Cand X*.

This also implies that the interactions between either Ci or Cj 6¼ i

and S are completely independent of one another. In addition, evenif authentication server AS receives the client’s authenticatorVCi¼H3ðCkSkX�kYkZjkMSÞ at the end of the E-APAKE protocol

(in the case of mutual authentication), the X* does not reveal anyinformation about the client’s identity because the probability forall clients to compute MS is equal. h

In our approach, the collusion of the AS, the DS, the FW and theserver S to discover the identity of the client does not threaten theanonymity of the client as the information related to the client intheir possession (i.e. the IP/MAC address used and the session keysused) do not reveal information about the identity of the client.

Furthermore, if the AS is dishonest and changes the E-APAKEprotocol in order to discover the identity of the client, it has thesame probability (1/n) as the random guess for the client’s identityas long as the authentication transactions are independent fromone another (i.e. the client cannot be traced through its IP addressby the AS as being the same client from one authentication trans-

action to another). This can be guaranteed in our protocols by hav-ing the client start the whole process of anonymouscommunication establishment (i.e. renew its pseudo-randomMAC address, renew its IP address before authentication) in casethe authentication fails.

Our protocols are robust against attackers spoofing IP addressesanonymously assigned to authorized clients, in order to abuse theanonymous channel for performing attacks or illegal actions. Thefirewall lets through only packets that include a message authen-tication code generated with the session key SKC–F derived fromthe keying material sent by the authentication server securelyusing their pre-shared symmetric key. As the symmetric keyencryption is considered secure, this firewall policy guaranteesrobustness against the abuse of the anonymous channel by unau-thorized clients.

5. Discussion

Our protocols and the Anonymizer [2] rely both on a server toprovide anonymity. However, our protocols guarantee anonymityeven if there is collusion of all the entities involved in the protocol,while in the Anonymizer approach, the compromise of the anony-mizer server reveals the client’s identity.

Our approach also outperforms other techniques such as Mixes[3], Onion Routing [4] and Crowds [8] in terms of communicationand computation efficiency. Indeed, our approach does not requireto reroute all the packets through various intermediate hosts thatperform cryptographic functions on these packets. In our protocols,after establishing the anonymous channel establishment (i.e. anon-ymous authentication, symmetric-key establishment in the enti-ties involved, and anonymous IP address assignment), thepackets are routed directly to their destination, involving thus onlyone encryption at the source, one decryption at the destination andthe generation of a message authentication code. Our proposals donot require encryption and decryption at intermediate stations orrouters as it is performed in Mixes and Onion Routing. Moreover,in Mixes and Onion Routing, the initial firewall can identify thesource IP address of the packets as it is not likely that there areintermediate routers (onion routers or mixes) before the firewall.This may also lead to firewall identifying the actual user as longas the IP address is assigned by the provider just after the userauthentication.

Our protocols are appropriate for providing anonymity overwireless hotspots such as Wifi hotspots and Wimax hotspots. Ifour protocols were used with Internet connection over the tele-phone lines, the anonymity is obviously compromised.

It is important also to consider the scalability issue with respectto size of clients set. Each client in our protocols holds the list of allclients’ identities to perform successfully the E-APAKE protocoland to generate the appropriate session key. Therefore, it is impor-tant for the client to keep an up-to-date list of clients’ identities.Specifically, any deletion or insertion that results in a change ofthe client’s index in the list requires an update of the set of clients’identities at each client. The AS keeps therefore up-to-date the listsat the access router for PANA compatible protocols (i.e., protocol 1,4, 5) and at the AP for 802.1� compatible protocol (i.e., protocol 3)so that they can check the set of identities included in the maskedmessage and send an update to the client if necessary. In protocol 2that is not compatible with any of the general frameworks, the up-date at the client is performed by the AS.

6. Conclusion

In this paper, we have proposed a set of new protocols for anon-ymous wireless communications that can restrict the usage of such

H. Fathi et al. / Computer Communications 31 (2008) 3662–3671 3671

channels to fair and legal activities. Our protocols are mainly basedon the efficient anonymous PAKE and on an anonymous stateful IPaddress assignment by DHCP servers. They present the followingassets: (1) preventing the abuse of the anonymous communicationchannels to perform malicious activities; (2) avoiding the time andbandwidth consuming rerouting involved in the existing solutions;(3) being available after registration of normal password to theauthentication server and do not require any special registrationprocedure. Each protocol fits in a specific scenario and has also dif-ferent features with respect to the changes required of the DHCPstandard, the controlled and adaptive IP address assignment, thecompatibility to the PANA and the 802.1� authentication frame-works, the number of messages involved and the scalability ofthe number of servers providing anonymous services. The securityanalysis of our protocols shows that the anonymity can be guaran-teed even against a dishonest authentication server and the threatof collusion of all entities. We have also discussed the advantagesof our protocols over existing ones and the scalability of our proto-cols with respect to size of clients set.

In future works, we will consider the migration to IPv6 net-works, and extend our proposals to support stateless IP addressauto-configuration and DHCP for IPv6.

Acknowledgement

Authors thank Yukiko Ito for her precious help in editing thispaper.

References

[1] D. Chaum, The dining cryptographers problem: unconditional sender andrecipient untraceability, Journal of Cryptology 1 (1) (1998) 65–75.

[2] Anonymizer, Available from: %3chttp://www.anonymizer.com%3e.[3] D. Chaum, Untraceable electronic mail, return addresses, and digital

pseudonyms, Communications of the ACM 24 (2) (1981) 84–88.

[4] D. Goldschlag, M. Reed, P. Syverson, Onion routing for anonymous andprivate internet connections, Communications of the ACM 42 (2) (1999) 39–41.

[5] P. Syverson, D. Goldschlag, and M. Reed, Anonymous connections and onionrouting, in: Proceedings of the IEEE Symposium on Security and Privacy, ser.,IEEE CS Press, May 1997, pp. 44–54.

[6] P. Syverson, M. Reed, D. Goldschlag, Onion routing access configuration, in:Proceedings of the DARPA Information Survivability Conference andExposition, ser., IEEE CS Press, January 2000, pp. 34–40.

[7] P. Syverson, G. Tsudik, M. Reed, C. Landwehr, Towards an analysis of onionrouting security, in: Proceedings of the Workshop on Design Issues inAnonymity and Unobservability, July 2000.

[8] M. Reiter, A. Rubin, Crowds: anonymity for web transactions, ACMTransactions on Information and System Security 1 (1) (1998) 66–92.

[9] R. Droms, Dynamic host configuration protocol, IETF RFC2131 March1997.

[10] S. Shin, K. Kobara, H. Imai, An efficient anonymous password-authenticatedkey exchange protocol, in: Proceedings of the ISEC 54, IEICE, Ed., July 2006, pp.107–114.

[11] D.Q. Viet, A. Yamamura, H. Tanaka, Anonymous password-based authenticatedkey exchange, in: Proceedings of the INDOCRYPT 2005, ser., LNCS 3797,Springer, Berlin, 2005, pp. 244–257.

[12] S. Patel, Number theoretic attacks on secure password schemes, in:Proceedings of the IEEE Symposium on Security and Privacy, ser., IEEE CSPress, 1997, pp. 236–247.

[13] Z. Wan and S. Wang, Cryptanalysis of two password-authenticated keyexchange protocols, in: Proceedings of the ACISP 2004, ser. LNCS 3108,Springer, Berlin, 2004, pp. 164–175.

[14] M. Bellare, P. Rogaway, Entity authentication and key distribution, in:Proceedings of the CCS’93, ACM, 1993, pp. 62–73.

[15] M. Bellare, D. Pointcheval, P. Rogaway, Authenticated key exchange secureagainst dictionary attacks, in: Proceedings of the EUROCRYPT 2000, ser. LNCS1807, Springer, Berlin, 2000, pp. 139–155.

[16] Donald E. Eastlake, Stephen D. Crocker, Jeffrey I. chiller, Randomnessrecommendations for security, IETF, 1994. December.

[17] Donald E. Knuth, The Art of Computer Programming, vol. 2: SeminumericalAlgorithms, Chapter 3: Random Numbers, 2nd ed., Addison-Wesley, Reading,MA, 1982.

[18] K. Chin, D. Lowe, W. Lau, Routing in MANETs with address conflicts, Mobileand ubiquitous systems: networking and services, Mobiquitous, 2005, pp.225– 236.

[19] J. Jeong, Z.J. Haas, An integrated security framework for open wirelessnetworking architecture, IEEE Wireless Communications Magazine 13 (2)(2007) 10–18. April.