# A Robust and Privacy-Preserving Anonymous User Authentication Scheme for Public Cloud Server

Authors: Naveed Khan; Jianbiao Zhang; Saeed Ullah Jan
Journal: Security and Communication Networks
 (2022)

---

## Abstract

Everyone desires to avail online services provided by different service providers securely, efficiently, and effectively. In this regard, security is still a significant concern for them. However, no one guarantees secure communication by browsing different applications remotely. To ensure confidentiality, authorization, availability, nonrepudiation, and removing eavesdropping, without a robust authentication scheme, nothing will go right. Therefore, we attempted to design a robust and privacy-preserving authentication scheme for end-users to securely access public cloud servers’ services remotely without losing performance. Our proposed scheme security has been evaluated formally using the random oracle model (ROM) and ProVerif2.03 and informally using proposition and discussion. At the same time, the performance metric has been analyzed by considering the scheme’s computation and communication costs. Upon comparing the proposed scenario with state-of-the-artwork, it has been demonstrated that the scheme is much better in terms of security and performance, as these are contradicting metrics, and the change in one conversely affects the other.


---

## Body

## 1. Introduction

With the advancement in high-speed Internet and the development of high-performance sensitive applications and smart devices, user privacy and authentication security have become more critical, such as in smartphone scenarios, a user interacts with a cloud server to send and receive data. The users access the cloud servers using smartphones or other portable devices over an insecure channel. From an intruder’s point of view, it is effortless and convenient to carry out malicious attacks and change the behaviour of smart devices.Furthermore, these malicious attacks can be fatal and severely damage the users and cloud service providers. Moreover, with innovation in mobile technologies, portable and affordable lightweight smartphones, laptops, wearable devices access cloud servers for e-commerce, e-banking, chatting, and many more from anywhere and anytime. According to the author of [1], in 2021, the number of mobile users is estimated to be 7.1 billion, and in 2022, it will reach 7.26 billion, while in 2025, the estimation will be 7.49 billion. Therefore, it is challenging to guarantee user data security and privacy because of its openness in wireless communication and anonymity and authentication issues.Furthermore, the communication among smartphones and cloud servers will suffer from malicious attacks such as man-in-the-middle, DoS, impersonation, and password-guessing attacks. Moreover, smartphone devices are resource-constrained and battery-powered. Thus, it is vulnerable to various network attacks.Therefore, authentication is vital among smartphones and cloud servers to protect user data and communication from malicious attacks. But, unfortunately, many protocols prefer usability over security, such as [2–4]. As a result, their scheme cannot resist offline password-guessing attacks and impersonation attacks. Moreover, they did not follow the designing principle of [5] to achieve robust security. Thus, authentication and key agreement protocol that balance security and performance remain a challenge for researchers nowadays.The first authentication and AKA scheme was proposed in 1981 by the author of [6], where the author used the password to authenticate. After that, several schemes were proposed for the radio frequency identification system [7], multiserver environment [8], and server-client [9]. In addition, the researcher tries to reduce the computational and communication cost in mobile scenarios using a hash function and symmetric key cryptography [7, 10, 11]. However, these schemes achieved computational and communication cost goals but failed to provide forward secrecy according to the author of [5].Many asymmetric cryptography techniques such as RSA, bilinear pairing, ECC, and Chaotic maps are used to design AKA schemes. The first chaotic map, AKA scheme for e-commerce, was proposed in 2005 [12]. However, according to the author of [13], the scheme used in [12] cannot resist counterfeiting attacks. Later, the scheme used in [12] was improved by the author of [14] using chaotic maps. After that, many schemes were proposed for different applications using chaotic maps [15–19].However, these proposed schemes used two-factor authentication such as password and smart card or password and biometric. Additionally, a two-factor authentication AKA scheme was proposed by the author of [15, 20] to achieve security and privacy. Moreover, compared to one-factor and two-factor AKA schemes, the three-factor AKA schemes are much more secure and have advantages over one-factor and two-factor AKA schemes. Nevertheless, the three-factor AKA schemes [2, 4, 20] cannot fulfil other security goals. Additionally, we attempt to use the three-factor AKA protocol in the mobile environment to achieve security and maintain performance properties.


### 1.1. Motivation and Contribution

The existing proposed schemes motivate us to design a three-factor authentication and key agreement scheme based on chaotic maps that provided maximum security over not compromising on performance for a mobile device in cloud computing. The scheme [2, 21] is not even indeed a three-factor authentication scheme, while the protocol proposed by the author of [16] cannot provide user un-traceability. Moreover, the [3, 21] schemes cannot resist offline/online password-guessing attacks and session key security. The scheme used in [20] is prone to counterfeiting attacks.To overcome the existing scheme security issues, we proposed a new three-factor authentication and key agreement scheme to satisfy the following goals.(i)
The proposed scheme shall be actual three-factor authentication and key agreement scheme such as if the adversary gains two factors, it will not succeed in achieving the third factor.(ii)
The proposed scheme will resist DoS attacks, offline/online password-guessing attacks.(iii)
User anonymity and untraceability are provided.(iv)
The session key between a mobile device and cloud server from an attacker is protected.(v)
The proposed scheme will protect from server impersonation attacks, Mobile user impersonation attacks, and key compromise attacks(vi)
The proposed scheme will be secured by analyzing the automated verification software toolkit ProVerif 2.03.(vii)
The proposed scheme will achieve maximum security, lower computation, and communication costs and reduce storage overheads compared to existing schemes.


### 1.2. Threat Model

