Anonymous gatewayoriented passwordbased authenticated key exchange based on RSA
 Fushan Wei^{1}Email author,
 Chuangui Ma^{1} and
 Qingfeng Cheng^{1}
https://doi.org/10.1186/168714992011162
© Wei et al; licensee Springer. 2011
Received: 29 January 2011
Accepted: 10 November 2011
Published: 10 November 2011
Abstract
A gatewayoriented passwordbased authenticated key exchange (GPAKE) is a threeparty protocol, which allows a client and a gateway to establish a common session key with the help of an authentication server. To date, most of the published protocols for GPAKE have been based on DiffieHellman key exchange. In this article, we present the first GPAKE protocol based on RSA, then prove its security in the random oracle model under the RSA assumption. Furthermore, our protocol can resist both eresidue and undetectable online dictionary attacks. Finally, we investigate whether or not a GPAKE protocol can achieve both client anonymity and resistance against undetectable online dictionary attacks by a malicious gateway. We provide an affirmative answer by adding client anonymity with respect to the server.
Preprint submitted to EURASIP JWCN October 16, 2011 to our basic protocol.
Keywords
1. Introduction
1.1. Passwordbased authenticated key exchange
Passwordbased authenticated key exchange (PAKE) protocols allow users to securely establish a common key over an insecure open network only using a lowentropy and humanmemorable password. Owing to the low entropy of passwords, PAKE protocols are susceptible to socalled dictionary attacks [1]. Dictionary attacks can be classified into three types [1]: online, offline, and undetectable online dictionary attacks. In online dictionary attacks, an adversary first guesses a password, and tries to verify the password using responses from a server in an online manner. Online password guessing attacks can be easily detected, and thwarted by counting access failures. In offline dictionary attacks, an adversary tries to determine the correct password without the involvement of the honest parties based on information obtained during previous executions of the protocol. Thus, the attacker can freely guess a password and then check if it is correct without limitation in the number of guesses. The last type is undetectable online dictionary at2 tacks, where a malicious insider tries to verify a password guess in an online manner. However, a failed guess cannot be detected by the honest client or the server. The malicious insider participates in the protocol legally and undetectably many times to get sufficient information of the password. Among these attacks, online dictionary attack is unavoidable when lowentropy passwords are used, the goal of PAKE protocols is to restrict the adversary to online dictionary attacks only. In other words, offline and undetectable online dictionary attacks should not be possible in a PAKE protocol.
In 1992, Bellovin and Merritt first presented a family of password protocols known as encrypted key exchange (EKE) protocols [2] which can resist dictionary attacks. They also investigated the feasibility of implementing EKE using three different types of publickey cryptographic techniques: RSA, ElGamal, and DiffieHellman key exchange. They found that RSAbased PAKE in their protocol is not secure against eresidue attacks [2, 3], and pointed out that EKE is only suitable for implementation using DiffieHellman key exchange. From then on, lots of PAKE protocols based on DiffieHellman have been proposed [1, 2, 4–9]. While the approach of designing PAKE protocols with RSA is far from maturity and perfection. In 1997, Lucks presented a scheme called OKE (open key exchange) [10] which is based on RSA. It was later found to be insecure against a variant of eresidue attacks because of MacKenzie et al. [11]. Furthermore, the authors modified OKE and proposed the first secure RSAbased PAKE protocol SNAPI. Since SNAPI protocol required that the RSA public exponent should be a larger prime than RSA modular, it is not practical. Later, Zhang proposed PEKEP and CEKEP protocols [12], which allow using both large and small prime numbers as RSA public exponents. To resist the eresidue attack, PEKEP protocol needs multiple RSA encryptions, and it is not very efficient. In 2007, Park et al. presented another efficient RSAEPAKE protocol [13] which can resist the eresidue attack based on numbertheoretic techniques. Unfortunately, as pointed by Youn et al. [14], RSAEPAKE is insecure against a separation attack. Though the attack can be easily avoided by limiting the number of failed trials, an adversary can get remarkably much information of the password from single trial. Therefore, the separation attack is still a threatening attack against RSAEPAKE protocol.
1.2. Related work
In 2005, Abdalla et al. [4] put forward the first gatewayoriented passwordbased authenticated key exchange (GPAKE) protocol among a client, a gateway, and an authentication server. The client and the server initially share a common password for authentication, but the session key is generated between the client and the gateway via the help of the server. In addition to the usual notion of semantic security of the session key, two additional security goals, namely key privacy with respect to honestbutcurious server and password protection with respect to malicious gateway, are considered to capture dishonest behaviors of the server and the gateway, respectively. In 2006, Byun et al. [8] showed that the GPAKE protocol proposed by Abdalla et al. [4] was vulnerable to an undetectable online dictionary attack. A malicious gateway can iteratively guess a password and verify its guess without being detected by the server. They also proposed a countermeasure for the attack by exploiting MAC of keying material sent to the authentication server from the client. In 2008, Shim [15] showed that Byun's countermeasure was still insecure against the same undetectable online dictionary attack contrary to the claim in [8] that it was. In addition, Shim also designed its enhanced version (SGPAKE) using a symmetric encryption algorithm to overcome the attack. Nevertheless, Yoon et al. [16] pointed out that the SGPAKE protocol was inefficiently and incorrectly designed. Recently, Abdalla et al. [6] presented an anonymous variant of the original GPAKE protocol [4] with similar efficiency. They proposed a new model having stronger security which captured all the security goals in a single security game. The new security model also allowed corruption of the participants. They proved the security of the new protocol in the enhanced security model. However, partially owing to client anonymity, the new protocol is still subjected to undetectable online dictionary attacks. It is quite interesting to ask whether there exists a GPAKE protocol which can achieve both client anonymity and resistance against undetectable online dictionary attacks.
1.3. Our contribution
In this article, we investigate GPAKE protocol based on RSA. We first propose an efficient RSAbased GPAKE protocol. The new protocol involves three entities. The client and the server share a short password while the client and the gateway, respectively, possess a pair of RSA keys. However, all the RSA public/private keys are selected by the entities rather than distributed by a certificate authentication center, so no publickey infrastructure is needed. To resist eresidue attacks, the client uses the public key e of an 80bit prime. The proposed protocol can be resistant to eresidue attacks and provablysecure under the RSA assumption in the random oracle model.
To achieve previously mentioned requirements, the authenticators and the final session key in the proposed protocol rely on different random numbers. In this way, the authenticators between the client and the server will leak no information of the password to the gateway, and the session key established between the client and the gateway is private to the server. Furthermore, standard techniques in thresholdbased cryptography can also be used to achieve threshold version of the proposed protocol. It is worth pointing out that our protocol does not require public parameters. The client and the server only need to establish a shared password in advance and do not need to establish other common parameters such as generators of a finite cyclic group. This is appealing in environments where clients have insufficient resources to authenticate public parameters.
We also investigate whether or not a GPAKE protocol can achieve both client anonymity and resistance against undetectable online dictionary attacks by a malicious gateway. These two requirements seem to contradict each other (it seems that the server needs to know who the user is in order to resist undetectable online dictionary attacks). Nevertheless, this can be reconciled by saying that a server learns whether it is interacting with a user that belongs to a defined set of authorized users, but nothing more about which user it is in that set. We provide an affirmative answer to the above question by adding client anonymity to our GPAKE protocol based on RSA.
The remainder of this article is organized as follows. In Section 2, we recall the communication model and some security definitions of GPAKE protocols. In Section 3, we present our protocol and show that the new protocol is provablysecure under the RSA assumption in the random oracle model. We show in Section 4 how to add client anonymity to the basic scheme using symmetric private information retrieval (SPIR) protocols [17]. We conclude this article in Section 5.
2. Security model
In this section, we recall the security model for GPAKE protocols introduced in [4]. We will prove security of our protocol in this model. We refer the reader to [4] for more details.
2.1. Overview
A GPAKE protocol allows a client to establish an authenticated session key with a gateway via the help of an authentication server. The password is shared between the client and the server for authentication. It is assumed that the communication channel between the gateway and the server is authenticated and private, but the channel connecting the client to the gateway is insecure and under the control of an adversary.
The main security goal of the GPAKE protocol is to securely generate a session key between the client and the gateway without leaking information about the password to the gateway. To achieve this goal, Abdalla et al. [4] defined three security notions to capture dishonest behaviors of the client, the authentication server, and the gateway, respectively. The first one is semantic security of the session key, which is modeled by a RealOrRandom (ROR) game; the second one is key privacy with respect to the server, which entails that the session key established between the client and the gateway is unknown to the passive server; and the last one is server password protection against a malicious gateway, which means that the gateway cannot learn any information about the client's password from the authentication server.
Protocol participants
The participants in a gatewayoriented passwordbased key exchange are the client $C\in \mathcal{C}$, the gateway $G\in \mathcal{G}$, and the authentication server $S\in \mathcal{S}$. We denote by $\mathcal{U}$ the set of all the participants (i.e., $\mathcal{U}=\mathcal{C}\cup \mathcal{G}\cup \mathcal{S}$) and by U a nonspecific participant in $\mathcal{U}$.
Longlived keys
Each client $C\in \mathcal{C}$ holds a password pw_{ c }. Each server $S\in \mathcal{S}$ holds a vector of passwords $p{w}_{S}={\u27e8p{w}_{C}\u27e9}_{C\in \mathcal{C}}$ with an entry for each client. pw_{ c }and pw_{ s }are also called the longlived keys of client C and server S, respectively.
2.2. Security Model
The security model we adopted here is the ROR model of Abdalla et al. [5]. The adversary's capabilities are modeled through queries. During the execution, the adversary may create several concurrent instances of a participant. Let U^{ i }denote the instance i of a participant U. The list of oracles available to the adversary is as follows:

