1 Introduction

Authenticated key exchange protocols are essential for bootstrap a secure wireless communications over the unprotected public channel. The protocol allows protocol participants to confirm the identities of their communication partners and agree a common session key to encrypt and sign messages in their communication session. Password-based authenticated key exchange protocols authenticate their partner using human-memoriable passwords. The security of these protocols rely on whether users are able to select high entropy passwords so that the adversary will not be able to guess the password on a random-password-guessing protocol interaction.

Three-party password-based authenticated key exchange (3PAKE) protocols are a family of protocols that set up secure communication for three parties using passwords (Chen et al. 2012; Xiong et al. 2017b; Chang et al. 2005; Chang and Chang 2004; Lee et al. 2005; Zhu 2017; Chang et al. 2011; Lin and Fu 2013; Xiong et al. 2017a; Zhu and Zhang 2017).

In the three-party setting, a trusted third party (TTP) is introduced to keep the passwords for the users and help the other two user parties in authentication and key exchange. It is required that a secure 3PAKE protocol (Li et al. 2018; Chen et al. 2018b; Chen et al. 2018a; Chen et al. 2016; Shen et al. 2015) to meet the following requirements for practical use:

  1. 1.

    Secure against on-line password guessing attacks: A 3PAKE protocol authenticates a user using its password. It is unavoidable that an attacker attempts to perform trial-and-error to guess the password by running the protocol many times. We say a protocol is secure against on-line password guessing attacks if the protocol can detect the failure login attempt of a particular user account. Under such circumstance other protocol participants (most often the TTP) can suspect the suspicious user account.

  2. 2.

    Secure against off-line password guessing attacks: A 3PAKE protocol is said to be secure against off-line password guessing attacks if no attacker can deduce a user password from a finite times of communication records.

  3. 3.

    Secure against impersonation attacks: A 3PAKE protocol is said to be secure against impersonation attacks if no attacker can impersonate another party without its password.

  4. 4.

    Secure against replay attacks: A 3PAKE protocol is said to be secure against replay attacks if no attacker can be authenticated by replaying some past communication records.

  5. 5.

    Secure against Man-In-The-Middle attacks: A 3PAKE protocol is said to be secure against Man-In-The-Middle (MITM) attacks if no attacker can allow some parties mutually authenticate each other while fail to agree the same session key.

  6. 6.

    Able to provide mutual authentication: A 3PAKE protocol is said to be able to provide mutual authentication if all protocol participants are convinced they are communicating with the trusted partners by the end of the protocol.

  7. 7.

    Secure against Known-session key attacks: A 3PAKE protocol is said to be secure against known-session key attacks if no any attacker who is given the session key of a past session can be able to be authenticated in the future, nor can be able to deduce the users password.

  8. 8.

    Able to provide session key perfect forward secrecy: A 3PAKE protocol is said to be able to provide session key perfect forward secrecy if no any attacker who is given the password would be able to recover the session key agreed in the past.

In 2012, Tallapally proposed a three-party password-based protocol (Farash and Attari 2014) for wireless communication and claimed that their protocol could meet various secure requirements. However, Farash and Attari pointed out that Tallapally’s 3PAKE protocol is vulnerable to undetectable on-line password guessing attacks and off-line password guessing attacks, and then proposed their improved scheme (Tallapally 2012). Unfortunately, Lu et al. (2015) observed that Farash and Attari protocol cannot resist off-line password guessing attacks as claimed. In order to defend such attacks, Lu et al. also proposed a modified 3PAKE protocol. In this paper, we find that Lu et al.’s protocol still cannot resist off-line password guessing attacks. In this paper we proposed a new 3PAKE for wireless communication. The proposed scheme is then validated by Proverif. Through the performance and security analysis, we show that the proposed scheme is more secure with similar efficiency.

The remainder of the paper is organized as follows. Section 2 briefly review the protocol of Lu et al.’s. We analyze their protocol and show the protocol cannot resist offline password guessing attack in Sect. 3. In Sect. 4, we propose our new three-party password-based protcol. Then we analyze the security and validity of our protocol with the automatic cryptographic protocol tool proverif in Sect. 5. Finally, our conclusion is present in Sect. 6.

2 Review of Lu et al.’s protocol