AdversaryA nowadays becomes more powerful; thus, all known possible attacks are possible. The adversary can modify, block, insert, delete, and intercept mobile user and public cloud server communication over an insecure channel based on the existing protocols. However, the adversary cannot obtain the secret key of the cloud server. Furthermore, the adversary can reveal all stored parameters in the smart card. Moreover, the possible threats are as follows:(1)
Spoofing threat: an attacker can impersonate a legal entity by spoofing the IDmu of a real mobile user or cloud server IDPCS.(2)
Routing threat: an adversary can launch wormhole, blockhole, and grey-hole attacks to change the route.(3)
Session key threat: the attacker can obtain the previous session key(4)
Insider threat: an adversary gains mobile user credentials and tries to launch an insider attack(5)
Unauthorized access threat: The attacker can gain access to any two of three factors.(6)
Untraceability threat: an adversary can track the physical location of a mobile user or cloud server, leading to fatal damage to both cloud server and mobile user.(7
Perfect forward secrecy threat: an adversary compromises key impersonation attack, where the attacker can obtain the secret key of the cloud server.(8)
Data leakage threat: an adversary can steal any credentials in data leaks and copy them for later use.(9)
Masquerading threat: the attacker employs a mock identity through valid access identification, such as a network identity, to get unwanted access to the stored information in the public cloud server. A masquerade attack can make an authorization process exceedingly vulnerable if it is not adequately protected.(10)
Impersonation threat: an impersonation attack occurs when an attacker impersonates a trusted contact to deceive a real user into revealing their identity or disclosing critical information.(11)
Man-in-the-Middle threat: an unauthorized person intercepts a communication between two systems or individuals, posing a threat. The interceptor tries to eavesdrop on the conversation or impersonate one of the legitimate peers not to notice the intrusion.(12)
Ephemeral secret leakage (ESL) threat: the opponent can divulge the user’s private keys, and the session key can be deduced from intercepted messages.(13)
Brute force threat: in this scenario, the attacker is attempting to crack passwords, encryption keys, and login credentials by using a hacking method on a trial basis. It is a simple but effective method for gaining unauthorized access to individual accounts as well as systems and networks of businesses.(14)
Denial-of-Service (DoS) threat: in denial of service threat, floods on the public cloud server or network have been launched by an attacker in preventing it from responding to queries.(15)
Phishing threat: the purpose is to steal sensitive data such as smart card and login information or infect the victim’s computer with malware.


### 1.3. Adversary Model

Modeling the role of attackers is an important topic in cyber defense because it aids in ensuring that security assessments are scientifically correct, particularly for conceptual contributions that are difficult to test or for which complete testing is impossible [22]. An adversary model is an operationalization of an attacker in a computer or networked system. The opponent could be an algorithm or a collection of statements/programs about abilities and intentions, depending on how extensive the formalization is? These strategies are used in a variety of computer security domains [23] by an attacker to reach the system and hack its credentials [23]. In light of this model, an adversary interacts with our mobile cloud architecture by posing as a malicious user with a cloud server and acting in the following manner:(i)
An adversary may extract stored data from the cloud server’s memory and use it to verify secret credentials(ii)
An adversary may alter, erase, upgrade, corrupt, or insert false information into a public network channel(iii)
Adversaries may replay, alter, or erase beneficial information exchanged between participants over a private channel(iv)
An adversary may acquire the internal sensitive credential from a stolen mobile device from a user or shape the memory of a stolen or misplaced mobile device using reverse engineering techniques or vital tags in offline mode, but not both simultaneously


### 1.4. Network Architecture

The proposed scheme consisted of a mobile device (umu), a public cloud registration centre (PCRC), and a public cloud server (PCS). The mobile device (umu) is battery-powered with limited resources, while PCRC does not require battery-powered and rich communication and computation costs. All mobile devices and PCRC have unique identities. The PCRC is trusted; thus, an attacker will not compromise it. The mobile devices used PCRC to communicate with PCS for data transmission. The performance of the PCRC is highly impacting the communication cost between mobile devices and PCS. Therefore, the calculated equations of PCRC capacity in noninterference and interference scenarios are worth mentioning. The equations are calculated by the author of [24] and as given as C = cN aN Nm G2,3, 3,3 (aN|1 − N(m + ms),−Nm, 1 – Nm/0,−Nm,−Nm ln(2) when the capacity is in noninterference mode, but it will be fΦ(φ) = cN aNm, N Γ (Nm + Nms) φNm−1, when the capacity is in interface mode. The diagrammatic representation of the proposed network model is shown in Figure 1.Figure 1
Network model.


## 1.1. Motivation and Contribution

The existing proposed schemes motivate us to design a three-factor authentication and key agreement scheme based on chaotic maps that provided maximum security over not compromising on performance for a mobile device in cloud computing. The scheme [2, 21] is not even indeed a three-factor authentication scheme, while the protocol proposed by the author of [16] cannot provide user un-traceability. Moreover, the [3, 21] schemes cannot resist offline/online password-guessing attacks and session key security. The scheme used in [20] is prone to counterfeiting attacks.To overcome the existing scheme security issues, we proposed a new three-factor authentication and key agreement scheme to satisfy the following goals.(i)
The proposed scheme shall be actual three-factor authentication and key agreement scheme such as if the adversary gains two factors, it will not succeed in achieving the third factor.(ii)
The proposed scheme will resist DoS attacks, offline/online password-guessing attacks.(iii)
User anonymity and untraceability are provided.(iv)
The session key between a mobile device and cloud server from an attacker is protected.(v)
The proposed scheme will protect from server impersonation attacks, Mobile user impersonation attacks, and key compromise attacks(vi)
The proposed scheme will be secured by analyzing the automated verification software toolkit ProVerif 2.03.(vii)
The proposed scheme will achieve maximum security, lower computation, and communication costs and reduce storage overheads compared to existing schemes.


## 1.2. Threat Model

AdversaryA nowadays becomes more powerful; thus, all known possible attacks are possible. The adversary can modify, block, insert, delete, and intercept mobile user and public cloud server communication over an insecure channel based on the existing protocols. However, the adversary cannot obtain the secret key of the cloud server. Furthermore, the adversary can reveal all stored parameters in the smart card. Moreover, the possible threats are as follows:(1)
Spoofing threat: an attacker can impersonate a legal entity by spoofing the IDmu of a real mobile user or cloud server IDPCS.(2)
Routing threat: an adversary can launch wormhole, blockhole, and grey-hole attacks to change the route.(3)
Session key threat: the attacker can obtain the previous session key(4)
Insider threat: an adversary gains mobile user credentials and tries to launch an insider attack(5)
Unauthorized access threat: The attacker can gain access to any two of three factors.(6)
Untraceability threat: an adversary can track the physical location of a mobile user or cloud server, leading to fatal damage to both cloud server and mobile user.(7
Perfect forward secrecy threat: an adversary compromises key impersonation attack, where the attacker can obtain the secret key of the cloud server.(8)
Data leakage threat: an adversary can steal any credentials in data leaks and copy them for later use.(9)
Masquerading threat: the attacker employs a mock identity through valid access identification, such as a network identity, to get unwanted access to the stored information in the public cloud server. A masquerade attack can make an authorization process exceedingly vulnerable if it is not adequately protected.(10)
Impersonation threat: an impersonation attack occurs when an attacker impersonates a trusted contact to deceive a real user into revealing their identity or disclosing critical information.(11)
Man-in-the-Middle threat: an unauthorized person intercepts a communication between two systems or individuals, posing a threat. The interceptor tries to eavesdrop on the conversation or impersonate one of the legitimate peers not to notice the intrusion.(12)
Ephemeral secret leakage (ESL) threat: the opponent can divulge the user’s private keys, and the session key can be deduced from intercepted messages.(13)
Brute force threat: in this scenario, the attacker is attempting to crack passwords, encryption keys, and login credentials by using a hacking method on a trial basis. It is a simple but effective method for gaining unauthorized access to individual accounts as well as systems and networks of businesses.(14)
Denial-of-Service (DoS) threat: in denial of service threat, floods on the public cloud server or network have been launched by an attacker in preventing it from responding to queries.(15)
Phishing threat: the purpose is to steal sensitive data such as smart card and login information or infect the victim’s computer with malware.


## 1.3. Adversary Model

Modeling the role of attackers is an important topic in cyber defense because it aids in ensuring that security assessments are scientifically correct, particularly for conceptual contributions that are difficult to test or for which complete testing is impossible [22]. An adversary model is an operationalization of an attacker in a computer or networked system. The opponent could be an algorithm or a collection of statements/programs about abilities and intentions, depending on how extensive the formalization is? These strategies are used in a variety of computer security domains [23] by an attacker to reach the system and hack its credentials [23]. In light of this model, an adversary interacts with our mobile cloud architecture by posing as a malicious user with a cloud server and acting in the following manner:(i)
An adversary may extract stored data from the cloud server’s memory and use it to verify secret credentials(ii)
An adversary may alter, erase, upgrade, corrupt, or insert false information into a public network channel(iii)
Adversaries may replay, alter, or erase beneficial information exchanged between participants over a private channel(iv)
An adversary may acquire the internal sensitive credential from a stolen mobile device from a user or shape the memory of a stolen or misplaced mobile device using reverse engineering techniques or vital tags in offline mode, but not both simultaneously


## 1.4. Network Architecture

The proposed scheme consisted of a mobile device (umu), a public cloud registration centre (PCRC), and a public cloud server (PCS). The mobile device (umu) is battery-powered with limited resources, while PCRC does not require battery-powered and rich communication and computation costs. All mobile devices and PCRC have unique identities. The PCRC is trusted; thus, an attacker will not compromise it. The mobile devices used PCRC to communicate with PCS for data transmission. The performance of the PCRC is highly impacting the communication cost between mobile devices and PCS. Therefore, the calculated equations of PCRC capacity in noninterference and interference scenarios are worth mentioning. The equations are calculated by the author of [24] and as given as C = cN aN Nm G2,3, 3,3 (aN|1 − N(m + ms),−Nm, 1 – Nm/0,−Nm,−Nm ln(2) when the capacity is in noninterference mode, but it will be fΦ(φ) = cN aNm, N Γ (Nm + Nms) φNm−1, when the capacity is in interface mode. The diagrammatic representation of the proposed network model is shown in Figure 1.Figure 1
Network model.


## 2. Related Work

Although there are many benefits of mobile cloud computing, despite the advantages, there are many risks, and the most notable one is outsourcing data storage. The data are distributed at more locations in cloud computing. Therefore, it triggers the risk of unauthorized physical access. However, encryption is the best possible solution to protect the data from unauthorized access. Data encryption and sending it to the cloud can stop unauthorized access from malicious users and cloud service providers. However, these encryption techniques need enhancement. For example, when an attacker compromises a secret key, the data must be protected from unauthorized access.The authentication and key agreement schemes allow users to log in to the remote servers over an insecure network. The first authentication and key agreement scheme were proposed by the author of [6] in 1981. In this scheme, the server verifies the user through username and password. However, the scheme maintains a password table; therefore, the intruder can intercept the previous password, launch a replay attack, and successfully log in to the server. Moreover, to overcome replay attacks, the author [25] proposed a two-factor authentication scheme in 1990. The two-factor scheme use username, password, and a second factor, a smart card, has been used.Two-factor authentication and key agreement scheme were proposed by the author of [26] using chaos theory in 2013. However, in [27], the author found out that the scheme used in [26] cannot provide session key security and anonymity. Additionally, the author of [15] cryptanalysis of the scheme [27] concludes that the scheme is vulnerable to DoS attacks and insider attacks and cannot ensure secure key agreement. Therefore, the author of [15] proposed two-factor authentication and a key agreement scheme to eliminate the issue in the scheme [27]. According to the author of [28], the scheme used in [15] cannot resist impersonation, key compromise, information leakage attacks, and the inability to provide local password updates and detect incorrect passwords.Additionally, three-factor authentication and key agreement protocols recently got attention in dealing with smart card loss attacks. The three-factor typically used username with password, smart card, and biometric identification. However, the traditional authentication and key agreement scheme are used only for a single server environment, whereas commercial services are based on a multiserver environment [23]. Therefore, these conventional authentications and key agreement schemes do not provide users anonymity and untraceability. Furthermore, in [27], the author proposed a three-factor scheme where the third factor is biometric authentication. However, according to the author of [29], the scheme used in [3] fails to provide user anonymity and impersonating attacks. Nevertheless, another three-factor multiserver scheme was proposed in [30, 31], and according to the author of [32], the scheme used in [31] is defenceless against user impersonation attacks.The security improvements of the scheme [33] are proposed in [34]. However, the [34] scheme also has security drawbacks, including privileged insider attacks and smart card losses. Therefore, the scheme [35, 36] provides the solution to the flaws of [34]. However, the security defects of [37, 38] are identified by the author of [39] and improve the scheme of [40] to achieve user anonymity. Additionally, the scheme in [41] stored the user's public keys on the server-side. On the other hand, the scheme developed by the author of [42] suffers from insider attacks and cannot provide user untraceability. According to the author of [43], the protocol used in [44] is vulnerable to impersonation, reply, DoS attacks, and fails to provide strong user anonymity. However, the author also claims that their protocol has high computation and communication costs, storage costs, and no balance between performance and security. Meanwhile, the author [43] proposed a solution for [44] to achieve high security, tractability, robustness, and lightweight feature. Hence, an authentication scheme using a smart card is proposed the author of [45], which offers reliable information delivery and mutual authentication between server and client. Furthermore, BioHashing techniques have been used to prevent biometrics information from being stolen or misplaced smart card.Consequently, in 2014, a three-factor AKA scheme was proposed in [46] and claimed that it provides security against smart card loss attacks and many more threats. Nevertheless, according to the author of [19], the scheme is vulnerable to offline password-guessing attacks, smart card loss attacks, and biometric sample leaks.Furthermore, in 2015, the author [16] cryptanalysis the scheme [47] and found out that the scheme cannot provide mutual authentication and also vulnerable to replay attacks, DoS attacks, and password guessing attacks. However, according to the author of [16], the scheme used in [16] has not indeed achieved three-factor authentication and key agreement and cannot resist offline password-guessing attacks.Later in 2017, a scheme was proposed in [2] that cannot provide perfect forward secrecy and truly three-factor authentication and resist offline password-guessing attacks. In addition, the schemes [3, 4] are also vulnerable to password-guessing attacks, and the scheme in [4] is also prone to impersonation attacks.The most recent schemes were proposed from 2018–2021 to achieve security features and reduce storage overhead, communication, and computation costs. However, these schemes have the vulnerability to provide perfect security in current scenarios. In contrast, the scheme [48] did not offer traceability and mutual authentication. Therefore, [49, 50] proposed a three-factor authentication scheme based on ECC to achieve perfect forward secrecy. However, these schemes cannot provide perfect forward secrecy and user anonymity and resist replay attacks.Furthermore, the protocol [51] provides securities feature over the cost of computation. The author [52] proposed a lightweight authentication scheme, although its key generation time is very high. Therefore, it contracted with the feature of a lightweight scenario.Furthermore, a scheme [8] was proposed which used symmetric en/decryption, hash function, and chaotic maps to provide authentication and key agreements for multiserver environments. However, according to the author of [28], their scheme is prone to offline password-guessing attacks, biometric, and smart card leaks. Recently, Jiang et al. [53] proposed a scheme for cloud-assisted autonomous vehicles in which they used biometrics and fuzzy extractor for authentication consisting of user registration, user authentication, and biometric extraction phases. After extensive analysis, the scheme proposed by the author of [53] shows the following loopholes.


### 2.1. Lack of Strong User Anonymity and Unlinkability

If adversary A finds a misplaced mobile device or stolen from a legitimate user and restore C, tpi from its memory by reverse engineering, they can also get UIDi from the public channel easily due to the availability of C, tpi credentials. Moreover, the adversary also gets pk from message 1and vki from message 2 easily due to its publicly transmitted network channel. Moreover, in [53], the key is unchanged, and the adversary can easily figure out other credentials. Therefore, Jiang et al.’s [53] scheme is vulnerable to user anonymity and unlinkability.


### 2.2. Lack of Perfect Forward Security

If by power analysis method, the adversary recovers the public key from user smart card/mobile device, then they can be allowed to compute secret session key uvsk =h(UIDi||VIDj||CID||tkj||n1||n3), and vcsk = h(VIDj||CID||||n2||n3||vkj). Due to easily computing, pk = h(ps||M1||CID) and vkj = h(VIDj||k||rj). Therefore, jiang et al. [53] does not provide perfect forward secrecy.


### 2.3. Side-Channel Attack

Jiang et al. [53]do not use a timestamp in each round trip, which leads to a side-channel attack.


## 2.1. Lack of Strong User Anonymity and Unlinkability

If adversary A finds a misplaced mobile device or stolen from a legitimate user and restore C, tpi from its memory by reverse engineering, they can also get UIDi from the public channel easily due to the availability of C, tpi credentials. Moreover, the adversary also gets pk from message 1and vki from message 2 easily due to its publicly transmitted network channel. Moreover, in [53], the key is unchanged, and the adversary can easily figure out other credentials. Therefore, Jiang et al.’s [53] scheme is vulnerable to user anonymity and unlinkability.


## 2.2. Lack of Perfect Forward Security

If by power analysis method, the adversary recovers the public key from user smart card/mobile device, then they can be allowed to compute secret session key uvsk =h(UIDi||VIDj||CID||tkj||n1||n3), and vcsk = h(VIDj||CID||||n2||n3||vkj). Due to easily computing, pk = h(ps||M1||CID) and vkj = h(VIDj||k||rj). Therefore, jiang et al. [53] does not provide perfect forward secrecy.


## 2.3. Side-Channel Attack

Jiang et al. [53]do not use a timestamp in each round trip, which leads to a side-channel attack.


## 3. Proposed Scheme

This section of the research paper will demonstrate the proposed mechanism for such a crucial infrastructure that everyone needs to browse information securely. Our proposed scheme has three participants. The first participant is mobile userumu, and the second is public cloud server PCS, and the last is public cloud registration centre (PCRC). The public cloud registration centre selects secret key SKPCRC, public key PKPCRC, and random number r1, which are only known to PCRC and publicly available public key. Furthermore, the notation is presented in Table 1. The proposed scenario consists of registration, login, and authentication, and password/biometric change phases, and each of these phases are described one by one under the following headings.Table 1
Notation explanation.
NotationDescriptionumuMobile userPCSPublic cloud serverPCRCPublic cloud registration centrer1,r2Random numbersSKmu, PKmuSecret and public key of mobile usersSKPCS, PKPCSSecret and public key of public cloud serverIDmu, IDPCSIdentity of a mobile user and public cloud serverPWmuMobile user passwordbio(Bmu)Mobile user biometrich(.)One-way hash function⊕XOR||Concatenation


### 3.1. User’s Registration Phase

This phase of the proposed scenario competes in the following steps:(i)
Step 1: In this phase, the mobile user selects his/her identity IDmu and password PWmu, imprints biometric bio(Bmu), and chooses a random number r2 and calculates S1 = h(h(IDmu||PWmu)||r2||bio(Bmu)), S2 = h(PWmu||r2), and S3 = S1 ⊕ r2. After calculation, the mobile user sends IDmu, S2, S3 towards the public cloud registration centre.(ii)
Step 2: After receiving IDmu, S2, S3, the public cloud registration centre calculates PKmu = r1.P, SKmu = r1.P ⊕ h(IDmu⊕ PKmu), N=S3 ⊕ SKmu, M = h(IDmu ⊕ r1) ⊕ h(IDmu||S2||SKmu), and O = h(IDmu||S3||PKmu). The public cloud registration server sends smart card with credentials {PKmu, N, M, O} towards the mobile user.(iii)
Step 3: After receiving smart card with credentials {PKmu, N, M, O} from the public cloud registration centre, the mobile user calculates further C = r2 ⊕ bio(Bmu), N/= N ⊕ r2, and store {O, M, N/, PKmu} in smart card as shown in Table 2.Table 2
User registration.
UserPublic cloud registration centre (PCRC)User choose identity IDmuPassword PWmu and imprints biometric bio(Bmu)Choose a random numberr2 and calculateS1 = h(h(IDmu||PWmu)||r2||bio(Bmu))S2 = h(PWmu||r2)S3 = S1 ⊕ r2 IDmu, S2, S3⟶IDmu,S2,S3Calculate: PKmu = r1.PSKmu = r1.P ⊕ h(IDmu⊕ PKmu)N=S3 ⊕ SKmuM = h(IDmu ⊕ r1) ⊕ h(IDmu||S2||SKmu)O = h(IDmu||S3||PKmu)←SCPKmu,N,M,OCalculate: SC {PKmu, N, M, O}C = r2 ⊕ bio(Bmu)N/ = N ⊕ r2Store = {O, M, N/, PKmu} in smart card


### 3.2. Public Cloud Server (PCS)’s Registration Phase

This phase is completed in the following steps:(i)
Step 1: The public cloud server selects identity IDPCS, chooses 160 bits integer q, and calculates PIDPCS = IDPCS||q. After calculation, the public cloud server sends PIDPCS towards the public cloud registration centre.(ii)
Step 2: After receiving PIDPCS from public cloud server, the public cloud registration centre chooses a random number r1 and calculates PKPCS = r1.q, SKPCS = (r1.P) ⊕ h(PIDpcs||PKPCS), and send PKPCS, SKPCS, r1 back to public cloud server.(iii)
Step 3: The public cloud server stores {SKPCS, r1} and publishes PKPCS, as shown in Table 3.Table 3
Public cloud server registration phase.
Public cloud server (PCS)Public cloud registration centre (PCRC)Select IDPCS and 160-bits big integer qPIDPCS = IDPCS||q⟶PIDPCSChoose random numberr1PKPCS = r1.qSKPCS = (r1.P) ⊕ h(PIDpcs||PKPCS)←PKPCS,SKPCS,r1Store {SKPCS, r1} and publish PKPCS


### 3.3. Login and Authentication Phase

This phase is a crucial stage of the protocol, which is accomplished in the following steps:(i)
Step 1: The legitimate user first inputs their identity, provides password, and imprints biometrics, the EEPROM inside the chip while computinge = c⊕ bio(Bmu), O/= h(IDmu||S3||SKmu), and confirms O/ = O, and if not matched, the process will terminate locally, else, proceed J= (r2.P), and transmit MSG1 over a public network channel.(ii)
Step 2: When receiving MSG1, the public cloud server computes PKmu= (r1.P), Q = r1 ⊕ SKPCS h(r1.P ⊕ r2.P) and transmits MSG2 back towards the user again on the same public channel.(iii)
Step 4: The user, upon receiving MSG2, verifies Q/? = r1 ⊕ PKPCSh(r1.P ⊕ r2.P), computes S1 = h(h(IDmu||PWmu)||r2||bio(Bmu), D = (r1 ⊕ PKmu)h(PIDPCS ⊕ (r1.P)⊕  (r2.P)), M = h(IDmu ⊕ r1) ⊕ h(IDmu||S2||SKmu), PKmu= (r1.P), SKmu = h(r1.P, r2.P)||h(IDmu||SKmu)||r1||h(IDmu||PIDPCS), Y = h(SKmu, r1, r1.P, r2.P, IDmu), W = h((r1.P), (r2.P)), and transmits MSG3 towards public cloud server over open channel.(iv)
Step 3: The server, when receiving MSG3, computes W/= h((r1.P),(r2.P)), D/= (r1 ⊕ PKmu) ⊕ (PIDPCS ⊕ (r1.P) ⊕ (r2.P)), confirms W/ = W/D/= D, if not matched, considered for potential replay attack, else, computes the session secret shared key SkPCS = h(r1.P, r2.P)||h(IDmu||PKmu)||r1||h(IDmu||IDPCS), computes Y? = h(SKmu, r1, r1.P, r2.P, IDmu), and keeps Skmu, SkPCS is the session secret key for future communication, as shown in Table 4.Table 4
Login and authentication phase.
User (U)Public cloud server (PCS)Input IDmu, PWmu, and bio(Bmu)Calculate:e =C ⊕ bio(Bmu)O/ = h(IDmu||S3||SKmu)CheckO/ = O proceed furtherJ = (r2||P)⟶MSG1JCompute: PKmu = (r1||P)Q = r1 ⊕ SKPCS||h(r1||P ⊕ r2||P)←MSG2r1.P,QCompute:Q/? = r1 ⊕ PKPCS ⊕ h(r1||P) ⊕ (r2||P)S1 = h(h(IDmu||PWmu)||r2||bio(Bmu)D = (r1 ⊕ PKmu) ⊕ (PIDPCS ⊕ (r1||P) ⊕ (r2||P))M = h(IDmu ⊕ r1) ⊕ h(IDmu||S2||SKmu)PKu = (r1||P)SKmu = h(r1||P ⊕ (r2.P)||h(IDmu||SKmu)||r1||h(IDmu||PIDPCS)Y = h(SKmu||r1) ⊕ (r1||P) ⊕ (r2||P)||IDmu)W = h((r1||P) ⊕ (r2||P))⟶MSG3W,Y,DCompute:W/ = h((r1||P) ⊕ (r2||P))D/ = (r1 ⊕ PKmu) ⊕ (PIDPCS ⊕ (r1||P) ⊕ (r2||P))CheckW/ = W, and D/= D, proceed furtherSkPCS = h(r1||P) ⊕ (r2||P)||h(IDmu||PKmu)||r1||h(IDmu||PIDPCS)Compare: Y? =h(SKmu||r1) ⊕ (r1||P) ⊕ (r2||P)||IDmu)Session key = SKmu = SKPCS


### 3.4. Biometric and Password Change Phase

First, a legitimate user enters his/her old identity and password and imprints biometrics {IDmu, PWmu bio(Bmu)}, takes a random number, and calculates S1 = h(IDmu||PWmu) ⊕ h(r2||bio(Bmu)), S2 = h(PWmu||r2), S3 = S1 ⊕ r2. If this set of calculations is performed successfully, they will locally be asked for the provision of the new identity and password and imprints biometrics {IDmunew, PWmunew, bio(Bmu)new}. The EEPROM locally makes necessary computations by using replication and generation functions to make the credentials secure for any resisting any insider attack; to do so, S1new = h(IDmunew||PWmunew ⊕ h(r2new||bio(Bmu)), S2h(PWmunew||r2new), S2new = Snew ⊕ r2new. Furthermore, S1, S2, and S3 are replaced with S1new, S2new, and S3new. Similar is the case for the password and other credentials changing.


## 3.1. User’s Registration Phase

This phase of the proposed scenario competes in the following steps:(i)
Step 1: In this phase, the mobile user selects his/her identity IDmu and password PWmu, imprints biometric bio(Bmu), and chooses a random number r2 and calculates S1 = h(h(IDmu||PWmu)||r2||bio(Bmu)), S2 = h(PWmu||r2), and S3 = S1 ⊕ r2. After calculation, the mobile user sends IDmu, S2, S3 towards the public cloud registration centre.(ii)
Step 2: After receiving IDmu, S2, S3, the public cloud registration centre calculates PKmu = r1.P, SKmu = r1.P ⊕ h(IDmu⊕ PKmu), N=S3 ⊕ SKmu, M = h(IDmu ⊕ r1) ⊕ h(IDmu||S2||SKmu), and O = h(IDmu||S3||PKmu). The public cloud registration server sends smart card with credentials {PKmu, N, M, O} towards the mobile user.(iii)
Step 3: After receiving smart card with credentials {PKmu, N, M, O} from the public cloud registration centre, the mobile user calculates further C = r2 ⊕ bio(Bmu), N/= N ⊕ r2, and store {O, M, N/, PKmu} in smart card as shown in Table 2.Table 2
User registration.
UserPublic cloud registration centre (PCRC)User choose identity IDmuPassword PWmu and imprints biometric bio(Bmu)Choose a random numberr2 and calculateS1 = h(h(IDmu||PWmu)||r2||bio(Bmu))S2 = h(PWmu||r2)S3 = S1 ⊕ r2 IDmu, S2, S3⟶IDmu,S2,S3Calculate: PKmu = r1.PSKmu = r1.P ⊕ h(IDmu⊕ PKmu)N=S3 ⊕ SKmuM = h(IDmu ⊕ r1) ⊕ h(IDmu||S2||SKmu)O = h(IDmu||S3||PKmu)←SCPKmu,N,M,OCalculate: SC {PKmu, N, M, O}C = r2 ⊕ bio(Bmu)N/ = N ⊕ r2Store = {O, M, N/, PKmu} in smart card


## 3.2. Public Cloud Server (PCS)’s Registration Phase

This phase is completed in the following steps:(i)
Step 1: The public cloud server selects identity IDPCS, chooses 160 bits integer q, and calculates PIDPCS = IDPCS||q. After calculation, the public cloud server sends PIDPCS towards the public cloud registration centre.(ii)
Step 2: After receiving PIDPCS from public cloud server, the public cloud registration centre chooses a random number r1 and calculates PKPCS = r1.q, SKPCS = (r1.P) ⊕ h(PIDpcs||PKPCS), and send PKPCS, SKPCS, r1 back to public cloud server.(iii)
Step 3: The public cloud server stores {SKPCS, r1} and publishes PKPCS, as shown in Table 3.Table 3
Public cloud server registration phase.
Public cloud server (PCS)Public cloud registration centre (PCRC)Select IDPCS and 160-bits big integer qPIDPCS = IDPCS||q⟶PIDPCSChoose random numberr1PKPCS = r1.qSKPCS = (r1.P) ⊕ h(PIDpcs||PKPCS)←PKPCS,SKPCS,r1Store {SKPCS, r1} and publish PKPCS


## 3.3. Login and Authentication Phase

This phase is a crucial stage of the protocol, which is accomplished in the following steps:(i)
Step 1: The legitimate user first inputs their identity, provides password, and imprints biometrics, the EEPROM inside the chip while computinge = c⊕ bio(Bmu), O/= h(IDmu||S3||SKmu), and confirms O/ = O, and if not matched, the process will terminate locally, else, proceed J= (r2.P), and transmit MSG1 over a public network channel.(ii)
Step 2: When receiving MSG1, the public cloud server computes PKmu= (r1.P), Q = r1 ⊕ SKPCS h(r1.P ⊕ r2.P) and transmits MSG2 back towards the user again on the same public channel.(iii)
Step 4: The user, upon receiving MSG2, verifies Q/? = r1 ⊕ PKPCSh(r1.P ⊕ r2.P), computes S1 = h(h(IDmu||PWmu)||r2||bio(Bmu), D = (r1 ⊕ PKmu)h(PIDPCS ⊕ (r1.P)⊕  (r2.P)), M = h(IDmu ⊕ r1) ⊕ h(IDmu||S2||SKmu), PKmu= (r1.P), SKmu = h(r1.P, r2.P)||h(IDmu||SKmu)||r1||h(IDmu||PIDPCS), Y = h(SKmu, r1, r1.P, r2.P, IDmu), W = h((r1.P), (r2.P)), and transmits MSG3 towards public cloud server over open channel.(iv)
Step 3: The server, when receiving MSG3, computes W/= h((r1.P),(r2.P)), D/= (r1 ⊕ PKmu) ⊕ (PIDPCS ⊕ (r1.P) ⊕ (r2.P)), confirms W/ = W/D/= D, if not matched, considered for potential replay attack, else, computes the session secret shared key SkPCS = h(r1.P, r2.P)||h(IDmu||PKmu)||r1||h(IDmu||IDPCS), computes Y? = h(SKmu, r1, r1.P, r2.P, IDmu), and keeps Skmu, SkPCS is the session secret key for future communication, as shown in Table 4.Table 4
Login and authentication phase.
User (U)Public cloud server (PCS)Input IDmu, PWmu, and bio(Bmu)Calculate:e =C ⊕ bio(Bmu)O/ = h(IDmu||S3||SKmu)CheckO/ = O proceed furtherJ = (r2||P)⟶MSG1JCompute: PKmu = (r1||P)Q = r1 ⊕ SKPCS||h(r1||P ⊕ r2||P)←MSG2r1.P,QCompute:Q/? = r1 ⊕ PKPCS ⊕ h(r1||P) ⊕ (r2||P)S1 = h(h(IDmu||PWmu)||r2||bio(Bmu)D = (r1 ⊕ PKmu) ⊕ (PIDPCS ⊕ (r1||P) ⊕ (r2||P))M = h(IDmu ⊕ r1) ⊕ h(IDmu||S2||SKmu)PKu = (r1||P)SKmu = h(r1||P ⊕ (r2.P)||h(IDmu||SKmu)||r1||h(IDmu||PIDPCS)Y = h(SKmu||r1) ⊕ (r1||P) ⊕ (r2||P)||IDmu)W = h((r1||P) ⊕ (r2||P))⟶MSG3W,Y,DCompute:W/ = h((r1||P) ⊕ (r2||P))D/ = (r1 ⊕ PKmu) ⊕ (PIDPCS ⊕ (r1||P) ⊕ (r2||P))CheckW/ = W, and D/= D, proceed furtherSkPCS = h(r1||P) ⊕ (r2||P)||h(IDmu||PKmu)||r1||h(IDmu||PIDPCS)Compare: Y? =h(SKmu||r1) ⊕ (r1||P) ⊕ (r2||P)||IDmu)Session key = SKmu = SKPCS


## 3.4. Biometric and Password Change Phase

First, a legitimate user enters his/her old identity and password and imprints biometrics {IDmu, PWmu bio(Bmu)}, takes a random number, and calculates S1 = h(IDmu||PWmu) ⊕ h(r2||bio(Bmu)), S2 = h(PWmu||r2), S3 = S1 ⊕ r2. If this set of calculations is performed successfully, they will locally be asked for the provision of the new identity and password and imprints biometrics {IDmunew, PWmunew, bio(Bmu)new}. The EEPROM locally makes necessary computations by using replication and generation functions to make the credentials secure for any resisting any insider attack; to do so, S1new = h(IDmunew||PWmunew ⊕ h(r2new||bio(Bmu)), S2h(PWmunew||r2new), S2new = Snew ⊕ r2new. Furthermore, S1, S2, and S3 are replaced with S1new, S2new, and S3new. Similar is the case for the password and other credentials changing.


## 4. Security Analysis

In this section of the research, we will investigate, scrutinize, and analyze the security of the proposed protocol by using two methods. First, to check whether the random number exchanges among the participants are securely communicated or not? Whether the hash code created will create a collision with other code or not? Similarly, we also will check the advantage of an adversary to break our protocol. To do so, we use the following methods.


### 4.1. Formal Security Analysis

To determine the security of the proposed protocol using a formal approach, we, in this subsection of the research, will use a random oracle model (ROM) (advantage with the adversary to breach the proposed protocol).


#### 4.1.1. Random Oracle Model (ROM) Analysis

SupposeX means protocol; the external user who is currently using our protocol is denoted as U, the registration centre is denoted by G, and the public cloud server is PCS. When running X, each participant has many occurrences to be touched with X via r1, r2, p, P, q, PK, SK. Furthermore, suppose we create a table of random numbers called an oracle. Also, let Is be the xth occurrence of U, Js is the yth occurrence of G, and Ks is the zth occurrence of PCS. While Is is supposed to be the occurrence of all participants, then definitely, there are possibly three occurrences available A, B, C. A = successfully usage of the protocol, and the user is securely authenticating with the destination, B = never authenticate, and C = no result. Afore running X, U has MSG1, G has MSG2, and PCS has MSG3, and suppose the shared secret key SK is stored securely in the memory of U, G, and PCS.Suppose an adversary desires to enter our protocol over the open channel and try to start their own session or terminate theU session by arbitrating the participation. The adversary must be known J = (r2.P) and PKmu = (r1.P), and then, he/she can execute {Is, Js} and {Js, Is} quires. In this regard, A's advantage to breach the proposed protocol is(1)AdvxA=2ProbC+C/−1,whereas C means flipping a coin by the adversary, and when flipping the coin, the result is C/. For hash queries, the advantage with the adversary A is(2)AdvxA=ProbS2−ProbS2+qhe2/2thS+1+qhe+12/2thS+1+qhe2/2thS,whereas qhe2/2thS+1+qhe+12/2thS+1+qhe2/2thS are at most chances of collision of hash code with each other in the oracle. By expanding (2), we get(3)ProbS3−ProbS2≤2qU+2qPCS2qG.The advantage with the adversary to capture shared session key as(4)|probS1−ProbS2≤qPCS.AdvxA.If we keep another list of numbers/dictionary (D), then probability with the adversary A is(5)probS3=12maxqU2,qPCSD.By combining (1)–(5), we get(6)AdvxA=ProbS1−1=2ProbS0−ProbS4+maxqU2,qPCSD≤2ProbS0−ProbS4+maxqU2,qPCSD=2ProbS1−ProbS2+ProbS3−ProbS4+maxqU2,qPCSD≤qU2+qPCS2+qG22q+qU+qPCS22q−1+2qPCS.AdvX.APCS+2qU2q,qPCSD.


#### 4.1.2. ProVerif2.03 Simulation

To check whether the session secret is secured, confidentiality computed, and exchanged security among different peers or to check its reachability and test whether an attacker can forage it during a starting session or not, ProVerif2.03 verification software toolkit is used. This is a widely accepted software verification toolkit. The whole code and result are generated as follows:(∗ --------- CHANNELS ----------∗)free PrivCh:channel [private]. (∗secure channel between User and Server∗)free PublPub:channel. (∗public channel between User and Server∗)(∗----------- CONSTANTS AND VARIABLES ---------∗)free IDmu:bitstring.free PIDpcs:bitstring.free RIDs:bitstring.free RIDdrj:bitstring.free PWmu:bitstring[private].free Bmu:bitstring[private].free SKpcs:bitstring[private].free PKpcs:bitstring.free P:bitstring.free TCui:bitstring.free taui:bitstring.free q:bitstring.free r:bitstring.free r1:bitstring.free r2:bitstring.free SKmu:bitstring[private].free PKmu:bitstring.(∗-------Queries------∗)query id:bitstring; inj-event(end_Ui(IDUi)) = => inj-event(start_U(IDmu)).query id:bitstring; inj-event(end_S(IDS)) = => inj-event(start_S(PIDpcs)).query attacker(SKmu).(∗ = = = = = ∗Events∗ = = = = = ∗)event start_U(bitstring).event end_U(bitstring).event start_PCS(bitstring).event end_PCS(bitstring).(∗ = = = = = = = = Constructors = = = = = = = ∗)fun XOR(bitstring, bitstring): bitstring.fun H(bitstring): bitstring.fun CONCAT(bitstring, bitstring): bitstring.(∗ = = = = = = Equations = = = = = = = ∗)equation forallm: bitstring, n: bitstring; XOR(XOR(m,n),m) = n.(∗ = = = = = = = = = = USER = = = = = = = = = = = = ∗)letU =event start_U(IDmu);freee:bitstring.lete = XOR(C, Bmu) inletO = H(H(IDmu, S3), SKmu) inif Odash =O thenletj = H(r2, P) inout(PublCh, (j));in(PublCh, (r1:bitstring, P:bitstring, Q:bitstring)) inlet Qdash = XOR(XOR(r1, PKpcs), H(H(r1, P), r2)) inletS1 = H(H(H(H(IDmu, PWmu), r2), Bmu)) inletD = XOR(XOR(XOR(r1, PKmu), PIDpcs), r1), r2)) inletM = XOR(XOR(XOR(IDmu, r1), IDmu), S2), SKmu)) inlet PKmu =H(r1, P) inlet SKmu =H(H(H(H(H(r1, r2), IDmu), SKmu), PIDpcs));letY=H(H(H(H(H(H(SKmu, r1), r1), r2), P), IDmu));letW = XOR(H(H(r, P), r2), P));event end_U(IDmu)else0.(∗-----------PUBLIC CLOUD SERVER (PCS) ---------∗)let PCS =event start_PCS(PIDmu);in (PublCh, (J:bitstring));let PKmu =H(r1, P) inletQ = XOR(h(r1, SKpcs), (h(h(h(r1, P), r2), P))) inout(PublCh,(r1, P, Q));event end_PCS(PIDmu)else0.process ((!U) | (!PCS))Upon running the code, the following result will generate, which shows no attacker at any stage cannot forge, crack, and hack the secret session key. Also, its reachability is confirmed among the participants.Completing equations…Completing equations…-- Process 1-- Query not attacker(SK[]) in process 1Translating the process into Horn clauses…Completing…200 rules inserted. Base: 136 rules (27 with conclusion selected). Queue: 24 rules.Starting query not attacker(SK[])RESULT not attacker(SK[]) is true.-- Query inj-event(end_U(U[])) ==>  inj-event(start_U(IDmu[])) in process 1Translating the process into Horn clauses…Completing…200 rules inserted. Base: 136 rules (27 with conclusion selected). Queue: 24 rules.Starting query inj-event(end_U(IDmu[])) ==>  inj-event(start_U(IDmu[]))RESULT inj-event(end_U(IDum[])) ==>  inj-event(start_U(IDmu[])) is true.-- Query inj-event(end_PCS(PIDmu[])) =>  inj-event(start_PCS(PIDmu[])) in process 1Translating the process into Horn clauses…Completing…200 rules inserted. Base: 126 rules (27 with conclusion selected). Queue: 28 rules.Starting query inj-event(end_PCS(PIDmu[])) =>  inj-event(start_PCS(PIDmu[]))RESULT inj-event(end_PCS(PIDmu[])) =>  inj-event(start_PCS(PIDmu[])) is true.-- Query inj-event(end_U(IDmu[])) ==>  inj-event(start_U(IDmu[])) in process 1Translating the process into Horn clauses…Completing…200 rules inserted. Base: 136 rules (27 with conclusion selected). Queue: 24 rules.Starting query inj-event(end_PCS(IDmu[])) ==>  inj-event(start_U(IDmu[]))RESULT inj-event(end_PCS(PIDmu[])) ==>  inj-event(start_U(PIDmu[])) is true.Verification summary:Query not attacker(SK[]) is true.Query inj-event(end_U(IDmu[])) ==>  inj-event(start_U(IDmu[])) is true.Query inj-event(end_PCS(PIDmu[])) ==>  inj-event(start_PCS(PIDmu[])) is true.


### 4.2. Informal Security Analysis

This section will intensely discuss the possible attacks and their prevention and discuss our proposed scheme features.(1)
Provide user anonymity: the proposed scheme provides user anonymity. When mobile user sends IDmu by calculating, W = h((r1.P), (r2.P)). The (r1.P) and (r2.P) are only known to the public cloud server. Therefore, the proposed scheme provides user anonymity.(2)
Provide user untraceability: theA cannot extract information from W = h((r1.P), (r2.P)) because it is only known to a public cloud server. Thus, the proposed is a protected user untraceability feature.(3)
Resist to offline password-guessing attacks: theA can get W = h((r1.P), (r2.P)), Y = h(SKmu, r1, r1.P, r2.P, IDmu), D = (r1 ⊕ PKmu)h(PIDPCS ⊕ (r1.P) ⊕ (r2.P)) on insecure medium. Although the A can also extract contents from smart card {PKmu, N, M, O}, the A cannot get mobile user password PWmu from these credentials. Therefore, the proposed scheme resists offline password attacks.(4)
Resist to masquerading attacks: in the proposed scheme, theA cannot launch an impersonation attack because of unable to get PWmu or the secret keys of the mobile user. The A cannot modify the Y = h(SKmu, r1, r1.P, r2.P, IDmu) because of (r1.P), (r2.P). Therefore, the proposed scheme resists masquerading attacks.(5)
Resist to smart card stolen attacks: TheA guesses mobile user password PWmu and launches a user impersonation attack. However, the A cannot launch forgery, modification, and replay attacks in the proposed scheme because the A will need a mobile user secret key and the random number to compute Y = h(SKmu, r1, r1.P, r2.P, IDmu). Therefore, the proposed scheme resists smart card stolen attacks.(6)
Provide perfect forward secrecy: the proposed scheme provides perfect forward secrecy even if the secret key of the public cloud registration server is lost. The proposed scheme generates session keySKmu = h(r1.P, r2.P)||h(IDmu||SKmu)||r1||h(IDmu||PIDPCS) by using random numbers with multiplication with P. It is very difficult for A to compute those numbers because of ECDLP in a short period of time.(7)
Provide known key security: theA cannot get mobile user and public cloud server secret keys and random numbers. Although if the A gets the session key, it cannot extract secret keys and random numbers. Therefore, the proposed scheme protected against the known key attacks.(8)
Resist to session key attacks: if theA gets a random number, it still requires a mobile user secret key to generate a session key. Therefore, the proposed scheme resists session key attacks.(9)
Resist to credentials leakage attacks: TheA may get some mobile user leaked credentials and try to launch a masquerading server attack. Our proposed protocol resists such attacks even if mobile user credentials are leaked. The A cannot generate Q = r1 ⊕ SKPCSh(r1.P ⊕ r2.P) because of the public cloud server secret key. Therefore, the proposed scheme resists credentials leak attacks.(10)
Resist to replay attacks: theA may get the previous session key and extract meaningful information to launch the replay attack. In the proposed scheme, the public cloud server checks W/ = W and D/= D to stop replay attacks. Thus, the proposed protocol resists replay attacks.(11)
Resist to denial-of-service attacks: each session starts with a fresh and unique session key. The proposed scheme random numberr1,r2 is very hard to compute while the proposed scheme checks Q/ = Q, thus if A sends incorrect information to any participants, such request is rejected. Therefore, the proposed scheme resists denial of service attacks.(12)
Resist man-in-the-middle attacks: in our proposed scheme, the mobile user and public cloud server share session key after authenticating each other. Therefore,A cannot construct a connection with the mobile user and public cloud server because A needs random numbers, r1,r2, bio(Bmu), IDu, PWmu, and public cloud server secret key SKPCS. Thus, the proposed scheme resists a man-in-the-middle attack.(13)
Provide mutual authentication: in our proposed scheme’s login and authentication phase, the public cloud server computesQ = r1 ⊕ SKPCS||h(r1||P ⊕ r2||P) while the mobile user verifies Q/ = Q. On the other side, the mobile user calculates D = (r1 ⊕ PKmu) ⊕ (PIDPCS ⊕ (r1||P) ⊕ (r2||P)) while the public cloud server verifies D/ = D. Therefore, mobile users and public cloud servers authenticate each other.


## 4.1. Formal Security Analysis

To determine the security of the proposed protocol using a formal approach, we, in this subsection of the research, will use a random oracle model (ROM) (advantage with the adversary to breach the proposed protocol).


### 4.1.1. Random Oracle Model (ROM) Analysis

SupposeX means protocol; the external user who is currently using our protocol is denoted as U, the registration centre is denoted by G, and the public cloud server is PCS. When running X, each participant has many occurrences to be touched with X via r1, r2, p, P, q, PK, SK. Furthermore, suppose we create a table of random numbers called an oracle. Also, let Is be the xth occurrence of U, Js is the yth occurrence of G, and Ks is the zth occurrence of PCS. While Is is supposed to be the occurrence of all participants, then definitely, there are possibly three occurrences available A, B, C. A = successfully usage of the protocol, and the user is securely authenticating with the destination, B = never authenticate, and C = no result. Afore running X, U has MSG1, G has MSG2, and PCS has MSG3, and suppose the shared secret key SK is stored securely in the memory of U, G, and PCS.Suppose an adversary desires to enter our protocol over the open channel and try to start their own session or terminate theU session by arbitrating the participation. The adversary must be known J = (r2.P) and PKmu = (r1.P), and then, he/she can execute {Is, Js} and {Js, Is} quires. In this regard, A's advantage to breach the proposed protocol is(1)AdvxA=2ProbC+C/−1,whereas C means flipping a coin by the adversary, and when flipping the coin, the result is C/. For hash queries, the advantage with the adversary A is(2)AdvxA=ProbS2−ProbS2+qhe2/2thS+1+qhe+12/2thS+1+qhe2/2thS,whereas qhe2/2thS+1+qhe+12/2thS+1+qhe2/2thS are at most chances of collision of hash code with each other in the oracle. By expanding (2), we get(3)ProbS3−ProbS2≤2qU+2qPCS2qG.The advantage with the adversary to capture shared session key as(4)|probS1−ProbS2≤qPCS.AdvxA.If we keep another list of numbers/dictionary (D), then probability with the adversary A is(5)probS3=12maxqU2,qPCSD.By combining (1)–(5), we get(6)AdvxA=ProbS1−1=2ProbS0−ProbS4+maxqU2,qPCSD≤2ProbS0−ProbS4+maxqU2,qPCSD=2ProbS1−ProbS2+ProbS3−ProbS4+maxqU2,qPCSD≤qU2+qPCS2+qG22q+qU+qPCS22q−1+2qPCS.AdvX.APCS+2qU2q,qPCSD.


### 4.1.2. ProVerif2.03 Simulation

To check whether the session secret is secured, confidentiality computed, and exchanged security among different peers or to check its reachability and test whether an attacker can forage it during a starting session or not, ProVerif2.03 verification software toolkit is used. This is a widely accepted software verification toolkit. The whole code and result are generated as follows:(∗ --------- CHANNELS ----------∗)free PrivCh:channel [private]. (∗secure channel between User and Server∗)free PublPub:channel. (∗public channel between User and Server∗)(∗----------- CONSTANTS AND VARIABLES ---------∗)free IDmu:bitstring.free PIDpcs:bitstring.free RIDs:bitstring.free RIDdrj:bitstring.free PWmu:bitstring[private].free Bmu:bitstring[private].free SKpcs:bitstring[private].free PKpcs:bitstring.free P:bitstring.free TCui:bitstring.free taui:bitstring.free q:bitstring.free r:bitstring.free r1:bitstring.free r2:bitstring.free SKmu:bitstring[private].free PKmu:bitstring.(∗-------Queries------∗)query id:bitstring; inj-event(end_Ui(IDUi)) = => inj-event(start_U(IDmu)).query id:bitstring; inj-event(end_S(IDS)) = => inj-event(start_S(PIDpcs)).query attacker(SKmu).(∗ = = = = = ∗Events∗ = = = = = ∗)event start_U(bitstring).event end_U(bitstring).event start_PCS(bitstring).event end_PCS(bitstring).(∗ = = = = = = = = Constructors = = = = = = = ∗)fun XOR(bitstring, bitstring): bitstring.fun H(bitstring): bitstring.fun CONCAT(bitstring, bitstring): bitstring.(∗ = = = = = = Equations = = = = = = = ∗)equation forallm: bitstring, n: bitstring; XOR(XOR(m,n),m) = n.(∗ = = = = = = = = = = USER = = = = = = = = = = = = ∗)letU =event start_U(IDmu);freee:bitstring.lete = XOR(C, Bmu) inletO = H(H(IDmu, S3), SKmu) inif Odash =O thenletj = H(r2, P) inout(PublCh, (j));in(PublCh, (r1:bitstring, P:bitstring, Q:bitstring)) inlet Qdash = XOR(XOR(r1, PKpcs), H(H(r1, P), r2)) inletS1 = H(H(H(H(IDmu, PWmu), r2), Bmu)) inletD = XOR(XOR(XOR(r1, PKmu), PIDpcs), r1), r2)) inletM = XOR(XOR(XOR(IDmu, r1), IDmu), S2), SKmu)) inlet PKmu =H(r1, P) inlet SKmu =H(H(H(H(H(r1, r2), IDmu), SKmu), PIDpcs));letY=H(H(H(H(H(H(SKmu, r1), r1), r2), P), IDmu));letW = XOR(H(H(r, P), r2), P));event end_U(IDmu)else0.(∗-----------PUBLIC CLOUD SERVER (PCS) ---------∗)let PCS =event start_PCS(PIDmu);in (PublCh, (J:bitstring));let PKmu =H(r1, P) inletQ = XOR(h(r1, SKpcs), (h(h(h(r1, P), r2), P))) inout(PublCh,(r1, P, Q));event end_PCS(PIDmu)else0.process ((!U) | (!PCS))Upon running the code, the following result will generate, which shows no attacker at any stage cannot forge, crack, and hack the secret session key. Also, its reachability is confirmed among the participants.Completing equations…Completing equations…-- Process 1-- Query not attacker(SK[]) in process 1Translating the process into Horn clauses…Completing…200 rules inserted. Base: 136 rules (27 with conclusion selected). Queue: 24 rules.Starting query not attacker(SK[])RESULT not attacker(SK[]) is true.-- Query inj-event(end_U(U[])) ==>  inj-event(start_U(IDmu[])) in process 1Translating the process into Horn clauses…Completing…200 rules inserted. Base: 136 rules (27 with conclusion selected). Queue: 24 rules.Starting query inj-event(end_U(IDmu[])) ==>  inj-event(start_U(IDmu[]))RESULT inj-event(end_U(IDum[])) ==>  inj-event(start_U(IDmu[])) is true.-- Query inj-event(end_PCS(PIDmu[])) =>  inj-event(start_PCS(PIDmu[])) in process 1Translating the process into Horn clauses…Completing…200 rules inserted. Base: 126 rules (27 with conclusion selected). Queue: 28 rules.Starting query inj-event(end_PCS(PIDmu[])) =>  inj-event(start_PCS(PIDmu[]))RESULT inj-event(end_PCS(PIDmu[])) =>  inj-event(start_PCS(PIDmu[])) is true.-- Query inj-event(end_U(IDmu[])) ==>  inj-event(start_U(IDmu[])) in process 1Translating the process into Horn clauses…Completing…200 rules inserted. Base: 136 rules (27 with conclusion selected). Queue: 24 rules.Starting query inj-event(end_PCS(IDmu[])) ==>  inj-event(start_U(IDmu[]))RESULT inj-event(end_PCS(PIDmu[])) ==>  inj-event(start_U(PIDmu[])) is true.Verification summary:Query not attacker(SK[]) is true.Query inj-event(end_U(IDmu[])) ==>  inj-event(start_U(IDmu[])) is true.Query inj-event(end_PCS(PIDmu[])) ==>  inj-event(start_PCS(PIDmu[])) is true.


