Password-only authenticated three-party key exchange proven secure against insider dictionary attacks.

While a number of protocols for password-only authenticated key exchange (PAKE) in the 3-party setting have been proposed, it still remains a challenging task to prove the security of a 3-party PAKE protocol against insider dictionary attacks. To the best of our knowledge, there is no 3-party PAKE protocol that carries a formal proof, or even definition, of security against insider dictionary attacks. In this paper, we present the first 3-party PAKE protocol proven secure against both online and offline dictionary attacks as well as insider and outsider dictionary attacks. Our construct can be viewed as a protocol compiler that transforms any 2-party PAKE protocol into a 3-party PAKE protocol with 2 additional rounds of communication. We also present a simple and intuitive approach of formally modelling dictionary attacks in the password-only 3-party setting, which significantly reduces the complexity of proving the security of 3-party PAKE protocols against dictionary attacks. In addition, we investigate the security of the well-known 3-party PAKE protocol, called GPAKE, due to Abdalla et al. (2005, 2006), and demonstrate that the security of GPAKE against online dictionary attacks depends heavily on the composition of its two building blocks, namely a 2-party PAKE protocol and a 3-party key distribution protocol.

1. Introduction

Key exchange protocols (also known as key establishment protocols) enable two or more parties communicating over a public network to establish a shared secret key. This secret key, called a session key, is then used for building a confidential or integrity-preserving communication channel between the involved parties. Typically, a key exchange protocol is integrated with an authentication mechanism so that each party can ensure that the session key is in fact shared with the intended parties and not with an impostor. Achieving authenticated key exchange (AKE) inevitably requires some secret information to be preestablished between the parties during an initialization phase. Password-only authenticated key exchange (PAKE) protocols, for example, are designed to work when the preestablished secret information for authentication is only a human-memorable password.

The design of secure PAKE protocols continues to be a subject of active research. A major challenge in designing a PAKE protocol is to prevent dictionary attacks, in which an attacker exhaustively enumerates all possible passwords to find out the correct password. The difficulty of designing PAKE protocols secure against dictionary attacks is compounded in the 3-party setting, in which two clients wishing to establish a session key share their individual passwords only with an authentication server but not with any other client. A 3-party PAKE protocol must prevent potential dictionary attacks by a malicious client, who is registered with the server and thus is able to set up normal protocol sessions with other clients. (Throughout the paper, we will use the term “insider attacks” to refer to attacks mounted by a registered (malicious) client and use the term “outsider attacks” to refer to attacks mounted by a nonregistered party.) Indeed, a cursory review of the literature suggests that the majority of attacks mounted against 3-party PAKE protocols fall into the category of insider dictionary attacks; see, for example, Section 2 as well as [1-6].

The difficulties of obtaining a high level of assurance in the security of almost any new, or even existing, protocol are well illustrated with examples of errors found in many such protocols years after they were published. A widely accepted approach is to use a deductive reasoning process whereby the emphasis is placed on a proven reduction from the problem of breaking the protocol to another problem believed to be hard. Such an approach for key exchange protocols was made popular by Bellare and Rogaway [7] who provide the first formal definition for a model of adversary capabilities with an associated definition of the indistinguishability-based security. This model has been further revised several times, and one of the more recent revisions is the real-or-random () model proposed by Abdalla et al. [8, 9] for PAKE protocols. They also proposed a generic construction of a 3-party PAKE protocol that allows existing provably secure 2-party password-based key exchange and 3-party symmetric key distribution protocols to be plugged and played in a modular approach and yet remain secure [8, 9].

To date, a number of 3-party PAKE protocols have been presented with a formal proof of security [1, 8–17]. Most of these protocols were proven secure only in a restricted model, in which the adversary is not allowed to corrupt protocol participants [1, 8–10, 12–14]. In other words, these protocols were not proven secure against insider attacks including dictionary attacks conducted by insiders. Some protocols [11, 13] were subsequently found to be flawed [6, 18] and several protocols [15, 16] were proven secure only in a model that cannot capture (both insider and outsider) online dictionary attacks. Although protocols such as those of [19, 20] claimed to be provably secure against dictionary attacks of any kind, these protocols assume a “hybrid” 3-party setting where a server's public key is required in addition to passwords (see [21-27] for other protocols designed to work in a hybrid setting). To the best of our knowledge, no 3-party PAKE protocol has been proven secure against insider dictionary attacks.

We regard the contributions of this paper to be threefold.

