On the security of a simple three-party key exchange protocol without server's public keys.

Authenticated key exchange protocols are of fundamental importance in securing communications and are now extensively deployed for use in various real-world network applications. In this work, we reveal major previously unpublished security vulnerabilities in the password-based authenticated three-party key exchange protocol according to Lee and Hwang (2010): (1) the Lee-Hwang protocol is susceptible to a man-in-the-middle attack and thus fails to achieve implicit key authentication; (2) the protocol cannot protect clients' passwords against an offline dictionary attack; and (3) the indistinguishability-based security of the protocol can be easily broken even in the presence of a passive adversary. We also propose an improved password-based authenticated three-party key exchange protocol that addresses the security vulnerabilities identified in the Lee-Hwang protocol.

1. Introduction

One of the fundamental problems in the areas of cryptography and communication security is to enable two parties communicating over a public network to establish a high-entropy secret key (known as a session key) from their low-entropy passwords which are easy for humans to remember. Password-based authenticated key exchange (PAKE) protocols are designed to solve this problem and often assume the three-party setting, in which each party (commonly called a client) needs to remember only a single password shared with a trusted server [1-11]. The design of secure yet efficient three-party PAKE protocols is notoriously hard and continues to be a subject of active research. A key challenge in designing such protocols is to prevent potential attacks by a malicious client, who is registered with the server, and thus is able to set up normal protocol sessions with other clients.

In this work, we present previously unpublished flaws in the S-EA-3PAKE protocol, a three-party PAKE protocol proposed by Lee and Hwang [4]. The design of the S-EA-3PAKE protocol is relatively simple and efficient and carries a claimed proof of security in the ROR model according to Abdalla et al. [1]. However, despite the claim of provable security, this protocol exhibits major security weaknesses. First, the protocol fails to achieve implicit key authentication, which is the fundamental security property that any given key exchange protocol is expected to provide. We demonstrate this by mounting a man-in-the-middle attack against the protocol. The attacker could be any malicious client. Second, the protocol is vulnerable to an offline dictionary attack by a malicious client and thus other clients cannot be guaranteed of the security of their passwords. Third, the protocol does not achieve semantic security of session keys; that is, session keys established by S-EA-3PAKE are distinguishable from random keys. We show this by mounting a passive attack in the ROR model, thereby invalidating the existing proof of security for S-EA-3PAKE. In addition to reporting the security vulnerabilities, we will also show how to fix the S-EA-3PAKE protocol so that it can achieve implicit key authentication as well as password security and semantic security.

Throughout the paper, we make the following assumptions on the capabilities of the adversary A in order to properly analyze the security properties of three-party PAKE protocols.This assumption is the standard one [12, 13] and is consistent with Dolev-Yao model.

A is either an outsider or an insider who runs in a probabilistic polynomial time.

A has the complete control of all message exchanges between the server and clients. That is, A can eavesdrop, insert, modify, intercept, and delete messages exchanged among the protocol participants at will.

2. The S-EA-3PAKE Protocol

The S-EA-3PAKE protocol [4] is built upon Abdalla and Pointcheval's 2-party PAKE protocol called SPAKE [14]. Let A and B be two clients who wish to establish a session key, and pw and pw denote the passwords of A and B, respectively, shared with a trusted server S. The public parameters required by S-EA-3PAKE include

a large prime p and a generator g of Z *,

two random elements M and N of Z *,

a cryptographic hash function H used as a key derivation function and

a pair of message authentication code (MAC) generation/verification algorithms  (Mac,Ver), where  Ver outputs a bit, with 1 meaning accept and 0 meaning reject.

S-EA-3PAKE is shown in Figure 1 and proceeds as follows.

Figure 1

The S-EA-3PAKE protocol according to Lee and Hwang [4].

Step 1. A sends S and B a protocol initiation message M init = 〈A, B〉 which states “A wants to establish a session key with B.”

Step 2. A and S establish a shared secret key k by running the 2-party protocol SPAKE. Likewise, B and S establish a shared secret key k . More precisely, k and k are established as shown in Table 1.

Table 1

Establishing the secret keys k and k in the S-EA-3PAKE protocol.

pw A → k AS	pw B → k BS
A chooses a random x ∈ Z p*, computes X = g x and X* = X · M pwA, and sends X* to S. At the same time, S chooses a random u ∈ Z p*, computes U = g u and U* = U · N pwA, and sends U* to A. Then, A and S set k AS = g xu.	B chooses a random y ∈ Z p*, computes Y = g y and Y* = Y · M pwB, and sends Y* to S. At the same time, S chooses a random v ∈ Z p*, computes V = g v and V* = V · N pwB, and sends V* to B. Then, B and S set k BS = g yv.