## 4.1.1. Random Oracle Model (ROM) Analysis

SupposeX means protocol; the external user who is currently using our protocol is denoted as U, the registration centre is denoted by G, and the public cloud server is PCS. When running X, each participant has many occurrences to be touched with X via r1, r2, p, P, q, PK, SK. Furthermore, suppose we create a table of random numbers called an oracle. Also, let Is be the xth occurrence of U, Js is the yth occurrence of G, and Ks is the zth occurrence of PCS. While Is is supposed to be the occurrence of all participants, then definitely, there are possibly three occurrences available A, B, C. A = successfully usage of the protocol, and the user is securely authenticating with the destination, B = never authenticate, and C = no result. Afore running X, U has MSG1, G has MSG2, and PCS has MSG3, and suppose the shared secret key SK is stored securely in the memory of U, G, and PCS.Suppose an adversary desires to enter our protocol over the open channel and try to start their own session or terminate theU session by arbitrating the participation. The adversary must be known J = (r2.P) and PKmu = (r1.P), and then, he/she can execute {Is, Js} and {Js, Is} quires. In this regard, A's advantage to breach the proposed protocol is(1)AdvxA=2ProbC+C/−1,whereas C means flipping a coin by the adversary, and when flipping the coin, the result is C/. For hash queries, the advantage with the adversary A is(2)AdvxA=ProbS2−ProbS2+qhe2/2thS+1+qhe+12/2thS+1+qhe2/2thS,whereas qhe2/2thS+1+qhe+12/2thS+1+qhe2/2thS are at most chances of collision of hash code with each other in the oracle. By expanding (2), we get(3)ProbS3−ProbS2≤2qU+2qPCS2qG.The advantage with the adversary to capture shared session key as(4)|probS1−ProbS2≤qPCS.AdvxA.If we keep another list of numbers/dictionary (D), then probability with the adversary A is(5)probS3=12maxqU2,qPCSD.By combining (1)–(5), we get(6)AdvxA=ProbS1−1=2ProbS0−ProbS4+maxqU2,qPCSD≤2ProbS0−ProbS4+maxqU2,qPCSD=2ProbS1−ProbS2+ProbS3−ProbS4+maxqU2,qPCSD≤qU2+qPCS2+qG22q+qU+qPCS22q−1+2qPCS.AdvX.APCS+2qU2q,qPCSD.


