Cryptanalysis and improved mutual authentication key agreement protocol using pseudo-identity.

The authentication key agreement is a scheme that generates a session key for encrypted communication between two participants. In the authentication key agreement, to provide the mutual authentication and the robust session key agreement is one of the important security requirements to enhance the security performance of key agreement. Recently Zhou et al. had proposed the key agreement protocol using pseudo-identifiers, but we found that there were weaknesses in their protocol. We have demonstrated that Zhou et al.'s protocol is vulnerable to replay attack, fails to provide mutual authentication, no key control, re-registration with the original identifier and efficiency in the verification of wrong password. We improved their scheme and proposed an improved authentication key agreement protocol that provides robust mutual authentication and the secure session key agreement. We analyzed its security performance using BAN logic and AVISPA tools and compared computational cost, communication overhead and security properties with other related schemes.

1. Introduction

Authentication key agreement(AKA) is one of the important issues to ensure the confidentiality of network security (to protect user privacy and network resources) as a scheme where the session key is exchanged to encrypt a message exchanged between communication participants on a public network. The authentication key agreement protocol can be divided into key agreement for end-to-end communication, and key agreement for end-to-server communication, depending on the entities involved in the communication. In the key agreement protocol for end-to-end communication, two parties participating in key exchange are both users and it applies for the encrypted communication between users. The key agreement protocol for end-to-server communication is used for encrypted communication between the user and several servers or service providers. Key agreement for end-to-server communication can be classified as a key agreement scheme (SS-AKA) between single server and end users, a key agreement scheme between multiple servers and end users (MS-AKA) [1-38]. Recently, with the introduction of technologies such as P2p, cloud computing, WSN, and IoT, researchers are further investigating authentication key agreement between end-to-end servers. Particularly, research on key agreement for communication between multiple servers and end users(MS-AKA) is focused on.

For the MS-AKA implementation, researchers introduced multi-factor authentication such as password, smart card and biometrics and they used public key cryptographics and non-cryptographics for key agreement. Research has mainly focused on lightweight and security enhancement. The research for lightweight is based on non-cryptographics [1–13, 24–32] that only uses hash function and XOR operation, and the research for security performance improvement is mainly based on public key encryption [14–21, 32–37].

However, most of the lightweight approaches suffer from low security performance, and security performance improvements suffer from high computational costs and communication overhead. Research on authenticated key agreement scheme with higher security and lower computational cost and lower communication overhead is still a challenge for researchers. In particular, user anonymity and mutual authentication are very important properties for authenticated key agreement. In this paper, we propose an improved authenticated key agreement scheme based on pseudo-identiy and chaotic maps to provide user anonymity and mutual authentication.

1.1 Related work

In order to implement authentication key agreement between multiple servers and end users, researchers have studied both the key agreement scheme [1-21] where the registration center does not participate in key exchange and the key agreement scheme [24-38] where the registration center participates in key exchange.

In such a way that the registration center does not participate in key exchange, users, servers, or service providers register on the registration center in the system registration phase, and in the key exchange phase, exchange the key without the involvement of the registration center.

Research has mainly been done in terms of security performance enhancement rather than lightening of computational cost.

As authentication factors for the user, they used passwords, smart cards, and biometric information, and used a pre-shared key, a group key and secret-sharing technique for authentication to the service system.

The researchers used computationally efficient hash functions, elliptic curve cryptosystem (ECC), and Chebyshev chaotic maps (CCM) for key agreement to enhance the security performance of key exchange schemes between multiple servers and end users. For key agreement, they used hash functions and performed user authentication using a dynamic identifier and a pre-shared key. In 2007, Liao et al. [1] proposed a secure dynamic identifier-based remote user authentication scheme in a multi-server environment. But it was revealed that his protocol is vulnerable to insider attacks, impersonation attacks, server spoofing attacks, registration center spoofing attacks, and fails to provide mutual authentication by Hsiang et al. [22] in 2009. In 2012, Li et al. [2] proposed a new remote user authentication scheme based on smart card and dynamic identifier for multi-server environments. In order to protect the user identifier from tracking, their scheme allows the user’s identifier to change dynamically whenever the user logs on to the server. In 2012, Tsaur et al. [3] proposed an efficient and secure multi-server authentication scheme with key exchange. However, his protocol was found to be vulnerable to offline password guessing attacks, privileged insider attacks, and malicious user attacks by Xu et al. [4] in 2013. Xu et al. proposed a new dynamic identification-based authentication scheme for a multi-server environment using smart cards. He proposed an improved dynamic identity based scheme to eliminate all the security and efficiency weaknesses without decreasing other security performances in his work. In 2014, Chuang et al. [5] proposed an anonymous multi-server authenticated key agreement scheme based on trust computing using smart cards and biometrics. However, it was revealed that his protocol is vulnerable to denial of service attacks, stolen smartcard attacks, user impersonation attacks, and server spoofing attacks by Maitra et al. [6] and Mishra et al. [7] in 2014. Maitra et al. proposed efficient remote user authentication using biometric and password-based smart cards for telemedicine information systems in a multi-server environment. He found that an unregistered attacker can successfully log into the system as a valid user in Chuang et al.’s scheme, and in order to overcome vulnerabilities, he proposed a scheme that allows users to register simultaneously on a root remote server called registration center to be served from all branch remote servers using a registered smart card. In 2014 Mishra et al. proposed a multi-server authentication key agreement scheme using smart cards based on biometrics to preserve secure user anonymity. He improved Chuang et al.’s protocol, but it was found that his protocol is vulnerable to impersonation attacks, replay attacks, denial of service attacks, fails to achieve perfect forward security and no user re-registration phase by Wang et al. [10] in 2016. Wang et al. proposed cryptanalysis and improvement on multi-server authentication and key agreement schemes based on biometrics. But it was revealed that his protocol is vulnerable to user impersonation attacks, privileged insider attacks, and server impersonation attacks and does not provide perfect forward security by Yang et al. [20] in 2018. Yang et al. designed a protocol that performs mutual authentication between the user and the service provider and exchanges key without involvement of the registration center in a multi-service system environment. In his protocol, the registration center shares the pre-shared key (PSK) and long term key with service providers. In 2015, Amin et al. [8] proposed a new user authentication and key agreement protocol for multiple healthcare provider access available in TMIS. They developed a new structure for access to multiple healthcare providers in order to decrease the vulnerability of a single healthcare provider, where the user can communicate directly and safely with the doctor of the healthcare provider. They also developed smart card-based authentication and key agreement security protocols that can be used in TMIS systems using one-way hash functions as cryptography. In 2017, Guo et al. [11] proposed a key exchange protocol that provides user anonymity in a multi-service system environment. In key exchange, the registration server does not participate, shares a pre-shared key with the service providers and uses the public key of the service providers.

In 2019 Lwamo et al. [12] proposed a key exchange scheme without a third-party server using hash functions and symmetric key encryption. He demonstrated lightweight and anonymity, and the user identifier is encrypted with the service provider’s public key, and it is updated every round. In key exchange using only hash functions, the registration center shares pre-shared key with the service providers to authenticate them. In 2020, Mishra et al. [13] proposed a dynamic ID-based authenticated key agreement scheme for mobile edge computing without a trusted third party. The proposed scheme guarantees mutual authentication between user and edge servers and achieves important security properties such as secure communication, mutual authentication, user anonymity, and session key agreement.

To overcome the disadvantage of using a pre-shared key, researchers used public-key encryption for key exchange.

In 2014, Han et al. [14] proposed an identifier-based mutual authentication with a key agreement protocol for a multi-server environment based on elliptic curve cryptography. In order to improve the performance of precedent bilinear pairing-based several authentication schemes in a multi-server environment, they proposed a new identifier-based mutual authentication protocol using signature based elliptic curve cryptography. In 2016, Chaudhry et al. [9] proposed a secure biometrics-based multi-server authentication scheme for social multimedia networks. They show that first one of the two schemes of Lu et al. [37] designed for multi-server architectures is vulnerable to impersonation attacks and doesn’t provide user anonymity, and the second one is vulnerable to user impersonation attacks. They proposed an enhanced scheme, and used elliptic curve cryptography and hash functions for key exchange. In 2019, Ying et al. [15] proposed a lightweight remote user authentication protocol for multi-server 5G networks using self-verified public-key encryption. To reduce the computational complexity, they used self-verified public-key cryptography based on elliptic curve cryptography to verify the valid of users and servers. Without pairing operations, their scheme could improve computational efficiency and provide mutual authentication. In 2016, Irshad et al. [16] proposed an anonymous multi-user authentication key exchange protocol based on chaotic mapping using smart cards. They reviewed recent multi-server authentication schemes and proposed a single-round trip multi-server authentication protocol based on chaotic mapping to overcome their schemes’ limitations. In 2017 Kumari et al. [17] proposed a user key exchange scheme in a multi-server environment using chaotic mapping. His scheme is based on a single-sign-on, where the registration center pre-shares the secret key with the service providers. In 2019 Qiao et al. [18] proposed an authentication key exchange scheme that provides strong anonymity for multi-server environments in TMIS. His scheme exchanges key with chaotic mapping and encrypts the identifier with symmetric encryption without involving the key exchange server. In 2012 Chuang et al. [19] proposed a generalized identifier-based user authentication scheme for a mobile multi-server environment. In his work, he first proposed a security model for a multi-server environment and then a bilinear pairing-based mutual authentication and key exchange scheme. Their scheme can be used for both common users with long valid periods and anonymous users with short valid periods. In 2020 Yu et al. [21] proposed a key agreement scheme (AKA-NS) that shares keys without authentication servers in an IoT-based cloud environment based on bilinear pairing. His scheme authenticates users based on the Elgamal cryptography signature, and uses secret values based on bilinear pairingand hash functions for key agreement.

To overcome the disadvantage of using a pre-shared key, researchers also proposed a combination of group key agreement and secret-sharing techniques [22, 23]. In 2021, Vinoth et al. [22] proposed a secure multifactor authenticated key agreement scheme for industrial IoT environment to support authorized user remotely accessing the sensors. In their proposed scheme, only hash functions, XOR operation and symmetric encryption are used for session key agreement, and sensor devices share secret information by combining group key agreement and secret-sharing techniques.

The key agreement scheme involving the registration center in key exchange has been studied towards lightweight rather than maintaining security performance. Researchers used passwords, smart cards, and biometric information as the authentication factors for the user, and used a pre-shared key for authentication of the service provider system. In order to lighten the computational cost of the scheme, researchers focused on computationally efficient hash functions, ECC and ECM for key agreement. Some researchers designed the protocol where the registration center participates in key exchange, using only a hash function without using public-key encryption in key exchange to reduce computational cost.