Contribution 1. We present the first 3-party PAKE protocol, a hashed variant of the protocol of  [. Similar to the protocols of [1, 8, 9], our proposed protocol is generic in the sense that it can be constructed from any 2-party AKE protocol. Our construct can be viewed as a protocol compiler that transforms any 2-party AKE protocol into a 3-party AKE protocol with 2 more rounds of communication. If the given 2-party protocol is password-only authenticated, then the 3-party protocol output by the compiler will also be password-only authenticated. We prove the security of our construct in the random oracle model under the gap Diffie-Hellman (GDH) assumption; see Section 4.

Contribution 2. We offer a simple and intuitive approach of capturing dictionary attacks in the widely accepted model of Bellare et al. [28]. First, we clarify the relationship between the indistinguishability-based security of session keys and the password security against dictionary attacks. This observation allows us to exclude offline dictionary attacks from our consideration once we have proved the indistinguishability-based security. We then introduce a new security definition to capture UD online dictionary attacks. We claim that our approach, when compared to those of [19, 20] (where a separate security definition is introduced to capture both UD online and offline dictionary attacks), provides a more intuitive and simpler way of proving security against dictionary attacks (see Section 3).

The indistinguishability-based security property in the Bellare-Pointcheval-Rogaway model implies security against (both insider and outsider) offline dictionary attacks. We demonstrate this by showing that a protocol cannot achieve the indistinguishability-based security if it is not secure against an offline dictionary attack (see Section 3.3).

The indistinguishability-based security property does not imply security against undetectable online dictionary attacks (referred to as “UD online dictionary attacks” in the remainder of this paper). It is important to note that a protocol may be insecure against a UD online dictionary attack but it can still achieve the indistinguishability-based security (see Section 3.3).

Contribution 3. We revisit the generic protocol GPAKE of Abdalla et al. [8, 9] to provide a detailed analysis of its security against UD online dictionary attacks. (We note that the work of Wang and Hu [1] has only provided a sketch of an insider UD online dictionary attack against GPAKE.) GPAKE is parameterized with a 2-party PAKE protocol 2PAKE and a 3-party key distribution protocol 3KD. We found that the security of GPAKE against both insider and outsider UD online dictionary attacks depends heavily on the security properties provided by 2PAKE and 3KD. For example, we can launch an insider UD online dictionary attack against the protocol GPAKE if neither 2PAKE nor 3KD provides client-to-server authentication. An outsider UD online dictionary attack can also be mounted under the same condition in addition to the condition that 2PAKE provides server-to-client authentication (see Section 2 for details).

2. Undetectable Online Dictionary Attacks against GPAKE

This section presents a comprehensive analysis of the security of the GPAKE protocol [8, 9] against UD online dictionary attacks. Our analysis shows that (1) GPAKE relies its security against UD online dictionary attacks on how its building blocks are instantiated and (2) the attacks could be mounted not only by a registered client (an insider) but also by a nonregistered party (an outsider). After conducting the security analysis, we suggest possible combinations of the instantiations that allow the GPAKE protocol to avoid the attacks.

2.1. A Review of GPAKE

The GPAKE protocol is constructed using a combination of three building blocks: (1) a 2-party PAKE protocol 2PAKE, (2) a 3-party key distribution protocol 3KD, and (3) a message authentication code- (MAC-) based Diffie-Hellman key exchange protocol MDH. Let G be a finite cyclic group generated by an element g; and let Σ = (Mac, Ver) be a MAC scheme where Mac and Ver are the MAC generation and MAC verification algorithms, respectively. The security of MDH relies on the hardness of the decisional Diffie-Hellman (DDH) problem in G and on the security of the underlying MAC scheme Σ against chosen message attacks. S represents a trusted server which registers clients and, during the registration, each client shares their individual password secretly with S. Suppose that A and B are two registered clients who wish to establish a session key and pw and pw are the passwords of A and B, respectively.

2.1.1. Description

A high-level depiction of GPAKE is given in Figure 1 and its brief description follows. First, A (and B) and S establish a shared high-entropy key, k (and k , resp.), by running the 2-party PAKE protocol, 2PAKE. Then, S generates a MAC key, k , and distributes k to both A and B by running the 3-party key distribution protocol 3KD which takes k and k as input. A session key, sk = g , will be established between A and B after running the MAC-based Diffie-Hellman key exchange protocol MDH which takes k as an input.

Figure 1

GPAKE: Abdalla et al.'s generic 3-party PAKE protocol [8, 9].

2.1.2. Instantiations

Abdalla et al. [8, 9] suggested several practical and provably secure protocols that can be used in the instantiation of the 2-party protocol 2PAKE. Among them are the KOY protocol [29, 30] and its generalization [31], the PAK suite [32], and other protocols based on encrypted key exchange (EKE) of Bellovin and Merritt [33] (e.g., Bresson et al.'s OMDHKE protocol [34]). For the instantiation of 3KD, any particular choice that is secure with respect to a single session will do since the symmetric keys given as input to 3KD differ from session to session. Bellare and Rogaway's 3PKD protocol [35], for example, was suggested as a possible choice. The MAC scheme used in MDH can be instantiated with the HMAC [36] and the CBC MAC.

2.2. An Insider Attack

Let us consider, for example, the case where 2PAKE and 3KD are instantiated with the PPK protocol [32] and with the 3PKD protocol [35], respectively. In this case, a malicious client B who is registered with the server, S, can mount a UD online dictionary attack against any other client, for example, A. It is important to note that we do not require either of the protocols, PPK (see Figure 2) and 3PKD (see Figure 3), to be insecure and, in fact, we assume that both protocols are secure.

Figure 2

The PPK protocol [32].

Figure 3

The 3PKD protocol [35].

2.2.1. The PPK Protocol

Let G be a finite cyclic group of order q, and let g be a generator of G. The three hash functions used are G 1 : {0,1}* → G, G 2 : {0,1}* → G, and H : {0,1}* → {0,1}, where l is the length of the session key. pw denotes A's password known only to A and denotes the password verifiers held by S. The function acceptable  (∗) returns true, if and only if ∗ ∈ G (or, when G is defined as a (proper) subgroup of a group ). The session key k is computed as . We observe that two messages and are independent and thus the protocol can be easily modified to run in a single round.

2.2.2. The 3PKD Protocol

The cryptographic tools used in 3PKD include (1) a symmetric encryption scheme consisting of a pair of encryption/decryption algorithms (Enc, Dec) and (2) a MAC scheme consisting of a pair of MAC generation/verification algorithms (Mac, Ver). The protocol runs between a trusted server, S, and two clients, A and B. A (and B) and S are assumed to have preestablished a 2κ-bit secret k = k enc||k mac (resp., k = k enc||k mac). The protocol, depicted in Figure 3, begins by having A choosing a random κ-bit challenge r and sending it to client B. B also chooses a random κ-bit challenge r and sends 〈r , r 〉 to S. Upon receiving 〈r , r 〉, S generates a session key k which he will distribute. S then encrypts k under A's encryption key k enc (resp., B's encryption key k enc) to get ciphertext α (resp., α ). Then, S computes μ (resp., μ ), the MAC under key k mac (resp., k mac) of the string A||B||r ||α (resp. A||B||r ||α ). Then, S sends 〈α , μ 〉 and 〈α , μ 〉 to A and B, respectively. A and B accept the session key k if and only if their received MAC is valid.

In order for PPK and 3PKD to be used together, the session keys generated by PPK need to be at least 2κ-bit long.

2.2.3. One Possible Attack Scenario

The malicious client, B, can mount the following UD online dictionary attack against another client, A.

Step 1 (running PPK).

B  begins by initiating two concurrent runs, R1 & R2, of the PPK protocol.

In the (dishonest) run R1, B impersonating A makes a guess (denoted by pw ′) on A's actual password, pw , selects a random x ∈ Z , computes , and sends the server S a fabricated message . Since , S will respond with the message . After obtaining , B computes a key , where and . We let k ′ = k′ enc||k′ mac.

In the (honest) run R2, B honestly performs all the operations as per protocol specification and establishes the key, k = k enc||k mac.

Step 2 (running 3PKD).

Once R1 & R2 are completed, B proceeds to run the protocol 3PKD by sending the server S two random challenges r and r (selected as specified by the protocol). S will respond to the random challenges with two messages 〈α , μ 〉 and 〈α , μ 〉. After obtaining these two messages, B recovers the keys  k ′ = Dec (α ) and  k = Dec (α ).

Step 3 (verifying the password guess).

B verifies the correctness of pw ′ by checking that k ′ is equal to k . If they are equal, pw ′ is the correct password with an overwhelming probability. Otherwise, it means that pw ′ ≠ pw .

2.3. An Outsider Attack

We now consider the case where 2PAKE and 3KD are instantiated with the OMDHKE protocol [34] and with the 3PKD protocol [35], respectively. Although OMDHKE (see Figure 4) is largely similar to PPK, there is a marked difference between the two. OMDHKE provides server-to-client authentication while PPK focuses on implicit key authentication.

Figure 4

The OMDHKE protocol [34].

2.3.1. The OMDHKE Protocol

Let G be a finite cyclic group generated by an element g of prime order q. The hash functions used are G : {0,1}* → G, H : {0,1}* → {0,1}, and F : {0,1}* → {0,1}, where l is the length of the session key and f is the length of the authenticator Auth. Unlike the PPK protocol described in Figure 2, both A and S have a shared password, pw . The protocol starts when A chooses a random x ∈ Z , computes X = g , PW = G(pw ), and , and sends to S. Upon receiving the message from A, S computes PW = G(pw ) and , chooses a random z ∈ Z , and computes Z = g , K = X , and . Then S sends 〈S, Z, Auth〉 to A and computes the session key, . A computes K = Z , verifies Auth, and computes the session key if the verification succeeds.

Note that, in OMDHKE, server-to-client authentication is achieved via the authenticator Auth sent by S to A.

2.3.2. One Possible Attack Scenario

We now demonstrate how C, a malicious adversary who is not registered with the server, can mount a UD online dictionary attack against two registered clients, A and B.

Step 4 (running OMDHKE).

C initiates two concurrent runs, R1 & R2, of the protocol OMDHKE.

In the (dishonest) run R1, C impersonating A makes a guess (denoted by pw ′) on A's password, pw , chooses a random x ∈ Z , computes PW ′ = G(pw ′) and , and sends the fabricated message to S. C will then receive the response, 〈S, Z, Auth〉, from S as per protocol specification.

In the (dishonest) run R2, C proceeds as per R1 but impersonating B (instead of A) and making a guess (denoted as pw ′) on B's password, pw . Let Auth denote the authenticator received (in response) from  S.

Step 5 (running 3PKD).

After R1 & R2 are completed, C runs the 3PKD protocol with S while impersonating both A and B. (This step provides no useful information to C but is required for the attack to go undetected.)

Step 6 (verifying the password guess).

C can then verify the correctness of pw ′ by computing and then checking if Auth′ is equal to Auth. If they are equal, pw ′ is the correct password (with an overwhelming probability). Otherwise, C knows that pw ′ ≠ pw . Similarly, the correctness of pw ′ can be verified using the received Auth.

2.4. Discussion

The insider attack described in Section 2.2 works because neither PPK nor 3PKD provides client-to-server authentication. Indeed, the same attack also works if we replace the PPK protocol with the OMDHKE protocol [34], the EKE2 protocol [28], or the SPAKE protocol [37]. In other words, the GPAKE protocol becomes vulnerable to the insider attack when both 2PAKE and 3KD are instantiated with a protocol that does not provide client-to-server authentication. The outsider attack described in Section 2.3 works under the same circumstance but additionally exploits the fact that the OMDHKE protocol provides server-to-client authentication.

Informally, both attacks can be prevented if one of the two protocols, 2PAKE or 3KD, is instantiated with a protocol that provides client-to-server authentication. We observe that a typical 3-party key distribution protocol is not expected to provide client-to-server authentication, and hence, we suggest that the countermeasure targets the instantiation of 2PAKE. While some might also suggest that a round-optimal protocol (i.e., a protocol that runs in a single round) should be used in the instantiation of 2PAKE to achieve better efficiency, we caution against this as no round-optimal 2-party PAKE protocol is known to provide client-to-server authentication and achieve security against offline dictionary attacks.

3. Modelling Dictionary Attacks in the Password-Only 3-Party Setting

The model used for security analysis of GPAKE [8, 9] does not allow the adversary to access the Corrupt oracle and thus cannot capture any kind of insider attacks, in particular, (UD) online and offline dictionary attacks by a malicious insider. The security definition associated with the model intends to capture indistinguishability of session keys and does not consider mounting an online dictionary attack against a protocol to be a violation of the security of the protocol (see Section 3.3). Consequently, none of the online dictionary attacks presented in Section 2 can be captured in the model.

We begin this section by presenting a communication model adapted from the Bellare-Pointcheval-Rogaway 2000 model [28] to support key exchange in the password-only 3-party setting. Our communication model allows the adversary to ask Corrupt queries and thereby captures insider attacks (as well as forward secrecy and unknown key share attacks). We then define a typical indistinguishability-based security of session keys, which we call the SK security. As we demonstrate in Section 3.3, the SK security implies security against offline dictionary attacks but does not imply security against UD online dictionary attacks. We then introduce a separate security definition to capture UD online dictionary attacks. Unlike the approach of [19, 20] where a separate security definition is introduced to capture both online and offline dictionary attacks, we only need to prove the protocol secure against UD online dictionary attacks once we have proved that it is SK-secure.

3.1. The Communication Model

3.1.1. Participants and Long-Term Keys

We denote S by a trusted authentication server and C by the set of all clients registered with S. During registration, each client C ∈ C selects a password, pw , from a dictionary, D, and shares pw with S via a secure channel. pw is used as the long-term secret key shared between C and S. Any two clients, C, C′ ∈ C, may run a 3-party PAKE protocol P with S at any point in time to establish a session key. Let U = C ∪ {S}. A user, U ∈ U, may participate in multiple protocol sessions running, either serially or concurrently, with the same or different participants. Thus, at any given time, there could be multiple instances of a single user. Π denotes instance i of user U. We say that a client instance, Π , accepts when it computes its session key, sk , in an execution of the protocol.

3.1.2. Partnering

We say, informally, that two instances are partners if they participate in a protocol execution and establish a (shared) session key. Formally, partnering between instances is defined in terms of the notions of session and partner identifiers (See [38] on the role and the possible construct of session and partner identifiers as a form of partnering mechanism that enables the right session key to be identified in concurrent protocol executions.) Session identifier (sid) is a unique identifier of a protocol session and is usually defined as a function of the messages transmitted in the session (although this may not be possible in a multiparty protocol where not all participants have the same view).  sid denotes the sid of instance Π . A partner identifier (pid) is a sequence of identities of participants of a specific protocol session. Instances are given as input a pid before they can run the protocol.  pid denotes the pid given to instance Π .  Note that  pid = 〈C, C′, S〉, where C′ is another client with whom Π believes it runs the protocol. We say that two instances, Π and Π , are partners if the following holds: (1) both Π and Π have accepted, (2)  sid = sid , and (3)  pid = pid .

3.1.3. Adversary Capabilities

The probabilistic polynomial-time (ppt) adversary A is in complete control of all communications between users, and its capabilities are modeled via a predefined set of oracle queries described below.

Execute  (Π , Π , Π ): this query models passive attacks against the protocol. It prompts an execution of the protocol between the instances Π , Π and Π and returns the transcript of the protocol execution to A.

Send  (Π , m): this query sends message m to instance Π , modelling active attacks against the protocol. Upon receiving m, the instance Π proceeds according to the protocol specification. The message output by Π , if any, is returned to A. A query of the form Send (Π , start: 〈C, C′, S〉) prompts Π to initiate the protocol with pid C i = 〈C, C′, S〉.

Reveal  (Π ): this query captures the notion of known key security (it is often reasonable to assume that the adversary will be able to obtain session keys from any session different from the one under attack). The instance Π , upon receiving the query and if it has accepted, returns the session key, sk , back to A.

Corrupt  (U): this query returns the password pw of U. If U = S (i.e., the server is corrupted), all clients' passwords stored by the server are returned. This query captures not only the notion of forward secrecy but also unknown key share attacks and insider attacks.

Test  (Π ): this query is used to define the indistinguishability-based security of the protocol. If Π has accepted, then, depending on a randomly chosen bit b, A is given either the real session key sk (when b = 1) or a random key drawn from the session-key space (when b = 0). Following the model [8, 9], we allow A to ask as many Test queries as it wishes. All Test queries are answered using the same value of the hidden bit b. Namely, the keys output by the Test oracle are either all real or all random. But, we require that, for each different set of partners, A should access the Test oracle only once.

We describe the number of queries asked by an adversary as the query complexity of the adversary. The query complexity is represented as an ordered sequence of five nonnegative integers, Q = 〈q exec, q send, q reve, q corr, q test〉, where q exec, q send, q reve, q corr, and q test refer to the numbers of queries that the adversary asked, respectively, to the Execute, Send, Reveal, Corrupt, and Test oracles.

3.2. Session Key (SK) Security

We now proceed to define the basic security, called the SK security, of a 3-party PAKE protocol. The notion of freshness is a key element in defining the SK security. Intuitively, a fresh instance is one that holds a session key which should not be known to the adversary A, and an unfresh instance is one whose session key (or some information about the key) can be known by trivial means. A formal definition of freshness follows.

Definition 11 .

An instance Π is fresh unless one of the following occurs: (1) A queries Reveal  (Π ) or Reveal  (Π ), where Π is the partner of Π ; or (2) A queries Corrupt  (U), for some  U ∈ pid , before Π or its partner Π accepts.

The SK security of a 3-party PAKE protocol P is defined in the context of Box 1.

Box 1

Let  Succ 0 be the event that A succeeds in the experiment E x p 0. Let  Adv (A) denote the advantage of A in attacking protocol P and be defined as  Adv (A) = 2 · Pr⁡[Succ 0] − 1.

Definition 12 .

A 3-party PAKE protocol P is SK-secure if, for any ppt adversary A asking at most q send Send queries,  Adv (A) is only negligibly larger than c · q send/|D|, where c is a very small constant (usually around 2 or 4) when compared with |D|.

To quantify the security of protocol P in terms of the amount of resources expended by adversaries, we let Adv (t, Q) denote the maximum value of  Adv (A) over all ppt adversaries A with time complexity at most t and query complexity at most Q.

3.3. Password Security

3.3.1. Capturing Offline Dictionary Attacks

The SK security described in Definition 12 implies security against offline dictionary attacks. In other words, a 3-party PAKE protocol P is not SK-secure if it is not secure against an offline dictionary attack. To demonstrate this, suppose that the protocol P is not secure against an offline dictionary attack whereby an attacker B can derive the password of any registered client A. Then we can construct an adversary A who breaks the SK security of protocol P as follows.

Corruption. If B is a malicious insider, A queries Corrupt  (B) to obtain the password pw . Otherwise, A skips this step.

Dictionary Attack. Next, A runs the protocol P exactly in the way that B conducts its offline dictionary attack against client A. Note that A can perfectly simulate B's attack by using the disclosed password pw and by asking oracle queries appropriately. At the end of this step, A will obtain the password pw of client A as a result of the attack.

Impersonation. Now, A initiates a new protocol session by querying Send  (Π , start: 〈A, C, S〉), where Π is an unused instance of an uncorrupted client C. A runs this session as per the protocol specification, but simulating by itself all the actions of A (by using pw ). At the end of the session, the instance Π will accept with its session key sk .

Test. Clearly the instance Π is fresh, since (1) no Reveal query has been made on Π or its partner (which does not exist in this case) and (2) no Corrupt query has been made against any of A, C, and S. Thus, A may ask the Test  (Π ) query. Since A can compute the same session key as sk , the probability that A correctly guesses the bit b chosen by the Test oracle is 1 and so is the advantage of A in attacking the protocol. Then, by Definition 12, the protocol P is not SK-secure since the number of Send queries asked by A is much smaller (i.e., nonnegligibly smaller) than |D | /c.

3.3.2. Capturing Undetectable Online Dictionary Attacks

Unfortunately, the SK security does not imply security against UD online dictionary attacks. In other words, a 3-party PAKE protocol that is not secure against a UD online dictionary attack may be rendered SK-secure. Let us assume a 3-party PAKE protocol P that is susceptible to a UD online dictionary attack (e.g., the GPAKE protocol in Section 2). Then, we can construct an adversary A who attacks protocol P with advantage 1. The construction of A is the same as that of A , except that to correctly determine the password pw , A may have to ask Send queries as many times as d · |D| for some integer d ≥ 1. Note that verifying the correctness of a password guess may require more than one Send query to be asked. Even if  Adv (A ) = 1, the protocol P is still rendered SK-secure by Definition 12, as the following holds for some c ≥ 1: This result is not surprising since we call a protocol SK-secure if mounting an online dictionary attack by asking Send queries is the best an adversary can do. However, we want to be able to distinguish UD online dictionary attacks from detectable online dictionary attacks and ensure that the best an adversary can do is to mount a detectable online dictionary attack. The following new definitions together provide a simple and intuitive way of capturing security against UD online dictionary attacks.

Definition 13 (an online dictionary attack).

The Send  (Π , m) query models an online dictionary attack if both the following are true at the time of the termination of instance Π : (1) m was not output by a previous Send query asked to an instance of C by which Π believes m was sent and (2) the adversary A queried neither Corrupt  (S) nor Corrupt  (C).

In Definition 13, the first condition implies that a straightforward delivery of a message between instances is not considered as an online dictionary attack while the second condition implies that when C′ is the (assumed) peer of client C, the adversary A can corrupt the peer client C′ to mount an (insider) online dictionary attack. Note that our definition of an online dictionary attack does not impose any restriction on asking  Reveal queries.

Let Undet be the event that, in experiment E x p 0, a server instance terminates normally when an online dictionary attack was mounted against the instance. We say that the adversary A succeeds in mounting an UD online dictionary attack if the event Undet occurs. Formally, we define protocol's security against UD online dictionary attacks as follows:

Definition 14 .

A 3-party PAKE protocol P is secure against a UD online dictionary attack if, for any ppt adversary A asking at most q send  Send queries,  Pr⁡[Undet] is only negligibly larger than c · q send/|D|, where c is as defined in Definition 12.

4. A Compiler for 3-Party PAKE Protocols

We now present a protocol compiler that transforms any 2-party PAKE protocol into a 3-party PAKE protocol. If the given 2-party protocol is SK-secure, then the 3-party protocol output by the compiler is not only SK-secure but also secure against both insider and outsider UD online dictionary attacks. (We stress again that the SK security implies resistance against both insider and outsider offline dictionary attacks.) This is the case regardless of whether the underlying 2-party protocol provides client-to-server authentication or not. Our transformation does not require the use of a 3-party key distribution protocol and always takes only two additional rounds of communication. Hence, applying the compiler to a round-optimal 2-party PAKE protocol immediately yields a 3-party PAKE protocol running in three communication rounds.

Our generic construction, which we call H3PAKE (“H” for “hashed”), is a variant of NGPAKE that is the generic construction of Wang and Hu [1]. The key difference between H3PAKE and NGPAKE is in the computation of the session key. NGPAKE defines the session key simply as the Diffie-Hellman key g , whilst H3PAKE defines the session key as  H(pid||sid||g ) where H is a cryptographic hash function. The difference in how session key is computed, together with a minor modification in the specifications of the protocol messages, results in a significant improvement on the security of the constructions. More specifically, we are now able to prove that H3PAKE is secure against insider dictionary attacks, unlike NGPAKE where it is unclear whether it can be proven secure against insider dictionary attacks. Note that the security of NGPAKE was proved in the model that does not allow the adversary to ask Corrupt queries; and as shown in Section 3.3, protocols proven secure in such a model cannot claim provable security against insider attacks of any kind.

4.1. Preliminaries

We begin with the cryptographic primitives on which the security of our construction relies.

Gap Diffie-Hellman (GDH) Assumption. Consider a finite cyclic group G of prime order q where the operation is denoted multiplicatively. Since the order of G is prime, all the elements of G, except 1, are generators of G. Let g be a random generator of G. The GDH problem in G is to solve the computational Diffie-Hellman (CDH) problem in G when given an oracle O(·, ·, ·) that solves the decisional Diffie-Hellman (DDH) problem in G. The DDH oracle O(·, ·, ·), on input a triple (g , g , C) for a, b ∈ Z , outputs 1 if and only if C = g . We define the advantage of a ppt algorithm A in solving the GDH problem in G as  Adv GDH(A) = Pr⁡[A (G, q, g, g , g ) = g : x, y∈ Z ]. We say that the GDH assumption holds in G if  Adv GDH(A) is negligible for all ppt algorithms A. We denote by  Adv GDH(t) the maximum value of  Adv GDH(A) over all algorithms A running in time at most t.

Message Authentication Codes. A message authentication code (MAC) scheme Σ is a triple of efficient algorithms (Gen, Mac, Ver) where (1) the key generation algorithm Gen takes as input a security parameter 1 and outputs a key k chosen uniformly at random from {0,1}; (2) the MAC generation algorithm Mac  takes as input a key k and a message m and outputs a MAC (also known as a tag) σ; and (3) the MAC verification algorithm Ver takes as input a key k, a message m, and a MAC σ and outputs 1 if σ is valid for m under k or outputs 0 if σ is invalid. Let  Adv Σ(A) be the advantage of an adversary A in violating the strong existential unforgeability of Σ  under adaptive chosen message attacks. More precisely,  Adv Σ(A) is the probability that an adversary A, who mounts an adaptive chosen message attack against Σ with oracle access to  Mac (·) and  Ver (·), outputs a message/tag pair (m, σ) such that (1) Ver (m, σ) = 1 and (2) σ was not previously output by the oracle  Mac (·) as a MAC on the message m. We say that the MAC scheme Σ is secure if  Adv Σ(A) is negligible for every ppt adversary A. We use  Adv Σ(t, q mac , q ver ) to denote the maximum value of  Adv Σ(A) over all ppt adversaries A running in time at most t and asking at most q mac and q ver queries to  Mac (·) and  Ver (·), respectively.

2-Party PAKE Protocols. H3PAKE takes as input a 2-party PAKE protocol 2PAKE. We assume that the given 2-party protocol 2PAKE outputs session keys distributed in {0,1} and is SK-secure against an adversary who is given access to all the oracles: Send, Execute, Reveal, Corrupt, and Test. Let  Adv 2(A) be the advantage of an adversary A in breaking the SK security of 2PAKE. We require that, for any ppt adversary A asking at most q send    Send queries,  Adv 2(A) is only negligibly larger than q send/|D|.  Adv 2(t, Q) denotes the maximum value of  Adv 2(A) over all ppt adversaries A with time complexity at most t and query complexity at most Q.

Additionally, H3PAKE uses a cryptographic hash function H mapping {0,1}* to {0,1}, where κ is a security parameter representing the length of session keys. H is modelled as a random oracle in our proof of security for H3PAKE.

4.2. Description of H3PAKE

We assume that the following information has been preestablished and is known to all users in the network: (1) a cyclic group G of prime order q and a generator g of G, (2) a MAC scheme  Σ = (Gen, Mac, Ver), (3) a 2-party PAKE protocol 2PAKE, and (4) a cryptographic hash function H. These public parameters can be determined by the server and be broadcast to all its registered clients. Let A and B be two clients who wish to establish a session key, and let S be the trusted server with which A and B have registered their passwords pw and pw , respectively. We denote the partner identifier pid given as input to (an instance of) A (resp., B and S) by  pid (resp.,  pid  and  pid ). Recall that pid is a sequence of identities of protocol participants. The order of identities that appears in pid is of critical importance for the correctness of our construction and its security proof. For simplicity, we assume that  pid = pid = pid = 〈A, B, S〉. Figure 5 depicts how the generic 3-party PAKE protocol, H3PAKE, is constructed from any given 2-party protocol, 2PAKE. More specifically, H3PAKE is constructed as follows.

Figure 5

H3PAKE: our proposed generic 3-party PAKE protocol.

Ph as e 1. A and S establish a shared high-entropy key k by running the 2-party protocol 2PAKE. Likewise, B and S establish a shared high-entropy key k .

Ph as e 2. A and B establish their session key by running a MAC-based Diffie-Hellman key exchange protocol with assistance of S.

Step 1. A chooses a random x ∈ Z , computes X = g and  σ = Mac (A||X||pid ), and sends 〈A, X, σ 〉 to S. Meanwhile, B chooses a random y ∈ Z , computes Y = g and σ = Mac (B||Y||pid ), and sends 〈B, Y, σ 〉 to S.

Step 2. S checks that  Ver (A||X||pid , σ ) = 1 and   Ver (B||Y||pid , σ ) = 1. If either verification fails, S aborts the protocol. Otherwise, S computes  σ = Mac (S||Y||pid ) and  σ = Mac (S||X||pid ) and sends 〈S, Y, σ 〉 and 〈S, X, σ 〉 to A and B, respectively.

Step 3. A verifies that  Ver (S||Y||pid , σ ) = 1. If the verification fails, A aborts the protocol. Otherwise, A sets the session identifier,  sid = A||X||B||Y, and computes the Diffie-Hellman key,  K = Y , and the session key,  sk = H(pid ||sid ||K ). Meanwhile, B checks if  Ver (S||X||pid , σ ) = 1 and aborts if the check fails. Otherwise, B sets  sid = A||X||B||Y and computes K = X and  sk = H (pid ||sid ||K ).

At the end of the protocol execution, A and B will compute the same session key sk if they both hold the same sets of pid and sid and thus compute the same Diffie-Hellman key K = g .

We do not require 2PAKE to be instantiated with a protocol that provides either unilateral or mutual authentication, as H3PAKE already provides mutual authentication between the server and the clients (via the MAC values exchanged in Phase 2). Hence, any 2-party protocol that provides implicit key authentication, including one-round protocols, will be suitable candidates to instantiate 2PAKE.

4.3. Proof of SK Security

We claim that the generic construction H3PAKE described in Figure 5 is SK-secure in the random oracle model under the GDH assumption in G and the security of the MAC scheme Σ.

Theorem 15 .

Let H be a random oracle. Then, for any adversary with time complexity at most t and query complexity at most Q = 〈q , q , q , q , q 〉, its advantage in breaking the SK security of H3PAKE is bounded by where Q′ = 〈2q , q , q , q , 2q + q 〉 and t′ is the maximum time required to perform the experiment E x p 0 involving an adversary who attacks H3PAKE with time complexity t.

Proof. Assume a ppt adversary A who attacks H3PAKE with time complexity t and query complexity Q = 〈q exec, q send, q reve, q corr, q test〉. We prove the theorem by making a series of modifications to the experiment E x p 0, bounding the difference in A's advantage between two consecutive experiments, and ending up with an experiment in which A's advantage is negligible. By  Succ , we denote the event that A correctly guesses the hidden bit b (chosen by the Test oracle) in experiment E x p .

Before presenting the first modified experiment, we define the notion of a clean instance.

Definition 16 .

We say an instance Π is unclean if A has queried Corrupt  (U′) for some U′ ∈ pid . Otherwise, we say it is clean.

Experiment E x p 1.This experiment is different from E x p 0 only in that we replace each different MAC key with a random key drawn uniformly from {0,1} for all clean instances. The difference in A's advantage between E x p 0 and E x p 1 is bounded by the following lemma.

Lemma 17 .

|Pr⁡[Succ 1] − Pr⁡[Succ 0]| ≤ Adv 2PAKE(t′, Q′), where t′ and Q′ are as defined in Theorem 15.

Proof

We prove the lemma by constructing an adversary A′ attacking protocol 2PAKE from the adversary A whose advantage in attacking H3PAKE is different between E x p 0 and E x p 1. A′ begins by choosing a bit b uniformly at random. Then, A′ runs A as a subroutine while simulating the oracles as follows.

Ex ec ut e Queries. When A makes an Execute  (Π , Π , Π ) query, A′ first checks if any of A, B, and S was previously corrupted.

If so, A′ answers the Execute query as in experiment E x p 0.

Otherwise, A′ answers the query using its own oracles. A′ first asks two queries Execute  (Π , Π ) and Execute  (Π , Π ). Let  T 2 and  T 2′ be two transcripts returned in response to the Execute queries. Next, A′ makes the queries Test  (Π ) and Test  (Π ) and receives in return two keys and (either real or random). A′ then generates the rest of the protocol transcript (i.e., the messages to be sent in Phase 2), using and as the MAC keys. Finally, A′ returns these messages together with T 2 and  T 2′ after ordering them properly.

Se nd Queries. Whenever A makes a Send  (Π , m) query, A′ checks if m is a message for initiating a new session (of H3PAKE) or the Send query belongs to an execution of 2PAKE.

If both conditions are untrue, A′ responds to the query as in experiment E x p 0.

Otherwise, A′ answers it by making the same query to its own Send oracle. If the query prompts Π to accept, then A′ checks if anyone in  pid was previously corrupted.

If so, A′ makes a Reveal  (Π ) query and uses the output of this Reveal query as the MAC key of Π .

Otherwise, A′ makes a Test  (Π ) query (unless the partner of Π has already been tested) and uses the output of this Test query as the MAC key of Π .

Re ve al Queries. These queries are handled as in experiment E x p 0.

Co rr up t Queries. A′ answers these queries in the straightforward way using its own Corrupt oracle.

Te st Queries. A′ answers these queries according to the bit b that it has chosen at the beginning of the simulation. That is, A′ returns real session keys, which it has computed on its own, if b = 1, and otherwise returns random keys chosen uniformly at random from {0,1}.

At some point in time, A will terminate and output its guess b′. When this happens, A′ outputs 1, if b = b′, and 0 otherwise.

From the simulation, it is obvious that This means that  Adv 2(A′)  =  |Pr⁡[Succ 1] − Pr⁡[Succ 0]|.  Since A′ has at most time complexity t′ and query complexity Q′ = 〈2q exec, q send, q send, q corr, 2q exec + q send〉, we obtain Lemma 17.

the probability that A′ outputs 1 when its Test   oracle returns real session keys is equal to the probability that A correctly guesses the bit b in experiment E x p 0;

the probability that A′ outputs 1 when its Test  oracle returns random keys is equal to the probability that A correctly guesses the bit b in experiment E x p 1.

Experiment E x p 2. Let Forge be the event that the adversary A makes a Send query of the form Send  (Π , V||∗||σ) before querying Corrupt  (U) and Corrupt  (V), where σ is a valid tag on  V||∗||pid and was not output by a previous oracle query as a tag on  V||∗||pid . Then E x p 2 is different from E x p 1 only in that, if Forge occurs, the experiment is aborted and the adversary does not succeed. We claim the following lemma.

Lemma 18 .

|Pr⁡[Succ 2] − Pr⁡[Succ 1]| ≤ q · Adv Σ(t′, 2,2), where t′ is as defined in Theorem 15.

Given the adversary A attacking H3PAKE and assuming that the event Forge occurs, we construct an algorithm F that outputs, with a nonnegligible probability, a forgery against the MAC scheme Σ. The algorithm F is given oracle access to  Mac (·) and  Ver (·). The goal of F is to produce a message/tag pair (m, σ) such that (1)  Ver (m, σ) = 1 and (2) σ was not previously output by the Mac (·) oracle on input m.

Let n be the number of all different MAC keys that are established via a Send query of A. Clearly, n ≤ q send. F begins by choosing a random α ∈ {1,…, n}. Let k denote the αth key among all the n MAC keys, and let Send be a Send query that should be answered and/or verified using k . F invokes A as a subroutine and handles the oracle calls of A as in experiment E x p 1 except that it answers all  Send queries by accessing its MAC generation and verification oracles. As a result, the αth MAC key k is never used during the simulation. If Forge occurs against an instance that holds k , F halts and outputs the message/tag pair generated by A as its forgery. Otherwise, F halts and outputs a failure indication.

If the guess α is correct, then the simulation is perfect and F achieves its goal. Namely,  Adv Σ(F) = Pr⁡[Forge]/n. Since n ≤ q send, we get  Pr⁡[Forge] ≤ q send · Adv Σ(F). Then, Lemma 18 follows by noticing that F has at most time complexity t′ and makes at most two queries to  Mac (·) and  Ver (·).

Experiment E x p 3. This experiment is different from experiment E x p 2 only in that the Execute and Send oracles are simulated as in “the E x p 3 modification” described in Box 2.

Box 2

Since the view of A is identical between E x p 2 and E x p 3, following Lemma 19 is clear.

Lemma 19 .

Pr⁡[Succ 3] = Pr⁡[Succ 2].

In experiment E x p 3, the advantage of A in attacking H3PAKE is bounded by the following lemma.

Lemma 20 .

Pr⁡[Succ 3] ≤ (1/2) + Adv (t′) where t′ is as defined in Theorem 15.

The proof is via a reduction from the GDH problem which is believed to be hard. Assume that the advantage of A in attacking H3PAKE is nonnegligible. Then we can construct an algorithm A GDH that has a nonnegligible advantage in solving the GDH problem in G. The goal of A GDH is to compute and output the value W 3 = g ∈ G when given a CDH-problem instance (W 1 = g , W 2 = g ) ∈ G as well as an oracle O(·, ·, ·) that solves the DDH problem in G. A GDH runs A as a subroutine while simulating all the oracles on its own.

When A asks an Execute and Send query, A GDH answers it as specified in the E x p 3 modification but using W 1 and W 2 instead of V 1 and V 2. In this way, A GDH can embed the CDH-problem instance (W 1, W 2) into all protocol sessions. Accordingly, A GDH can compute no session keys but can still correctly answer Reveal queries by storing all the keying materials associated with each instance. For each instance Π whose only remaining work is to compute its session key, A GDH checks if the instance Π is clean or unclean. If it is clean, A GDH stores a tuple  (pid ,  sid ,  R, r, R′, r′) into a list, which we denote as CDHList, where R = W 1 and R′ = W 2 . Here, the exponent r (resp., r′) is the one chosen for the instance whose user identity comes first (resp., second) in  pid . If it is unclean, A GDH stores a tuple  (pid , sid , R, r, R′, ⊥) if C comes first in  pid or a tuple  (pid , sid , R, ⊥, R′, r′) if C comes second in  pid . Here, ⊥ indicates that the exponent of the received public Diffie-Hellman value may have been chosen by A.

While imbedding the CDH-problem instance as above, A GDH has to provide A with the same view as in experiment E x p 3. To this end, let kds be a key derivation string from which a session key is computed by applying the random oracle H. Let kds denote the kds of instance Π . Then,  kds = pid ||sid ||K . As is clear from the above simulation, A GDH cannot compute any kds on its own. But, given a string m, A GDH can determine whether m is the kds of some instance Π or not by repeatedly performing the deciding operation for the tuples in CDHList as in Box 3.

Box 3

The simulation of other oracles is provided as follows.

H Queries. A GDH uses a list, HList, to maintain input-output pairs of H. For each H query on a string m, A GDH first checks if an entry of the form (m, h) is in HList. If it is, A GDH returns h to A. Otherwise, A GDH checks if m is the kds of some instance Π by repeatedly performing the deciding operation above until a match is found. Reveal Queries. When A asks a Reveal  (Π ) query, A GDH finds a tuple of the form  (pid ,   sid , R, ∗, R′, ∗) in CDHList and checks if a tuple of the form  (pid ,  sid , R, R′, sk) is in the RList. If it is, A GDH returns sk to A. Otherwise, A GDH checks if HList contains an entry (m, h) such that m = kds . Given the tuple  (pid ,  sid ,  R, ∗, R′, ∗), this check can be done by performing the deciding operation for all entries in HList. If such entry (m, h) exists in HList, A GDH returns h in response to the query and adds the tuple (pid ,  sid ,  R, R′, h) into RList. Otherwise, A GDH returns a random κ-bit string str to A and adds the tuple (pid ,   sid , R, R′, str) into RList.

If a match is found and the corresponding tuple is of the form  (pid ,  sid ,  R, r, R′, r′), A GDH computes W 3 = (m )1/ and terminates outputting W 3. In this case, A GDH succeeds in solving the GDH problem.

If a match is found and the corresponding tuple is of the form  (pid ,  sid ,   R, r, R′, ⊥) or  (pid ,   sid ,   R, ⊥, R′, r′), A GDH checks if a tuple of the form  (pid ,  sid ,  R, R′, sk) is in the RList which is maintained by A GDH to store revealed session keys. If it is, A GDH returns sk to A and adds (m, sk) to HList. Otherwise, A GDH returns a random κ-bit string str to A and adds (m, str) to HList.

Otherwise, A GDH returns a random κ-bit string str to A and adds (m, str) to HList.

Co rr up t Queries. A GDH answers these queries in the obvious way.

Te s t Queries. For each of these queries, A GDH responses with a random κ-bit string.

Let A sk be the event that A makes an H query on a string m that is the kds of some fresh instance. From the simulation of H, it can be easily seen that as soon as A sk occurs, A GDH outputs the desired result W 3 = g and thus succeeds in solving the GDH problem in G. But, since H is a random oracle, A gains no advantage in distinguishing the test keys from random if the event A sk does not occur. This implies the assertion of Lemma 20.

This result combined with Lemmas 17–19 concludes the proof for Theorem 15.

4.4. Proof of Resistance to Undetectable Online Dictionary Attacks

We now claim that H3PAKE is secure against a UD online dictionary attack as long as the given 2-party protocol 2PAKE is SK-secure.

Theorem 21 .

Assume that, for any ppt adversary A′ asking at most q   Send queries,  Adv 2(A′) is only negligibly larger than q /|D|. Then, for any ppt adversary A asking at most q   Send queries,  Pr⁡[Undet] is only negligibly larger than q /|D|, where Undet is as defined in Section 3.3.

Let A be an adversary who asks q send  Send queries in attacking the protocol H3PAKE. Assume that  Pr⁡[Undet] is nonnegligibly larger than q send/|D|. Given the adversary A, we prove the theorem by constructing an adversary A′ against 2PAKE who asks at most q send   Send queries but has an advantage nonnegligibly larger than q send/|D|.

A′ invokes A as a subroutine and answers the oracle queries of A as follows.

Ex ec ut e Queries. When A makes an Execute  (Π , Π , Π ) query, A′ answers the query using its own Execute and Reveal oracles. A′ first queries Execute  (Π , Π ) and Execute  (Π , Π ). Let  T 2 and  T 2′ be two transcripts returned in response to the Execute queries. Next, A′ obtains two keys k and k by querying Reveal  (Π ) and Reveal  (Π ). A′ then generates the rest of the protocol transcript, using k and k as the MAC keys. Finally, A′ returns these messages together with  T 2PAKE and  T 2′ after ordering them properly.

Se nd Queries. When A makes a Send  (Π , m) query, A′ checks if m is a message for initiating a new session (of H3PAKE) or the Send query belongs to an execution of 2PAKE. Corrupt Queries. A′ answers these queries using its own Corrupt oracle.

If both conditions are untrue, A′ responds to the query as that in the original experiment E x p 0.

Otherwise, A′ answers it by making the same query to its own Send oracle. If the query prompts Π to accept,  A′ checks if Π is a server instance against which A has mounted an online dictionary attack. If not, A′ makes a Reveal (Π ) query (and later uses the output of this Reveal query as the MAC key of Π ). (How to handle the other case will be explained below.)

Re ve al/Test Querise. A′ answers these queries as in the original experiment E x p 0.

Let Π be any server instance against which A has mounted an online dictionary attack. Let  k be the session key that the instance Π has computed in its execution of 2PAKE. In order for the instance Π to terminate normally, the adversary A has to make a query of the form Send  (Π , C||∗||σ ) such that  Ver (C||∗||pid , σ ) = 1. When A makes such a Send query (i.e., when the event Undet occurs), A′ makes a Test query against the instance Π . Note that the instance Π is fresh as (1) it is partnered with no instance and (2) S and C must have not been corrupted. Let be the key returned in response to the Test query. A′ outputs 1, if  , and outputs 0, otherwise. If Undet does not occur, A′ outputs a random bit.

From the simulation above, it is clear to see that Then, Theorem 21 immediately follows since the number of Send queries asked by A′ against 2PAKE is at most q send.

5. Concluding Remarks

The undetectable online dictionary attacks we presented against the widely studied GPAKE protocol of Abdalla et al. [8, 9] are a reminder of the difficulty of designing a secure yet efficient 3-party PAKE protocol. The GPAKE protocol was proven secure in a model that does not capture undetectable online dictionary attacks, and thus, our attacks do not invalidate the proof of security for GPAKE.

We also presented a simple and intuitive approach of capturing all classes of dictionary attacks in the framework of the widely accepted Bellare-Pointcheval-Rogaway model. What motivated our approach is the observation that no prior work has provided a rigorous formal treatment of insider (online/offline) dictionary attacks in the password-only 3-party setting and as a consequence 3-party PAKE protocols insecure against such attacks have proliferated. We believe that our approach provides protocol designers with an easier and more accessible way of proving security of their protocols against dictionary attacks.

Finally, we presented a generic 3-party PAKE protocol (H3PAKE) and proved its security in the random oracle model under the gap Diffie-Hellman assumption. To the best of our knowledge, H3PAKE is the first 3-party PAKE protocol proven secure against both insider and outsider dictionary attacks as well as offline and online dictionary attacks. Future work includes coming up with a 3-party PAKE protocol that achieves the same (or even better) level of security and efficiency as H3PAKE but does not rely its security proof on the random oracle model.