## 4.1.2. ProVerif2.03 Simulation

To check whether the session secret is secured, confidentiality computed, and exchanged security among different peers or to check its reachability and test whether an attacker can forage it during a starting session or not, ProVerif2.03 verification software toolkit is used. This is a widely accepted software verification toolkit. The whole code and result are generated as follows:(∗ --------- CHANNELS ----------∗)free PrivCh:channel [private]. (∗secure channel between User and Server∗)free PublPub:channel. (∗public channel between User and Server∗)(∗----------- CONSTANTS AND VARIABLES ---------∗)free IDmu:bitstring.free PIDpcs:bitstring.free RIDs:bitstring.free RIDdrj:bitstring.free PWmu:bitstring[private].free Bmu:bitstring[private].free SKpcs:bitstring[private].free PKpcs:bitstring.free P:bitstring.free TCui:bitstring.free taui:bitstring.free q:bitstring.free r:bitstring.free r1:bitstring.free r2:bitstring.free SKmu:bitstring[private].free PKmu:bitstring.(∗-------Queries------∗)query id:bitstring; inj-event(end_Ui(IDUi)) = => inj-event(start_U(IDmu)).query id:bitstring; inj-event(end_S(IDS)) = => inj-event(start_S(PIDpcs)).query attacker(SKmu).(∗ = = = = = ∗Events∗ = = = = = ∗)event start_U(bitstring).event end_U(bitstring).event start_PCS(bitstring).event end_PCS(bitstring).(∗ = = = = = = = = Constructors = = = = = = = ∗)fun XOR(bitstring, bitstring): bitstring.fun H(bitstring): bitstring.fun CONCAT(bitstring, bitstring): bitstring.(∗ = = = = = = Equations = = = = = = = ∗)equation forallm: bitstring, n: bitstring; XOR(XOR(m,n),m) = n.(∗ = = = = = = = = = = USER = = = = = = = = = = = = ∗)letU =event start_U(IDmu);freee:bitstring.lete = XOR(C, Bmu) inletO = H(H(IDmu, S3), SKmu) inif Odash =O thenletj = H(r2, P) inout(PublCh, (j));in(PublCh, (r1:bitstring, P:bitstring, Q:bitstring)) inlet Qdash = XOR(XOR(r1, PKpcs), H(H(r1, P), r2)) inletS1 = H(H(H(H(IDmu, PWmu), r2), Bmu)) inletD = XOR(XOR(XOR(r1, PKmu), PIDpcs), r1), r2)) inletM = XOR(XOR(XOR(IDmu, r1), IDmu), S2), SKmu)) inlet PKmu =H(r1, P) inlet SKmu =H(H(H(H(H(r1, r2), IDmu), SKmu), PIDpcs));letY=H(H(H(H(H(H(SKmu, r1), r1), r2), P), IDmu));letW = XOR(H(H(r, P), r2), P));event end_U(IDmu)else0.(∗-----------PUBLIC CLOUD SERVER (PCS) ---------∗)let PCS =event start_PCS(PIDmu);in (PublCh, (J:bitstring));let PKmu =H(r1, P) inletQ = XOR(h(r1, SKpcs), (h(h(h(r1, P), r2), P))) inout(PublCh,(r1, P, Q));event end_PCS(PIDmu)else0.process ((!U) | (!PCS))Upon running the code, the following result will generate, which shows no attacker at any stage cannot forge, crack, and hack the secret session key. Also, its reachability is confirmed among the participants.Completing equations…Completing equations…-- Process 1-- Query not attacker(SK[]) in process 1Translating the process into Horn clauses…Completing…200 rules inserted. Base: 136 rules (27 with conclusion selected). Queue: 24 rules.Starting query not attacker(SK[])RESULT not attacker(SK[]) is true.-- Query inj-event(end_U(U[])) ==>  inj-event(start_U(IDmu[])) in process 1Translating the process into Horn clauses…Completing…200 rules inserted. Base: 136 rules (27 with conclusion selected). Queue: 24 rules.Starting query inj-event(end_U(IDmu[])) ==>  inj-event(start_U(IDmu[]))RESULT inj-event(end_U(IDum[])) ==>  inj-event(start_U(IDmu[])) is true.-- Query inj-event(end_PCS(PIDmu[])) =>  inj-event(start_PCS(PIDmu[])) in process 1Translating the process into Horn clauses…Completing…200 rules inserted. Base: 126 rules (27 with conclusion selected). Queue: 28 rules.Starting query inj-event(end_PCS(PIDmu[])) =>  inj-event(start_PCS(PIDmu[]))RESULT inj-event(end_PCS(PIDmu[])) =>  inj-event(start_PCS(PIDmu[])) is true.-- Query inj-event(end_U(IDmu[])) ==>  inj-event(start_U(IDmu[])) in process 1Translating the process into Horn clauses…Completing…200 rules inserted. Base: 136 rules (27 with conclusion selected). Queue: 24 rules.Starting query inj-event(end_PCS(IDmu[])) ==>  inj-event(start_U(IDmu[]))RESULT inj-event(end_PCS(PIDmu[])) ==>  inj-event(start_U(PIDmu[])) is true.Verification summary:Query not attacker(SK[]) is true.Query inj-event(end_U(IDmu[])) ==>  inj-event(start_U(IDmu[])) is true.Query inj-event(end_PCS(PIDmu[])) ==>  inj-event(start_PCS(PIDmu[])) is true.