Execute(C^{ i },G^{ j }): This query models passive eavesdropping of a protocol execution between a client instance C^{ i }and a gateway instance G^{ j }. At the end of the execution, a transcript is given to the adversary, which logs everything an adversary could see during the execution.

Send(U^{ i },m): This query models an active attack against the client or gateway instance U^{ i }, in which the adversary may intercept a message and then modify it, create a new one, or simply forward it to the intended recipient. Instance U^{ i }executes as specified by the protocol and sends back its response to the adversary.

Test(U^{ i }): This query is used to measure the semantic security of the session key of instance U^{ i }, if the latter is defined. If the key is not defined, return the undefined symbol ⊥. Otherwise, return either the session key held by instance U^{ i }if b = 1 or a random key of the same size if b = 0, where b is a hidden bit chosen uniformly at random at the beginning of the experiment defining the semantic security of session keys.
In the ROR model, the adversary can ask Test queries for all the sessions. All the Test queries will be answered using the same random bit b that was chosen at the beginning of the experiment. In other words, the keys returned by the Test oracle are either all real or all random. However, in the random case, the same random key is returned for two partnered instances (see the notion of partnering below). The goal of the adversary is to guess the value of the hidden bit b used to answer Test queries. The adversary is said to be successful if it guesses b correctly.
It should be noted that Reveal oracle exists in the FindThenGuess (FTG) model is not available to the adversary in the ROR model. However, since the adversary in FTG model is restricted to asking only a single query to the Test oracle, the ROR security model is actually stronger than the FTG security model. Abdalla et al. demonstrated that proofs of security in the ROR model can be easily translated into proofs of security in the FTG model. For more details, refer to [5].
2.3. Security notions
We give the main definitions in the following. The definition approach of partnering uses session identifications and partner identifications. The session identification is the concatenation of all the messages of the conversation between the client and the gateway instances before the acceptance. Two instances are partnered if they hold the same nonnull session identification.
Definition 1. A client instance C^{ i }and a gateway instance G^{ j }are said to be partnered if the following conditions are met: (1) both C^{ i }and G^{ j }accept; (2) both C^{ i }and G^{ j }share the same session identification; (3) the partner identification for C^{ i }is G^{ j }and vice versa; (4) no instance other than C^{ i }and G^{ j }accepts with a partner identification equal to C^{ i }or G^{ j }.
The adversary is only allowed to perform tests on fresh instances. Otherwise, it is trivial for the adversary to guess the hidden bit b. The freshness notion captures the intuitive fact that a session key is not trivially known to the adversary.
Definition 2. An instance of a client or a gateway is said to be fresh in the current protocol execution if it has accepted.
Semantic security
Consider an execution of the key exchange protocol $\mathcal{P}$ by the adversary $\mathcal{A}$ in which the latter is given access to Execute, Send oracles, as well as to Test oracle calls to fresh instances. The goal of the adversary is to guess the value of the hidden bit b used by the Test oracle. Let Succ denote the event in which the adversary successfully guesses the hidden bit b used by Test oracle.
where maximum is over all$\mathcal{A}$with timecomplexity at most t and using resources at most R (such as the number of oracle queries).
We have the following definition of semantic secure GPAKE protocol, which is the same as in [4].
Definition 4. A GPAKE protocol$\mathcal{P}$is said to be semantically secure if the advantage$Ad{v}_{\mathcal{P},\mathcal{D}}^{akeror}\left(t,R\right)$is only negligibly larger than$kn\u2215\left\mathcal{D}\right$, where n is number of active sessions, and k is a constant.
Note that k = 1 is the best one can hope for since an adversary that simply guesses the password in each of the active sessions has an advantage of $n\u2215\left\mathcal{D}\right$.
Key privacy
In GPAKE protocols, the session key between the client and the gateway is established with the help of the server. In order to reduce the amount of trust one puts into the server, we require that the session key should be even indistinguishable to an honest but curious server who knows all the passwords of the clients. The notion of key privacy with respect to the server was first introduced in [5] to capture this security requirement.
To define the notion of key privacy, we consider a server which knows all the passwords of the clients, and behaves in an honest but curious manner. We give the server access to all the oracles, but restricts the server to testing session keys generated by two oracles. To achieve this aim, we use a new type of TestPair oracle which was first introduced in [5]. The TestPair oracle is defined as follows:

