Abstract

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 [16].

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, 817]. Most of these protocols were proven secure only in a restricted model, in which the adversary is not allowed to corrupt protocol participants [1, 810, 1214]. 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 [2127] 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  [1], whose indistinguishability-based security as well as password security against all classes of dictionary attacks are formally proved in a well-defined communication model. 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.(i)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).(ii)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). 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).

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 be a finite cyclic group generated by an element ; and let (, ) be a MAC scheme where and 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 and on the security of the underlying MAC scheme against chosen message attacks. represents a trusted server which registers clients and, during the registration, each client shares their individual password secretly with . Suppose that and are two registered clients who wish to establish a session key and and are the passwords of and , respectively.

2.1.1. Description

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

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 who is registered with the server, , can mount a UD online dictionary attack against any other client, for example, . 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.

2.2.1. The PPK Protocol

Let be a finite cyclic group of order , and let be a generator of . The three hash functions used are , , and , where is the length of the session key. denotes ’s password known only to and denotes the password verifiers held by . The function ACCEPTABLE   returns true, if and only if (or, when is defined as a (proper) subgroup of a group ). The session key 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 (, ) and (2) a MAC scheme consisting of a pair of MAC generation/verification algorithms (, ). The protocol runs between a trusted server, , and two clients, and . (and ) and are assumed to have preestablished a -bit secret (resp., ). The protocol, depicted in Figure 3, begins by having choosing a random -bit challenge and sending it to client . also chooses a random -bit challenge and sends to . Upon receiving , generates a session key which he will distribute. then encrypts under ’s encryption key (resp., ’s encryption key ) to get ciphertext (resp., ). Then, computes (resp., ), the MAC under key (resp., ) of the string (resp. ). Then, sends and to and , respectively. and accept the session key 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 -bit long.

2.2.3. One Possible Attack Scenario

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

Step 1 (running PPK). begins by initiating two concurrent runs, R1 & R2, of the PPK protocol. (i)In the (dishonest) run R1, impersonating makes a guess (denoted by ) on ’s actual password, , selects a random , computes , and sends the server a fabricated message . Since , will respond with the message . After obtaining , computes a key , where and . We let .(ii)In the (honest) run R2, honestly performs all the operations as per protocol specification and establishes the key, .

Step 2 (running 3PKD). Once R1 & R2 are completed, proceeds to run the protocol 3PKD by sending the server two random challenges and (selected as specified by the protocol). will respond to the random challenges with two messages and . After obtaining these two messages, recovers the keys   and  .

Step 3 (verifying the password guess). verifies the correctness of by checking that is equal to . If they are equal, is the correct password with an overwhelming probability. Otherwise, it means that .

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.

2.3.1. The OMDHKE Protocol

Let be a finite cyclic group generated by an element of prime order . The hash functions used are , , and , where is the length of the session key and is the length of the authenticator . Unlike the PPK protocol described in Figure 2, both and have a shared password, . The protocol starts when chooses a random , computes , , and , and sends to . Upon receiving the message from , computes and , chooses a random , and computes , , and . Then sends to and computes the session key, . computes , verifies , and computes the session key if the verification succeeds.

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

2.3.2. One Possible Attack Scenario

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

Step 4 (running OMDHKE). initiates two concurrent runs, R1 & R2, of the protocol OMDHKE. (i)In the (dishonest) run R1, impersonating makes a guess (denoted by ) on ’s password, , chooses a random , computes and , and sends the fabricated message to . will then receive the response, , from as per protocol specification.(ii)In the (dishonest) run R2, proceeds as per R1 but impersonating (instead of ) and making a guess (denoted as ) on ’s password, . Let denote the authenticator received (in response) from  .

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

Step 6 (verifying the password guess). can then verify the correctness of by computing and then checking if is equal to . If they are equal, is the correct password (with an overwhelming probability). Otherwise, knows that . Similarly, the correctness of can be verified using the received .

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 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 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 by a trusted authentication server and by the set of all clients registered with . During registration, each client selects a password, , from a dictionary, , and shares with via a secure channel. is used as the long-term secret key shared between and . Any two clients, , may run a 3-party PAKE protocol with at any point in time to establish a session key. Let . A user, , 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 of user . We say that a client instance, , accepts when it computes its session key, , 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 () 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).   denotes the of instance . A partner identifier () is a sequence of identities of participants of a specific protocol session. Instances are given as input a before they can run the protocol.   denotes the given to instance .  Note that  , where 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)  , and (3)  .