## 4.2. Informal Security Analysis

This section will intensely discuss the possible attacks and their prevention and discuss our proposed scheme features.(1)
Provide user anonymity: the proposed scheme provides user anonymity. When mobile user sends IDmu by calculating, W = h((r1.P), (r2.P)). The (r1.P) and (r2.P) are only known to the public cloud server. Therefore, the proposed scheme provides user anonymity.(2)
Provide user untraceability: theA cannot extract information from W = h((r1.P), (r2.P)) because it is only known to a public cloud server. Thus, the proposed is a protected user untraceability feature.(3)
Resist to offline password-guessing attacks: theA can get W = h((r1.P), (r2.P)), Y = h(SKmu, r1, r1.P, r2.P, IDmu), D = (r1 ⊕ PKmu)h(PIDPCS ⊕ (r1.P) ⊕ (r2.P)) on insecure medium. Although the A can also extract contents from smart card {PKmu, N, M, O}, the A cannot get mobile user password PWmu from these credentials. Therefore, the proposed scheme resists offline password attacks.(4)
Resist to masquerading attacks: in the proposed scheme, theA cannot launch an impersonation attack because of unable to get PWmu or the secret keys of the mobile user. The A cannot modify the Y = h(SKmu, r1, r1.P, r2.P, IDmu) because of (r1.P), (r2.P). Therefore, the proposed scheme resists masquerading attacks.(5)
Resist to smart card stolen attacks: TheA guesses mobile user password PWmu and launches a user impersonation attack. However, the A cannot launch forgery, modification, and replay attacks in the proposed scheme because the A will need a mobile user secret key and the random number to compute Y = h(SKmu, r1, r1.P, r2.P, IDmu). Therefore, the proposed scheme resists smart card stolen attacks.(6)
Provide perfect forward secrecy: the proposed scheme provides perfect forward secrecy even if the secret key of the public cloud registration server is lost. The proposed scheme generates session keySKmu = h(r1.P, r2.P)||h(IDmu||SKmu)||r1||h(IDmu||PIDPCS) by using random numbers with multiplication with P. It is very difficult for A to compute those numbers because of ECDLP in a short period of time.(7)
Provide known key security: theA cannot get mobile user and public cloud server secret keys and random numbers. Although if the A gets the session key, it cannot extract secret keys and random numbers. Therefore, the proposed scheme protected against the known key attacks.(8)
Resist to session key attacks: if theA gets a random number, it still requires a mobile user secret key to generate a session key. Therefore, the proposed scheme resists session key attacks.(9)
Resist to credentials leakage attacks: TheA may get some mobile user leaked credentials and try to launch a masquerading server attack. Our proposed protocol resists such attacks even if mobile user credentials are leaked. The A cannot generate Q = r1 ⊕ SKPCSh(r1.P ⊕ r2.P) because of the public cloud server secret key. Therefore, the proposed scheme resists credentials leak attacks.(10)
Resist to replay attacks: theA may get the previous session key and extract meaningful information to launch the replay attack. In the proposed scheme, the public cloud server checks W/ = W and D/= D to stop replay attacks. Thus, the proposed protocol resists replay attacks.(11)
Resist to denial-of-service attacks: each session starts with a fresh and unique session key. The proposed scheme random numberr1,r2 is very hard to compute while the proposed scheme checks Q/ = Q, thus if A sends incorrect information to any participants, such request is rejected. Therefore, the proposed scheme resists denial of service attacks.(12)
Resist man-in-the-middle attacks: in our proposed scheme, the mobile user and public cloud server share session key after authenticating each other. Therefore,A cannot construct a connection with the mobile user and public cloud server because A needs random numbers, r1,r2, bio(Bmu), IDu, PWmu, and public cloud server secret key SKPCS. Thus, the proposed scheme resists a man-in-the-middle attack.(13)
Provide mutual authentication: in our proposed scheme’s login and authentication phase, the public cloud server computesQ = r1 ⊕ SKPCS||h(r1||P ⊕ r2||P) while the mobile user verifies Q/ = Q. On the other side, the mobile user calculates D = (r1 ⊕ PKmu) ⊕ (PIDPCS ⊕ (r1||P) ⊕ (r2||P)) while the public cloud server verifies D/ = D. Therefore, mobile users and public cloud servers authenticate each other.