TestPair(C^{ i },G^{ j }): If the client instance C^{ i }and the gateway instance G^{ j }do not share the same key, then return the undefined symbol ⊥. Otherwise, return either the session key established between C^{ i }and G^{ j }if b = 1 or a random key of the same size if b = 0, where b is a hidden bit chosen uniformly at random at the beginning of the experiment defining the key privacy of session keys.
Consider an execution of the key exchange protocol $\mathcal{P}$ by an adversary $\mathcal{A}$ with access to all the passwords held by the server as well as to the Execute, Send, and TestPair oracles. Let Succ denote the event in which the adversary is successful in guessing the hidden bit b used by TestPair oracle. The advantage of an adversary $\mathcal{A}$ in violating the key privacy of the protocol $\mathcal{P}$ in the ROR sense ($Ad{v}_{\mathcal{P},\mathcal{D}}^{akekp}\left(\mathcal{A}\right)$) and the advantage function of $\mathcal{P}\left(Ad{v}_{\mathcal{P},\mathcal{D}}^{akekp}\left(t,R\right)\right)$, when passwords are uniformly drawn from a dictionary $\mathcal{D}$, can be defined as in Definition 3.
Definition 5. A GPAKE protocol$\mathcal{P}$is said to achieve key privacy if the advantage$Ad{v}_{\mathcal{P},\mathcal{D}}^{akekp}\left(t,R\right)$is negligible.
Server password protection
One of the security goals of GPAKE protocol is to prevent the gateway from learning the client's password that is stored in the server. If the adversary interacts q times with the server, then the probability that it can distinguish the true password from a random one in the dictionary should be only negligibly larger than $q\u2215\left\mathcal{D}\right$. However, this does not rule out the possibility of undetectable online dictionary attacks by a malicious gateway. A malicious gateway can iteratively guess a password and verify its guess until it finds the correct password. To resist such attacks, we consider a malicious gateway $\mathcal{A}$ who guesses a password and verifies its guess by interacting with the server. If a failed guess will not be detected by the server, then we say the malicious gateway is successful. Let $Ad{v}_{\mathcal{P},\mathcal{D}}^{akeuoda}\left(\mathcal{A}\right)$ denotes the success probability of the gateway.
Definition 6. A GPAKE protocol$\mathcal{P}$can resist undetectable online dictionary attacks if$Ad{v}_{\mathcal{P},\mathcal{D}}^{akeuoda}\left(\mathcal{A}\right)$is negligibly larger than$kn\u2215\left\mathcal{D}\right$, where n is number of active sessions, and k is a constant.
3. Our GPAKE protocol based on RSA
In this section, we describe our GPAKE protocol based on RSA, and present its security results.
3.1. Description
Define hash functions H_{1},H_{2}, H_{3} : {0,1}* → {0, 1}^{ k }, and H : {0,1}* → Z_{ n }, where k is a security parameter, e.g., k = 160. We assume that H_{1},H_{2},H_{3}, and H are independent random functions in the following.
 1.
The client C sends her public key (n, e) and a random number r _{1} ∈ {0, 1}^{ k }to the gateway G, and G just forwards the message and her RSA public key (n', e') to the authentication server.
 2.