In 2009, Hsiang et al. [24] proposed a secure dynamic ID-based remote user authentication scheme for a multi-server environment. But it was revealed that his protocol is vulnerable to impersonation attacks, server spoofing attacks, cannot be easily repaired, and cannot provide mutual authentication by Lee et al. [25] In 2011, Lee et al. proposed a secure dynamic identifier-based remote user authentication scheme for a multi-server environment using smart cards. But it was revealed that his protocol is vulnerable to impersonation attacks and server spoofing attacks, and if the mutual authentication message is partly modified by the attacker, it cannot provide a corresponding authentication by Li et al. [2] in 2012. In 2014, Xue et al. [26] proposed a lightweight dynamic anonymous identity-based authentication and key exchange protocol that does not use verification tables in a multi-server environment. However, in 2015, Gupta et al. [27] has shown that Xue et al.’s protocol is vulnerable to known password guessing attacks, stolen smartcard attacks, and impersonation attacks, and in 2018, Amin et al. [29] found that Xue et al.’s protocol has flaws in user anonymity, offline password guessing attacks, privileged insider attacks, no key control, user impersonation attacks. Gupta et al. proposed a hash function-based multi-server key exchange protocol with smart cards. But in 2019, it was found that his protocol is vulnerable to denial of service attack, stolen smart card attack, and user impersonation attacks and that it does not achieve perfect forward security by Tomar et al. [35]. Tomar et al. proposed an authentication key exchange protocol with a password, biometrics (Fuzzy extractor) and smart cards. His protocol uses timestamps, uses elliptic curve cryptography to establish the session key, and performs mutual authentication using two control servers. Amin et al. proposed the anonymous authentication and key exchange protocol between a user and multi-server in cloud environment. In his work, the server and user use a shared secret that combines the server’s secret with the user’s identifier, and the user accesses to the smart card using the password. In 2016, Maitra et al. [28] proposed an enhanced multi-server authentication protocol using passwords and smart cards. He found that some flaws in the precedent works, and he proposed a new protocol, focusing on the improvement of their security performances, and used symmetric key encryption. In 2018, Wei et al. [30] proposed a two-factor authentication key exchange protocol using the password and secret keys stored in smart cards in cloud environments. They used the shared-secret key combined with timestamps as a message-encryption key. In 2019, Zhou et al. [31] proposed a lightweight authentication key exchange protocol based on a hash function in cloud computing environment. In his work, they updated pseudo-identities of two participants every round. The user registers with identifiers, pseudo-identifiers, passwords, and random numbers, and the IoT controller registers with identifiers, pseudo-identifiers, and random numbers.

To enhance the security performance of key exchange, some researchers have used public key encryption such as ECC and ECM.

In 2010, Yoon et al. [32] proposed a robust multi-server authentication scheme based on biometrics using smart cards in elliptic curve cryptography. They proposed an authentication scheme without a verification table, and the proposed scheme can provide stronger user authentication by using biometrics, and provide more secure key exchange scheme based on ECC. In 2017, Chandrakar et al. [33] proposed a key exchange protocol for remote user authentication that provides three factors authentication and anonymity using elliptic curve cryptography in a multi-server environment. For the exchanged key, they use Elliptic Curve Diffie–Hellman (ECDH), but for the encryption, they use the addition of a point on elliptic curve, and XOR without the use of special encryption. In 2018, Qi et al. [34] proposed a key exchange scheme using elliptic curve cryptography in a multi-server environment. They used the server’s public-key-based symmetric key encryption for the communication between the user and the server. They also used the registration center’s public-key-based symmetric key encryption for communication between the server and the registration center. Thus, his protocol provides a relatively strong key exchange scheme. In 2017, Irshad et al. [36] proposed a new user authentication key exchange protocol based on chaotic mapping for a multi-server environment. They used password, biometrics, smart card and the secret key shared with the registration center to authenticate the user and used chaotic mappings and bio-hash functions to exchange the session key. In 2021, Xia [38] proposed a modular exponention based anonymous authentication and key agreement scheme with privacy-preserving in IoT environment for smart city, and the work for authenticated key agreement scheme was studied not only in P2P, IoT environment, but also in VANET environment [39].

1.2 Motivation and our contribution

According to the research of the precedent schemes, we found that key agreement protocols without the registration server have several disadvantages such as the mutual authentication, anonymity and untraceability in their implementation for communication between multiple servers and end users [1, 3, 7, 10]. Also we found that the research in protocols with the registration server has been intensified towards lightweight, but on the other hand, their security performance has become weakened [24, 26, 29]. In our work, we analysed the pre-shared key-based Lwamo et al.’s scheme [12] where the registration center doesn’t participate in the key agreement, and found that his scheme is vulnerable to the stolen smart card attack. We also analysed the pseudo-identities-based Zhou et al.’s scheme [31] where the registration center participates in the key agreement, and found that their scheme is vulnerable to replay attack and does not provide mutual authentication, no key control, re-registration with an original identity, and efficiency in the verification of wrong password. From this research, we propose an improved authentication key agreement protocol for communication between multi-servers and end users to overcome the flaws of Zhou et al.’s scheme. Finally, we analysed the security properties of our protocol and performed comparative analysis with precedent protocols to show that our protocol is superior in terms of security properties and computational complexity.

2. Preliminaries

This section describes Fuzzy extractor, Chebyshev chaotic maps, their computational problems and threat model.

2.1 Fuzzy extractor

The fuzzy extractor includes two functions Gen and Rep. The function Gen extracts biometric input BI, and outputs a nearly random binary string R and an auxiliary binary string P. And the function Rep recovers R with the assistance of corresponding auxiliary string P and biometric BI*. If dis(BI, BI*) ≤ t and Gen(BI) → , then we have Rep(BI*, P) = R. Otherwise, there is no guarantee provided by function Rep. The literature [40, 41] describes more details about the fuzzy extractor.

2.2 Chebyshev polynomials

Chebyshev polynomial T(a) is defined as follows [42].

Chebyshev polynomials satisfy the following recursive relationship [42].

2.3 The property of Chebyshev polynomials

Chebyshev polynomials have the following two properties [42, 43].

Chaotic property: When m>1, Chebyshev polynomial map T(a): [-1,1]→[-1,1] of degree m is a chaotic map with its invariant density , for positive Lyapunov exponent ln(m) > 0.

Semi-group property: For x, y∈N and any a∈[-1,1], T(T(a)) = T(a) = T(T(a)).

2.4 Enhanced Chebyshev polynomials

The semi-group property holds for Chebyshev polynomials on the interval (-∞, +∞), which can enhance the property as follows [43]:

2.5 Computational problems based on Chebyshev polynomials

CDLP (Chaotic map-based Discrete Logarithm problem): For given two real numbers a and b, it is infeasible to find the integer m by any polynomial time bounded algorithm, where b = T(a) mod p [43].

CDHP (Chaotic map-based Diffie-Hellman problem): For given three elements a, T(a) mod p and T(a) mod p, it is infeasible to compute the value T(a) mod p by any polynomial time bounded algorithm [43].

2.6 Threat model

In this subsection, we introduce several threat models including the Dolev-Yao threat model [44], side channel attack [45], and password guessing attack [46], for the security analysis of the proposed scheme and previous schemes.

An attacker can eavesdrop, modify, remove, block and retransmit all messages transmitted on the public channel [44].

An attacker can extract all stored data from a lost or stolen smart card as a power analysis attack [40].

An attacker can perform offline and online password guessing attacks after obtaining information from user’s smart card [46].

An attacker can be a malicious user or an outside hacker [20].

3. Analysis of precedent schemes

In this section, we review the schemes proposed by Lwamo et al. [12] and Zhou et al. [31], and show that their schemes have some flaws.

3.1 Analysis of Lwamo et al.’s scheme

3.1.1 Lwamo et al.’s scheme

Lwamo et al. proposed the authentication key agreement protocol without the registration center using hash function and symmetric key encryption. The user identity is encrypted with the public key of the service server and it is updated every round.

Table 1 shows the notations used in his scheme.

Table 1

Notations in Lwamo et al.’s scheme.

Notation	Description
A i	The ith user
B j	The jth server
S	The secret value of RC
RC	The registration center
U i	Ai’s identity
MU i	Ai’s masked identity
S j	Bj’s identity
MS j	Bj’s masked identity
P i	Ai’s password
MP i	Ai’s masked password
BO i	Ai’s biometric information
h(.)	One-way hash function
VPSK	A secure pre-shared key between RC and the server
a i	A nonce
pu j	Bj ‘s public key
pr j	Bj ‘s private key
Ek()	Encryption with k as a key
Dk()	Decryption with k as a key
⊕	XOR operator
||	concatenation operator

Registration for server

To be a valid server, the server sends a registration request to RC via a secure channel. The server’s identity S and its public key pu are contained in the registration request. Then RC sends VPSK and s to the server by a response via a secure channel like Internet Key Exchange version 2 (IKEv2) and publishes pu

Registration for user

Step 1: First the user A selects his/her identity U, password P, a nonce a and biometric information BO

Step 2: A computes MP = h(U || a || P) and VREG = h(MP⊕BO).

Step 3: The registration request {U, VREG = h(MP⊕BO)} is sent to RC by A.

Step 4: SA = h (U || s), SB = h(SA) and SC = h(VREG = h(MP ⊕BO))⊕SB are generated by RC.

Step 5: The RC chooses a nonce a for A, computes MU = E(U||a), SD = VPSK⊕MU and makes the smart card storing {MU, SB, SC, SD, h(.)} its own possession.

Step 6: The A inserts the nonce a into the smart card, which now includes SC = {MU, a SB, SC, SD, h(.)} and owns the smart card.

Step 1: A inserts the smart card into the reader and enters U, P and BO.

Step 2: Then the smart card computes SB* = SC⊕h(h(U||a||P) ⊕ BO) and sees if SB* = SB. If SB*≠SB, the smart card stops the login phase. The smart card is blocked if the two values do not match for three continued trials within limited threshold time.

Step 3: Then the smart card chooses a nonce Ra and computes M1 = h(SB) ⊕ Ra, M2 = h(Ra || MU || SD ||T1), where T1 is the current time on the smart card, and M3 = Epu(MU, M1).