## 5. Performance Analysis

This section will calculate communication and computation cost and compare our proposed scheme with other recent related protocols regarding communication and computation cost and possible attacks and scheme features.


### 5.1. Communication Cost

In this section, we will discuss the communication cost in detail. The computation of communication cost is calculated based on the messages transmitted between the mobile user and public cloud server in the login and authentication phase. MSG1 {J}, MSG2 {r1.P, Q}, MSG3 {W, Y, D} is equal to 160 bits + 160 bits + 160 bits+160 bits + 160 bits + 160 bits + 160 bits = 1120.


### 5.2. Computation Cost

We will consider the work done by the author of [54–62] for the time consumed during session key establishment among different participants, as shown in Table 5.Table 5
Computation time for different cryptographic functions.
Function descriptionsNotationComputation cost in msTime for a collision-free hash functionTh0.0023 msTime for bitwise XOR operationT⊕0.0288 msExtraction of random numberTRN0.539 msMultiplication time complexityTMLT0.0171 msTherefore, keeping in view the aforementioned values, the computation time for the proposed authentication protocol is given asUSER SIDE COMPUTATION: 12T⊕ + 11Th + 1TRN + 11TMLT.By putting values from Table5, we get(7)=120.0288+110.0023+10.539+110.0171=0.3456+0.0253+0.539+0.1881=1.098ms.SERVER SIDE COMPUTATION: 7T⊕ + 7Th + 2TRN + 11TMLT.By putting values from Table5, we get(8)=70.0288+70.0023+20.539+110.0171=0.2016+0.0161+1.078+0.1881=1.4838ms.By adding equations (7) and (8), we get(9)=1.098+1.183=2.281ms.Therefore, the time required to compute session shared key among user and server is just 2.281 milliseconds.