3.1.3. Adversary Capabilities

The probabilistic polynomial-time (PPT) adversary is in complete control of all communications between users, and its capabilities are modeled via a predefined set of oracle queries described below.(i)  (): 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 .(ii)  (): this query sends message to instance , modelling active attacks against the protocol. Upon receiving , the instance proceeds according to the protocol specification. The message output by , if any, is returned to . A query of the form (, start: ) prompts to initiate the protocol with .(iii)  (): 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, , back to .(iv)  (): this query returns the password of . If (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.(v)  (): this query is used to define the indistinguishability-based security of the protocol. If has accepted, then, depending on a randomly chosen bit , is given either the real session key (when ) or a random key drawn from the session-key space (when ). Following the model [8, 9], we allow to ask as many queries as it wishes. All queries are answered using the same value of the hidden bit . Namely, the keys output by the oracle are either all real or all random. But, we require that, for each different set of partners, should access the 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, , , , , , where , , , , and refer to the numbers of queries that the adversary asked, respectively, to the , , , , and 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 , 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) queries  () or  (), where is the partner of ; or (2) queries  (), for some  , before or its partner accepts.
The SK security of a 3-party PAKE protocol is defined in the context of Box 1.
Let   be the event that succeeds in the experiment . Let   denote the advantage of in attacking protocol and be defined as  .

Definition 12. A 3-party PAKE protocol is SK-secure if, for any PPT adversary asking at most    queries,   is only negligibly larger than , where is a very small constant (usually around 2 or 4) when compared with .

To quantify the security of protocol in terms of the amount of resources expended by adversaries, we let denote the maximum value of   over all PPT adversaries with time complexity at most and query complexity at most .

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 is not SK-secure if it is not secure against an offline dictionary attack. To demonstrate this, suppose that the protocol is not secure against an offline dictionary attack whereby an attacker can derive the password of any registered client . Then we can construct an adversary who breaks the SK security of protocol as follows.