Step 4: The smart card sends the login request LOGIN {M2, M3, S, T1} to the server B.

Step 5: When B receives the request, the difference between the received login request time T1 and the server time T2 is computed as ΔT = T2 –T1 by B, the phase is terminated by the server if the difference is bigger than the required transfer time.

Step 6: To get MU and M1, M3 is decrypted as Dpr(M3) by the server. And to get the real identity of the user MU is decrypted as Ds(MU) = U || a by the server.

Step 7: The server calculates SA* = h (U||s) and R = M1 ⊕h2(SA*).

Step 8: M2* = h (R|| MU || (VPSK⊕MU) ||T1) is computed and it is checked if M2 = M2* by the server. The session is stopped if M2 ≠ M2*.

Step 9: The server selects two nonces Ra and Ra, calculates s* = h(Ra|| T3) where T3 is the current server time, and computes a new identity for A as MU = h(U|| Ra).

Step 10: Then a challenge message M4 = E (MU||Ra||Ra||U||R||S) and the masked identity MS = h(S⊕Ra) are computed by the server. And the message CHALLENGE {M4, MS, T3} is sent to A

Step 11: After receiving the message from the server, the smart card computes the difference ΔT = T4 − T3, where T4 is the current time on the smart card. The smart card stops the session if the difference is bigger than the defined interval.

Step 12: The smart card calculates s* = h(Ra|| T3) and M4 is decrypted as Ds*(M4) to get MU, Ra, Ra, Ra, U and S.

Step 13: The smart card calculates MU * = h(U|| Ra *) and MS* = h(S||Ra). And then it sees if MS = MS* and if MU = MU. Also the smart card sees if R and U are equal to those sent to the server on the login request, if they do not match, the smart card terminates the session.

Step 14: The response message M5 = h(Ra||MU||Ra) and the session key Sk = h(Ra||SB||S||Ra) is calculated by the smart card. And the smart card sends the response RESP {M5} to B.

Step 15: After the server receives the response, it calculates M5* = h (Ra||MU||Ra) and sees if M5* = M5. The session is stopped if M5*≠M5.

Step 16: The session key Sk = h(Ra||h(U||s) ||S||Ra) is computed by the server. In this step, the mutual authentication between the user and the server is achieved and the session key between them is created.

Step 1: The user inserts the smart card into the card reader and inputs U, P and BO.