### 5.3. Comparison Analysis

In this section, we will compare our scheme with recently published protocols such as [54–61] and [62] in terms of communication and computation cost and security features. Table 6 shows the comparison of our proposed scheme with other state-of-the-art schemes in terms of communication cost, while the security features are shown in Table 7. Moreover, Figure 2 shows communication and computation cost comparison with other schemes in graphical representation. The result shows that our scheme is lightweight and has more security features than other schemes.Table 6
Communication cost comparison.
SchemesNo of messagesTotal cost[53]45280[54]31728[55]31536[56]31696[57]32528[58]41312[59]32560[60]32016[61]21184[62]31184Our31120Table 7
Security features.
Features[53][54][55][56][57][58][59][60][61][62]OurAXX✓✓✓✓XX✓✓✓B✓✓X✓✓✓✓✓X✓✓C✓✓X✓✓✓✓XX✓✓D✓✓✓✓✓✓XX✓✓✓E✓✓✓✓✓✓✓X✓✓✓F✓✓✓✓✓✓✓✓✓✓✓G✓XX✓✓✓✓✓X✓✓H✓✓✓✓X✓✓✓✓✓✓I✓XXX✓✓XXX✓✓J✓✓X✓✓✓✓✓✓X✓KX✓X✓✓✓✓✓✓✓✓L✓✓✓✓✓✓✓✓✓✓✓A: Provide user anonymity. B: Provide mutual authentication. C: Resist privileged insider attack. D: Resist offline password-guessing attack. E: Resist stolen smart card attack. F: Resist replay attack. G: Session key. H: Provide key management. I: Resist impersonation attack. J: Resist to DoS attack. K: Provide untraceability. L: Resist brute-force attack.Figure 2
Communication and computation cost comparison.