In this section, we review Lu et al.’s protocol briefly. The protocol involves three parties, the user A, B, and the server S. Each user shares the identity and the hashed password h(pw) with S. The server initializes the system with a large prime p and a generator g. Following steps explain Lu et al.’s protocol. For simplicity, modulo p operations are hidden from computations. Note that notation used in this paper are summarized in Table 1.

Table 1 Notations used in this paper
Full size table
  1. 1.

    A selects two nonces x, \(r_a \in Z_p^*\) and computes \(H_a\) = \(h(pw_a) \oplus r_a\), \(V_a\) = \(h(pw_a||r_a||A)\), and \(R_a\) = \(g_x \oplus V_a\). Then, A sends \(m_1\) = \(\{H_a, V_a, R_a, A\}\) to S. In the same time, B performs similarly as A. B first selects two nonces y, \(r_b \in Z_p^*\) and computes similarly. Then, B sends \(m_1'\) = \(\{H_b, V_b, R_b, B\}\) to S.

  2. 2.

    After S receives the messages, S retrieves the hashed passwords to recover \(r_a\) and \(r_b\). Then, S checks the value \(V_a\) and the value \(V_b\) using corresponding values. If they are verified successfully, S computes \(R_a'\) = \(R_a \oplus h(A||pw_a||r_a)\), and \(R_b'\) = \(R_b \oplus h(A||pw_b||r_b)\). Then, S selects a nonce z and computes \(N_s\) = \(g^z\), \(K_{sa}\) = \((R_a')^z\), \(K_{sb}\) = \((R_b')^z\), \(T_a\) = \(h(pw_a||r_a||K_{sa}||A)\), \(T_b\) = \(h(pw_b||r_b||K_{sb}||B)\). Next, S sends \(m_2\) = \(\{T_a, N_s, B\}\) to A and \(m_2'\) = \(\{T_b, N_s, A\}\) to B.

  3. 3.

    After A receives the message, A computes \(K_{as}\) = \((N_s)^x\) and checks the value \(T_a\) using corresponding values. If it is verified successfully, A computes \(W_a\) = \(h(A||B||K_{as}||pw_a||r_a)\) and sends \(m_3\) = \(\{A, W_a\}\) to S. B processes the received message in a similar way, and sends \(m_3'\) = \(\{B, W_b\}\) to S if the verification is correct.

  4. 4.

    After S receives the messages, S verifies \(W_a\) and \(W_b\). If both return true, S computes \(U_a\) = \(K_{sb} \oplus h(A||B||K_{sa}||pw_a||r_a)\) and \(U_b\) = \(K_{sa}\)\(\oplus\)h(A\(||B||K_{sb}||pw_b||r_b)\), and sends \(m_4\) = \(\{U_a\}\) to A and \(m_4'\) = \(\{U_b\}\) to B.

  5. 5.

    After the messages arrive, A computes \(K_{sb}'\) = \(U_a \oplus h(A||B||K_{sa}||pw_a||r_a)\), sk = \((K_{sb}')^x\), and \(A_a\) = h(sk||A||B), while B computes \(K_{sa}'\) = \(U_b \oplus h(A||B||K_{sb}||pw_b||r_b)\), sk = \((K_{sa}')^y\), and \(A_b\) = h(sk||A||B). Then, they exchange the message \(m_5\) = \(\{A_a, A\}\) and \(m_5'\) = \(\{Ab, B\}\).

  6. 6.

    After the messages arrive, A and B checks the validity of \(A_a\) and \(A_b\) respectively.

Finally, if they both hold true, A and B establish a common session key sk = \(g_{xyz}\).

3 Cryptanalysis of Lu et al.’s protocol

In this section, we show that Lu et al.’s protocol is vulnerable to an off-line password guessing attack. Assume that an adversary E overhears a protocol run among user A, user B, and server S, and captures the messages sent by them. Then, E performs the following steps to launch an off-line password guessing attack.

  1. 1.

    Extract \(H_a\), \(V_a\), \(R_a\), A from \(m_1\).

  2. 2.

    For each possible password \(pw'\), repeat:

    • Compute \(r_a'\) = \(H_a \oplus h(pw')\), \(V_a'\) = \(h(pw'||r_a'||A)\).

    • If \(V_a\) = \(V_a'\), return \(pw'\).

The second step indicates a loop to check whether the guessed password is correct or not. Since in each loop, it takes two hash operations and one exclusive-or operation, E can obtain the correct password in a time proportional to \(|D| \times t_H\), where |D| represents the size of the password set, and \(t_H\) is the time cost of a hash operation. The attack aims at the user A’s password, but it can also be launched to obtain the user B’s password. The adversary E simply eavesdrops the message \(m_1'\), computes \(r_b'\), \(V_b'\), and checks the equation \(V_b\) = \(V_b'\). The time cost is the same as the attack on A’s password.

4 The proposed 3PAKE protocol

This section aims to propose an enhanced a new 3PAKE protocol to overcome the above mentioned problems with the Lu et al.’s protocol. The same as Lu et al.’s protocol, each user shares the identity and the hashed password h(pw) with S. The server initializes the system with a large prime p and a generator g. For convenience, modulo p operations are also hidden from computations.

The protocol is showed in Fig. 1 and more details are provided as follows:

Fig. 1
figure 1

The proposed 3PAKE protocol

Full size image
  1. 1.

    A randomly chooses one number a, and computes \(R_A\) = \(g_a\), \(K_{AS}\) = \((g^x)^a\), \(H_{AS}\) = \(h_1(ID_A||ID_B||R_A||K_{AS}|| h_1(PW_A))\). Then, it sends \(\{ID_A\), \(ID_B\), \(R_A\), \(H_{AS}\}\) to server S. B also selects one random number b, computes \(R_B\)=\(g_b\), \(K_{BS}\)= \((g^x)^b\), \(H_{BS}\)=\(h_1(ID_A||ID_B||R_B||K_{BS}|| h_1(PW_B))\) and sends \(\{ID_A,ID_B,R_B,H_{BS}\}\) to server S.

  2. 2.

    Upon receiving the messages form A and B. S computes \(K_{AS}\) = \((R_A)^x\), \(H_{AS}'\) = \(h_1(ID_A||ID_B||R_A||K_{AS}|| h_1(PW_A))\), \(K_{BS}'\) =\((R_B)^x\), \(H_{BS}\) = \(h_1(ID_A\)\(||ID_B||R_A||K_{BS}|| h_1(PW_B))\), and then check \(H_{AS}' {\mathop {=}\limits ^{?}} H_{AS}\), \(H_{BS}' {\mathop {=}\limits ^{?}} H_{BS}\), which holds if A and B are legal. After that, S selects one random number c, computes \(K_{BS}'\) =\((R^B)^c\), \(K_{AS}'\) = \((R^A)^c\), \(H_{SA}\) = \(h_1(K_{BS}' \oplus K_{AS}||K_{AS})\), \(H_{SB}\) = \(h_1(K_{AS}' \oplus K_{BS} ||K_{BS})\). Lastly, it sends \(\{K_{BS}' \oplus K_{AS}, H_{SA}\}\) to A and \(\{K_{AS}' oplus K_{BS},H_{SB}\}\) to B.

  3. 3.

    After A receives the message, A computes \(K_{BS}'\) = \((K_{BS}' \oplus K_{AS}) \oplus K_{AS},\) and verify \(H_{SA} {\mathop {=}\limits ^{?}} h_1(K_{BS}' \oplus K_{AS} ||K_{AS})\). If verification does not hold, it terminates the session. Otherwise,computes K =\((K_{BS}')^a\), SK=\(h_1(K)\), \(M_{AB}\)= \(h_1(1||ID_A||ID_B||K)\), \(M_{AS}\)=\(h_1(1||K_{AS}||M_{AB})\). Then, it sends \(\{M_{AB}, M_{AS}\}\) to S.

  4. 4.

    After B receives the message, B computes \(K_{AS}'\) = \((K_{AS}' \oplus K_{BS}) \oplus K_{BS},\) and verifies \(H_{SB} {\mathop {=}\limits ^{?}} h_1(K_{AS}' oplus K_{BS}|| K_{BS})\). If verification does not hold, it terminates the session. Otherwise, B computes K =\((K_{AS}')^b\), SK=\(h_1(K)\), \(M_{BA}\) = \(h_1(1||ID_A||ID_B||K)\), \(M_{BS} = h_1(1||K_{BS}||M_{BA})\). Then, it sends \(\{M_{BA}, M_{BS}\}\) to S.

  5. 5.

    After receiving the messages, S verifies \(M_{AS}\) and \(M_{BS}\). If both return true, S sends \(M_{BA}\) to A and \(M_{AB}\) to B, respectively.

  6. 6.

    After the messages arrive, A and B checks \(M_{BA} {\mathop {=}\limits ^{?}} M_{AB}\) and \(M_{AB}{\mathop {=}\limits ^{?}} M_{BA}\) respectively.

Finally, if they both hold true, A and B establish a common session key sk = \(h_1(K)\) = \(h_1(g^{abc})\).

5 Security analysis

This section presents security features of the proposed protocol, which reveals our protocol is safe from several kinds of attacks.

5.1 On-line password guessing attack

If an adversary E attempts to guess A’s password, E guesses a password \(PW_A'\) and selects a random integer \(\alpha '\), computes \(R_A'\)= \(g^{\alpha '}\), \(K_{AS}'\) = \((g^x)^{\alpha '}\) and \(H_{AS}'\)= \(h_1 ( ID_A ||ID_s || R_A'|| K_{AS}' || h_1 (PW_A'))\). Then E sends the message \(\{ID_A,ID_B,R_A',H_{AS}'\}\) to the trust server S. However, S can detect this attack since it checks the validity of the value \(H_{AS}'\) when S receives the message. Also, if E attempts to guess B’s password, S can detect it in the say way. Therefore, the proposed protocol can resist an on-line password guessing attack.

5.2 Off-line password guessing attack

Without loss of generality, we assume that an adversary E intercepts the message \(\{ID_A,ID_B,R_A,H_{AS},K_{BS}' \oplus K_{AS}, H_{SA},M_{AB},M_{AS},M_{BA} \}\) and attempts to launch an off-line password guessing attack to obtain A’s password (B is the same case). As we know, only the parameter \(H_{AS}\) is related to A’s password. However, E cannot check whether his guessed password is right or not since without the parameter \(R_A\), he cannot reconstruct \(H_{AS}'\) and compare it with \(H_{AS}\). Therefore, the proposed protocol can resist an off-line password guessing attack.

5.3 Impersonation attack

Assume that an adversary E attempts to A with the intercepted message \(\{ID_A,ID_B\), \(R_A,H_{AS},K_{BS}' \oplus K_{AS}, H_{SA},M_{AB},M_{AS},M_{BA} \}\). However, without the correct A’s password, E will be detected when S checks the value of \(H_{AS}\) which contains the correct value of A. Therefore, E cannot impersonate user A. Similarly, E cannot impersonate user B as well.

When E attempts to impersonate S, he also cannot succeed since without S’s secret key x, he cannot construct \(K_{AS}\). Therefore, E cannot impersonate S.

5.4 Replay attack

Assume that E has obtained all the messages transmitted among A, B and S. However, he cannot perform this attack by replay A’s or B’s message since these parameters are protected by random integer and will be detected immediately when received by S. Similarly, when E replays the S’s messages, A or B will be detect with the aid of the selected random integers. Therefore, the proposed protocol can resist a replay attack.

5.5 Man-in-the-middle attack

From the above analysis, we can know that E cannot succeed by impersonating and replaying. On the other hand, because the transmitted parameters \(H_{AS}\), \(H_{BS}\) contain the user’s identities, thus man-in-the-middle attack cannot succeed. The proposed protocol can resist a man-in-the-middle attack.

5.6 Mutual authentication

In the proposed protocol, S authenticates A by computing \(H_{AS}\) and \(M_{AS}\) and authenticates B by computing \(H_{BS}\) and \(M_{BS}\). Meanwhile, A and B authenticate S by computing \(H_{SA}\) and \(H_{SB}\), respectively. Therefore, the proposed protocol can achieve mutual authentication.

5.7 Known-key security

In the proposed protocol, the session key SK = \(h_1(g^{abc})\) is depend on the random integers a, b, and c, which are diffident in all sessions. Thus, an adversary E cannot compute the previous and the future session keys even he has known one session key.

6 Simulation verification with proverif

Proverif is an automatic cryptographic protocol verifier, which is widely used to specify and analyze the security of authenticated key agreement protocols (Jiang et al. 2017; Chaudhry et al. 2017; Wu et al. 2017b; Abbasinezhad-Mood and Nikooghadam 2018a, b; Jiang et al. 2018; Wu et al. 2017a). In this section, we utilize Proverif to further analyze the security and validity of the proposed protocol. The whole simulation contains the following procedures:

  • First, a public channel ch is defined for the communications. SKa and SKb are the session keys generated by the users, and x is the secret key of S. Then comes the functions and rules (Fig. 2).

  • The purpose of the verification is to verify the following four queries. The former two are about whether an adversary can have the shared session keys or not, and the rest ones are about the correctness of the authentication process (Fig. 3).

  • The process of user A. (Fig. 4).

  • The process of user B (Fig. 5).

  • The process of user S (Fig. 6).

  • The main execution. (Fig. 7).

  • The result of the proposed protocol. From the results, we can conclude that an adversary has no ways to obtain users’ session key (Fig. 8).

Fig. 2
figure 2

Functions and rules

Full size image
Fig. 3
figure 3

Four queries: The first two queries check if an adversary is unable to obtain the shared session key. The last two queries check if the identity cannot be forged

Full size image
Fig. 4
figure 4

The process of user A

Full size image
Fig. 5
figure 5

The process of user B

Full size image
Fig. 6
figure 6

The process of S

Full size image
Fig. 7
figure 7

The main execution

Full size image
Fig. 8
figure 8

The result of the proposed protocol. All four queries return ‘true’ which means the attacker is unable to obtain the session key and also unable to forge the user’s identity in the protocol

Full size image

7 Performance evaluation

This section describes performance evaluation of the proposed protocol along with other related protocols (Lu et al. 2015; Farash and Attari 2014; Tallapally 2012), in security properties, communication cost and estimated time. We focus on the security against on-line password guessing attack, off-line password guessing attack, impersonation attack, replay attack, man-in-the-middle attack, mutual authentication, known-key security and the session key perfect forward secrecy. From Table 2, we can observe that only the proposed protocol fulfills all the security properties.

Table 2 Comparison of security properties
Full size table

To compare the communication cost, we assumed that the output of a user identity is 32-bit, a random integer is 128-bit, a hash function(SHA-256) is 256-bit, a trapdoor is 1024-bit, and modular exponential operation (DH-1024) is 1024-bit. From Table 3, we see that the proposed protocol costs less in bits then Farash et al.’s protocol (Farash and Attari 2014) and Lu et al.’s protocol (Lu et al. 2015), but a little bit more than Tallapally’s protocol(Tallapally 2012). Thats because Tallapally’s protocol does not design parameters for mutual authentication.

Table 3 Comparison of communication cost (in bits)
Full size table

We then use a personal smart device (iPhone 6s with ARM(armv8-a) CPU, 2GB RAM and iOS10.1.1 operation system) to execute the related operations such as SHA-256 and exponential modulo operation (based on GMP library). We execute each for 10000 times and compute the average running times. A hash function needs 0.014 ms and an exponential modulo operation needs 0.471 ms. With them, we compute the estimated time of the protocols in Table 4. With Table 4, we can see that the proposed protocol cost more time. Indeed, Lu et al.’s scheme (Lu et al. 2015) has a better performance (2.994 ms) than our protocol (4.962 ms). However, their scheme cannot withstand online/off-line password guessing attack. Also, their scheme does not provided mutual authentication. Our protocol provides these security requirements. In other aspect, even 1.968ms (4.962–2.994) is too short for human beings to sense. In return, the proposed protocol provides better security and communication cost.

Table 4 Comparison of estimated time
Full size table

8 Conclusion

In this paper, we demonstrate a weakness in Lu et al.s 3PAKE protocol. We find that their protocol is vulnerable to off-line password guessing attack. In order to erase the weakness of Lu et al.’s protocol and enhance the security, we later proposed a new 3PAKE protocol. The security of the proposed protocol is proved by the cryptographic protocol tool proverif. We also compare our protocol against three other similar works and found that our communication cost is the lowest among the rest while maintaining a similar computation cost.