Step 2: The smart card computes SB* = SC⊕h ((h(U||a||P) ⊕ BO).

Step 3: The smart card sees if SB* = SB and stops the session if SB*≠SB.

Step 4: The smart card gets a new password P from the user and calculates SC = SC⊕h(h(U|| a || P) ⊕BO) ⊕h(h(U|| a || P) ⊕BO).

Step 5: The value of SC is replaced with SC by the smart card.

3.1.2 Flaws of Lwamo et al.’s scheme

Stolen smart card attack. In his scheme, SC = {MU, SB, SC, SD, h(.), a} is stored in his/her smart card. Thus, an attacker can get SB directly without inputting the identity U, the password P or the biometric BO if he gets the user’s smart card. Then the attacker generates a random number Ra, computes M1 = h (SB) ⊕ Ra, M2 = h (Ra||MU||SD||T1) and M3 = E(MU, M1) and sends LOGIN{M2, M3, S, T1} with a time stamp T1 to the server B. In this case, B recognizes the attacker as a valid user A. After receiving the message CHALLENGE {M4, MS, T3} from the server via step 10 from the step 4 of the login and authentication phase, the attacker finally gets the session key Sk = h(Ra||h(U||s) ||S||Ra) between himself and the server B.

As a result, Lwamo et al.’s scheme is vulnerable to the stolen smart card attack.

3.2 Analysis of Zhou et al.’s scheme

3.2.1 Zhou et al.’s scheme

In 2019, Zhou et al. proposed a hash function-based lightweight authentication key agreement scheme for user-multi IoT access in IoT environment. In their scheme, the pseudo-identities are used. Table 2 shows the notations used in Zhou et al.’s scheme.

Table 2

Notations in Zhou et al.’s scheme.

Notation	Description
Ics, k	CS’s identity and secret key
SVj, SIj, PSIj	The jth cloud server, its identity and pseudo-identity
UVi, Ii, PIi, PAi	The ith user, his/her identity, pseudo-identity, password
AV	The attacker
h(·)	Hash function
SKu, SKs, SKcs	UVi, SVj and CS’s session keys
M1, M2, M3, M4	Messages for the authentication
||	Concatenation operator
⊕	XOR operator

Registration for user

Step 1: UV chooses his/her identity and pseudo-identity pair (I, PI), password PA and a random number r. HP = h (PA || r) is computed and (I, PI) is sent to CS through the secure channel by the user.

Step 2: CS sees if I is valid and will terminate the registration process if the identity is invalid. If it is valid, then CS computes C1* = h (PI||I||k) and C2* = h (I||k). And the identity I is stored in database and (C1*, C2*, I) is sent to UV through the secure channel by CS.

Step 3: The user calculates C1 = C1* ⊕ HP, C2 = C2* ⊕ h (I ||HP) and C3 = r ⊕ h(I || PA) and stores (C1, C2, C3, PI, I) in his smart card.

Registration for cloud server

Step 1: The server SV’s identity and pseudo-identity pair (SI, PSI) is sent to CS through a secure channel by the server.

Step 2: CS calculates B1 = h(PSI||I||k) and B2 = h(SI ||k), stores S and (B1, B2, I) is sent to the server through the secure way.

Step 3: (B1, B2, SI, PSI, I) is stored in SV’s database.

Step 1: The user UV inserts his/her smart card into the reader and inputs (I, PA). And the smart card chooses a nonce b and a new pseudo-identity PI and calculates r = C3 ⊕h(I || PA), HP = h(PA|| r), C1* = C1 ⊕ HP, C2* = C2 ⊕ h(I || HP), D1 = C1* ⊕ b, D2 = h(b||PI||I) ⊕I, D3 = C2* ⊕ h(I ||HP) ⊕ PI ⊕ h(b || I), D4 = h(I||PI||PI||b||D3). Then the user sends the message M1 = {PI, D1, D2, D3, D4} to the nearest cloud server SV.

Step 2: The server chooses PSI and a nonce b, calculates D5 = B1 ⊕ b, D6 = h (b||PSI||I) ⊕ SI, D7 = B2 ⊕ PSI ⊕ h(b || SI), D8 = h(SI||PSI||PSI||b||D7). And SV sends the message M2 = {PI, D1, D2, D3, D4, PSI, D5, D6, D7, D8} to CS through the secure channel.

Step 3: b = D1 ⊕ h(PI||I||k), I = D2 ⊕ h(b||PI||I), PI = D3 ⊕ h(I || k) ⊕ h(b || I) is computed by CS and CS sees if I is valid and sees if D4 = h(I||PI||PI||b||D3). If so, CS computes b = D5 ⊕ h(PSI||I||k), SI = D6 ⊕ h(b||PSI||I), PSI = D7 ⊕ h(SI ||k) ⊕ h(b || SI) and sees if S is valid and sees if D8 = h(SI||PSI||PSI||b||D7). CS will stop the session if any verification is not right. Or else, CS chooses a nonce b and computes SK = h(b ⊕ b ⊕ b), D9 = h(PSI||I||k) ⊕ h(b || PSI), D10 = h(PSI||b||PSI) ⊕ (b ⊕ b), D11 = h(SK||D9||D10 || h(SI || k)), D12 = h(PI||I||k) ⊕ h(b|| PI), D13 = h(PI||b||PI) ⊕(b ⊕ b), D14 = h(SK||D12||D13|| h(I || k)). And CS sends the message M3 = {D9, D10, D11, D12, D13, D14} to SV.

Step 4: (b ⊕ b) = D10 ⊕ h (PSI||b||PSI) and SK = h (b ⊕b ⊕ b) are computed by SV. And the server sees if D11 = h (SK||D9||D10 || B2) is true. If it’s true, SV computes B1 = D9 ⊕ h(b ||PSI) and replaces (B1, PSI) with (B1, PSI). In the end, the server sends the message M4 = {D12, D13, D14} to UV.

Step 5: After receiving M4, the smart card calculates (b ⊕ b) = D13 ⊕ h(PI||b||PI), SK = h(b ⊕ b ⊕ b) and sees if D14? = h (SK||D12||D13 || C2*) is true. If passed, the smart card calculates C1 = D12 ⊕ h (b || PI) ⊕ HP and replaces (C1, PI) with (C1, PI).

Step 1: When the user UV wants to change his/her password, he/she inserts his/her smart card into the reader and inputs (I, PA). And the smart card chooses a nonce bu and a new pseudo-identity PI and calculates r = C3 ⊕h(I || PA), HP = h(PA || r), C1 * = C1 ⊕ HP, C2 * = C2 ⊕ h(I || HP), D1 = C1* ⊕ b, D2 = h(b||PI||I) ⊕I, D3 = C2* ⊕ h(I || HP) ⊕ PI ⊕ h(b || I) and D4 = h(I||PI||PI||b||D3). Then the user sends the message M5 = {PI, D1, D2, D3, D4} with a password change request to CS.

Step 2: CS calculates b, I, P and sees if I and D4 are correct. If so, D12 and D15 = h(I||PI||PI||b||D12) is computed by CS. In the end, M6 = {D12, D15} with a permission is sent to UV

Step 3: The smart card sees if D15 = h(I||PI||PI||b||D12) is true. If so, it prompts UV to enter a new password PA and calculates HP = h(PA || r), C1 = D12 ⊕ h(b ||PI) ⊕ HP, C2 = C2* ⊕ h(I || HP) and C3 = r ⊕ h(I || PA) and replaces (C1, C2, C3, PI) with (C1, C2, C3, PI).

3.2.2 Cryptanalysis of Zhou et al.’s scheme

No providing mutual authentication. Zhou et al.’s scheme doesn’t provide the mutual authentication between the user and the server. At first, in the step 1 of authentication phase, the message M1 = {PI, D1, D2, D3, D4} which is sent to the server by the user doesn’t include the information concerned with the server SV. And in the step 2 of authentication phase, after receiving the message M1, SV directly computes D5, D6, D7 and D8 without verifying the user which sends M1, and then sends the message M2 = {PI, D1, D2, D3, D4, PSI, D5, D6, D7, D8} to the registration center CS. Also in the step 3, CS authenticates SV by checking if D8 = h(SI||PSI||PSI||b||D7) and authenticates UV by checking if D4 = h(I||PI||PI||b||D3). In the step 4, when the server receives the message M3 = {D9, D10, D11, D12, D13, D14}, the server authenticates CS by checking if D11 = h (SK||D9||D10 || B2). But the message M3 doesn’t contain the information that the server can authenticate the user UV. In this step, the information concerned with UV is only (b ⊕ b) but using it, the server cannot authenticate the user UV. So in this step, the server can authenticate CS, but it cannot authenticate the user UV. Continuously in the step5, UV receives the message M4 = {D12, D13, D14} from the server and authenticates CS by checking if D14 = h(SK||D12||D13 || C2*). But the information that the user can authenticate the server SV isn’t included in the message M4. In this step, the information concerned with SV is only (b ⊕ b) but using it, the user cannot authenticate SV. So in this step, the user can authenticate CS, but cannot authenticate the server SV.

In conclusion, Zhou et al.’s scheme doesn’t provide the mutual authentication between the user and the server.

According to the random oracle model [46], the attacker can intercept and steal the message M1 which is sent to the server SV by UV and he can send it to another server SV which is not the server SV. Then SV cannot know that UV sent M1 to itself because the mutual authentication isn’t provided between them. And the server SV sends the message M4 to the attacker after passing from the step2 to the step 4. In that case, the attacker sends back this message to the user UV and the user UV regards the session key which he computes in the end as the session key between himself and the server SV because he doesn’t know that he has communicated with the server SV until then.

Like this, in this scheme, the user doesn’t know which server he is communicating with, so even if the attacker sends his message to the other server, he will never recognize it.

Replay attack. In the step2 of the authentication phase, after receiving the message M1 from the user, the server doesn’t check if the message M1 was replayed. And the server computes D5, D6, D7, D8 and sends the message M2 to CS. And in the step3, the message M2 which the server sent to CS doesn’t contain any information which CS can check if M1 was replayed in the step1 such as a time stamp or the random number which CS generated and sent to the user. In this step, CS only knows the random number b generated by the user. So CS also doesn’t recognise the replay attack. Thus, if the attacker steals the message M1 and retransmits it to the server SV, the server will not recognize this attack and will keep computing. After receiving M1, the server will send M2 to CS and CS also will not recognize the replay attack and will transmit M3 to the server. Finally, the server will send M4 to the attacker. Like this way, the attacker can pass the step2, 3 and 4 very easily. As a result, this scheme is vulnerable to the replay attack.

No key control. In Zhou et al.’s scheme, the session key is computed as follow: SK = h(b ⊕b ⊕ b). Here, b is the random number generated by the server, b is the random number generated by the user and b is the random number generated by CS. In the step3 of the authentication phase, CS gets b and b by computing b = D1 ⊕ h (PI||I||k) and b = D5 ⊕ h(PSI||I||k). And CS generates the random number b and computes the session key SK = h (b ⊕ b ⊕ b). Like this, CS knows all of the three random numbers so the session key between the user and the server publishes to CS. As we know, the session key is the secret value which only two session entities must have because this is the key for the session between the user and the server. But in this scheme, CS also gets the session key between the user and the server. Thus, this scheme doesn’t provide no key control property.

Re-registration with the original identity. In the user registration process of this scheme, the secret value concerned with the user identity is C2* = h(I || k). In the case that CS’s secret key k is known to the attacker, the user has to update the value of C2* concerned with his identity by reregistration in CS. So the attacker cannot guess the next round’s secret value. But in this scheme, the user cannot register again with his original identity I and he can no longer use this identity because the secret C2* doesn’t include any nonce.

If a random number is included in the computing of C2*, the user can use the original identity because he can update C2* by generating the new random number.

Inefficiency in the verification of wrong password. In 2006, Tsai et al. [47] pointed out that the ideal password-based scheme should detect typo error quickly without the communication with the home server. But in Zhou et al.’s scheme, if the attack inputs wrong password, it can not be quickly detected by the smart card. In the step 1 of the authentication phase, the smart card gets r = C3 ⊕ h(I || PA) when the user enters his identity and password. But in this step, the smart card doesn’t check if this r is the same with the random number generated by the user in the registration phase, keeps computing and sends the message M1 to the server. In the step2, there is also no verification process of the password and in this step the server sends the message M2 to CS. Only then in the step3, CS can recognise the wrong password by checking the value of D4.

Therefore, if the attacker inputs the wrong password in the step1, all the values computed in this step will be wrong. But the authentication process keeps going passing the step2 and step3, only then in the step3 these errors are detected.

4. Proposed scheme

In this section we describe an improved authentication key agreement protocol using pseudo-identity that overcomes the limitations of the Zhou et al.’s scheme. The proposed scheme consists of four steps: registration phase, authentication, session key exchange phase, password change phase and user revocation, reregistration phase. The notations in Table 3 are used to describe the proposed scheme in our work.

Table 3

Notation used in proposed scheme.

Notation	Description
R	Registration center
URi,SRj	The ith user, jth server
x U	Secret key which R shares with URi
x S	Secret key which R shares with SRj
SC i	Smart card of URi
UID i	Identity of URi
PUID i	Pseudo-identity of URi
RID	Identity of R
SID j	Identity of SRj
PSID j	Pseudo-identity of SRj
PW i	Password of URi
BIO i	Biometric of URi
SK	Session key for URi and SRj
Tn(α)	Chebyshev chaotic map
h(∙)	One-way hash function
||	Concatenation operator
⊕	XOR operator

4.1 Registration phase

4.1.1 User registration phase

All users who want to exchange session keys using the proposed scheme must register on CS.

Fig 1 shows the user registration process.

Fig 1

User registration phase in the proposed scheme.

Step 1: The user UR selects UID, PUID, PW and inputs BIO in the smart card. Then the smart card extracts (R, P) from Gen(BIO) → (R, P), computes VD = h(PW||R||UID) and sends (UID,PUID) to R via a secure channel.

Step 2: The registration center R generates a random number RU computes UD1* = h(PUID||RID||x), UD2* = h(UID||xU||RU) and stores UID, RU in its database. And then R sends (UD1*, UD2*, RID) to UR via a secure channel.

Step 3: The user computes UD1 = UD1*⊕VD, UD2 = UD2*⊕VD, UD3 = h(VD||UD1*||UD2*) and stores (UD1,UD2,UD3,PUID,RID,P) in his smart card.

4.1.2 Server registration phase

Fig 2 shows the server registration process.

Fig 2

Server registration phase in the proposed scheme.

Step 1: The server SR first selects SID, PSID and sends (SID, PSID) to R via a secure channel.

Step 2: R computes SD1 = h (PSID||RID||x), SD2 = h(SID||x||RS) and stores SID, RS in the database. And then R sends (SD1, SD2, RID) to the server.

Step 3: The server SR stores (SD1, SD2, SID, PSID, RID) in his smart card.

4.2 Authentication and session key exchange phase

Fig 3 shows the authentication and session key exchange steps of the proposed scheme.

Fig 3

Authentication and session key exchange phase of the proposed scheme.

Step 1: The user UR inserts his smart card into a card reader and enters UID, PW and BIO*. The smart card recovers R from Rep(BIO*,P) → R, selects the random numbers r, PUID, rk and computes P = T(α) mod p, UD1* = UD1⊕h(PW||R||UID), UD2* = UD2⊕h(PW||R||UID). And then UR computes UD3’ = h(h(PW ||R ||UID) ||UD1*||UD2*) and checks if UD3’ = UD3. If it’s false, this phase will be stopped. If so, the smart card calculates E1 = UD1*⊕r, E2 = h(r||PUID||RID) ⊕UID, E3 = PUID⊕h(r||UID), V = h(UID||PUID||PUID||r||P||SID||T1||UD2*)(T1 is a time stamp.) and sends the message M1 = {PUID,E1,E2,E3,V, P,T1} to the server SR.

Step 2: After receiving the message M1, the server SR computes ΔT = T1-T2 that is the difference between T1 and T2 (T2 is the current time on SR). If the difference ΔT is greater than ΔT that is the defined time interval, the server will stop the authentication phase. Else the server selects PSID, r, rk and calculates P = T(α) mod p, SK = T(P) = T(α) mod p, E4 = SD1⊕r, E5 = h(r||PSID||RID)⊕SID, E6 = PSID⊕h(r||SID), V = h(SK||SID||RID), V = h(SID||PSID|| PSID||r||P||P||T3||V|| SD2) (T3 is a time stamp.). And SR transmits the message M2 = {PUID,E1,E2,E3, V,E4,E5,E6,V,T1,T3,P, P,V} to the registration center R.

Step 3: And R computes ΔT* = T3-T4 that is the difference between T3 and T4 (T4 is the current time on R). If ΔT* is greater than ΔT* that is the defined time interval, R will stop this phase. Else R computes the following data: r = E1⊕h(PUID||RID||x), UID = E2⊕h(r||PUID||RID), UD2*’ = h(UID||x||RUcs), PUID = E3⊕h(r||UID), r = E4⊕h(PSID||RID||x), SID = E5⊕ h(r ||PSID||RID), SD2* = h(SID||x||RScs), PSID = E6⊕h(r||SID). And then R checks if the identity UID is valid. If so, R computes V’ = h(UID||PUID||PUID||r||P||SID||T1||UD2*) and checks if V’ = V. If not so, the session will be terminated. Else it is checked if SID is valid, computes V’ = h(SID||PSID|| PSID||r||P||P||T3||V|| SD2) and checks if V’ = V. If so, E7 = h(PSID||RID||x)⊕h(r||PSID), V = h(SD2*||r||P), E8 = h(PUID||RID||x)⊕h(r||PUID), V = h(UD2*’||r||P) are computed and R sends the message M3 = {E7,E8,V,V,P,V} to UR.

Step 4: Then the user calculates V’ = h(UD2*||r||P) and checks if V’ = V. If so, he calculates SK’ = T(P) = T(α) mod p, V’ = h(SK’||SID||RID) and checks if V’ = V. If not so, the session will be stopped. Else he keeps SK’ as the session key SK. And the user computes UD1* = E8⊕h(r||PUID), UD1 = UD1*⊕ h(PW||BIO||UID) and replaces (UD1,PUID) with (UD1,PUID). Also he calculates V = h(SK||RID) and transmits the message M4 = {E7, V V} to the server SR.

Step 5: The server SR computes V’ = h(SD2||r||P) and checks if V’ = V. If so, SR computes V’ = h(SK||RID) and checks if V = V’. If not so, the session will be terminated. Else the server regards SK as the session key for itself and UR, computes SD1 = E7⊕h(r||PSID) and replaces (SD1, PSID) with (SD1, PSID).

Step 1: When the user UR wants to change his password, he first inserts his smart card into a reader and inputs UID, PW and BIO. Then the smart card extracts (R, P) from Gen(BIO) → (R, P), selects r, PUID, rk, computes P = T(α) mod p, UD1* = UD1⊕h(PW||R||UID), UD2* = UD2 ⊕h(PW||R||UID),UD3’ = (h(PW||R||UID)||UD1*||UD2*) and checks if UD3’ = UD3. If so, the smart card calculates E1 = UD1⊕r, E2 = h(r||PUID||RID) ⊕UID and E3 = UD2*⊕PUID⊕h(r||UID), V = h(UID||PUID||PUID||r||P||SID||T5)(T5 is a time stamp.), and sends the message M5 = {PUID,E1,E2,E3,V, P,T5} with a password change request to R.

Step 2: After receiving the message with a request, R calculates ΔT** = T5-T6 that is a difference between T5 and T6 (T6 is the current time on R). If ΔT** is greater than a defined time interval, R will terminate this phase. Else R computes r = E1⊕h(PUID||RID||x), UID = E2⊕h(r||PUID||RID), UD2*’ = h(UID||x||RU), PUID = E3⊕UD2*’⊕h(r||UID). And R checks if UID is valid, computes V’ = h(UID||PUID||PUID||r||P||SID||T1) and checks if V’ = V. If so, E8 = h(PUID||RID||x)⊕h(r||PUID), E9 = h(UID||PUID||PUID||r||D8) are computed and the message M6 = {E8,E9} is sent to the user UR.

Step 3: And the smart card of UR calculates E9’ = h(UID||PUID||PUID||r||E8) and checks if E9’ = E9. If so, UR enters the new password PW. Then the smart card calculates VD = h(PW||R||UID), UD = UD1⊕VD, UD2 = UD2*⊕VD, UD3 = h(VD||UD1||UD2*) and replaces (UD1,UD2,UD3) with (UD1,UD2,UD3).

4.4 User revocation and re-registration phase

4.4.1 User revocation phase

If the user UR wants to revocate his data on the registration center, he needs to send his identity UIDi with a revocation request to R via a secure channel. Then R checks if UIDi was included in its database and if so, R will remove all data concerned with the identity UID in the database. And a revocation response is sent to the user UR via a secure channel.

4.4.2 Reregistration phase

If the user UR wants to register again, he has to choose his new identity, new pseudo-identity, new password, new biometric and to pass the steps in the user registration phase as they are. In the precedent schemes, the user’s secret key UD1* = h (UID||x) consists of only the user’s identity and the server’s secret value. Thus, if the user’s secret key is published, the user must choose a new identity to register again. But in our scheme, the user’s secret key UD1* = h (UID||x||RU) consists of the user’s identity, the server’s secret value and a nonce. The user’s secret key is updated without the identity change because the registration center R generates a new nonce RU every registration phase. Therefore, the user can register again on R without change of his identity. To register again on R with an original identity, the user has to transmit his original identity, pseudo-identity, password and biometric to R. And then he has to pass the steps in the user registration phase as they are.

5. Security analysis of the proposed scheme

In this section, we analyse the security properties of the proposed scheme. First, we prove the validation of the session key between the user and server by using BAN logic [48]. Next, we simulate the proposed scheme for the formal security analysis by using AVISPA (Automated validation of internet security protocol and application) tool [49]. Last, we demonstrate the proposed scheme can resist various kinds of attacks.

5.1 Authentication proof based on BAN logic

Notations and rules

We define P and Q as the specific participators, S is the trusted server, and X is the formula (statement). Some notations and rules of BAN logic are as follows [48].

P |≡ X: P believes X.

P ⊲ X: P sees X.

P |∼ X: P once said X.

P |⇒ X: P has jurisdiction over X.

#(X): X is fresh.

: K is a shared secret key between P and Q.

{X}: Formula X is encrypted under the key K.

: X combined with the formula Y.

(Message-meaning rule): if P believes that the key K is shared with Q and receives a message containing X encrypted under K, then P believes that Q once said X.

(Nonce-verification rule): if P believes X is fresh and Q once said X, P believes Q believes X.

(Jurisdiction rule): if P believes that Q had jurisdiction right to X and believes Q believes X, P believes X.

(Freshness rule): If X is a part of message (X, Y) and X is fresh, message (X, Y) is also fresh.

(Belief rule 1): If P believes Q believes the message set (X, Y), P also believes Q believes the message X.

(Belief rule 2): If P believes the message X and Y, P also believes the message set (X, Y).

(Hash function rule): if P believes that Q once said H(X) and receives X, P believes Q once said X.

Goals

The session key exchange protocol should achieve the following goals:

Idealize

We idealize the communication messages of the proposed scheme as follows:

Assumptions

The initial assumptions of the proposed scheme are as follows:

A: UR|≡rk

A: UR|≡#(rk)

A: UR|≡R|⇒P

A: UR|≡r

A: UR|≡#(r)

A: SR|≡rk

A: SR|≡#(rk)

A: SR|≡R|⇒P

A: SR|≡r

A: SR|≡#(r)

Analysis

According to M3 and A, we apply the hash function rule (R7), we can obtain:

According to M3 and A, we apply the Freshness rule (R4), we can obtain:

According to S1 and S2, we apply the Nonce-verification rule (R2) and Belief rule 1(R5), we can obtain:

According to S3 and A, we apply the Jurisdiction rule (R3), we can obtain:

According to S4, A and SK = T (P) mod p, we apply the Belief rule 2(R6), we can obtain:

According to M4 and A, we apply the message meaning rule (R1) and the hash function rule (R7), we can obtain:

According to M4 and A, we apply the Freshness rule (R4), we can obtain:

According to S6 and S7, we apply the Nonce-verification rule (R2) and Belief rule 1(R5), we can obtain:

According to A and S8, we apply the jurisdiction rule (R3), we can obtain:

According to A, S9 and SK = T(P) mod p, we apply the Belief rule 2(R6), we can obtain:

According to M3 and S5, we apply the message meaning rule (R1) and the hash function rule (R7), we can obtain:

According to A, M3 and SK = T(P) mod p, we apply the Freshness rule (R4), we can obtain:

According to S11 and S12, we apply the Nonce-verification rule (R2) and Belief rule 1(R5), we can obtain:

According to M4 and S10, we apply the message meaning rule (R1) and the hash function rule (R7), we can obtain:

According to A, M4 and SK = T(P) mod p, we apply the Freshness rule (R4), we can obtain:

According to S14 and S15, we apply the Nonce-verification rule (R2) and Belief rule 1(R5), we can obtain:

5.2 Validation test based on AVISPA

In this section, we simulate the proposed scheme for the formal security analysis using AVISPA, which is widely used to verify the security properties of designed protocol such as resistance against replay attack and man-in-the-middle attack. This tool implements four back-ends: On-the-Fly-Model-Check (OFMC), Constraint Logic based Attack Searcher (CL-AtSe), SAT-based Model-Checker (SATMC) and Three Automata based on Automatic Approximations for the Analysis of Security Protocols (TA4SP). In order to verify the security properties of the protocol using AVISPA, it needs to be specified in HLPSL (High Level Protocol Specification Language), which is a role-based language: basic roles for representing each participant role, and composition roles for representing scenarios of basic roles. Each role is independent from the other, communicating with the other roles by channels [44]. The output format is generated by using one of the four back-ends.

Specifying the proposed protocol

In our HLPSL implementation, we define three basic roles for the user U, server S and registration center R. Figs 4–6 shows the specifications in HLPSL for the role of U, S and R.

Fig 4

Role specification in HLPSL for the user U.

Fig 6

Role specification in HLPSL for the registration center R.

In Figs 7–9, we show the HLPSL implementation for the role of the session, environment and goal.

Fig 7

Role specification in HLPSL for the session.

Fig 9

Role specification in HLPSL for the goal.

In our implementation, we verified the following fifteen secrecy goals and six authentication properties.

secrecy_of sec_rscs: It represents that the nonce Rscs generated by R is kept secret to the registration center R only.

secrecy_of sec_vd: It represents that user U’s private data VD is kept secret to the user U only.

secrecy_of sec_rucs: It represents that the nonce Rucs generated by R is kept secret to the registration center R only.

secrecy_of sec_xs: It represents that registration center R’s secret key X is kept secret to R only.

secrecy_of sec_b1: It represents that the server S’s shared secret key B1 is kept secret to the user U and the registration center R only.

secrecy_of sec_b2: It represents that the server S’s shared secret key B2 is kept secret to the user U and the registration center R only.

secrecy_of sec_rks: It represents that the nonce Rks generated by the server S is kept secret to the server S only.

secrecy_of sec_rs: It represents that the nonce Rs generated by the server S is kept secret to the server S only.

secrecy_of sec_sid: It represents that the server S’s identity SID is kept secret to the user U, the server S and the registration center R only.

secrecy_of sec_c1: It represents that the user U’s shared secret key C1 is kept secret to the user U and the registration center R only.

secrecy_of sec_c2: It represents that the user U’s shared secret key C2 is kept secret to the user U and the registration center R only.

secrecy_of sec_xu: It represents that registration center R’s secret key X is kept secret to R only.

secrecy_of sec_rku: It represents that the nonce Rku generated by the user U is kept secret to the user U only.

secrecy_of sec_ru: It represents that the nonce Ru generated by the user U is kept secret to the user U only.

secrecy_of sec_uid: It represents that the user U’s identity UID is kept secret to the user U and the registration center R only.

authentication_on auth_vsr: It represents that the registration R authenticates the server S.

authentication_on auth_vsu: It represents that the user U authenticates the server S.

authentication_on auth_vrs: It represents that the server S authenticates the registration center R.

authentication_on auth_vus: It represents that the server S authenticates the user U.

authentication_on auth_vru: It represents that the user U authenticates the registration center R.

authentication_on auth_vur: It represents that the registration center R authenticates the user U.

Analysis of the results

We have simulated the proposed scheme using FMC and CL-AtSe back-ends of AVISPA. The simulation results for the security verification are shown in Figs 10 and 11.

Fig 10

The result of the analysis using OFMC back-end.

Fig 11

The result of the analysis using CL-AtSe back-end.

The results ensure that the proposed scheme is secure under the test of AVISPA using OFMC and CL-AtSe back-ends, and guarantees user anonymity, and it is also secure against the passive attacks and the active attacks, such as the replay attack and man-in-the-middle attack.

5.3 Informal security analysis

In this part, we demonstrate the proposed scheme can resist various kinds of attacks.

Mutual authentication

The proposed scheme provides the mutual authentication.

In the step 3 of the authentication phase, the registration center R computes r = E1⊕ h(PUID||RID||x), UID = E2⊕h(r||PUID||RID), UD2*’ = h(UID||x||RU), PUID = E3⊕ h(r||UID), r = E4⊕h(PSID||RID||x), SID = E5⊕h(r||PSID||RID), SD2* = h(SID||x||RS), PSID = E6⊕h(r||SID) and checks if the user’s identity UID is included in the verification table. If so, R computes V’ = h(UID||PUID||PUID||r||P||SID||T1|| UD2*) and checks if V’ = V. If so, R authenticates the user UR. The proof of this authentication is as follows. At first, UD2* included in V is a secret key known to only the user UR and the registration center R. And V contains the nonce r generated by the user. Thus the registration center can verify that V was sent by the user and that it wasn’t replayed if V’ = V is true.

And the registration center R checks if the server’s identity SID is included in the verification table. If so, R computes V’ = h (SID||PSID|| PSID||r||P||P||T3||V||SD2) and checks if V’ = V. If so, R authenticates the server SR. The proof of this authentication is as follows. At first, SD2 included in V is a secret key known to only the server SR and the registration center R. And V contains the nonce r generated by the server. Thus the registration center can verify that V was sent by the server and that it wasn’t replayed if V’ = V is true.

In the step4, the user UR computes V’ = h (UD2*||r||P) and checks if V’ = V. If so, UR authenticates the registration center R. The proof of this authentication is as follows. At first, UD2* included in V is a secret key known to only the user UR and the registration center R. And V contains the nonce r generated by the user. Thus the user can verify that V was sent by R and that it wasn’t replayed if V’ = V is true.

And UR computes SK = T (P) = T(α) mod p, V’ = h(SK||SID||RID) and authenticates the server SR by checking if V’ = V. The proof of this authentication is as follows. Because SK included in V is computed as SK = T (P) = T (P) = T(α) mod p, it is a secret generated by only the server SR except for the user UR. Also it contains the nonce r generated by the user in step 1. Thus the user can verify that V was sent by the server and that it wasn’t replayed if V’ = V is true.

In the step5, the server computes V’ = h (SD2||r||P) and checks if V’ = V. If so, the server authenticates the registration center R. The proof of this authentication is as follows. At first, SD2 included in V is a secret key known to only the server SR and the registration center R. And V contains the nonce r generated by the server. Thus the user can verify that V was sent by R and that it wasn’t replayed if V’ = V is true.

And the server computes V’ = h(SK||RID) and authenticates the user UR by checking if V’ = V. The proof of this authentication is as follows. Because SK included in V is computed as SK = T(P) = T(P) = T(α) mod p, it is a secret generated by only the user UR except for the server SR. Also it contains the nonce r generated by the server in step2. Thus the server can verify that V was sent by the user and that it wasn’t replayed if V’ = V is true.

Therefore, the registration center authenticates the user and server in the step3, the user authenticates the registration center and server in step4, and the server authenticates the registration center and user in step5. Thus the proposed scheme achieves the mutual authentication between the registration center, user and server.

User anonymity

The proposed scheme provides user anonymity for key exchange.

The data that an attacker can use to get the user’s identity UID is E2 = h(r||PUID||RID) ⊕ UID among the messages M1 = {PUID, E1, E2, E3, V, P, T1}, M2 = {PUID, E1, E2, E3, V, E4, E5, E6, V, T1, T3, P, V}, M3 = {E7, E8, V, V, P, V} and M4 = {E7, V V} in authentication key exchange process. If the attacker wants to get UID, he may compute as follows: UID = E2⊕h (r||PUID||RID). For this, the attacker needs to know the nonce r generated by the user and has to compute r = E1⊕h (PUID||RID||x). So the attacker also needs to know x, but the attacker cannot get x because it is a secret known to only the registration center R. Thus, the attacker cannot get the user’s identity UID.

If the attacker wants to get the server’s identity SID, he may compute as follows: SID = E5⊕h(r||PSID||RID). For this, the attacker needs to know the nonce r generated by the server and has to compute r = E4⊕h(PSID||RID||x). So the attacker also needs to know x but the attacker cannot get x because it is a secret known to only the registration center R. Thus, the attacker cannot get the server’s identity SID.

As a result, the attacker cannot get both the user’s identity and server’s identity.

Perfect forward security of session key

In the proposed scheme, the session key SK is computedd as SK = T(P) = T(P) = T(α) mod p. It contains the random numbers rk and rk generated by the different session entities for each session. Thus, even if the attacker gets rk and rk for the current session, he cannot compute the session key for the previous session. Therefore, the proposed scheme provides the perfect forward secrecy of session key.

Untraceability

The proposed scheme provides the untraceability.

Let’s imagine that the attacker can get the secret data of the user and server for the previous session by stealing previous messages. But in the step 4 of authentication key exchange phase, the user replaces (UD1, PUID) with (UD1, PUID) and in the step 5, the server replaces (SD1, PSID) with (SD1, PSID). And for the next session, both the user and server combine their identities with the updated secret data and generated new random numbers. Therefore, the attacker cannot get the identities of the user and server, for the next session using the previous messages, so he cannot know the current communicating entities.

No key control

The proposed scheme provides no key control property.

In the proposed scheme, the session key SK is computed as SK = T(P) = T(P) = T(α) mod p. In this equation, P is computed as T(α) mod p and P is computed as T(α) mod p. And rk is only known to the server and the user knows only P. But according to the rules CDLP [36] and CDHP [36], the user never computes rk from P. Also rk is only known to the user and the server never gets rk from P. Thus, the session key cannot be generated by each of the user and server, and it can be only generated by the agreement of both of them.

Off-line password guessing attack

The proposed scheme resists the password guessing attack.

This scheme does not use passwords during the authentication process but only uses passwords for access to the smart card. The information stored in the user’s smart card is (UD1, UD2, UD3, PUID, RID, P) and the information that can be used for guessing password is UD1 = UD1* ⊕ h(PW||R||UID) and UD2 = UD2* ⊕ h(PW||R||UID). Let’s imagine that an attacker steals the user’s smart card SC and gets his identity UID. Then to guess the password PW, the attacker must compute VD* = h(PW*||R||UID), UD1*’ = UD1⊕VD*, UD2*’ = UD2⊕VD*, UD3’ = h(VD* ||UD1*’ ||UD2*’) by using UID and any password PW* to compare UD3’ and UD3 stored in SC. But the attacker cannot get R because he cannot know the user’s biometric BIO so he cannot calculate above equations. Thus, the attacker cannot guess the user’s password.

Privileged insider attack

The proposed scheme is secure against the privileged-insider attack. In the registration phase of the proposed scheme, only the user’s identifier is transmitted to the registration center through a secure channel and the user’s password and biometric are not transmitted to the registration center. Therefore, the privilege insider of the registration center cannot know the user’s password and biometric. Therefore, the proposed scheme is secure against this attack.

Stolen verifier attack

The proposed scheme is secure against stolen verifier attack.

In the registration phase, the registration center R stores {UID, RU} in the user registration table. Here UID is the identity of the user UR and RU is the random number chosen by R. The essential factors that R can use to authenticate the user are the shared secrets between the registration center and user, UD1* = h(PUID||RID||x), UD2* = h(UID||x||RU) and the random numbers r rk generated by the user. So even if the attacker knows UID and RU, he cannot pass the authentication steps safely. Therefore, the attacker cannot be successful in this attack.

User impersonate attack

The proposed scheme is secure against the user impersonate attack. In order to impersonate as the user UR, the attacker has to compute E1 = UD1*⊕r, E2 = h(r||PUID||RID) ⊕ UID and E3 = PUID⊕h(r||UID). Let’s imagine that the attacker knows PUID, RID, UID and he generates PUID and a nonce r. Then he can calculate E3 = PUID⊕h(r||UID) and E2 = h(r||PUID||RID) ⊕UID. But he cannot compute E1 = UD*⊕r without knowing of UD*. But he cannot compute UD1* = h(PUID||RID||x) because x is a secret known to only the registration center and cannot also calculate E1 = UD1*⊕r.

Therefore, the attacker cannot impersonate as UR and achieve this attack.

Server impersonate attack

The proposed scheme is secure against the server impersonate attack.

In order to impersonate as the server SR, the attacker has to compute E4 = SD1⊕r, E5 = h(r||PSID||RID) ⊕ SID and E6 = PSID⊕h(r||SID). Let’s imagine that the attacker knows RID, SID and he generates PSID and a nonce r. Then he can calculate E6 = PSID ⊕ h(r||SID) and E5 = h(r||PSID||RID) ⊕SID. But he cannot compute E4 = SD1⊕r without knowing of SD1. But he cannot compute SD1 = h(PSID||RID||x) because x is a secret known to only the registration center and cannot also calculate E4 = SD1⊕r.

Therefore, the attacker cannot impersonate as SR and achieve this attack.

Man-in-the-middle attack

As it is shown above, the proposed scheme achieves certain mutual authentication and the attacker can neither impersonate as the initiator UR and the responder SR, so an attacker cannot achieve the man-in-the-middle attack. The reasons for this are as follows.

First, the attacker cannot exchange any messages with the user by impersonating as the responder, valid server. As we show above, the attacker cannot compute SD1 = h(PSID||RID||x) because x is a secret known to only the registration center and cannot also calculate E4 = SD1⊕r. Hence, the attacker cannot impersonate as the responder. Also the attacker cannot exchange any messages with the server by impersonating as the initiator, valid user. As we show above, the attacker cannot compute UD1* = h(PUID||RID||x) because x is a secret known to only the registration center and cannot also calculate E1 = UD1*⊕r. Hence, the attacker cannot impersonate as the initiator.

In conclusion, the attacker cannot achieve the man-in-the-middle attack.

Replay attack

In the step 2 of the authentication key exchange phase, after receiving the message M1, the server checks if ΔT = T1-T2<ΔT and if it is false, the server stops the session. Here T1 is the time when the message is sent and T2 is the time when the message is received. So the replay attack can’t be achieved in this step. Also in the step 3, the attacker cannot achieve the replay attacker because the message M3 contains a time stamp. In the step 4, the user checks if V = h(UD2*||r||P) is true. Here r is a nonce generated by the user in the step 1, so in the case that the attacker replays the message M3 to the user, the user can recognize this attack using r. Like this, in the step 5, the server can recognize that the message M4 was replayed by the attacker by checking r generated by the server in the step 2.

Therefore, the attacker cannot achieve replay attack.

Forgery attack

Forgery attack means that an attacker attempts to forge captured messages to masquerade as the legitimate user for wireless system access to the resources.

These followings are the analysis of messages in the proposed scheme.

In the message M1, E1 and V both contain x.

In M2, x is required in both E4 and V, besides the original elements in M1.

In M3, E7, V, E8 and V all needs x and x.

In M4, x and x are required in both E7 and V.

As it is shown above, the attacker has to know both x and x to forge any messages in the session. But x and x cannot be captured by the attacker because both of them are the secret keys known to only the registration center R. Therefore, the attacker cannot forge any messages and we can claim that the proposed scheme resists forgery attack.

Known key security

In the proposed scheme, the session key SK is calculated as SK = T (P) = T(P) = T(α) mod p. It contains the random numbers rk and rk that are generated by session entities for each session. Even if an attacker gets the previous session key, he cannot calculate the current session key.

Therefore, the proposed scheme provides known key security property.

6. Performance comparisons

In this section, we compare the computational cost, communication overhead and security performance of the proposed scheme with the recent similar authentication key exchange protocols [12, 31, 35].

The notations used for comparison of computational cost are as follows.

t: time needed for Chebyshev polynomial operation

t: time needed for a scalar multiplication on elliptic curve

t: time needed for symmetric encryption/decryption operation

t: time needed for public key encryption/decryption operation

t: time needed for one-way hash function operation

Table 4 shows the comparison of the computational cost of the four schemes, including the proposed scheme in the authentication and session key exchange phase. According to the execution overhead given in [50-52], in the environment where CPU is 2.20GHz and RAM is 2048MB, it takes about 0.0023ms, 0.0046ms, 2.226ms, 3.85ms, 2.226ms to execute the one-way hash function, symmetric encryption/decryption, the scalar multiplication on elliptic curve, public key encryption/decryption and Chebyshev polynomial operation respectively. Compared with other schemes, the result shows that our scheme requires nearly low computational cost.

Table 4

Comparison of the computational cost between the proposed scheme and other schemes in the authentication and session key exchange phase.

	Lwamo et al. [12]	Zhou et al. [31]	Tomar et al. [35]	proposed
UR i	9th+ts+tp	10th	3te + 11th	2tc + 8th
SR j	9th+ 2ts+ tp	7th	3te + 7th	2tc + 7th
R		19th	2te + 12th	16th
Total	18th+3ts+ 2tp	36th	8te+ 30th	4tc + 31th
Total execution time	7.7552ms	0.0828ms	17.877ms	8.9753ms
Round	3	4	5	4

In order to measure the communication overhead of our proposed scheme, let us assume the bit size of identity, random number, timestamp, hash output, Chebyshev chaotic maps and elliptic curve cryptography as |ID| = 160, |N| = 160, |Ts| = 32, |H| = 160, |T| = 160 and |E| = 320 bits respectively.

Table 5 shows the communication overhead of our proposed scheme according to above assumption.

Table 5

Communication overhead of our proposed scheme.

	Expression	Length of message(bits)
M1	|ID| +4|H| + |T|+|Ts|	992
M2	|ID|+9|H| +2|Ts|+2|T|	1984
M3	5|H| +|T|	960
M4	3|H|	480
Total	2|ID| + 21|H| + 4|T|+3|Ts|	4416

Table 6 shows the comparison of the communication overhead of our proposed scheme and three other schemes. As shown in Table 6, the communication overhead of our proposed scheme is higher than other schemes.

Table 6

Comparison of the computational cost between the proposed scheme and other schemes.

	Lwamo et al. [12]	Zhou et al. [28]	Tomar et al. [32]	proposed
M1	2|H|+2|ID|+|Ts|	|ID|+4|H|	|ID|+4|H|+|E|+|Ts|	|ID| +4|H| + |T|+|Ts|
M2	3|N|+3|ID|+|H|+2|Ts|	8|H|+2|ID|	|ID|+7|H|+2|E|+|Ts|	|ID|+9|H| +2|Ts|+2|T|
M3	|H|	6|H|	3|H|+|Ts|	5|H| +|T|
M4		3|H|	3|H|+|E|+|Ts|	3|H|
M5			|H|
Total	5|ID|+3|N|+4|H|+3|Ts|	3|ID|+21|H|	2|ID|+18|H|+4|E|+4|Ts|	2|ID| + 21|H| + 4|T|+3|Ts|
Total bits	2016	3840	4608	4416

Table 7 shows the comparative evaluation of the security function between the proposed scheme and other schemes.

Table 7

Comparative evaluation of the security function between the proposed scheme and other schemes.

	Lwamo et al. [12]	Zhou et al. [31]	Tomar et al. [35]	proposed
Provision of mutual authentication	Yes	No	Yes	Yes
Provision of User anonymity	Yes	Yes	Yes	Yes
Provision of untraceability	Yes	Yes	Yes	Yes
Protection of password guessing attack	Yes	Yes	Yes	Yes
Protection of Privileged insider attack	Yes	Yes	Yes	Yes
Protection of stolen smart card attack	No	Yes	Yes	Yes
Protection of User impersonate attack	Yes	Yes	Yes	Yes
Efficiency in the verification of wrong password	Yes	No	Yes	Yes
Protection of replay attack	Yes	No	Yes	Yes
Provision of no key control	Yes	No	Yes	Yes
Reregistration with the original identity	No	No	No	Yes
Using biometric	Yes	Yes	Yes	Yes
Using smart card	Yes	Yes	Yes	Yes

As shown in Tables 4, 6 and 7, the proposed scheme outperforms the other schemes in terms of the security properties presented.

Lwamo et al.’s scheme has high computational cost because it uses the public key encryption. Also his scheme has lower communication overhead than ours’ scheme and doesn’t provide re-registration with the original identity and it is vulnerable to the stolen smart card attack.

Zhou et al.’s scheme uses only hash functions so it has very low computational cost, but it has lower communication overhead than ours. And it is vulnerable to the replay attack and doesn’t provide various properties such as mutual authentication, no key control, re-registration with the original identity, and efficiency in the verification of wrong password.

Tomar et al.’s scheme provides the security properties mentioned in the Table 7 but his scheme has higher computational cost and higher communication overhead than our proposed scheme. And it doesn’t provide the re-registration with the original identity.

As shown in Tables 4, 6 and 7, the schemes with strong security performances have high computational cost, while the schemes with low computational cost don’t provide the strong security performances.

7. Conclusion

In this work, we analysed Lwmao et al.’s scheme and Zhou et al.’s scheme, pointed out its weakness and proposed an improved chaotic mapping-based authentication key agreement protocol with low computational cost, high communication overhead, robust security performance and strong mutual authenticaton. The proposed scheme was designed to provide strong mutual authentication between communication participants, so the length of messages is long and communication overhead is relatively high. In the proposed scheme, we allowed the users to re-register without modifying their identities by including the random numbers in their secret keys shared with the registration center in the registration phase. Also, we used the users’ biometrics and the fuzzy extractor to keep their privacies more secure. We also prevented the replay attack using timestamps and chaotic maps, and provided the robust mutual authentication and safer session key agreement. The proposed scheme also achieved various security properties and attack resistances such as the anonymity, untraceability and resistance of stolen smart card attack. Also, we formally analysed our protocol based on BAN logic and AVISPA tool, and demonstrated that it is secure against various attacks through informal security analysis.

9 May 2022

A rebuttal letter that responds to each point raised by the academic editor and reviewer(s). You should upload this letter as a separate file labeled 'Response to Reviewers'.

A marked-up copy of your manuscript that highlights changes made to the original version. You should upload this as a separate file labeled 'Revised Manuscript with Track Changes'.

An unmarked version of your revised paper without tracked changes. You should upload this as a separate file labeled 'Manuscript'.

If you would like to make changes to your financial disclosure, please include your updated statement in your cover letter. Guidelines for resubmitting your figure files are available below the reviewer comments at the end of this letter.

If applicable, we recommend that you deposit your laboratory protocols in protocols.io to enhance the reproducibility of your results. Protocols.io assigns your protocol its own identifier (DOI) so that it can be cited independently in the future. For instructions see: https://journals.plos.org/plosone/s/submission-guidelines#loc-laboratory-protocols. Additionally, PLOS ONE offers an option for publishing peer-reviewed Lab Protocol articles, which describe protocols hosted on protocols.io. Read more information on sharing protocols at https://plos.org/protocols?utm_medium=editorial-email&utm_source=authorletters&utm_campaign=protocols.

We look forward to receiving your revised manuscript.

Kind regards,

Pandi Vijayakumar, Ph.D

Academic Editor

PLOS ONE

Journal Requirements:

When submitting your revision, we need you to address these additional requirements.

1. Please ensure that your manuscript meets PLOS ONE's style requirements, including those for file naming. The PLOS ONE style templates can be found at

https://journals.plos.org/plosone/s/file?id=wjVg/PLOSOne_formatting_sample_main_body.pdf and

https://journals.plos.org/plosone/s/file?id=ba62/PLOSOne_formatting_sample_title_authors_affiliations.pdf

2. We suggest you thoroughly copyedit your manuscript for language usage, spelling, and grammar. If you do not know anyone who can help you do this, you may wish to consider employing a professional scientific editing service.

Whilst you may use any professional scientific editing service of your choice, PLOS has partnered with both American Journal Experts (AJE) and Editage to provide discounted services to PLOS authors. Both organizations have experience helping authors meet PLOS guidelines and can provide language editing, translation, manuscript formatting, and figure formatting to ensure your manuscript meets our submission guidelines. To take advantage of our partnership with AJE, visit the AJE website (http://learn.aje.com/plos/) for a 15% discount off AJE services. To take advantage of our partnership with Editage, visit the Editage website (www.editage.com) and enter referral code PLOSEDIT for a 15% discount off Editage services.  If the PLOS editorial team finds any language issues in text that either AJE or Editage has edited, the service provider will re-edit the text for free.

Upon resubmission, please provide the following:

The name of the colleague or the details of the professional service that edited your manuscript

A copy of your manuscript showing your changes by either highlighting them or using track changes (uploaded as a *supporting information* file)

A clean copy of the edited manuscript (uploaded as the new *manuscript* file)”

3. Thank you for stating the following financial disclosure:

"No"

At this time, please address the following queries:

a) Please clarify the sources of funding (financial or material support) for your study. List the grants or organizations that supported your study, including funding received from your institution.

b) State what role the funders took in the study. If the funders had no role in your study, please state: “The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.”

