Abstract

Protocols for password-only authenticated key exchange (PAKE) in the three-party setting allow two clients registered with the same authentication server to derive a common secret key from their individual password shared with the server. Existing three-party PAKE protocols were proven secure under the assumption of the existence of random oracles or in a model that does not consider insider attacks. Therefore, these protocols may turn out to be insecure when the random oracle is instantiated with a particular hash function or an insider attack is mounted against the partner client. The contribution of this paper is to present the first three-party PAKE protocol whose security is proven without any idealized assumptions in a model that captures insider attacks. The proof model we use is a variant of the indistinguishability-based model of Bellare, Pointcheval, and Rogaway (2000), which is one of the most widely accepted models for security analysis of password-based key exchange protocols. We demonstrated that our protocol achieves not only the typical indistinguishability-based security of session keys but also the password security against undetectable online dictionary attacks.

1. Introduction

Authenticated key exchange is one of the most fundamental problems in cryptography and network security. In 1992, Bellovin and Merritt [1] introduced encrypted key exchange (or EKE) protocols, which allow

arbitrary two parties, who share only a low-entropy password, to establish a common high-entropy secret key (called a session key) over an insecure public network.

Since the work of Bellovin and Merritt [1], password-only authenticated key exchange (PAKE) protocols have attracted much greater attention mainly due to the persistent popularity of passwords as a practical (and cheap) authentication method [2]. Since the publication of the first EKE protocol (with only heuristic security arguments), many provably secure PAKE protocols have been published. Recent examples include the protocol of Katz and Vaikuntanathan [3], which enjoys both round optimality and provable security in the standard model (i.e., without random oracles and ideal ciphers).

A major challenge in designing PAKE protocols is to protect passwords from a dictionary attack, in which an adversary enumerates all possible passwords while testing each one against known password verifiers in order to determine the correct one. The design of two-party PAKE protocols secure against dictionary attacks has been extensively studied over the past two decades and is now fairly well understood. However, three-party PAKE protocols have received far less attention and preventing dictionary attacks is more challenging in the three-party setting. Unlike the two-party setting that assumes the same password is shared between the two parties, the three-party setting assumes that the two parties (commonly known as clients) wishing to establish a session key do not share the same password but hold their individual password shared only with a trusted server. This implies that in the three-party setting, a malicious client can attempt to mount an insider dictionary attack against its partner client. Indeed, many published three-party PAKE protocols were subsequently found to be vulnerable to an insider online/offline dictionary attack (e.g., [410]).

It is widely regarded that the design of key exchange protocols (including PAKE protocols) is notoriously hard, and conducting security analysis for such protocols is time-consuming and error-prone [1113]. The many flaws discovered in published protocols have promoted the use of formal models and rigorous security proofs [1416]. In the provable security paradigm for protocol analysis, a deductive reasoning process is adopted whereby emphasis is placed on a proven reduction from the problem of breaking the protocol to another problem believed to be computationally hard. A complete mathematical proof with respect to cryptographic definitions provides a strong assurance that a protocol is behaving as desired. It is now standard practice for protocol designers to provide security proofs in a well-defined formal model in order to assure protocol implementers about the security properties of protocols.

Over the past decade, we have seen a number of PAKE protocols proposed in the three-party setting [48, 1729]. Many of these published protocols either did not have a proof of security [5, 6, 17, 2225] or were subsequently found to be flawed [410, 12, 23, 24, 27, 3036]. There are only a handful of provably secure three-party PAKE protocols [4, 7, 8, 21] whose claimed security properties have not been invalidated. However, there are limitations in the security proof of these protocols. For example, the protocols of [7, 8] are proven secure in the random oracle model. Although a proof of security in the random oracle model is definitely better than having no proof, it may not guarantee security in the real world (currently an open question). The protocols of [4, 21] are proven secure in a restricted model where the adversary is not allowed to corrupt protocol participants. Note that a protocol proven secure in such a restricted model cannot guarantee its security against attacks by malicious clients including insider online/offline dictionary attacks. (Readers who are unfamiliar with formal security models are referred to Section 2.1.) Although Yang and Cao [37] proposed a new three-party key exchange protocol that was proven secure in the standard model, the protocol is based on the ElGamal encryption scheme and thus requires a server's public key as well as clients' passwords to be preestablished before the protocol is ever executed. We refer the readers to [33, 3844] for other recently published protocols designed to work in a “hybrid” setting where a cryptographic key is required in addition to passwords.