Step 3. A (resp. B) computes the authenticator  (resp. ) and sends it to S.

Step 4. S aborts if either Ver or Ver is untrue. Otherwise, S selects a random s ∈ Z *, computes and sends and to A and B, respectively.

Step 5. A checks if Ver and aborts if the check fails. Otherwise, A computes the key derivation secret, , and the session key, sk = H(A||B||K ). Meanwhile, B checks if Ver and aborts if the check fails. Otherwise, B computes and sk = H(A||B||K ).

Step 6. A and B perform key confirmation by exchanging  and  and verifying them in a straightforward way.

The correctness of S-EA-3PAKE can be easily verified from K = K = g .

3. Previously Unpublished Flaws

3.1. No Implicit Key Authentication

Implicit key authentication of S-EA-3PAKE can be violated via a man-in-the-middle attack by a malicious (registered) client C. A possible attack scenario is as follows.At the end of the attack scenario, A and B believe that they have established a secure session with each other sharing a key, while in fact they have shared their keys with the attacker C. Consequently, S-EA-3PAKE fails to achieve implicit key authentication.

The attacker C blocks the protocol initiation message M init = 〈A, B〉 from reaching S and instead sends (to S) two forged initiation messages M init′ = 〈A, C〉 and M init′′ = 〈C, B〉 which state, respectively, “A wants to establish a session key with C” and “C wants to establish a session key with B.” As a result, S will think that there are two protocol sessions running concurrently; let Π denote the session between A and C and let Π denote the session between C and B.

In both sessions Π and Π, C performs Step 2 through 5 as per the protocol specification with its true identity. This can go undetected since none of the authenticators, σ , σ , σ , and σ , can confirm who the actual protocol participants are. As a result, C will share a session key, sk , with A and another session key, sk , with B.

With sk and sk in hand, C can perform Step 6 (of both sessions) in the straightforward way without being detected; C simply replaces  and  with  and , respectively.

3.2. No Password Security

We now show that S-EA-3PAKE cannot protect clients' passwords against an offline dictionary attack. Assume a malicious client C who wants to find out the passwords of A and B. Let pw be the password of C. Then, an offline dictionary attack by C against both A and B can be mounted as follows.

Phase 1 (gathering password verifiers online).

C conducts a type of man-in-the-middle attack to obtain information required to verify password guesses.

C blocks the initiation message M init = 〈A, B〉 from reaching S and instead sends two forged initiation messages M init′ = 〈A, C〉 and M init′′ = 〈C, B〉, thereby deceiving S into thinking that there are two protocol sessions, Π and Π, running concurrently.

C then performs Step 2 through 5 of both sessions as specified by the protocol except for the following.

When A and B send X* = X · M and Y* = Y · M in Step 2, C makes a copy of these messages for later use.

C sends the same Step 2 message Z* = g · M of its own for both sessions, where z∈ Z *.

When S sends and , respectively, to A and B in Step 4 of the sessions, C replaces and with and , respectively.

Let and denote the two messages sent by S to C in Step 4 of Π and Π, respectively.

Now when A and B exchange the key confirmation messages  and , C intercepts these messages and instead sends the clients “a failure message” to trick them into believing that, due to an unexpected error, their partner has failed to compute the session key and thus has aborted the protocol.

Phase 2 (verifying password guesses offline).

C can now verify password guesses both on pw and pw using the obtained information and , respectively. (For simplicity, we here describe this verification phase only for pw ; the case for pw proceeds correspondingly).

Step 1. C computes where k is the secret key shared between C and S in Step 2 of session Π.

Step 2. Note that, since was replaced with , A must have computed K as With this in mind, C makes a guess pw ′ on the password pw and computes

Step 3. A verifies the correctness of pw ′ by checking that σ is equal to σ ′. If they are equal, then pw ′ is the correct password with an overwhelming probability.

Step 4. C repeats Steps 2  and  3 (of this verification phase) until a correct password is found.

This offline dictionary attack can be trivially simplified to an insider-attacker version whereby one of the two clients, A and B, tries to discover the other client's password. After all, the S-EA-3PAKE protocol cannot prevent any (malicious) client from mounting an offline dictionary attack against any other clients.

3.3. No Semantic Security

Finally, we point out that the S-EA-3PAKE protocol does not achieve the semantic security of session keys. In S-EA-3PAKE, the session key sk (resp. sk ) is used as the MAC key in generating the authenticator  (resp. ). This oversight leaks some information about the session key and allows an adversary to distinguish the real session key from a random key chosen from the session key space. Indeed, S-EA-3PAKE can be easily broken even in the presence of a passive adversary who asks only a single  Execute and  Test query. A simple attack by such an adversary A can be described as follows.This attack invalidates the existing proof of security for S-EA-3PAKE [4]. We refer the reader to the work of Bellare et al. [13] for a possible countermeasure.