c) If any authors received a salary from any of your funders, please state which authors and which funders.

d) If you did not receive any funding for this study, please state: “The authors received no specific funding for this work.”

Please include your amended statements within your cover letter; we will change the online submission form on your behalf.

4. We note you have included a table to which you do not refer in the text of your manuscript. Please ensure that you refer to Tables 1 and 2 in your text; if accepted, production will need this reference to link the reader to the Table.

Additional Editor Comments:

The paper has many serious problems. So the authors should carefully address the reviewers comments and they should submit a revised version in the next round.

[Note: HTML markup is below. Please do not edit.]

Reviewers' comments:

Reviewer's Responses to Questions

Comments to the Author

1. Is the manuscript technically sound, and do the data support the conclusions?

The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented.

Reviewer #1: Yes

Reviewer #2: No

**********

2. Has the statistical analysis been performed appropriately and rigorously?

Reviewer #1: N/A

Reviewer #2: No

**********

3. Have the authors made all data underlying the findings in their manuscript fully available?

The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified.

Reviewer #1: Yes

Reviewer #2: No

**********

4. Is the manuscript presented in an intelligible fashion and written in standard English?

PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here.

Reviewer #1: Yes

Reviewer #2: Yes

**********

5. Review Comments to the Author

Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters)

Reviewer #1: The authors have developed a mutual key agreement scheme to be used in various applications.