To the best of our knowledge, there is no published three-party PAKE protocol whose security is proven secure in the standard model that allows an adversary to corrupt protocol participants. In this work, we present the first three-party PAKE protocol that achieves provable security in the standard model against an active adversary with the corruption capability. We prove the security of session keys for our protocol in the widely accepted indistinguishability-based model of Bellare, Pointcheval, and Rogaway [14]—this model is, probably, one of the most popular proof models in the provable security paradigm for key exchange protocols. However, the indistinguishability-based security of session keys proven in the Bellare-Pointcheval-Rogaway model (and several other standard models) does not imply the security of passwords against undetectable online dictionary attacks, in which each guess on the password is checked undetectably via an online transaction with the server (see Section 2.3 for more details). We address this problem by providing a separate proof of security for the protocol against undetectable online dictionary (UDOD) attacks. This second proof is compact and elegant and does not rely upon idealized assumptions about the cryptographic primitives. Table 1 compares our protocol against other provably secure three-party PAKE protocols in terms of security proofs.

The remainder of this paper is structured as follows. Section 2 describes a formal proof model along with the associated definitions of security. Section 3 presents our proposed three-party PAKE protocol. In Section 4, we prove that the proposed protocol achieves not only the typical indistinguishability-based security of session keys but also the password security against undetectable online dictionary attacks. We conclude the paper in Section 5.

2. Formal Setting

In this section, we(1)first describe a security model adapted from the Bellare-Pointcheval-Rogaway 2000 model [14],(2)define a typical indistinguishability-based security of session keys, which we call the SK security,(3)provide a simple and intuitive definition of security against undetectable online dictionary attacks.

2.1. The Security Model

Protocol Participants. Let be the set of all clients registered with the trusted authentication server . Clients who are both registered with may run a three-party PAKE protocol at any point in time to establish a session key. Let . A party may have several instances involved in distinct, possibly concurrent, executions of protocol . We use to denote the th instance of party . A client instance is said to accept when it successfully computes its session key in a protocol execution.

Long-Term Keys. Each client chooses a password from a fixed dictionary   PW and shares it with the server via a secure channel. Accordingly, holds all the passwords . Each password is used as the long-term secret key of and .

Partnership. The notion of partnership is a key element in defining the security of the protocol. Two instances are partners if both participate in a protocol execution and establish a (shared) session key. We define the partnership relations between instances using the notions of session identifiers and partner identifiers (see [45] 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.). A session identifier (sid) is a unique identifier of a protocol session and is defined as a function of the messages transmitted in the protocol session. We use  to denote the  sid of instance . A partner identifier (pid) is the set of participants of a specific protocol session. Instances should receive as input a  pid before they can run the protocol. By , we denote the  pid given to instance . Notice that  consists of three participants: server , client , and another client with whom believes it runs the protocol. We say that any two instances and are partners if (1) both and have accepted, (2)  , and (3)  .