First, A makes an Execute(Π query, where Π*, Π*, and Π* denote any instance of A, B, and S, respectively. This query prompts an honest execution of the protocol between the three instances and will return the transcript of the protocol execution.

Next, A makes a Test(Π query and receives a key in response to the query.

Then, A computes  and checks if σ ′ is equal to σ . The key is real if they are equal and otherwise it is random.

4. An Improved Three-Party PAKE Protocol

In this section, we propose an improved three-party PAKE protocol which achieves semantic security and is secure against man-in-the-middle attacks as well as offline dictionary attacks. Let S be the trusted server and let A and B be two registered clients of S who wish to establish a shared session key. We denote the passwords of A and B by pw and pw , respectively. Our improved protocol uses the following public parameters:The improved protocol is illustrated in Figure 2 and its description is as follows.

Figure 2

Our improved three-party PAKE protocol.

a finite cyclic group G of prime order q and a generator g of G;

two random elements M and N of G;

a cryptographic hash function H : {0,1}* → {0,1}, where l represents the bit length of session keys;

a pair of message authentication code (MAC) generation/verification algorithms (Mac, Ver), where Ver outputs a bit, with 1 meaning accept and 0 meaning reject.

Step 1. A sends S and B a protocol initiation message M init = 〈A, B〉 which states “A wants to establish a session key with B.”

Step 2. A and S establish a shared secret key  k by running the 2-party protocol SPAKE. Likewise, B and S establish a shared secret key k . More precisely, k and k are established as shown in Table 2. (Note in Table 2 that all the random exponents are selected from Z as our protocol works in a group of prime order q.)

Table 2

Establishing the secret keys k and k in our improved protocol.

pw A → k AS	pw B → k BS
A chooses a random x ∈ Z q, computes X = g x and X* = X · M pwA, and sends X* to S. At the same time, S chooses a random u ∈ Z q, computes U = g u and U* = U · N pwA, and sends U* to A. Then, A and S set k AS = g xu.	B chooses a random y ∈ Z q, computes Y = g y and Y* = Y · M pwB, and sends Y* to S. At the same time, S chooses a random v ∈ Z q, computes V = g v and V* = V · N pwB, and sends V* to B. Then, B and S set k BS = g yv.

Step 3. A (resp. B) computes the authenticator  (resp. ) and sends it to S.

Step 4. S aborts if either Ver or Ver, σ ) = 1 is untrue. Otherwise, S selects a random s ∈ Z , computes and sends and to A and B, respectively.

Step 5. A checks if  and aborts if the check fails. Otherwise, A computes the key derivation secret, , and the session key, sk = H(A||B||K ). Meanwhile, B checks if  and aborts if the check fails. Otherwise, B computes and sk = H(A||B||K ).

Step 6. A and B perform key confirmation by exchanging σ = H(K ||A||B) and σ = H(K ||B||A) and verifying them in a straightforward way.

It can be easily verified that A and B compute session keys of the same value since K = K = g . Compared with the S-EA-3PAKE protocol, our improved protocol does not require the computations of and and simplifies the computations of K and K . Therefore, it is fair to say that our protocol performs slightly better than the S-EA-3PAKE protocol.

Man-in-the-middle attacks and offline dictionary attacks such as the ones we mounted against the S-EA-3PAKE protocol are no longer valid against our improved protocol since the authenticators, σ , σ , σ , and σ , can now confirm who the actual protocol participants are. Moreover, our protocol achieves semantic security as the key derivation secrets K and K instead of the session keys sk and sk are used in generating the authenticators σ = H(K ||A||B) and σ = H(K ||B||A).

5. Concluding Remarks

The model where S-EA-3PAKE was claimed to be provably secure does not allow the adversary to ask Corrupt queries and thus cannot capture any kind of attacks that can be mounted by malicious clients. Accordingly, neither the man-in-the-middle attack nor the offline dictionary attack described in this work can be captured in the proof model. This situation is clearly unacceptable, from both theoretic and practical perspectives, and highlights the importance of considering Corrupt queries when proving security of three-party PAKE protocols. Although both the man-in-the-middle attack and the dictionary attack can be easily prevented by modifying the computations of the authenticators σ , σ , σ , and σ , the existence of a security proof for the S-EA-3PAKE protocol in a stronger model remains an open question. We finally note that all the three attacks presented in this work against S-EA-3PAKE also apply to the S-IA-3PAKE protocol [4], a simplified variant of S-EA-3PAKE. This becomes clear as soon as we notice that S-IA-3PAKE is different from S-EA-3PAKE only in the fact that it does not require the transmission of the authenticators σ ,  σ , σ , and σ .