They have also analysed the performance of the proposed scheme using BAN logic and AVISPA tools. The authors must address the following comments before submitting the next version of the manuscript.

The abstract must contain the name of the technical algorithm which the authors had used when comparing their work with the other two different schemes given in the abstract.

The introduction section must be strengthened. It must cover the scope of the proposed work and the objectives must be clearly defined.

Moreover, the proposed mutual key agreement scheme given in the manuscript must cover the following manuscripts. The following manuscript can be considered for analysis in the related work or for comparison in the performance analysis section. The titles of some notable referecnes are given below

�  Secure multifactor authenticated key agreement scheme for industrial IoT.

�  An efficient group key agreement protocol for secure P2P communication.

�  An efficient anonymous authentication and key agreement scheme with privacy-preserving for smart cities.

�  A provably secure dynamic ID-based authenticated key agreement framework for mobile edge computing without a trusted party.

�  An unlinkable authenticated key agreement with collusion resistant for VANET’s

�  A PUF-based lightweight authentication and key agreement protocol for smart UAV networks.

Based on the above considerations, I would recommend MAJOR revision.

Reviewer #2: In this proposed work, the authors mentioned about the Stolen smart card attack. However, practically, the smart card data should be available in the encrypted form with the support of the private key of the user like the ATM cards. In ATM cards, the the pin number is linked with the card number. Similarly, in such type of smart cards also, the data should be protected with the support of the users private keys.