Corruption. If is a malicious insider, queries  ( to obtain the password . Otherwise, skips this step.

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

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

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

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 that is susceptible to a UD online dictionary attack (e.g., the GPAKE protocol in Section 2). Then, we can construct an adversary who attacks protocol with advantage . The construction of is the same as that of , except that to correctly determine the password , may have to ask queries as many times as for some integer . Note that verifying the correctness of a password guess may require more than one query to be asked. Even if  , the protocol is still rendered SK-secure by Definition 12, as the following holds for some : This result is not surprising since we call a protocol SK-secure if mounting an online dictionary attack by asking 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  ( query models an online dictionary attack if both the following are true at the time of the termination of instance : (1) was not output by a previous query asked to an instance of by which believes was sent and (2) the adversary queried neither  () nor  ().

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 is the (assumed) peer of client , the adversary can corrupt the peer client to mount an (insider) online dictionary attack. Note that our definition of an online dictionary attack does not impose any restriction on asking   queries.

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

Definition 14. A 3-party PAKE protocol is secure against a UD online dictionary attack if, for any PPT adversary asking at most queries,   is only negligibly larger than , where 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 (“” 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 , whilst H3PAKE defines the session key as   where 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 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 of prime order where the operation is denoted multiplicatively. Since the order of is prime, all the elements of , except , are generators of . Let be a random generator of . The GDH problem in is to solve the computational Diffie-Hellman (CDH) problem in when given an oracle that solves the decisional Diffie-Hellman (DDH) problem in . The DDH oracle , on input a triple for , outputs if and only if . We define the advantage of a PPT algorithm in solving the GDH problem in as  : . We say that the GDH assumption holds in if   is negligible for all PPT algorithms . We denote by   the maximum value of   over all algorithms running in time at most .

Message Authentication Codes. A message authentication code (MAC) scheme is a triple of efficient algorithms (, , ) where (1) the key generation algorithm takes as input a security parameter and outputs a key chosen uniformly at random from ; (2) the MAC generation algorithm  takes as input a key and a message and outputs a MAC (also known as a tag) ; and (3) the MAC verification algorithm takes as input a key , a message , and a MAC and outputs if is valid for under or outputs if is invalid. Let be the advantage of an adversary in violating the strong existential unforgeability of  under adaptive chosen message attacks. More precisely,   is the probability that an adversary , who mounts an adaptive chosen message attack against with oracle access to   and  , outputs a message/tag pair such that (1) and (2) was not previously output by the oracle   as a MAC on the message . We say that the MAC scheme is secure if   is negligible for every PPT adversary . We use   to denote the maximum value of   over all PPT adversaries running in time at most and asking at most and queries to   and  , 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 and is SK-secure against an adversary who is given access to all the oracles: , , , , and . Let   be the advantage of an adversary in breaking the SK security of 2PAKE. We require that, for any PPT adversary asking at most     queries,   is only negligibly larger than .   denotes the maximum value of   over all PPT adversaries with time complexity at most and query complexity at most .

Additionally, H3PAKE uses a cryptographic hash function mapping to , where is a security parameter representing the length of session keys. 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 of prime order and a generator of , (2) a MAC scheme  , (3) a 2-party PAKE protocol 2PAKE, and (4) a cryptographic hash function . These public parameters can be determined by the server and be broadcast to all its registered clients. Let and be two clients who wish to establish a session key, and let be the trusted server with which and have registered their passwords and , respectively. We denote the partner identifier given as input to (an instance of) (resp., and ) by   (resp.,    and  ). Recall that is a sequence of identities of protocol participants. The order of identities that appears in is of critical importance for the correctness of our construction and its security proof. For simplicity, we assume that  . 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.

1. and establish a shared high-entropy key by running the 2-party protocol 2PAKE. Likewise, and establish a shared high-entropy key .

2. and establish their session key by running a MAC-based Diffie-Hellman key exchange protocol with assistance of . 1. chooses a random , computes and  , and sends to . Meanwhile, chooses a random , computes and , and sends to . 2. checks that   and   . If either verification fails, aborts the protocol. Otherwise, computes   and  and sends and to and , respectively. 3. verifies that  . If the verification fails, aborts the protocol. Otherwise, sets the session identifier,  , and computes the Diffie-Hellman key,  , and the session key,  . Meanwhile, checks if   and aborts if the check fails. Otherwise, sets   and computes and  .

At the end of the protocol execution, and will compute the same session key if they both hold the same sets of and and thus compute the same Diffie-Hellman key .

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 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 and the security of the MAC scheme .

Theorem 15. Let be a random oracle. Then, for any adversary with time complexity at most and query complexity at most , , , , , its advantage in breaking the SK security of H3PAKE is bounded by where , , , , and is the maximum time required to perform the experiment involving an adversary who attacks H3PAKE with time complexity .

Proof. Assume a PPT adversary who attacks H3PAKE with time complexity and query complexity , , , , . We prove the theorem by making a series of modifications to the experiment , bounding the difference in ’s advantage between two consecutive experiments, and ending up with an experiment in which ’s advantage is negligible. By  , we denote the event that correctly guesses the hidden bit (chosen by the oracle) in experiment .

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

Definition 16. We say an instance is unclean if has queried  ( for some . Otherwise, we say it is clean.

Experiment .This experiment is different from only in that we replace each different MAC key with a random key drawn uniformly from for all clean instances. The difference in ’s advantage between and is bounded by the following lemma.

Lemma 17. , where and are as defined in Theorem 15.

Proof. We prove the lemma by constructing an adversary attacking protocol 2PAKE from the adversary whose advantage in attacking H3PAKE is different between and . begins by choosing a bit uniformly at random. Then, runs as a subroutine while simulating the oracles as follows.
Queries. When makes an  (, , ) query, first checks if any of , , and was previously corrupted. (i)If so, answers the query as in experiment .(ii)Otherwise, answers the query using its own oracles. first asks two queries  (, ) and  (, ). Let   and   be two transcripts returned in response to the queries. Next, makes the queries  () and  () and receives in return two keys and (either real or random). then generates the rest of the protocol transcript (i.e., the messages to be sent in 2), using and as the MAC keys. Finally, returns these messages together with and   after ordering them properly.
Queries. Whenever makes a  (, ) query, checks if is a message for initiating a new session (of H3PAKE) or the query belongs to an execution of 2PAKE.(1)If both conditions are untrue, responds to the query as in experiment .(2)Otherwise, answers it by making the same query to its own oracle. If the query prompts to accept, then checks if anyone in   was previously corrupted.(a)If so, makes a  () query and uses the output of this query as the MAC key of .(b)Otherwise, makes a  () query (unless the partner of has already been tested) and uses the output of this query as the MAC key of .
Queries. These queries are handled as in experiment .
Queries. answers these queries in the straightforward way using its own oracle.
Queries. answers these queries according to the bit that it has chosen at the beginning of the simulation. That is, returns real session keys, which it has computed on its own, if , and otherwise returns random keys chosen uniformly at random from .
At some point in time, will terminate and output its guess . When this happens, outputs 1, if , and 0 otherwise.
From the simulation, it is obvious that (i)the probability that outputs when its   oracle returns real session keys is equal to the probability that correctly guesses the bit in experiment ;(ii)the probability that outputs when its  oracle returns random keys is equal to the probability that correctly guesses the bit in experiment . This means that    =  .  Since has at most time complexity and query complexity   , , , , we obtain Lemma 17.

Experiment . Let be the event that the adversary makes a query of the form  (, ) before querying  () and , where is a valid tag on   and was not output by a previous oracle query as a tag on  . Then is different from only in that, if occurs, the experiment is aborted and the adversary does not succeed. We claim the following lemma.

Lemma 18. , where is as defined in Theorem 15.

Proof. Given the adversary attacking H3PAKE and assuming that the event occurs, we construct an algorithm that outputs, with a nonnegligible probability, a forgery against the MAC scheme . The algorithm is given oracle access to   and  . The goal of is to produce a message/tag pair such that (1)   and (2) was not previously output by the   oracle on input .
Let be the number of all different MAC keys that are established via a query of . Clearly, . begins by choosing a random . Let denote the th key among all the MAC keys, and let be a query that should be answered and/or verified using . invokes as a subroutine and handles the oracle calls of as in experiment except that it answers all   queries by accessing its MAC generation and verification oracles. As a result, the αth MAC key is never used during the simulation. If occurs against an instance that holds , halts and outputs the message/tag pair generated by as its forgery. Otherwise, halts and outputs a failure indication.
If the guess is correct, then the simulation is perfect and achieves its goal. Namely,  . Since , we get  . Then, Lemma 18 follows by noticing that has at most time complexity and makes at most two queries to  and  .

Experiment . This experiment is different from experiment only in that the and oracles are simulated as in “the modification” described in Box 2.

Since the view of is identical between and , following Lemma 19 is clear.

Lemma 19. .

In experiment , the advantage of in attacking H3PAKE is bounded by the following lemma.

Lemma 20. where is as defined in Theorem 15.

Proof. The proof is via a reduction from the GDH problem which is believed to be hard. Assume that the advantage of in attacking H3PAKE is nonnegligible. Then we can construct an algorithm that has a nonnegligible advantage in solving the GDH problem in . The goal of is to compute and output the value when given a CDH-problem instance as well as an oracle that solves the DDH problem in . runs as a subroutine while simulating all the oracles on its own.
When asks an and query, answers it as specified in the modification but using and instead of and . In this way, can embed the CDH-problem instance into all protocol sessions. Accordingly, can compute no session keys but can still correctly answer queries by storing all the keying materials associated with each instance. For each instance whose only remaining work is to compute its session key, checks if the instance is clean or unclean. If it is clean, stores a tuple   into a list, which we denote as CDHList, where and . Here, the exponent (resp., ) is the one chosen for the instance whose user identity comes first (resp., second) in  . If it is unclean, stores a tuple   if comes first in   or a tuple  if comes second in  . Here, indicates that the exponent of the received public Diffie-Hellman value may have been chosen by .
While imbedding the CDH-problem instance as above, has to provide with the same view as in experiment . To this end, let be a key derivation string from which a session key is computed by applying the random oracle . Let denote the of instance . Then,  . As is clear from the above simulation, cannot compute any on its own. But, given a string , can determine whether is the of some instance or not by repeatedly performing the deciding operation for the tuples in CDHList as in Box 3.
The simulation of other oracles is provided as follows.
H Queries. uses a list, HList, to maintain input-output pairs of . For each query on a string , first checks if an entry of the form is in HList. If it is, returns to . Otherwise, checks if is the of some instance by repeatedly performing the deciding operation above until a match is found. (i)If a match is found and the corresponding tuple is of the form  ,  ,  , , , , computes and terminates outputting . In this case, succeeds in solving the GDH problem.(ii)If a match is found and the corresponding tuple is of the form  ,  ,   , , , or  ,   ,   , , , , checks if a tuple of the form  ,  ,  , , is in the RList which is maintained by to store revealed session keys. If it is, returns to and adds to HList. Otherwise, returns a random -bit string to and adds to HList.(iii)Otherwise, returns a random -bit string to and adds to HList. Queries. When asks a  () query, finds a tuple of the form  ,   , in CDHList and checks if a tuple of the form  ,  , , , is in the RList. If it is, returns to . Otherwise, checks if HList contains an entry such that . Given the tuple  ,  , this check can be done by performing the deciding operation for all entries in HList. If such entry exists in HList, returns in response to the query and adds the tuple (,  ,  , , ) into RList. Otherwise, returns a random -bit string to and adds the tuple (,   , , , ) into RList.
Queries. answers these queries in the obvious way.
Queries. For each of these queries, responses with a random -bit string.
Let be the event that makes an query on a string that is the of some fresh instance. From the simulation of , it can be easily seen that as soon as occurs, outputs the desired result and thus succeeds in solving the GDH problem in . But, since is a random oracle, gains no advantage in distinguishing the test keys from random if the event does not occur. This implies the assertion of Lemma 20.
This result combined with Lemmas 1719 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 asking at most queries,   is only negligibly larger than . Then, for any PPT adversary asking at most queries,   is only negligibly larger than , where is as defined in Section 3.3.

Proof. Let be an adversary who asks queries in attacking the protocol H3PAKE. Assume that  is nonnegligibly larger than . Given the adversary , we prove the theorem by constructing an adversary against 2PAKE who asks at most queries but has an advantage nonnegligibly larger than .
invokes as a subroutine and answers the oracle queries of as follows.
Queries. When makes an  (, , ) query, answers the query using its own and oracles. first queries  (, ) and  (, ). Let  and  be two transcripts returned in response to the queries. Next, obtains two keys and by querying  () and  (). then generates the rest of the protocol transcript, using and as the MAC keys. Finally, returns these messages together with  and  after ordering them properly.
Queries. When makes a  (, ) query, checks if is a message for initiating a new session (of H3PAKE) or the query belongs to an execution of 2PAKE. (1)If both conditions are untrue, responds to the query as that in the original experiment .(2)Otherwise, answers it by making the same query to its own oracle. If the query prompts to accept,  checks if is a server instance against which has mounted an online dictionary attack. If not, makes a () query (and later uses the output of this query as the MAC key of ). (How to handle the other case will be explained below.) Queries. answers these queries using its own oracle.
/ Querise. answers these queries as in the original experiment .
Let be any server instance against which has mounted an online dictionary attack. Let  be the session key that the instance has computed in its execution of 2PAKE. In order for the instance to terminate normally, the adversary has to make a query of the form  (, ) such that  . When makes such a query (i.e., when the event occurs), makes a query against the instance . Note that the instance is fresh as (1) it is partnered with no instance and (2) and must have not been corrupted. Let be the key returned in response to the query. outputs 1, if  , and outputs 0, otherwise. If does not occur, outputs a random bit.
From the simulation above, it is clear to see that Then, Theorem 21 immediately follows since the number of queries asked by against 2PAKE is at most .

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.

Conflict of Interests

The authors of the paper do not have a direct financial relation with any institution or organization mentioned in their paper that might lead to a conflict of interests for any of the authors.

Acknowledgments

This research was supported by Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Science, ICT, and Future Planning (2014R1A1A2002775).