The authentication server S verifies if e is an 80bit prime, and n is an odd integer. S may also verify that the integer n is large enough, e.g., n > 2^{1023}. If e is not an 80bit prime or n is not an odd integer, S rejects; otherwise, S selects three random numbers ${x}_{1},{x}_{2}\in {Z}_{n}^{*}$, and r _{2} ∈ {0, 1}^{ k }. S then computes ${y}_{1}={x}_{1}^{e}$ mod n and ${y}_{2}={x}_{2}^{e}$ mod n, S also computes w = H (pw, x _{2}, C, G, n, e, n', e', r _{1},r _{2},y _{2}) and checks whether gcd (w, n) = 1. If gcd (w, n) = 1, S computes z = y _{1} · w mod n and sends (r _{2},z, y _{2}) to the gateway. Upon receiving (r _{2},z, y _{2}), G sends (n', e', r _{2},z, y _{2}) to C.
 3.
Upon receiving (n', e', r _{2}, z, y _{2}) from G, C verifies if n' is an odd integer and n' is large enough, e.g., n' > 2^{1023}. C selects a random number ${b}_{1}\in {Z}_{{n}^{\prime}}^{*}$. C then decrypts ${x}_{2}={y}_{2}^{d}$ mod n, computes w using her password pw and x _{2}, then checks if w and n are relatively prime. If gcd (w, n) = 1, C decrypts x _{1} = (w ^{1} · z)^{ d }mod n, computes ${c}_{1}={b}_{1}^{{e}^{\prime}}$ mod n'. Finally, C computes μ = H _{1}(x _{1},C, G, n, e, n', e', r _{1},r _{2}, y _{2},z, c _{1}) and sends (c _{1},μ) to G. Upon receiving (c _{1},μ), G selects a random number ${b}_{2}\in {Z}_{n}^{*}$, computes ${c}_{2}={b}_{2}^{e}$ mod n, sends (c _{1},c _{2}, μ) to S.
 4.
S checks whether μ is valid or not. If μ is valid, S computes her authenticator η = H _{2}(x _{1}, C, G, n, e, n', e', r _{1}, r _{2},y _{2}, z, c _{1}, c _{2}). Finally, S sends η to G.
 5.
Upon receiving η, G decrypts ${b}_{1}={c}_{1}^{{d}^{\prime}}$ mod n', sets the session key sk = H _{3}(b _{1}, b _{2}, ID), where ID is the concatenation of all the exchanged messages. G sends η and c _{2} to C.
 6.