## 5.1. Communication Cost

In this section, we will discuss the communication cost in detail. The computation of communication cost is calculated based on the messages transmitted between the mobile user and public cloud server in the login and authentication phase. MSG1 {J}, MSG2 {r1.P, Q}, MSG3 {W, Y, D} is equal to 160 bits + 160 bits + 160 bits+160 bits + 160 bits + 160 bits + 160 bits = 1120.


## 5.2. Computation Cost

We will consider the work done by the author of [54–62] for the time consumed during session key establishment among different participants, as shown in Table 5.Table 5
Computation time for different cryptographic functions.
Function descriptionsNotationComputation cost in msTime for a collision-free hash functionTh0.0023 msTime for bitwise XOR operationT⊕0.0288 msExtraction of random numberTRN0.539 msMultiplication time complexityTMLT0.0171 msTherefore, keeping in view the aforementioned values, the computation time for the proposed authentication protocol is given asUSER SIDE COMPUTATION: 12T⊕ + 11Th + 1TRN + 11TMLT.By putting values from Table5, we get(7)=120.0288+110.0023+10.539+110.0171=0.3456+0.0253+0.539+0.1881=1.098ms.SERVER SIDE COMPUTATION: 7T⊕ + 7Th + 2TRN + 11TMLT.By putting values from Table5, we get(8)=70.0288+70.0023+20.539+110.0171=0.2016+0.0161+1.078+0.1881=1.4838ms.By adding equations (7) and (8), we get(9)=1.098+1.183=2.281ms.Therefore, the time required to compute session shared key among user and server is just 2.281 milliseconds.


## 5.3. Comparison Analysis

In this section, we will compare our scheme with recently published protocols such as [54–61] and [62] in terms of communication and computation cost and security features. Table 6 shows the comparison of our proposed scheme with other state-of-the-art schemes in terms of communication cost, while the security features are shown in Table 7. Moreover, Figure 2 shows communication and computation cost comparison with other schemes in graphical representation. The result shows that our scheme is lightweight and has more security features than other schemes.Table 6
Communication cost comparison.
SchemesNo of messagesTotal cost[53]45280[54]31728[55]31536[56]31696[57]32528[58]41312[59]32560[60]32016[61]21184[62]31184Our31120Table 7
Security features.
Features[53][54][55][56][57][58][59][60][61][62]OurAXX✓✓✓✓XX✓✓✓B✓✓X✓✓✓✓✓X✓✓C✓✓X✓✓✓✓XX✓✓D✓✓✓✓✓✓XX✓✓✓E✓✓✓✓✓✓✓X✓✓✓F✓✓✓✓✓✓✓✓✓✓✓G✓XX✓✓✓✓✓X✓✓H✓✓✓✓X✓✓✓✓✓✓I✓XXX✓✓XXX✓✓J✓✓X✓✓✓✓✓✓X✓KX✓X✓✓✓✓✓✓✓✓L✓✓✓✓✓✓✓✓✓✓✓A: Provide user anonymity. B: Provide mutual authentication. C: Resist privileged insider attack. D: Resist offline password-guessing attack. E: Resist stolen smart card attack. F: Resist replay attack. G: Session key. H: Provide key management. I: Resist impersonation attack. J: Resist to DoS attack. K: Provide untraceability. L: Resist brute-force attack.Figure 2
Communication and computation cost comparison.


## 6. Conclusion

This research article proposes a robust privacy-preserving authentication and key agreement scheme, which guarantees secure communication among participants. The possible threats to the system and power with an adversary have been highlighted and designed a scheme for three participants (user, PCRC, and PCS). The security analysis section shows that our protocol is secure and effective informally and formally. In the end, the result of performance metrics of the scheme offers a delicate balance with security which is most probabilistically missing in prior protocols. Upon checking the different security functionalities, our scheme is much accurate, robust, and lightweight and preserves the privacy of an end-user. In the future, we have planned to simulate the scheme using the AVISPA tool and NS3.Data Availability: If anyone desires to need data like figures, tables, code, and modules of this article that are utilized in support of the study’s strength/findings, they can correspond with the principal author of the paper. They will be facilitated by sending the relevant materials upon request.



---

*Source: 1943426-2022-03-14.xml*