In User revocation phase, the communication is completely happened in the secure channel like SSL. It will enhance the computational overhead enormously.

The authors mentioned that the proposed scheme is secure against the user impersonate attack and the forgery attack. However, there is no proper explanation available about the withstanding against the forgery. There is no proper justification against the main in the middle attack.

In performance analysis, the simulation tools are not mentioned. How did they get the timing values for the cryptographic operations without mentioning the simulation tools.

**********

6. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files.

If you choose “no”, your identity will remain anonymous but your review may still be made public.

Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy.

Reviewer #1: No

Reviewer #2: No

[NOTE: If reviewer comments were submitted as an attachment file, they will be attached to this email and accessible via the submission site. Please log into your account, locate the manuscript record, and check for the action link "View Attachments". If this link does not appear, there are no attachment files.]

While revising your submission, please upload your figure files to the Preflight Analysis and Conversion Engine (PACE) digital diagnostic tool, https://pacev2.apexcovantage.com/. PACE helps ensure that figures meet PLOS requirements. To use PACE, you must first register as a user. Registration is free. Then, login and navigate to the UPLOAD tab, where you will find detailed instructions on how to use the tool. If you encounter any issues or have any questions when using PACE, please email PLOS at figures@plos.org. Please note that Supporting Information files do not need this step.