C checks whether η is valid or not. If valid, C decrypts ${b}_{2}={c}_{2}^{d}$ mod n and sets the session key to be sk = H _{3}(b _{1}, b _{2}, ID), where ID is the concatenation of all the exchanged messages.
In RSAbased protocols, security against eresidue attacks [3] has to be considered. To void such an eresidue attack, we adopt the approach of [18] and require the public key of the client is an 80bit prime. However, [18] is basically a twofactor protocol, and their main concern is security against replacement attacks. Hence, in this context, we still briefly prove the security against eresidue attacks of our protocol. Suppose the adversary $\mathcal{A}$ generates the RSA parameter (n,e), where e is an 80bit prime and gcd (e, ϕ(n)) = e. Upon receiving (n, e), the authentication server S randomly chooses ${x}_{1},{x}_{2}\in {Z}_{n}^{*}$, computes ${y}_{1}={x}_{1}^{e}$ mod n and ${y}_{2}={x}_{2}^{e}$ mod n, then S calculates w using the password pw and x_{2}. Finally, S sends (r_{2}, z, y_{2}) back to the adversary, where z = y_{1} · w mod n. To mount an eresidue attack, first of all, the adversary should correctly find out the committed value x_{2}. Since ${y}_{2}={x}_{2}^{e}$ mod n, which is equivalent to e·ind_{ g }x_{2} ≡ ind_{ g }y_{2} mod ϕ(n). The congruence has exactly e solutions because gcd (e, ϕ(n)) = e and eind_{ g }y_{2}. The success probability that the adversary correctly find out the committed value is 1/e, which is negligible since e is an 80bit prime.
Remark 1 To resist eresidue attacks, we require that the client use the public key e of an 80bit prime, the server needs to test the primality for the 80bit prime. However, there is no restriction on the gateway's public key e'. This is because the gateway's public key is only used to establish the session key and has nothing to do with the password.
Remark 2 In case of n > 2^{1023}, the computational load for generating an 80bit prime is less than for a single RSA decryption, and the computational load for the primality test of an 80bit prime is less than for a single RSA encryption with an 80bit exponent. Hence, our protocol is quite efficient in computation cost. Furthermore, if we exclude perfect forward secrecy from consideration, we need not to generate them in each session, this further improves the efficiency of our protocol.
3.2. Security
In this section, we prove the security of our protocol within the formal model of security given in Section 2. In our analysis, we assume the intractability of the RSA problem.
RSA assumption [13]
is negligible. In the following, we use Adv^{ rsa }(t) to denote $\mathsf{\text{ma}}{\mathsf{\text{x}}}_{\mathcal{C}}\left\{{Adv}_{\mathcal{C}}^{rsa}\left(t\right)\right\}$, where the maximum is taken over all the polynomialtime algorithms of running time t.
Semantic security
As the following theorem states, our protocol is a secure gatewayoriented passwordbased key exchange protocol as long as the RSA problem is intractable. The proof of security assumes $\mathcal{D}$ to be a uniformly distributed dictionary and of size smaller than 2^{ k }. The proof of Theorem 3.1 can be found in Appendix A.
where Q_{ execute }denotes the number of queries of type Execute, and Q_{ oh }denotes the number of random oracle calls.
Key privacy
As the following theorem shows, our protocol achieves the goal of key privacy as long as the RSA problem is intractable.
The proof of Theorem 3.2 is similar to the proof of Lemma A.1 in Appendix A. The only difference is that in this case the adversary knows the passwords of all the clients. However, this only brings negligible advantage to the adversary since the authenticators and the session keys rely on different random numbers. In order to distinguish the session key from random numbers chosen from {0, 1}^{ k }, the adversary still needs to break RSA. We omit the proof of Theorem 3.2 for simplicity.
Server password protection
As is shown by the following theorem, a malicious gateway cannot do much better than eliminating one password from the list of possible candidates with each interaction with the server. As a result, after q interactions with the server, the advantage of a malicious gateway would be only negligibly larger than $q\u2215\left\mathcal{D}\right$. Furthermore, a failed guess of the malicious gateway will be detected by the authentication server. A malicious gateway cannot iteratively guess a password and verify its guess without being detected. Hence, our protocol can resist undetectable online dictionary attacks. The proof of Theorem 3.3 can be found in Appendix B.
4. Adding client anonymity
Anonymity is one of the most important security goals of protocols on public networks. Many of the privacy problems that arise out of Internet use can be solved using anonymous Internet connections such that a client's actions are unlinkable. Implementing anonymity of clients not only protects their personal information but also reduces the chances of attacks based on impersonation. In this section, we show how to add client anonymity to our protocol.
The basic idea is same as Abdalla et al.'s [6]. We assume that there are many gateways, but the authentication server is unique. In order to add client anonymity, we try to hide the client identity to the authentication server using SPIR [17] protocols. An SPIR protocol allows a client to retrieve an item from a server in possession of a database without revealing which item they are retrieving, and it also allows for the restricting of the number of items a given client may retrieve. When the gateway receives an authorization request from a client, the gateway can run an SPIR protocol with the authentication server, such that the server does not know the real identity of the client and the gateway only gets the answer to the actual client. More precisely, the authentication server can be seen as a dynamic database. For each authorization request, the authentication server computes the answers for all the possible clients, and the gateway retrieves the one it is interested in. At the end of the SPIR protocol, the authentication server does not know which answer the gateway gets and the gateway will not get more than the number of the values it is allowed to retrieve.
Our RSAbased GPAKE can be efficiently implemented with any good SPIR protocol. Specifically, we assume that each client owns a password indexed by i, and the server manages a database of size N, which contains all the passwords for each client. In order to introduce anonymity to the protocol in Section 3, we do as follows: upon receiving of a Sendquery with input (C_{ j }, n, e, r_{1}), the gateway conceals the real identity of the client and sends (n, e, n', e', r_{1}) to the server. Upon receiving (n, e, n', e', r_{1}), the server dynamically generates a database by computing the answers for each message (C_{ i }, n, e, n', e', r_{1}), and thus for all the possible clients C_{ i }, since it does not know which one is interacting with the gateway. More precisely, the server chooses ${r}_{2}\in {\left\{0,1\right\}}^{k},{x}_{1}\in {Z}_{n}^{*}$, and for each C_{ i }, the server also chooses ${x}_{2i}\in {Z}_{n}^{*}$, computes ${y}_{1}={x}_{1}^{e}$ mod n and ${y}_{2i}={x}_{2i}^{e}$ mod n. The dynamic database consists of all the blocks Bi = (r_{2}, z_{ i }, y_{2i}), where z_{ i }= y_{1} · wi mod n and w_{ i }= H (pw_{ i }, x_{2i}, C_{ i },G, n, e, n', e', r_{1}, r_{2}, y_{2i}). Then, the gateway runs the SPIR protocol to get the correct B_{ j }, while preserving the anonymity of the client. The remains are the same as the proposed GPAKE protocol except that the values μ and η are computed as H_{1}(x_{1}, G, n, e, n', e', r_{1}, r_{2}) and H_{2}(x_{1},G, n, e, n', e', r_{1}, r_{2}, c_{1}, c_{2}), respectively.
It is worth pointing out that achieving client anonymity, our protocol still can resist the undetectable online dictionary attack in the sense that a failed guess of the malicious gateway will be detected by the server. To impersonate a client successfully, the malicious gateway needs recover y_{1} using the guessed password of the victim client and then obtains x_{1} by decrypting y_{1}. If the guessed password is not correct, then the value μ is not valid and the server will detect the attack, and then some measures should be taken to protect the passwords of the clients.
5. Conclusion
In this article, we investigate the design of RSAbased GPAKE protocols. First, we develop a new GPAKE protocol using RSA publickey cryptosystem. The proposed protocol is secure against eresidue attacks. Then, we provide a formal security analysis of our protocol under the RSA assumption and the random oracle model. We also show that our protocol is secure against undetectable online dictionary attacks. Finally, we investigate whether or not such a protocol can achieve both client anonymity and resistance to undetectable online dictionary attacks. We give an affirmative answer by adding client anonymity to our basic protocol.
Appendix A. Proof of Theorem 3.1
We prove Theorem 3.1 using similar techniques as described in [19]. We define a series of hybrid experiments. In each experiment, we modify the way session keys are chosen for instances involved in protocol execution. We start by choosing random session keys for instances for which the Execute oracle is called. Then, we continue to choose random session keys for instances for which the Send oracle is called. These instances are gradually changed over five hybrid experiments and in the last experiment, all the session keys are selected uniformly at random. Thus, the adversary $\mathcal{A}$ cannot distinguish them from random numbers. We denote these hybrid experiments by P_{0}, P_{1}, ..., P_{4} and by $Adv\left(\mathcal{A},{P}_{i}\right)$ the advantage of $\mathcal{A}$ when participating in experiment P_{ i }.
Experiment P_{0}
Each random oracle H_{ i }(or H) maintains a list of inputoutput pairs (q_{0}, r_{0}), (q_{1}, r_{1})···. On a new input q, H_{ i }(or H) checks if q was queried before. If there exists q_{ i }in the list such that q = q_{ i }, then the random oracle returns the corresponding r_{ i }as its reply. If q is not in the list, the random oracle chooses a random number r, returns r as its reply and adds the pair (q, r) to its list. It is clear that $Adv\left(\mathcal{A}\right)=Adv\left(\mathcal{A},{P}_{0}\right)$.
Experiment P_{1}
In this experiment, the Execute oracle is modified so that the session keys of instances for which Execute is called are selected uniformly at random, that is, if the oracle Execute (C^{ i }, G^{ j }) is called, then the session key sk is set equal to a random number selected from {0, 1}^{ k }, rather than the output of the random oracle H_{3}. The following lemma shows that modifying the Execute oracle in this way affects the advantage of $\mathcal{A}$ by a negligible value.
Lemma Appendix A.1
where Q_{ oh }denotes the number of random oracle calls, and t is the running time of$\mathcal{A}$.
Proof. We prove this lemma by showing how any advantage that $\mathcal{A}$ has in distinguishing P_{1} from P_{0} can be used to break RSA. In experiment P_{0}, the session key is the output of the random oracle H_{3} on the input (b_{1}, b_{2}, ID), where ID is the concatenation of all the exchanged messages. If the adversary does not know b_{1} and b_{2}, she cannot distinguish the output of H_{3} from a random number uniformly selected from {0, 1}^{ k }. Hence, the adversary $\mathcal{A}$ can distinguish P_{1} and P_{0} if and only if $\mathcal{A}$ can recover the integers b_{1} and b_{2}. Let ${p}_{{b}_{1}}\left({p}_{{b}_{2}}\right)$ denote the probability that $\mathcal{A}$ recovers the integer b_{1} (b_{2}).
For a easier analysis, we let the adversary win if the adversary recovers the integer b_{2}. To bound ${p}_{{b}_{2}}$, we consider the following two games G_{1} and G_{2}.
Game G_{1}
The adversary $\mathcal{A}$ carries out an honest execution between the instances C^{ i }and G^{ j }as the protocol description. When the game ends, the adversary $\mathcal{A}$ outputs her guess of the integer b_{2}.
Game G_{2}
This game is similar to game G_{1} except that we use private oracles when we compute w, μ, and η.
Let ${p}_{{b}_{2}}\left({G}_{1}\right)$ denote the probability that $\mathcal{A}$ makes a correct guess of b_{2} in game G_{1}. Likewise, ${p}_{{b}_{2}}\left({G}_{2}\right)$ denote the probability that ${p}_{{b}_{2}}={p}_{{b}_{2}}\left({G}_{1}\right)$ makes a correct guess of b_{2} in game G_{2}. It is clear that $\mathcal{A}$. Let AskH denote the event that $\mathcal{A}$ queries random oracle H on (pw, x_{2}, C, G, n, e, n', e', r_{1}, r_{2}, y_{2}). Let AskH_{1,2} denote the event that $\mathcal{A}$ queries random oracle H_{1} on (x_{1}, C, G, n, e, n', e', r_{1}, r_{2}, y_{2},z, c_{1}) or H_{2} on (x_{1}, C, G, n, e, n', e', r_{1}, r_{2}, y_{2}, z, c_{1}, c_{2}), while AskH does not happen.
Let Q_{ oh }denote the number of random oracle calls to H_{1} and H_{2} by $\mathcal{A}$ In the following, we bound the probabilities of events AskH and AskH_{1,2}, and also show that ${p}_{{b}_{1}}\left({G}_{2}\right)\le Ad{v}^{rsa}\left(O\left(t\right)\right)$.
Before we present the experiments P_{2}, P_{3}, and P_{4}, we describe Send oracles which an active adversary $\mathcal{A}$ uses.