Adversary. In the model, the probabilistic polynomial-time (PPT) adversary, , controls all the communications that take place between parties via a predefined set of oracle queries. For example, the adversary can ask participants to reveal session keys and passwords using  Reveal and  Corrupt queries as described below.(i)Execute(). This query models passive eavesdropping of a protocol execution. It prompts an honest execution of the protocol between the instances , and . The transcript of the protocol execution is returned as the output of the query.(ii)Send(). This query models active attacks against the protocol. It sends message to instance and returns the message that sends out in response to . A query of the form  Send(,  start : ) prompts to initiate the protocol with .(iii)Reveal(). This query returns the session key . This query captures the notion of known key security (and 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). Any client, , upon receiving such a query and if it has accepted and holds some session key, will send this session key back to . However, the adversary is not allowed to ask this query if it has already made a  Test query to the instance or its partner instance (see below for explanation of the  Test oracle).(iv)Corrupt(). This query captures not only the notion of forward secrecy but also unknown key share attacks and insider attacks. The query provides the adversary with ’s password . Notice that a  Corrupt query does not result in the release of the session keys since the adversary already has the ability to obtain session keys through  Reveal queries. If (i.e., the server is corrupted), all clients’ passwords stored by the server will be returned.(v)Test(). This query is the only oracle query that does not correspond to any of the adversary’s abilities. If   has accepted with some session key and is being asked a  Test() query, then depending on a randomly chosen bit , the adversary is given either the actual session key (when ) or a session key drawn randomly from the session key distribution (when ). The adversary can access the  Test oracle as many times as necessary. All the queries to the oracle are answered using the same value of the hidden bit . Namely, the keys returned by the  Test oracle are either all real or all random. But, we require that for each different set of partners, the adversary should access the  Test oracle only once.We represent the number of queries used by an adversary as an ordered sequence of five nonnegative integers, , where the five elements refer to the numbers of queries that the adversary made, respectively, to its  Execute,   Send,   Reveal,   Corrupt, and   Test oracles. We call this usage of queries by an adversary the query complexity of the adversary.

2.2. Session Key (SK) Security

We now define the basic security, called the SK security, of a 3-party PAKE protocol. As usual, we define the SK security via the notion of freshness. 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. The formal definition of freshness is explained in Definition 1.

Definition 1. An instance is fresh if none of the following occurs: (1) queries   Reveal or   Reveal, where is the partner of and (2) queries , for some , before or its partner accepts.

The SK security of a 3-party PAKE protocol is defined in the context of the following two-stage experiment.

Stage 1. makes any oracle queries at will except that:(i) is not allowed to ask the  Test() query if the instance is unfresh.(ii) is not allowed to ask the  Reveal() query if it has already made a  Test query to or , where is the partner of .

Stage 2. Once decides that Phase is over, it outputs a bit as a guess on the hidden bit chosen by the   Test oracle. is said to succeed if .
Let   Succ be the event that succeeds in this experiment. Then we define the advantage of in breaking the SK security of protocol as where the maximum is over all   PPT adversaries with time complexity at most and query complexity at most .

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

2.3. Modelling Undetectable Online Dictionary Attacks

The SK security does not imply security against undetectable online dictionary attacks. In other words, a 3-party PAKE protocol that is not secure against an undetectable online dictionary attack may be rendered SK-secure. To see this, suppose that a 3-party PAKE protocol is susceptible to undetectable online dictionary attacks whereby an attacker can find out the password of any registered client . Then, we can construct an adversary who attacks protocol with advantage as follows.

Corruption. If is a registered client, queries   Corrupt to obtain the password . Otherwise, skips this step.

Undetectable Online Dictionary Attacks. Next, runs the protocol in the same way as conducts its undetectable online dictionary attacks 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 as a result of the attacks.

Impersonation. then initiates a new protocol session by querying   Send,   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. The instance is fresh as (1) no   Reveal query has been made on or its partner (which does not exist) and (2) no   Corrupt query has been made against any of , , and . Thus, may ask the   Test() query. Since can compute the session key by itself, it follows that and thus .

Since verifying the correctness of a password guess may require more than one   Send queries to be asked, may have to ask   Send queries as many times as , for some integer , to correctly determine the password . Then, even if , the following holds for some : and the protocol is rendered SK-secure by Definition 2.

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 undetectable 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 undetectable online dictionary attacks.