Submitted filename: CRYPTANALYSIS PAPER.pdf

Click here for additional data file.

22 Jun 2022

Responses to the reviewer1

1) You pointed that “The abstract must contain the name of the technical algorithm which the authors had used when comparing their work with the other two different schemes given in the abstract.” in your comments.

In our paper, we have used the experiment results of Odelu et al.’s scheme and Kilinc et al.’s scheme when comparing the computational cost of our proposed scheme with other related schemes. And we describe about this in the abstract and Section 6 of our manuscript.

2) You also pointed that “The introduction section must be strengthened.”

We added a more detailed description of the scope and purpose of the study in the introduction section. We also studied the papers you suggested and cited them and included them in the related work.

Responses to the reviewer2

1) You pointed that the communication was completely happened through the secure channel in user revocation phase.

If a user loses or is stolen by a malicious user, the user must revocate the already registered user at the user revocation phase.

Since the user information in the proposed protocol is stored on a smart card, we argue that the user should work on a secure channel in the revocation phase as well as in the registration phase.

2) You pointed that there was no proper explanation available about the withstanding against the forgery attack.

We considered the same type of attack as the impersonate attack and forgery attack in the previous manuscript. In this revised manuscript, we individually analysed the forgery attack resistance by distinguishing it from impersonate attack resistance. In the informal security analysis section, we analysed the resistance of the proposed scheme to forgery attacks. We describe about this in lines from 930 to 941.

3) You pointed that there was no proper justification against the man-in-the-middle attack.

We have analysed in detail the man-in-the-middle attack resistance of the proposed scheme in the revised manuscript. We focused on the fact that the man-in-the-middle attack was largely composed of the initiator impersonate attack and the responder impersonate attack, and revealed the attack resistance against it.In our protocol, the session initiator is just the user and the session responder is the server. We have analysed the resistance of our proposed scheme against the man-in-the-middle-attack in the informal security analysis section. We describe about this in lines from 904 to 918.

4) You pointed that the simulation tools were not mentioned in performance analysis.

In the previous manuscript, we used the labels we defined without numerically comparing the computational cost. In the revised manuscript, we use the experimental results of the previous researchers to calculate the computational cost more accurately, based on which we compare the computational cost with the previous schemes. In our paper, we have used the experiment results of Odelu et al.’s scheme, Kilinc et al.’s scheme and Jangirala et al’s scheme to compare the computational cost of our proposed scheme with other related schemes. We describe about it in lines from 945 to 967.

Additionally, we also compare the communication overhead with previous works and describe it in line from 968 to 980.

We hope that the revised manuscript meets the requirements of the editors and reviewers.

Thank you and best regards.

from Kyongsok Pak

Submitted filename: Response to Reviewers.doc

Click here for additional data file.

8 Jul 2022

Cryptanalysis and improved mutual authentication key agreement protocol using pseudo-identity

PONE-D-22-11432R1

Dear Dr. Pak,

We’re pleased to inform you that your manuscript has been judged scientifically suitable for publication and will be formally accepted for publication once it meets all outstanding technical requirements.

Within one week, you’ll receive an e-mail detailing the required amendments. When these have been addressed, you’ll receive a formal acceptance letter and your manuscript will be scheduled for publication.

An invoice for payment will follow shortly after the formal acceptance. To ensure an efficient process, please log into Editorial Manager at http://www.editorialmanager.com/pone/, click the 'Update My Information' link at the top of the page, and double check that your user information is up-to-date. If you have any billing related questions, please contact our Author Billing department directly at authorbilling@plos.org.

If your institution or institutions have a press office, please notify them about your upcoming paper to help maximize its impact. If they’ll be preparing press materials, please inform our press team as soon as possible -- no later than 48 hours after receiving the formal acceptance. Your manuscript will remain under strict press embargo until 2 pm Eastern Time on the date of publication. For more information, please contact onepress@plos.org.

Kind regards,

Pandi Vijayakumar, Ph.D

Academic Editor

PLOS ONE

Additional Editor Comments (optional):

Reviewers' comments:

Reviewer's Responses to Questions

Comments to the Author

1. If the authors have adequately addressed your comments raised in a previous round of review and you feel that this manuscript is now acceptable for publication, you may indicate that here to bypass the “Comments to the Author” section, enter your conflict of interest statement in the “Confidential to Editor” section, and submit your "Accept" recommendation.

Reviewer #1: All comments have been addressed

Reviewer #2: All comments have been addressed

**********

2. Is the manuscript technically sound, and do the data support the conclusions?

The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented.

Reviewer #1: Yes

Reviewer #2: Yes

**********

3. Has the statistical analysis been performed appropriately and rigorously?

Reviewer #1: Yes

Reviewer #2: Yes

**********

4. Have the authors made all data underlying the findings in their manuscript fully available?

The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified.

Reviewer #1: Yes

Reviewer #2: Yes

**********

5. Is the manuscript presented in an intelligible fashion and written in standard English?

PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here.

Reviewer #1: Yes

Reviewer #2: No

**********

6. Review Comments to the Author

Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters)

Reviewer #1: (No Response)

Reviewer #2: (No Response)

**********

7. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files.

If you choose “no”, your identity will remain anonymous but your review may still be made public.

Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy.

Reviewer #1: No

Reviewer #2: No

**********

18 Jul 2022

PONE-D-22-11432R1

Cryptanalysis and improved mutual authentication key agreement protocol using pseudo-identity

Dear Dr. Pak:

I'm pleased to inform you that your manuscript has been deemed suitable for publication in PLOS ONE. Congratulations! Your manuscript is now with our production department.

If your institution or institutions have a press office, please let them know about your upcoming paper now to help maximize its impact. If they'll be preparing press materials, please inform our press team within the next 48 hours. Your manuscript will remain under strict press embargo until 2 pm Eastern Time on the date of publication. For more information please contact onepress@plos.org.

If we can help with anything else, please email us at plosone@plos.org.

Thank you for submitting your work to PLOS ONE and supporting open access.

Kind regards,

PLOS ONE Editorial Office Staff

on behalf of

Dr. Pandi Vijayakumar

Academic Editor

PLOS ONE