Send_{0}(C^{ i }): the instance C^{ i }selects a pair of RSA public/private keys e, d, n, and a random number r_{1} ∈ {0, 1}^{ k }. It returns C, n, e, and r_{1} to the adversary $\mathcal{A}$.

Send_{1}(G^{ j }, C, n, e, r_{1}): the instance G^{ j }selects a pair of RSA public/private keys (e', d', n'), sends (C, n, e, n', e', r_{1}) to the server. G^{ j }obtains (r_{2}, z, y_{2}) as the reply of the server. It returns (n', e', r_{2}, z, y_{2}) to the adversary $\mathcal{A}$.

Send_{2}(C^{ i }, n', e', r_{2}, z, y_{2}): the instance C^{ i }verifies if n' is big enough, i.e., n' > 1023. Then, C^{ i }selects a random number ${b}_{1}\in {Z}_{{n}^{\prime}}^{*}$, and decrypts ${x}_{2}={y}_{2}^{d}$ mod n, then computes w using her password pw and x_{2}, checks if w and n are relatively prime. If gcd (w, n) = 1, C^{ i }decrypts x_{1} = (w^{1}·z)^{ d }mod n, computes ${c}_{1}={b}_{1}^{{e}^{\prime}}$ mod n'. Finally, C^{ i }computes μ = H_{1}(x_{1}, C, G, n, e, n', e', r_{1}, r_{2}, y_{2}, z, c_{1}) and returns (c_{1}, μ) to the adversary $\mathcal{A}$.

Send_{3}(G^{ j },c_{1},μ): the instance G^{ j }selects a random number ${b}_{2}\in {Z}_{n}^{*}$, computes ${c}_{2}={b}_{2}^{e}$ mod n, sends (c_{1},c_{2},μ) to S. G^{ j }obtains η as the reply of the server. It decrypts ${b}_{1}={c}_{1}^{{d}^{\prime}}$ mod n', sets the session key sk = H_{3}(b_{1}, b_{2}, ID), where ID is the concatenation of all the exchanged messages. It returns η and c_{2} to the adversary $\mathcal{A}$.

Send_{4}(C^{ i }, η, c_{2}): the instance C^{ i }checks whether η is valid or not. If η is invalid, it rejects. Otherwise, it decrypts ${b}_{2}={c}_{2}^{d}$ mod n, and computes sk = H_{3}(b_{1}, b_{2}, ID), where ID is the concatenation of all the exchanged messages.
A message is said to have been oraclegenerated if it was output by an instance; otherwise, it is said to have been adversariallygenerated. A message generated by instance U^{ i }is said to have been U^{ i }oraclegenerated.
Experiment P_{2}
In this experiment, an instance G^{ j }receives a C^{ i }oraclegenerated message (C, n, e, r_{1}) in a Send_{1} oracle call. If both C^{ i }and G^{ j }accept, they are given the same random session keys sk ∈ {0, 1}^{ k }, and if G^{ j }accepts but C^{ i }does not accept, then only G^{ j }receives a random session key, and no session key is defined for C^{ i }.
Lemma Appendix A.2
where t is the running time of$\mathcal{A}$.
Proof. Assume that G^{ j }returns (G, n', e', r_{2}, z, y_{2}) to the adversary according to the description of the protocol after receiving a C^{ i }oraclegenerated message (C, n, e, r_{1}) in a Send_{1} oracle call. Since the RSA public key (e, n) was generated by C^{ i }, not by $\mathcal{A}$, the private key d is not known to $\mathcal{A}$. As shown in the proof of Lemma A.1, the probability for $\mathcal{A}$ to recover the random number x_{1} is upper bounded by Adv^{ rsa }(O (t)). Hence, except for a probability as small as Adv^{ rsa }(O (t)), G^{ j }has received a C^{ i }oraclegenerated message in a Send_{3} oracle when G^{ j }accepts. Similarly, if C^{ i }accepts, then it has received a G^{ j }oraclegenerated message in a Send_{4} oracle call. If both C^{ i }and G^{ j }accept, then they share the same session key which is equal to the output of the random oracle H_{3} on (b_{1}, b_{2}, ID), where ID is the concatenation of all the exchanged messages. Hence, the modification of the session keys of C^{ i }and G^{ j }affects the adversary's advantage by a value as small as Adv^{ rsa }(O (t)). Since $\mathcal{A}$ makes Q_{ send }oracle calls of type Send to different instances, $\mathcal{A}$'s advantage in distinguishing between P_{2} and P_{1} is upper bounded by Q_{ send }Adv^{ rsa }(O(t)).
Experiment P_{3}
In this experiment, an instance C^{ i }receives a G^{ j }oraclegenerated message (n', e', r_{2}, z, y_{2}) in a Send_{2} oracle call, while the instance G^{ j }has received a C^{ i }oraclegenerated message (C, n, e, r_{1}) in a Send_{1} oracle call. If both C^{ i }and G^{ j }accept, then they are given the same random session keys sk ∈ {0, 1}^{ k }. It is clear that the advantage of $\mathcal{A}$ in P_{3} is the same as its advantage in P_{2}.
Lemma Appendix A.3
Experiment P_{4}
In this experiment, we consider an instance C^{ i }(or G^{ j }) that receives an adversariallygenerated message in a Send_{2} (or Send_{1}) oracle call. In this case, if C^{ i }(or G^{ j }) accepts, then the experiment is halted, and the adversary is said to have succeeded. This certainly improves the probability of success of the adversary.
Lemma Appendix A.4
At this point, we have given random session keys to all the accepted instances that receive Execute or Send oracle calls. We next proceed to bound the adversary's success probability in P_{4}. The following lemma shows that the adversary's success probability in the experiment P_{4} is negligible.
Lemma Appendix A.5
where Q_{ oh }denotes the number of random oracle calls, and t is the running time of$\mathcal{A}$.
Proof. Let ${Q}_{sen{d}_{1}}$ and ${Q}_{sen{d}_{2}}$ denote the number of Send_{1} and Send_{2} oracle calls made by the adversary in experiment P_{4}, respectively. We consider the following two cases:
Case 2: Consider an instance G^{ j }receives an adversariallygenerated message (C, n, e, r_{1}) in a Send_{1} oracle, where n is an odd integer, and e is odd prime. The instance G^{ j }sends (C, n, e, n, e, r_{1}) to the server. The server replies (r_{2}, z) according to the protocol description. To succeed in this case, $\mathcal{A}$ must send back a number μ which is equal to the output of the random oracle H_{1} on (x_{1}, C, G, n, e, n', e', r_{1}, r_{2}, z, c_{1}). Without the knowledge of x_{1}, the probability for $\mathcal{A}$ to generate μ is just 2^{k}. Let ${p}_{{x}_{1}}$ denote the probability that $\mathcal{A}$ can recover the integer x_{1}.
Note that (n, e) was generated by $\mathcal{A}$. If gcd (e, ϕ(n)) = 1, then $\mathcal{A}$ can compute w = H (pw', x_{2}, C, G, n, e, n', e', r_{1}, r_{2}, y_{2}) using a guessing password pw'. Then, congruence $z={x}_{1}^{e}\cdot w$ mod n has a unique solution because gcd (e, ϕ(n)) = 1. If $\mathcal{A}$ guesses the correct password pw = pw', then $\mathcal{A}$ can obtain x_{1} correctly. If $\mathcal{A}$ does not guess the correct password, then $\mathcal{A}$ will not succeed. On the other hand, if gcd (e, ϕ(n)) ≠ 1, since we require that e is an 80bit prime, then the congruence ${y}_{2}={x}_{2}^{e}$ mod n has e solutions. In order to recover the correct x_{1}, the adversary needs to find out the correct x_{2}. As is shown in Section 3, the probability to find out the correct x_{2} is 1/2^{80}, which is negligible.
This completes the proof of Lemma A.5.
By combining Lemma A.1 to Lemma A.5, we get the announced result.
Appendix B. Proof of Theorem 3.3
Consider a malicious gateway $\mathcal{A}$ generates a message (C, n, e, n', e', r_{1}). The malicious gateway sends the message to the server. The server replies (r_{2}, z) according to the protocol description. To succeed in this case, the malicious gateway must send back a number μ which is equal to the output of the random oracle H_{1} on (x_{1}, C, G, n, e, n', e', r_{1}, r_{2}, y_{2}, z, c_{1}). Otherwise, the online impersonation attack will be detected by the authentication server. Without the knowledge of x_{1}, the probability for $\mathcal{A}$ to generate μ is just 2^{k}.
Let ${p}_{{x}_{1}}$ denote the probability that the malicious gateway can recover the integer x_{1}.
Note that (n, e) was generated by $\mathcal{A}$. If gcd (e, ϕ(n)) = 1, then $\mathcal{A}$ can compute w = H (pw', x_{2}, C, G, n, e, n', e', r_{1}, r_{2}, y_{2}) using a guessing password pw'. Then, congruence $z={x}_{1}^{e}\cdot w$ mod n has a unique solution because gcd (e, ϕ(n)) = 1. If $\mathcal{A}$ guesses the correct password pw = pw', then $\mathcal{A}$ can obtain x_{1} correctly. If $\mathcal{A}$ does not guess the correct password, then $\mathcal{A}$ will not succeed. On the other hand, if gcd (e, ϕ(n)) ≠ 1, since we require that e is an 80bit prime, then the congruence ${y}_{2}={x}_{2}^{e}$ mod n has e solutions. In order to recover the correct x_{1}, the adversary needs to find out the correct x_{2}. As is shown in Section 3, the probability to find out the correct x_{2} is 1/2^{80}, which is negligible.
Declarations
Acknowledgements
The authors would like to thank the anonymous referees for their helpful comments. This study was supported by the National High Technology Research and Development Program of China (No. 2009AA01Z417) and Key Scientific and Technological Project of Henan Province (No. 092101210502).
Authors’ Affiliations
References
 Ding Y, Horster P: Undetectable online password guessing attacks. ACM Oper Syst Rev 1995, 29: 7786. 10.1145/219282.219298View ArticleGoogle Scholar
 Bellovin SM, Merritt M: Encrypted key exchange: passwordbased protocols secure against dictionary attacks. IEEE Symp on Security and Privacy 1992 1992, 7284.View ArticleGoogle Scholar
 Patel S: Number theoretic attacks on secure password schemes, in. In Proc IEEE Symposium on Security and Privacy. Oakland, CA; 1997.Google Scholar
 Abdalla M, Chevassut O, Fouque PA, Pointcheval D: A simple threshold authenticated key exchange from short secrets. Volume 3788. Springer, Heidelberg; 2005:566584.Google Scholar
 Abdalla M, Fouque P, Pointcheval D: Passwordbased authenticated key exchange in the threeparty setting. Volume 3386. Springer, Heidelberg; 2005:6584.Google Scholar
 Abdalla M, Izabachene M, Pointcheval D: Anonymous and transparent gatewaybased passwordauthenticated key exchange. Volume 5339. Springer, Heidelberg; 2008:133148.Google Scholar
 Abdalla M, Pointcheval D: Interactive DiffieHellman assumptions with applications to passwordBased Authentication. Volume 3570. Springer, Heidelberg; 2005:341356.Google Scholar
 Byun JW, Lee DH, Lim JI: Security analysis and improvement of a gatewayoriented passwordbased authenticated key exchange protocol. IEEE Commun Lett 2006, 10(9):683685. 10.1109/LCOMM.2006.1714545View ArticleGoogle Scholar
 Bellare M, Pointcheval D, Rogaway P: Authenticated key exchange secure against dictionary attacks. Volume 1807. Springer, Heidelberg; 2000:139155.Google Scholar
 Lucks S: Open key exchange: how to defeat dictionary attacks without encrypting public keys. In Proc of Security Protocol Workshop. Volume 1361. Springer, Heidelberg; 1997:7990. LNCSView ArticleGoogle Scholar
 MacKenzie P, Patel S, Swaminathan R: Passwordauthenticated key exchange based on RSA. Volume 1976. Springer, Heidelberg; 2000:599613.Google Scholar
 Zhang MX: New approaches to password authenticated key exchange based on RSA. Volume 3329. Springer, Heidelberg; 2004:230244.Google Scholar
 Park S, Nam J, Kim S, Won D: Efficient passwordauthenticated key exchange based on RSA. Volume 4377. Springer, Heidelberg; 2007:309323.Google Scholar
 Youn TY, Park YH, Kim C, Lim J: Weakness in a RSAbased password authenticated key exchange protocol. Inf Process Lett 2008, 108: 339342. 10.1016/j.ipl.2008.06.002MathSciNetView ArticleMATHGoogle Scholar
 Shim KA: Cryptanalysis and enhancement of modified gatewayoriented passwordbased authenticated key exchange protocol. IEICE Trans Fund 2008, E91A(12):38373839. 10.1093/ietfec/e91a.12.3837View ArticleGoogle Scholar
 Yoon Ej, Yoo KY: An optimized gatewayoriented passwordbased authenticated key exchange protocol. IEICE Trans Fund 2010, E93A(4):850853. 10.1587/transfun.E93.A.850MathSciNetView ArticleGoogle Scholar
 Lincoln L: Symmetric private information retrieval via homomorphic probabilistic encryption. PhD thesis.2006. [http://www.cs.rit.edu/7Elbl6598/thesis/Lincolnfulldocument.pdf]Google Scholar
 Shin S, Kobara K, Imai H: An RSAbased leakageresilient authenticated key exchange protocol secure against replacement attacks, and its extensions. IEICE Trans Fund 2010, E93A(6):10861101. 10.1587/transfun.E93.A.1086View ArticleGoogle Scholar
 Zhang MX: New approaches to password authenticated key exchange based on RSA.[http://eprint.iacr.org]
Copyright
This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.