Definition 3. The   Send 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   Send query asked to an instance of by which, believes, was sent and (2) the adversary queried neither   Corrupt nor   Corrupt.

In Definition 3, 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   Reveal queries.

Consider the two-stage experiment described in the previous section. Let   Undet be the event that in the 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 undetectable online dictionary attack if the event   Undet occurs.

Definition 4. A 3-party PAKE protocol is secure against an undetectable online dictionary attack if, for any PPT adversary asking at most    Send queries, [Undet] is only negligibly larger than , where is as in Definition 2.

3. Our Proposed Protocol

As we have earlier claimed, our proposed protocol presented in this section is the first three-party PAKE protocol proven secure in the standard model against an active adversary who has the corruption ability.

3.1. Preliminaries

We begin by reviewing some cryptographic primitives which underlie the security of our protocol.

Decisional Diffie-Hellman (DDH) Assumption. Let be a cyclic (multiplicative) group of prime order . Since the order of is prime, all the elements of , except , are generators of . Let be a random fixed generator of and let be randomly chosen elements in where . Informally stated, the DDH problem for is to distinguish between the distributions of and , and the DDH assumption is said to hold in if it is computationally infeasible to solve the DDH problem for . More formally, we define the advantage of in solving the DDH problem for as . We say that the DDH 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. Let be a message authentication code (MAC) scheme. The key generation algorithm   Gen takes as input a security parameter and outputs a key chosen uniformly at random from . The MAC generation algorithm   Mac takes as input a key and a message and outputs a MAC (also known as a tag) . The MAC verification algorithm   Ver 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 probability that an adversary succeeds in breaking the existential unforgeability of under adaptive chosen message attacks. 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 its MAC generation and verification oracles, respectively.

Two-Party PAKE Protocols. Let   be a two-party PAKE protocol that outputs session keys distributed in . We assume that   is SK-secure against an adversary who is given access to all the oracles:   Send,   Execute,    Reveal,   Corrupt, and   Test. Let   be the advantage of an adversary in breaking the SK security of  . We require that, for all  PPT adversaries making at most    Send queries,   is only negligibly larger than . We denote by  the maximum value of  over all  PPT adversaries with time complexity at most and query complexity at most .

3.2. Protocol Description

Let and be two clients who wish to establish a session key, and let be a trusted server with which and have secretly shared their respective passwords and . Our protocol proceeds as follows.

Step 1. and establish a shared secret key by running the two-party protocol  . Likewise, and establish a shared secret key .

Step 2. (resp., and ) selects a nonce (resp., and ) at random from and sends (resp., and ) to the other two parties. All the parties (, , and ) define their session identifiers as  .

Step 3. chooses a random , computes and  , and sends to . Meanwhile, chooses a random , computes and  , and sends to .

Step 4. checks that   and  . If either of these is untrue, aborts the protocol. Otherwise, computes   and   and sends and to and , respectively.

Step 5. computes the session key if  , while computes the session key if  . and abort the protocol if their verification fails.

The operation of this protocol is illustrated in Figure 1. Steps 1 and 2 of the protocol are independent and can be performed in parallel. The session-key computation in the protocol is the same as in the Diffie-Hellman key exchange protocol (i.e., ). Hence, it is straightforward to verify the correctness of the protocol.

4. Security Proofs

In this section we prove that our three-party PAKE protocol is SK-secure and is resistant to undetectable online dictionary attacks. The proofs of both properties rely on neither random oracles nor ideal ciphers. Therefore, if   2PAKE is instantiated with a protocol proven secure in the standard model (e.g., [3, 49]), our three-party PAKE protocol would also be provably secure in the standard model. Hereafter, we denote our protocol by   3PAKEsm (“sm” for “standard model”).

4.1. Proof of SK Security

We first claim that, if the underlying two-party protocol   2PAKE is SK-secure, then the   3PAKEsm protocol is SK-secure as well under the DDH assumption in and the security of the MAC scheme .

Theorem 5. Let . For any adversary with query complexity at most and time complexity at most , its advantage in attacking protocol   3PAKEsm is bounded by where and is the maximum time required to perform an entire experiment involving an adversary who attacks protocol  3PAKEsm with time complexity .

Proof. Assume an adversary attacking protocol   3PAKEsm with time complexity and query complexity . We prove Theorem 5 by introducing a sequence of experiments and bounding the difference in 's advantage between two consecutive experiments. is the original experiment (described in Section 2.2) in which attacks the actual protocol, and is the experiment in which the advantage of is . Let   be the event that correctly guesses the hidden bit (chosen by the  Test oracle) in experiment . By definition, we get  .
Before providing details of the proof, we first define the notion of an uncorrupted instance.

Definition 6. We say an instance is clean if no one in   has been asked a   Corrupt query. Otherwise, we say it is unclean.

Experiment . We modify the experiment so that each different MAC key is chosen uniformly at random from for all clean instances. The difference in 's success probability between and is bounded by

Claim 1.

Proof. Assume that the advantage of in attacking protocol   3PAKEsm is different between two experiments and . Then we prove the claim by constructing, from , an adversary   attacking protocol   2PAKE with time complexity and query complexity .
begins by choosing a bit uniformly at random.   then invokes as a subroutine and answers the oracle queries of on its own as follows.
Execute Queries.   answers   Execute queries of by making   Execute and   Test queries to its own oracles. Specifically,   handles each   Execute(, , ) query as follows.(i)If anyone in has been corrupted, then   answers the   Execute query as in experiment .(ii)Otherwise,   first makes two queries   Execute() and   Execute(). Let   T2PAKE and   be two transcripts returned in response to the   Execute queries. Next,   makes the queries   Test() and   Test() and receives in return two keys and (either real or random).   then generates the messages of Steps 24 of protocol   3PAKEsm, using and as the MAC keys. Finally,   returns these messages prepended by   T2PAKE and  .
Send Queries. At a high level, the simulation of the   Send oracle is similar to that of the   Execute oracle. Specifically,   handles each   Send(, ) query as follows. (i)If the instance is clean or the message belongs to Step 2 or later steps, then   answers the query as in experiment .(ii)Otherwise,   answers it by making the same query to its own   Send oracle. If the query causes to accept, then   also makes a   Test() query (if it had not previously asked a   Test query to the partner of ). As in the simulation of the   Execute oracle,   uses the output of this   Test query as the MAC key in generating the messages of Steps 24 of protocol   3PAKEsm.
Reveal Queries. These queries are answered in the obvious way. Namely,   responds to the query   Reveal() by returning the session key .
Corrupt Queries. When queries   Corrupt(),   makes the same query to its own   Corrupt oracle and simply forwards the output to .
Test Queries.   answers these queries according to the bit 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 .
Now at some point in time, when terminates and outputs its guess ,   outputs 1 if and outputs 0 otherwise.
From the simulation above, it is easy to see that   has at most time complexity and query complexity . The advantage of   in attacking protocol   2PAKE is immediate if we notice the following. (i)The probability that   outputs when its   Test oracle returns real session keys is equal to , the probability that correctly guesses the bit in experiment .(ii)The probability that   outputs when its   Test oracle returns random keys is equal to , the probability that correctly guesses the bit in experiment . This means that   =. Claim 1 then follows.

Experiment . Let   Repeat be the event that a nonce selected by an instance of a party is selected again by another instance of the same party. The experiment is aborted, and the adversary does not succeed, if the event   Repeat occurs. This is the only difference between and . By a straightforward calculation, we get the following.

Claim 2.

Experiment . Let   Forge be the event that the adversary makes a   Send query of the form   Send(, ) before querying   Corrupt, for some  , such that (1) is a valid tag on  and (2) no oracle had not previously generated a tag on . If  Forge occurs, this experiment is aborted and the adversary does not succeed. Then we have the following.

Claim 3.

Proof. Assuming that the event   Forge occurs, we construct, from , an algorithm who 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) is a valid tag on the message (i.e.,   and (2) had not previously queried its oracle   on the message .
Let be the number of all active sessions that initiates by asking a   Send query. First, chooses a random . then simulates the oracle calls of as in experiment ; except that in the th session, it answers   Send queries by accessing its MAC generation and verification oracles. If   Forge occurs in the th session, halts and outputs the message/tag pair generated by as its forgery. Otherwise, halts and outputs a failure indication. This simulation is perfect unless the adversary makes a   Corrupt query against a participant of the th session. But note that the event of making such a   Corrupt query should not happen if   Forge occurs in the th session.
From the simulation, it is immediate that  . Since , we get   Pr. Then, Claim 3 follows by noticing that has at most time complexity and makes at most queries to    and   .

Experiment . This experiment is different from in that the session key sk of each pair of instances partnered via an   Execute query is chosen uniformly at random from instead of being computed as . As the following claim states, the difference in ’s advantage between and is negligible if the DDH assumption holds in .

Claim 4.

Proof. Assume that the advantage of is nonnegligibly different between and . We prove the claim by constructing, from , a distinguisher that solves the DDH problem in . Let be an instance of the DDH problem given as input to . begins by choosing a bit uniformly at random. then invokes as a subroutine and proceeds to simulate the oracles. answers all the oracle queries of as in experiment , except that it handles each   Execute(, ) query by (1)selecting two random ,(2)computing and ,(3)returning a transcript generated with and in place of and ,(4)then setting . Let be the output of . outputs 1 if and outputs 0, otherwise.
Then, the following is clear:(i)The probability that outputs on a true Diffie-Hellman triple is exactly the probability that correctly guesses the bit in experiment .(ii)The probability that outputs on a random triple is exactly the probability that correctly guesses the bit in experiment . This completes the proof of Claim 4.

Experiment . In this experiment, the session key of each instance activated by a   Send query is chosen uniformly at random from if no one in     has been corrupted before determines its session identifier   . The difference in ’s advantage between and is bounded by the following.

Claim 5.

Proof. The proof of this claim is essentially similar to that of Claim 4. From the adversary whose advantage is nonnegligibly different between and , we construct a distinguisher that solves the DDH problem in . Let be an instance of the DDH problem given as input to . begins by selecting a bit uniformly at random and generating a list   DDHList which is used to link an instance of the DDH problem to a session identifier, then runs as a subroutine and simulates the oracles. It handles all the queries of as in experiment except for   Send queries.
Consider a query of the form    which delivers a random nonce to instance . Whenever such a query is made, answers it as follows. (i)If is not the last nonce that is expected to receive, simply waits for the next nonce.(ii)Otherwise, defines    and checks that anyone in    was corrupted.(a)If so, responds to the query as in experiment .(b)If not, checks if the list   DDHList contains an entry of the form   , where .(1)If it does, computes    and returns in response to the query.(2)Otherwise, selects two random , computes , , , and   , returns to , and finally adds the tuple    to   DDHList.
When makes a  Send query that causes an instance to accept, checks if   DDHList contains an entry of the form  . If so, sets . Otherwise, computes as in experiment . For all other  Send queries of , answers them as in experiment . Now when terminates and outputs its guess , outputs 1 if and outputs 0 otherwise.
One can easily see the following. (i)The probability that outputs on a true Diffie-Hellman triple is exactly the probability that correctly guesses the bit in experiment .(ii)The probability that outputs on a random triple is exactly the probability that correctly guesses the bit in experiment .This implies Claim 5.

In experiment , the session keys of all fresh instances are chosen uniformly at random from and thus the adversary obtains no information on the bit chosen by the   Test oracle. Therefore, it follows that   . This result combined with the previous claims yields the statement of Theorem 5.

4.2. Proof of Resistance to Undetectable Online Dictionary Attacks

We now claim that   3PAKEsm is secure against undetectable online dictionary attacks as long as the   2PAKE protocol is SK-secure.

Theorem 7. Let   Undet be as defined in Section 2.3 and assume that for any PPT adversary asking at most    Send queries,   is only negligibly larger than  . Then, for any   PPT adversary asking at most    Send queries,   is only negligibly larger than  .

Proof. Let be a  PPT adversary who asks    Send queries in mounting an undetectable online dictionary attack against   3PAKEsm. Consider the experiment described in the proof of Theorem 5 (see Section 4.1). By   (resp.,  ), we denote the event   Undet defined in experiment (resp., ). We prove Theorem 7 by first proving Claim 6 and then Claim 7.

Claim 6. is only negligibly larger than  .

Claim 7. is only negligibly larger than  .

Proof of Claim 6. We prove the claim by constructing an adversary who attacks the SK security of   2PAKE witfh advantage equal to  .
chooses a random bit and invokes the adversary as a subroutine. then simulates the oracles for in the exactly same way as in the simulation for the proof of Claim 1. outputs 1 if   occurs and 0 otherwise. From the way the oracles are simulated, it is easy to see the following. (i)The probability that   outputs when its   Test oracle returns real session keys is equal to the probability that the event   Undet occurs in experiment .(ii)The probability that outputs when its   Test oracle returns random keys is equal to the probability that the event   Undet occurs in experiment . Since makes at most    Send queries, we obtain the statement of Claim 6.

Proof of Claim 7. Assume that   is nonnegligibly larger than  . Given the adversary , we construct an adversary against   2PAKE who asks at most    Send queries but has an advantage nonnegligibly larger than  .
runs as a subroutine while simulating the oracles on its own. handles all the oracle queries of as in the experiment except for   Send queries. When makes a   Send(, ) query, checks if is a message for initiating a new session (of   3PAKEsm) or the   Send query belongs to an execution of   2PAKE. (1)If both are untrue, responds to the query as in experiment .(2)Otherwise, answers it by making the same query to its own   Send oracle. If the query prompts to accept, then checks if is clean.(a)If so, sets the MAC key of to be a random key drawn uniformly from .(b)Otherwise, makes a   Reveal() query and sets the MAC key of to be the output of this   Reveal query.
Let be any server instance against which has mounted an online dictionary attack. Let be the session key (i.e., the MAC 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   Send(, ) such that   . When makes such a    Send query (i.e., when the event  occurs), makes a   Test query against the instance . Note that the instance is fresh as it is partnered with no instance and and must have not been corrupted. Let be the key returned in response to the   Test query. outputs 1 if    and outputs 0, otherwise. If   does not occur, outputs a random bit. Then, it is not hard to see that This completes the proof of Claim 7.

Theorem 7 immediately follows from Claims 6 and 7.

5. Conclusion

In this work, we have presented a three-party PAKE protocol whose security does not rely on the existence of random oracles. The model that we used to prove the security of our protocol allows the adversary to ask    Corrupt queries and thus captures insider attacks as well as forward secrecy. It is a known fact that proving the security of protocols in such a model is of particular importance in the three-party setting as insider dictionary attacks are most serious threats to three-party PAKE protocols. To the best of our knowledge, our protocol is the first three-party PAKE protocol proven secure against insider, active adversaries in the standard model (i.e., without random oracles and ideal ciphers). Another advantage our protocol has over previously published protocols is that it also achieves provable security against undetectable online dictionary attacks. The latter property is also significant as designing three-party PAKE protocol secure against undetectable online dictionary attacks is an ongoing challenge (as evidenced by the number of three-party PAKE protocols found to be vulnerable to an undetectable online dictionary attack). We leave it as a future work to design a three-party PAKE protocol that achieves not only provable security in the standard model but is more efficient than our protocol.

Conflict of Interests

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

Acknowledgment

This work was supported by the Priority Research Centers Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education (NRF-2010-0020210).