Provably Secure Lightweight Mutual Authentication and Key Agreement Scheme for Cloud-Based IoT Environments

Abstract

A paradigm that combines cloud computing and the Internet of Things (IoT) allows for more impressive services to be provided to users while addressing storage and computational resource issues in the IoT environments. This cloud-based IoT environment has been used in various industries, including public services, for quite some time, and has been researched in academia. However, various security issues can arise during the communication between IoT devices and cloud servers, because communication between devices occurs in open channels. Moreover, issues such as theft of a user’s IoT device or extraction of key parameters from the user’s device in a remote location can arise. Researchers interested in these issues have proposed lightweight mutual authentication key agreement protocols that are safe and suitable for IoT environments. Recently, a lightweight authentication scheme between IoT devices and cloud servers has been presented. However, we found out their scheme had various security vulnerabilities, vulnerable to insider, impersonation, verification table leakage, and privileged insider attacks, and did not provide users with untraceability. To address these flaws, we propose a provably secure lightweight authentication scheme. The proposed scheme uses the user’s biometric information and the cloud server’s secret key to prevent the exposure of key parameters. Additionally, it ensures low computational costs for providing users with real-time and fast services using only exclusive OR operations and hash functions in the IoT environments. To analyze the safety of the proposed scheme, we use informal security analysis, Burrows–Abadi–Needham (BAN) logic and a Real-or-Random (RoR) model. The analysis results confirm that our scheme is secure against insider attacks, impersonation attacks, stolen verifier attacks, and so on; furthermore, it provides additional security elements. Simultaneously, it has been verified to possess enhanced communication costs, and total bit size has been shortened to 3776 bits, which is improved by almost 6% compared to Wu et al.’s scheme. Therefore, we demonstrate that the proposed scheme is suitable for cloud-based IoT environments.

1. Introduction

The Internet of Things (IoT) is a network in which Internet-enabled objects interact with each other through the internet [1,2]. IoT objects collect data from their surroundings, provide web services to users, and communicate with each other. Therefore, IoT objects such as smart devices need significant resources to store data collected from sensors and perform real-time computations using limited hardware. Hence, addressing the limitations of storage and computing capacities is crucial for the formation of a network of IoT objects [3,4,5]. However, cloud computing technology refers to the practice of moving computational power and storage space from individual devices to larger shared data centers [6]. Cloud computing allows access to a shared pool of computing resources such as networks, servers, storage, and applications. By using cloud computing, it becomes possible to overcome the limitations inherent in IoT devices [7,8,9,10]. The development and discussion of cloud-based IoT (CloudIoT) have been ongoing since before 2008 and continue to evolve. Figure 1 illustrates the structure of CloudIoT. This structure comprises three entities: user, cloud server, and control server. Users with IoT devices can access the resources provided by the cloud service provider’s server anytime and anywhere through IoT objects. The cloud server collects user’s requests and delivers the right service through IoT. The control server, acting as a trusted entity, generates the necessary parameters for communication between authenticated users and the cloud server through the registration process. Additionally, it monitors the key agreement phase to ensure that users and the cloud server establish the same session key for subsequent communications when needed.

Figure 1. Cloud-based IoT enviroment.

In 2022, Wu et al. [11] proposed a lightweight authentication protocol for IoT-enabled cloud computing environments. The authors argued that their scheme could resist various attacks, such as man-in-the-middle, insider, DDoS, and masquerade attacks, and provides privacy, traceability, and integrity. However, we identified several vulnerabilities in Wu et al.’s scheme, including susceptibility to insider attacks, verification table attacks, user impersonation, and cloud server impersonation. Furthermore, the scheme lacks user untraceability, allowing an attacker to track the same user across different sessions through message eavesdropping alone. To address these vulnerabilities, we propose a provably secure lightweight mutual authentication and key agreement (MAKA) scheme. In our proposed scheme, we protect crucial parameters stored in the user’s IoT smart card using the user’s biometric information to prevent attacks like user impersonation and offline password-guessing. We also enhanced security by adding a secret key to the cloud server, preventing attackers from exploiting leaked database values. Additionally, we reduced the communication and computation overhead by employing only hash functions and exclusive-OR operations.

1.1. Research Contributions

We review and conduct a security analysis of Wu et al.’s authentication scheme. We demonstrate that Wu et al.’s scheme is vulnerable to insider attacks, verification table leakage attacks privileged insider attacks, user impersonation, and cloud server impersonation. Additionally, we propose an MAKA for cloud-based IoT environments that leverages biometric information. The proposed scheme is tailored to the IoT environments, using only exclusive OR operations and hash functions to align with a lightweight architecture. Additionally, we use a Real-or-Random (RoR) model and Burrow–Abadi–Needham (BAN) logic to demonstrate formally the security and robustness of the proposed. Moreover, we substantiate the security of our scheme against different attacks, including insider attacks, impersonation attacks, reply and man-in-the-middle (MITM) attacks, privileged insider attacks, ephemeral security leakage, stolen verifier attacks, DoS attacks, and session key disclosure attacks. In addition, we confirmed that our scheme can provide user anonymity, user untraceability, perfect forward secrecy, and mutual authentication. Last, we evaluate the security features, communication costs, and computation costs of the proposed scheme with related schemes, including Wu et al.’s.

1.2. Organization

In Section 2, we introduce studies related to cloud-based IoT, IoT, and cloud computing. We present the system model and adversary model used in our proposed scheme in Section 3. Following that, we discuss Wu et al.’s scheme in Section 4. We then delve into the vulnerabilities we identified in Wu et al.’s scheme in Section 5. In Section 6, we introduce our proposed scheme, and in Section 7, we provide security analyses using tools such as BAN logic, and RoR model. Performance analyses, including security features, communication, and computation costs, are presented in Section 8. Finally, in Section 9, we conclude our paper and outline future plans.

2. Related Works

When providing services to users over the internet, application security is crucial in gaining user trust. To access various services, including storage services provided by cloud service providers, the environments should be well prepared to handle various attacks and security threats that may exist. Furthermore, in IoT environments, lightweight protocol computations are essential to provide users with a seamless real-time service anytime, anywhere. In the following sections, we will review the authentication protocols in the existing cloud-based IoT environments.

In 2019, Schouqi et al. [12] introduced an authentication protocol for IoT built on Nikooghadam et al.’s [13] protocol. The protocol of Nikooghadam et al. was developed as a responses to issues with the authentication protocol proposed by Kumari et al. [14]. However, Nikooghadam et al.’s scheme has already been analyzed by researchers in the field, including Limbasiya et al., Chandrakar-Om, and Sharma-Kalra [15,16,17]. These researchers raised concerns about its security, highlighting vulnerabilities to various attacks such as password-guessing, insiders, and modification attacks. They also indicated that the protocol lacked forward secrecy and did not provide session key verification and a biometric update phase. The author of the new scheme reviewed the security issues known in Nikooghadam et al.’s protocol and proposed enhancements based on these findings.

Prosanta and Biplab (Prosanta-Biplab) [18] proposed lightweight two-factor authentication scheme for IoT devices in 2019. They argued that two-factor authentication schemes that use a passwords and smartcards, often vulnerable to physical attacks. To overcome these security issues they suggested physically uncloneable functions(PUF) as an authentication factor for IoT devices. However, in 2020, Siddiqui et al. [19] demonstrated that the scheme is vulnerable to man-in-the-middle, impersonations, session- hijacking and conventional and differential template attacks.

In 2019, Zhou et al. [20] presented a lightweight two-factor authentication scheme for IoT devices available in the cloud environments. In the same year, Rafael et al. [21] indicated that Zhou et al.’s scheme has several security issues. Rafael et al. demonstrated that Zhou et al.’s scheme failed to provide mutual authentication, was unsuccessful in protecting the secret key, and was vulnerable to various attacks, including insider attacks and man-in-the-middle attacks.

In 2020, Alzahrani et al. [22] presented an authentication protocol for IoT environments based on self-certified public keys and elliptic curve cryptography (ECC). Alzahrani conducted research on protocols proposed by Islam-Biswas [23] and Mandal et al. [24], highlighting their failure to ensure user anonymity and vulnerability to impersonation attacks. Therefore, the author developed a protocol that guarantees anonymity among connected devices and addresses security vulnerabilities. However, this scheme does not guarantee security against physical attacks.

Chen et al. [25] proposed a lightweight user authentication and key-agreement scheme for IoT. Chen et al. utilized XOR operations, hash functions, and elliptical multiplication. Lee et al. [26] indicated that Chen et al.’s scheme did not provide a steal-resistant smartcard offline password, offline identity guessing and reply attack. Subsequently, in 2020, Ye et al. [27] proposed an authentication and key agreement scheme for IoT-based cloud computing environments by advancing the protocol developed by He et al. [28]. Ye et al. addressed various security issues in the scheme proposed by He et al, such as failure to resist insider attacks, offline password-guessing, user impersonation, and potential DoS attacks.

Table 1, summarizes cryptographic technologies and limitations of various authentication schemes related to IoT, cloud-based IoT, and cloud computing environments. Related papers propose various protocols to provide users with secure and fast services in the CloudIoT environment. However, there are still vulnerabilities and challenges in fully supporting security features, as some attacks persist. Additionally, methods using symmetric keys like ECC may incur higher computation costs in IoT environments. Therefore, our goal is to design a lightweight protocol tailored for IoT environments using XOR and to achieve higher security in our scheme.

Table 1. Authentication scheme overview.

Schemes	Cryptographic Technologies	Limitaion
Islam-Biswas [23]	- ECC - Self-certified public keys	- Cannot provide anonymity - Vulnerable to reply and clogging attacks
He et al. [28]	- Asymmetric cryptography	- Vulnerable to insider attacks, offline password-guessing, user impersonation attacks, and DoS attacks
Chen at al. [25]	- XOR operation - Hash function - Elliptic multiplication	- Vulnerable to stolen smartcard, offline password-guessing, offline identity guessing, and reply attacks
Prosanta-Biplab [18]	- PUF - Fuzzy extractor	-Vulnerable to man-in-the-middle attacks, impersonation attacks, session key hijaking, conventional and differential template attacks
Zhou et al. [20]	- XOR operation - Hash function	- Cannot provide mutual authentication - Vulnerable to insider attacks and man-in-the-middle attacks
Nikooghadam et al. [13]	- XOR operation - Hash function	- Vulnerable to reply attacks, privileged insider attacks, offline password-guessing, known key temporary imformation attacks, server spoofing attacks and impersonation attcks
Tsai-Lo [29]	- Single Sign On scheme	- Cannot provide sesssion key security, mutual authentication, and user anonymity - Vulnerable to impersonation attacks
Kumari et al. [30]	- Hash function - Diffie-Hellman	- Cannot provide user unlinkability and anonymity, data confidentiality - Vulnerable to known session-specific temporary information attacks, impersonation attacks, and desynchronization attacks
Bhuarya et al. [31]	- ECC	- Cannot provide mutual authentication - Vulnerable to impersonation attacks and man-in-the-middle attacks

3. Preliminaries

3.1. System Model

As shown in Figure 2, an IoT-enable cloud computing environment includes three entities: user, cloud server, and control server. Users can also use cloud computing provided by a cloud server, using IoT-enabled devices. Therefore, the user and cloud server should register and authenticate it through the control server. Finally, the user and cloud server share a session key for communication. The details are as follows

Figure 2. System model.

• User ($U_i$): User uses IoT devices with cloud services. Communicates with the cloud servers, then the user should register with the control server. The user can use smart cards and biometric technology to store sensitive information or the user’s identity and password. We assumed that the user is an untrusted entity, implying that the user can execute unauthorized or malicious attacks.
• Cloud server ($S_j$): A cloud server provides cloud services to users using IoT devices. To achieve this, the cloud server should be registered with the control server. As a semi-trusted entity, the cloud server can misbehave; however, it cannot directly collude or participate.
• Control server ($CS$): This manages the registration of the user and cloud server, and helps generate the session key for authentication and subsequent communication. As a semi-trusted entity, the control server can misbehave; however, it cannot directly collude or participate.

3.2. Adversary Model

We employ the widely used “Dolev–Yao (DY) model” [32] to define the capabilities of the adversary. The details are as follows:

• Within the DY model, entities in the IoT environments are considered trustworthy, and the communication channel is also considered insecure. Consequently, the adversary can engage in various actions through the insecure channel, including resending, eavesdropping, blocking, and deleting any messages transmitted.
• The adversary can extract sensitive information through power analysis attacks from stolen user smart cards. Additionally, because the control and cloud servers are semi-trusted entities, the adversary can also extract information from their databases.

Furthermore, the “Canetti–Krawczyk (CK) model” [33] assumes that stronger adversaries can also be adapted to our protocol. The adversaries in the CK model can obtain and use ephemeral values or long-term values, and using those, ephemeral leakage attacks can be performed.

4. Revisit of Wu et al.’s Scheme

4.1. Registration Phase

Before generating a session key for communication, the user and cloud server must go through the registration process via a secure channel. The detailed process is as follows.

4.1.1. User Registration Phase

Step 1: 

The $U_i$ enters $I{D}_i$, $P{W}_i$ and imprints $B_i$ on the device. Then, calculates $Gen\left(B_i\right)={\sigma }_i,{\tau }_i$, $HP{W}_i=h(P{W}_i\left|\right|{\sigma }_i)$ and sends $I{D}_i,HP{W}_i$ to $CS$ as a registration request message through a secure channel.

Step 2: 

$CS$ checks if $U_i$’s identity is new, and generates a random number $n_i$ to calculate $TI{D}_i=h\left(I{D}_i\right)$, $A_1=h(I{D}_{CS}\left|\right|HP{W}_i)\oplus (n_i\oplus x)$. Then, stores $\{TI{D}_i,HP{W}_i\}$ in its database, and stores $\{A_1,I{D}_{CS}\}$ to smart card $SC$. After that, sends $SC$ to $U_i$ through a secure channel.

Step 3: 

$U_i$ computes $A_2=h(I{D}_i\left|\right|HP{W}_i)$ and store $\{A_1,A_2,I{D}_{CS},Gen(·),Rep(·),{\tau }_i\}$ in $SC$.

4.1.2. Cloud Server Registration Phase

Step 1: 

$S_j$ selects $SI{D}_j$ and random number $n_j$ and sends $\{SI{D}_j,n_j\}$ as a request message to $CS$ through a secure channel.

Step 2: 

$CS$ checks if $S_j$’s identity is new, and chooses $S_j$’s pseudo identity $QI{D}_j$, computes $A_3=h(SI{D}_j\left|\right|x\oplus n_j)$, then stores $\{QI{D}_j,n_j\}$ in its database. Next, $CS$ sends $QI{D}_j,n_j$ to $S_j$ through secure channel.

Step 3: 

$S_j$ computes $A_3^{*}=A_3\oplus SI{D}_j$, and stores $\{A_3^{*},QI{D}_j\}$.

4.2. Login and Authentication Phase

In this phase, the control server first verifies the identities of the user and the cloud server. If both are confirmed, a shared session key for subsequent communication is generated. The detailed process is as follows and illustrated in Figure 3.

Figure 3. AKA phase of Wu et al.’s scheme.

Step 1: 

$U_i$ enters $I{D}_i$, $P{W}_i$ and imprints $B_i$, and calculates $Rep(B_i,{\tau }_i)={\sigma }_i$, $HP{W}_i=h(P{W}_i\left|\right|{\sigma }_i)$, $A^{\prime }2=h(I{D}_i\left|\right|HP{W}_i)$. Then, by confirming $A_2^{\prime }\stackrel{?}{=}A2$, $U_i$ can be verified as a legitimate user. If this is valid, $U_i$ selects a random number $r_i$ and timestamp $T{S}_1$, then calculates $(n_i\oplus x)=A_1\oplus h(I{D}_{CS}\left|\right|HP{W}_i)$, $B_1=r_i\oplus h(I{D}_{CS}\left|\right|HP{W}_i\oplus SI{D}_j)$, $B_2=SI{D}_j\oplus h(I{D}_{CS}\left|\right|HP{W}_i)$, and $B_3=h(TI{D}_i\left|\right|I{D}_{CS}\left|\right|n_i\oplus x)\oplus HP{W}_i$. Finally, generates a message $M_1=\{TI{D}_i,A_1,B_1,B_2,B_3,T{S}_1\}$ and sends it to $S_j$ via open channel.

Step 2: 

Upon receiving $U_i$’s message, $CS$ confirms timestamp $|T{S}_1-T{S}_c| \leqq \Delta T$. If the timestamp is valid, $S_j$ chooses a random value $r_j$ and timestamp $T{S}_2$. $S_j$ computes $A_3=SI{D}_j\oplus A_3^{*}$, $B_4=r_j\oplus h(A_3\left|\right|SI{D}_j)$, and $B_5=h(r_j\left|\right|A_3\left|\right|SI{D}_j)$. Finally, message $M_2=\{M_1,QI{D}_j,B_4,B_5,T{S}_2\}$ is sent through an open channel.

Step 3: 

After receiving the $M_2$, $S_j$ confirms timestamp $|T{S}_2-T{S}_c| \leqq \Delta T$. If the timestamp is successfully verified, $CS$ uses $TI{D}_i$ to find $HP{W}_i$ and performs the following computations: $SI{D}_j=B_2\oplus h(I{D}_{CS}\left|\right|HP{W}_i)$, $r_i=B_1\oplus h(I{D}_{CS}\left|\right|HP{W}_i\oplus SI{D}_j)$, and $B_3^{\prime }=h(TI{D}_i\left|\right|I{D}_{CS}\left|\right|n_i\oplus x)\oplus HP{W}_i$. And by checking $B_3^{\prime }\stackrel{?}{=}{B}_3$, the $CS$ confirms whether $U_i$ is the legitimate user. Next, $CS$ utilizes the value of $QI{D}_j$ to find $n_j$ and then performs the following computations: $A_3=h(SI{D}_j\left|\right|x\oplus n_j)$, $r_j=B_4\oplus h(A_3\left|\right|SI{D}_j)$, and $B_5^{\prime }=h(r_j\left|\right|A_3\left|\right|SI{D}_j)$. After checking $B_5^{\prime }\stackrel{?}{=}{B}_5$ is valid, CS then selects $r_k$, $T{S}_3$, computes $SK=h(r_i\oplus HP{W}_i|\left|r_j\right|\left|r_k\right|\left|SI{D}_j\right)$, $B_6=(r_i\oplus HP{W}_i)\oplus A_3$, $B_7=h(A_3\left|\right|r_j\left|\right|SI{D}_j)\oplus r_k$, $B_8=h(r_j\left|\right|r_k\left|\right|SK\left|\right|T{S}_3)$, $(n_i\oplus x)=A_1\oplus h(I{D}_{CS}\left|\right|HP{W}_i)$, $B_9=h(n_i\oplus x\left|\right|SI{D}_j)\oplus r_j$, and $B_{10}=h(HP{W}_i\left|\right|r_i)\oplus r_k$, $B_{11}=h\left(SK\right||n_i\oplus x\left|\right|r_k\left|\right|r_j)$. At last, $CS$ generates message $M_3=\{B_6,B_7,B_8,B_9,B_{10},B_{11},T{S}_3\}$ and sends to $S_j$ through an open channel.

Step 4: 

Upon receiving $M_3$, $S_j$ checks timestamp $|T{S}_3-T{S}_c| \leqq \Delta T$. If the timestamp is valid, $S_j$ calculates following computations: $(r_i\oplus HP{W}_i)=B_6\oplus A_3$, $SK=h(r_i\oplus HP{W}_i|\left|r_j\right|\left|r_k\right|\left|SI{D}_j\right)$, and $B_8^{\prime }=h(r_j\left|\right|r_k\left|\right|SK\left|\right|T{S}_3)$, and confirms $B_8^{\prime }\stackrel{?}{=}{B}_8$. If it confirms, $S_j$ generates message $M_4=\{B_9,B_{10},T{S}_4\}$ to $U_i$ via open channel.

Step 5: 

$U_i$ verifies timestamp $|T{S}_4-T{S}_c| \leqq \Delta T$. If the timestamp is valid, $U_i$ calculates $r_j=h(n_i\oplus x\left|\right|SI{D}_j)\oplus B_9$, $r_k=h(HP{W}_i\left|\right|r_i)\oplus B_{10}$, $SK=h(r_i\oplus HP{W}_i|\left|r_j\right|\left|r_k\right|\left|SI{D}_j\right)$, and $B_{11}^{\prime }=h\left(SK\right||n_i\oplus x\left|\right|r_k\left|\right|r_j)$ and calculates $B_{11}^{\prime }\stackrel{?}{=}{B}_{11}$. If it confirms, $U_i$ computes $B_{12}=h\left(SK\right||r_j)$ and generates $M_5=\left\{B_{12}\right\}$ and sends to $S_j$.

Step 6: 

$S_j$ calculates the equation $B_{12}^{\prime }=h\left(SK\right||r_j)$ and then checks $B_{12}^{\prime }\stackrel{?}{=}{B}_{12}$. If they match, $S_j$ stores $SK$ for future communication.

5. Cryptanalysis of Wu et al.’s Scheme

Following the description of Section 3, adversary $\mathcal{A}$ can obtain important values from the user’s smart card by using a power analysis attack. Furthermore, $\mathcal{A}$ can extract parameters from the cloud server and control server itself, because they are considered semi-trusted. With this information, various security attacks, including insider attack, verification table leakage attack, privileged insider attack, user impersonation, and cloud server impersonation, can be executed by $\mathcal{A}$. Details are described below.

5.1. Insider Attack

An adversary A, who has undergone the registration process as a legitimate user, can obtain session keys from another user $U_i$’s sessions or impersonate $U_i$. The detailed process is as follows:

Step 1: 

After completing the registration process, A obtains $B_6$ of $M_3$ during their AKA process. Subsequently, A calculates $A_3$ of $S_j$ using their own $HP{W}_a$ and $r_a$.

Step 2: 

In another user $U_i$’s session, A obtains message $M_2$ and uses $B_4$ and the previously acquired $A_3$ to deduce $r_j$.

Step 3: 

From B${}_6$ of $M_3$, A calculates user $U_i$’s $r_i$ and $HP{W}_i$, and from $B_7$, A calculates $r_k$.

Step 4: 

Using the computed values, A can generate the session key $SK=h(r_i\oplus HP{W}_i||r_j$$\left|\right|r_k\left|\right|SI{D}_j)$ for another user $U_i$ and potentially disclose or exploit it.

Therefore, Wu et al.’s scheme cannot resist insider attacks.

5.2. Verification Table Leakage Attack

If $\mathcal{A}$ extracts verification table of cloud server, $\mathcal{A}$ can disclose session key. The following procedures are below:

Step 1: 

$\mathcal{A}$ extracts the verification table to take $\{A_3^{*},QI{D}_j\}$ from $S_j$. And also intercept message $M_2=\{M_1,QID,B_4,B_5,T{S}_2\}$ transmitted in public channel.

Step 2: 

$\mathcal{A}$ calculates $A_3=SI{D}_j\oplus A_3^{*}$, and $r_j=B_4\oplus h(A_3\left|\right|SI{D}_j)$ to extract $A_3$ and $r_j$.

Step 3: 

$\mathcal{A}$ takes message $M_3=\{B_6,B_7,B_8,B_9,B_{10},B_{11},T{S}_3\}$.

Step 4: 

$\mathcal{A}$ computes $(r_i\oplus HP{W}_i)=B6\oplus A_3$, and $r_k=h(A_3\left|\right|r_j\left|\right|SI{D}_j)\oplus B_7$. In addition by calculating $SK=h(r_i\oplus HP{W}_i|\left|r_j\right|\left|r_k\right|\left|SI{D}_j\right)$, A can generate a session key to disclose or exploit it.

Therefore, Wu et al.’s scheme cannot resist verification table leakage attacks.

5.3. Privileged Insider Attack

A privileged insider can take important information like $\{I{D}_j,HP{W}_j\}$ from the registration message and values stored in the user’s smart card such as $\{A_1,A_2,I{D}_{cs},Gen\left(\right),Rep\left(\right),\}$. Through support from this privileged insider, a malicious $\mathcal{A}$ can generate a session key through the following:

Step 1: 

$\mathcal{A}$ computes $SI{D}_j=B_2\oplus h(I{D}_{CS}\left|\right|HP{W}_i)$, and $r_i=B_1\oplus h(I{D}_{CS}\left|\right|HP{W}_i\oplus SI{D}_j)$, $(n_i\oplus x)=A_1\oplus h(I{D}_{CS}\left|\right|HP{W}_i)$; therefore, $\mathcal{A}$ can extract parameters $SI{D}_j$, $r_i$, and $(n_i\oplus x)$.

Step 2: 

$\mathcal{A}$ intercepts message $M_4=\{B_9,B_{10},T{S}_4\}$.

Step 3: 

$\mathcal{A}$ calculates $r_j=h(n_i\oplus x\left|\right|SI{D}_j)\oplus B_9$, and $r_k=h(HP{W}_i\left|\right|r_i)\oplus B_{10}$. Hence, $\mathcal{A}$ can compute session key $SK=h(r_i\oplus HP{W}_i|\left|r_j\right|\left|r_k\right|\left|SI{D}_j\right)$ and disclose it.

Thus, Wu et al.’s scheme is insecure against privileged insider attacks.

5.4. Impersonation

When $\mathcal{A}$ obtains the table information $\{k_n,SI{D}_n\}$ of the control center, $\mathcal{A}$ can calculate $S{K}_{nm}=h(SI{D}_m\left|\right|SI{D}_n\left|\right|SI{D}_c\left|\right|A_8)$.

(1)

User impersonation: If the privileged insider described in Section 5.3 generates random number $r_i$ and time stamp $T{S}_1$, $\mathcal{A}$ can forge message $M_1=\{TI{D}_i,A_1,B_1,B_2,B_3,T{S}_1\}$. In addition, by $\mathcal{A}$ to take message $M_4=\{B_9,B_{10},T{S}_4\}$ from an unsecured public channel, $\mathcal{A}$ can generate session key and $rj$. Thus, $\mathcal{A}$ can send message $M_5=\left\{B12\right\}$ impersonates user.

(2)

Cloud server impersonation: According to the previous verification table attack in Section 5.2, $\mathcal{A}$ generates random number $r_j$ and time stamp $T{S}_2$, and $\mathcal{A}$ can send $M_2=\{M_1,QI{D}_j,B_4,B_5,T{S}_2\}$. Second, $\mathcal{A}$ can generate $M_4=\{B_9,B_{10},T{S}_4\}$ after intercept message $M_3=\{B_6,B_7,B_8,B_9,B_{10},B_{11},T{S}_3\}$. Hence $\mathcal{A}$ can impersonate cloud server.

Therefore, Wu et al.’s scheme cannot resist user and cloud impersonation attack.

5.5. Lack of Untraceability

If an attacker A continues to eavesdrop on $M_1=\{TI{D}_i,A_1,B_1,B_2,B_3,T{S}_1\}$ and compares the value of $TI{D}_i$ contained in $M_1$, A can track the user $U_i$. The reason is that the pseudo identity of $U_i$, $TI{D}_i$, is a fixed value, and an attacker can easily obtain it through eavesdropping on the message. Indeed, by verifying whether the value of $TI{D}_i$ matches the values from previous or subsequent communications, A can detect the user. In conclusion, Wu et al.’s scheme lacks anonymity and untraceability.

5.6. Impossibility of Offline Password Update

In the user registration phase in Wu et al.’s scheme, the value of $HP{W}_i$ is created by concatenating the user’s password $P{W}_i$ with their biometric information ${\sigma }_i$. Additionally, this $HP{W}_i$ is transmitted to the control server $CS$ and undergoes the operation $A_1=h(I{D}_{CS}\left|\right|HP{W}_i)\oplus (n_i\oplus x)$, and stored in the $CS$’s database as $A_1$. However, this design leads to a problem where users must communicate with the $CS$ to update the $A_1$ value stored in the $CS$ if they wish to change their password, because $CS$ cannot create the $HP{W}_i$ on its own. Consequently, Wu et al.’s scheme does not support offline password updates.

6. Proposed Protocol

6.1. Registration Phase

Before generating a session key for communication, the user and the cloud server must go through the registration process with the control server via a secure channel. In this phase, users register the information, such as identity, password, and biometrics, with the control server. The detailed process is as follows and illustrated in Figure 4.

Figure 4. User registration phase of proposed scheme.

6.1.1. User Registration Phase

Step 1: 

The $U_i$ enters $I{D}_i$, $P{W}_i$ and imprints $B_i$ on the device. Then, calculates $Gen\left(B_i\right)={\sigma }_i$ and sends $I{D}_i$ to $CS$ as a registration request message through a secure channel.

Step 2: 

$CS$ checks if $U_i$’s identity is new, and generates a random number $n_i$ to calculate $SI{D}_i=h(I{D}_i\oplus x_{cs}$, $k_i=h(SI{D}_i\left|\right|x_{cs}\left|\right|n_i)$. $SI{D}_i^{*}=SI{D}_i\oplus h(x_{cs}\left|\right|n_i)$ and $PI{D}_i=h(SI{D}_i\left|\right|n_i)$. Then, stores $\{PI{D}_i,SI{D}_i^{*},n_i\}$ in its database, and sends $\{PI{D}_i,I{D}_{cs},k_i,SI{D}_i\}$ to $U_i$ through secure channel.

Step 3: 

$U_i$ computes $RP{W}_i=h(I{D}_i\left|\right|P{W}_i\left|\right|{\sigma }_i)$, $A_1=k_i\oplus h(I{D}_i\left|\right|H{P}_i)$, and $A_2=SI{D}_i\oplus h({\sigma }_i\left|\right|P{W}_i)$. Then, store $\{PI{D}_i,I{D}_{CS},RP{W}_i,A_1,A_2,Gen(·),Rep(·),{\tau }_i\}$ in $SC$.

6.1.2. Cloud Server Registration Phase

In this phase, cloud servers register the information with the control server. The detailed process is as follows and illustrated in Figure 5.

Figure 5. Cloud server registration phase of proposed scheme.

Step 1: 

$S_j$ selects $SI{D}_j$ and sends $\left\{I{D}_j\right\}$ as a request message to $CS$ through a secure channel.

Step 2: 

$CS$ checks if $S_j$’s identity is new, and chooses random number $n_j$, computes $k_j=h(I{D}_j\left|\right|n_j\left|\right|x_{cs})$. Then, stores $\{I{D}_j,n_j\}$ in its database. Next, $CS$ sends $k_j$ to $S_j$ through secure channel.

Step 3: 

$S_j$ computes $A_3=k_j\oplus x_j$, and stores $\left\{A_3\right\}$.

6.2. Login and Authentication Phase

In this phase, the control server first verifies the identities of the user and the cloud server. If both are confirmed, a shared session key for subsequent communication is generated. The detailed process is as follows and illustrated in Figure 6.

Figure 6. AKA phase of proposed scheme.

Step 1: 

$U_i$ enters $I{D}_i$, $P{W}_i$, imprints $B_i$, and calculates $Rep(B_i,{\tau }_i)={\sigma }_i$, $RP{W}_i^{\prime }=h(ID-I||P{W}_i\left|\right|{\sigma }_i)$, $k_i=A_1\oplus (I{D}_i\left|\right|P{W}_i)$ and $SI{D}_i=A_q\oplus ({\sigma }_i\left|\right|P{W}_i)$. Then, by confirming $RP{W}_i^{\prime }\stackrel{?}{=}RP{W}_i$, $U_i$ can be verified as a legitimate user. If this is valid, $U_i$ selects a random number $r_i$ and timestamp $T{S}_1$ then calculates $B_1=r_i\oplus h(SI{D}_i\left|\right|I{D}_{CS}\left|\right|k_i)$, $B_2=I{D}_j\oplus h(I{D}_{CS}\left|\right|SI{D}_i\left|\right|r_i)$ and $V_1=h(I{D}_{CS}\left|\right|T{S}_1\left|\right|SI{D}_i\left|\right|k_i\left|\right|r_i)$. Finally, it generates a message $M_1=\{PI{D}_i,B_1,B_2,V_1,T{S}_1\}$ and sends it to $S_j$ via open channel.

Step 2: 

Upon receiving $U_i$’s message, $CS$ confirms timestamp $|T{S}_1-T{S}_c| \leqq \Delta T$. If thetimestamp is valid, $S_j$ chooses a random value $r_j$ and timestamp $T{S}_2$. $S_j$ computes $k_j=A_3\oplus x_j$, $B_3=r_j\oplus h(k_j\left|\right|I{D}_j)$, and $V_2=h(k_j\left|\right|T{S}_2\left|\right|I{D}_j\left|\right|r_j)$. Finally, message $M_2=\{M_1,B_3,V_2,T{S}_2\}$ is sent through an open channel.

Step 3: 

After receiving the $M_2$, $S_j$ confirms timestamp $|T{S}_2-T{S}_c| \leqq \Delta T$. If the timestamp is successfully verified, $CS$ uses $PI{D}_i$ to find $\{SI{D}_i^{*},n_i\}$ and performs the following computations: $SI{D}_i=SI{D}_i^{*}\oplus (x_{CS}\left|\right|n_i)$, $k_i=h(SI{D}_i\left|\right|x_{CS}\left|\right|n_i)$, $r_i=B_1\oplus h(SI{D}_i\left|\right|I{D}_{CS}\left|\right|k_i)$ and $V_1^{\prime }=h(I{D}_{CS}\left|\right|T{S}_1\left|\right|SI{D}_i\left|\right|k_i\left|\right|r_i)$. And by checking $V_1^{\prime }\stackrel{?}{=}{V}_1$, the $CS$ confirms whether $U_i$ is the legitimate user.

Step 4: 

Next, $CS$ calculates $I{D}_j=B_2\oplus h(I{D}_{CS}\left|\right|SI{D}_i\left|\right|r_i)$ and utilizes the value of $I{D}_j$ to find $n_j$. Then, it performs the following computations: $k_j=h(I{D}_j\left|\right|n_j\left|\right|x_{CS})$, $r_j=B_3\oplus h(k_j\left|\right|I{D}_j)$, and $V_2^{\prime }=h(k_j\left|\right|T{S}_2\left|\right|I{D}_j\left|\right|r_j)$. Subsequently, it checks if $V_2^{\prime }\stackrel{?}{=}{V}_2$ is valid.

Step 5: 

CS then selects $r_k$, $T{S}_3$, computes $SI{D}_j=I{D}_j\oplus h(k_j\left|\right|r_k)$, $C_1=h(SI{D}_i\oplus SI{D}_j\oplus I{D}_{CS})$, $PI{D}_i^{*}=PI{D}_i\oplus h(PI{D}_i\left|\right|r_k\left|\right|r_i)$. Next, it updates the old $PI{D}_i$ to $PI{D}_i^{*}$.

Step 6: 

$B_6=(r_k\left|\right|r_i)\oplus h(r_j\left|\right|k_j)$, $B_7=C_1\oplus h(k_j\left|\right|r_k)$, $B_8=(r_j\left|\right|r_k)\oplus h(SI{D}_i\left|\right|I{D}_{CS}\left|\right|r_i)$, $B_9=SI{D}_j\oplus h(SI{D}_i\left|\right|r_k)$, $V_3=h(r_j\left|\right|r_k\left|\right|C_1\left|\right|I{D}_j\left|\right|T{S}_3)$ and $V_4=h(SI{D}_i\left|\right|r_j\left|\right|r_k\left|\right|C_1\left|\right|$$T{S}_3)$. At last, $CS$ generates message $M_3=\{B_6,B_7,B_8,B_9,V_3,V_4,T{S}_3\}$ and sends to $S_j$ through an open channel.

Step 7: 

Upon receiving $M_3$, $S_j$ checks timestamp $|T{S}_3-T{S}_c| \leqq \Delta T$. If the timestamp is valid, $S_j$ calculates following computations: $(r_k\left|\right|r_i)=B6oplush(r_j\left|\right|k_j)$, $C_1=B_7\oplus h(k_j\left|\right|r_k)$, $SK=h\left(C_1\right|\left|r_i\right|\left|r_j\right|\left|r_k\right)$, and $V_3^{\prime }=h(r_j\left|\right|r_k\left|\right|C_1\left|\right|I{D}_j\left|\right|T{S}_3)$. Subsequently, it confirms $V_3^{\prime }\stackrel{?}{=}{V}_3$. If it confirms, $S_j$ generates message $M_4=\{B_8,B_9,V_4,T{S}_4\}$ to $U_i$ via an open channel.

Step 8: 

$U_i$ verifies timestamp $|T{S}_4-T{S}_c| \leqq \Delta T$. If the timestamp is valid, $U_i$ calculates $(r_j\left|\right|r_k)=B_8\oplus h(SI{D}_i\left|\right|I{D}_{CS}\left|\right|r_i)$, $SI{D}_j=B_9\oplus h(SI{D}_i\left|\right|r_k)$, $C_1=h(SI{D}_i\oplus SI{D}_j\oplus I{D}_{CS})$, $SK=h\left(C_1\right|\left|r_i\right|\left|r_j\right|\left|r_k\right)$, and calculates $V_4^{\prime }=h(SI{D}_i\left|\right|r_j\left|\right|r_k\left|\right|C_1\left|\right|T{S}_3)$ to check $B_{11}^{\prime }\stackrel{?}{=}{B}_{11}$. If it confirms, $U_i$ computes $PI{D}_i^{*}=PI{D}_i\oplus h(PI{D}_i\left|\right|r_k\left|\right|r_i)$ and update old $PI{D}_i$ to $PI{D}_i^{*}$.

6.3. Offline Password and Biometric Template Update

In this phase, an authenticated user U can locally change their password and biometrics without a connection to CS. U must perform the login process on the IoT device before updating data offline. A logged-in user can update their password or biometric template. The detailed process is as follows and illustrated in Figure 7.

Figure 7. Offline password and biometric template update of proposed scheme.

Step 1: 

$U_i$ enters $I{D}_i$, $P{W}_i$ and imprint $B_i$ on the device. Compute $Rep(Bi{o}_i,{\tau }_i)={\sigma }_i$ and check $RP{W}_i^{\prime }=h(I{D}_i\left|\right|P{W}_i\left|\right|{\sigma }_i)$ for login phase and confirm user.

Step 2: 

Then, ask $U_i$ to change password and biometric data. $U_i$ select new password $P{W}_i^{new}$, and compute $RP{W}_i^{new}=h(I{D}_i\left|\right|P{W}_i^{new}\left|\right|{\sigma }_i)$, $A_1^{new}=k_i\oplus h(I{D}_i\left|\right|P{W}_i^{new})$ and $A_2^{new}=SI{D}_i\oplus h({\oplus }_i\left|\right|P{W}_i^{new})$. Subsequently, update $RP{W}_i$, $A_1$, and $A_2$ with new data to change the password.

Step 3: 

Compute $Rep(B{i}_i,{\tau }_i)={\sigma }_i^{new}$, $RP{W}_i^{new}=h\left(ID\right||P{W}_i\left|\right|{\sigma }_i^{new})$ and $A_2^{new}=SI{D}_i\oplus h({\sigma }_i^{new}\left|\right|P{W}_i)$. Subsequently, update $RP{W}_i^{new}$ and $A_2^{new}$ with new data to change the biometric template.

7. Security Analysis

7.1. ROR Model

In this section, we conduct an analysis of session key security using the ROR model [34]. To apply the proposed protocol to the ROR model, we first define participants, especially $U_{US}^{i_1}$, $U_{SJ}^{i_2}$, and $U_{CS}^{i_3}$ as user, cloud server, and control server, respectively. Note that $i_k$$(k=1,2,3)$ is an instance for each participant. In ROR model, the adversary can eavesdrop, delete, intercept, and send messages through the public channel. Moreover, the adversary can extract secret parameters from the user $U_{US}^{i_1}$. These actions of the adversary can be defined as queries in the ROR model.

• $EX(U_{US}^{i_1},U_{SJ}^{i_2},U_{CS}^{i_3})$: This query is an eavesdropping attack that the adversary can obtain messages transmitted via a public channel. Thus, this query can be defined as a passive attack.
• $CoUD\left(U_{US}^{i_1}\right)$: In this query, the adversary extracts secret parameters using the smart device of $U_{US}^{i_1}$. Therefore, we can define the query $CoUD$ is an active attack.
• $Sn\left(U_p^i\right)$: The adversary sends messages to legal participants through open channels. This query is an active attack.
• $Ts\left(U_p^i\right)$: In this query, the adversary flips an unbiased coin. When the result of the flipped coin is 0, the session key is not fresh. When the result of the flipped coin is 1, we can demonstrate that the session key is fresh. Otherwise, the result outputs $NULL$ (⊥).

Theorem 1.

We take a definition of $P_{AD}$, $HA$, $q_{HA}$, and $q_{Sn}$ as the possibility of breaking session key, range space of hash function, number of hash functions, and number of send queries, respectively. Moreover, we define that s and C are the Zipf’s parameters [35]. From that, the adversary tries to reveal the session key of the proposed protocol in polynomial time. Following [36,37,38], the ROR model analysis of the proposed protocol is composed of four games ($GAM{E}_m$, $m=0,1,2,3$) and the winning possibility of the adversary is $P{W}_{GAM{E}_m}$ for each game $GAM{E}_m$.

$$P_{AD}\le \frac{q_{HA}^2}{\left|HA\right|}+2\left\{C{q}_S^{Sn}\right\}$$

(1)

• $GAM{E}_0$: In this game, the adversary has no knowledge about the session key. Thus, the adversary picks a random bit B.

  $$P_{AD}=|2P{W}_{GAM{E}_0}-1|$$

  (2)
• $GAM{E}_1$: The adversary conducts $EX$ query to collect the messages transmitted via public channels. Thus, the adversary obtains $\{PI{D}_i,B_1,B_2,V_1,T{S}_1\}$, $\{M_1,B_3,V_2\}$, $\{B_6,B_7,B_8,V_3,V_4,T{S}_3\}$, and $\{B_8,V_5,T{S}_4\}$. After that, the adversary flips an unbiased coin to execute the $Ts$ query. However, the adversary has no knowledge of the session key $SK=h(C_1\Vert r_i\Vert r_j\Vert r_k)$ because it is composed of random numbers $r_i$, $r_j$ and $r_k$ and masked in the hash functions. For these reasons, the adversary can obtain the following:

  $$P{W}_{GAM{E}_1}=P{W}_{GAM{E}_1}$$

  (3)
• $GAM{E}_2$: The adversary conducts $HA$ and $Sn$ queries to reveal session key in this game. However, the session key is composed of fresh random numbers and a cryptographic hash function. Therefore, the adversary cannot make hash collisions to calculate the session key. Applying the birthday paradox [39], we obtain the following:

  $$|P{W}_{GAM{E}_2}-P{W}_{GAM{E}_1}|\le \frac{q_{HA}^2}{\left|HA\right|}$$

  (4)
• $GAM{E}_3$: In the last game, the adversary conducts $CoUD$ query to obtain the secret parameters $\{PI{D}_i,I{D}_{CS},RP{W}_i,A_1,A_2,Gen(.),Rep(.),{\tau }_i\}$. However, the adversary cannot decrypt the secret parameters because these parameters are encrypted using the identity $I{D}_i$, password $P{W}_i$, and biometrics $B_i$. Since simultaneously guessing $I{D}_i$, $P{W}_i$, and $B_i$ is a computationally infeasible task, the adversary has no advantage in this game. We obtain the following using Zipf’s law [35].

  $$|P{W}_{GAM{E}_3}-P{W}_{GAM{E}_2}|\le C{q}_S^{Sn}$$

  (5)
  When all the games end, the adversary becomes a random bit B.

  $$P{W}_{GAM{E}_3}=\frac{1}{2}$$

  (6)
  We can calculate (7) utilizing (2) and (3).

  $$\frac{1}{2}{P}_{AD}=|P{W}_{GAM{E}_0}-\frac{1}{2}|=|P{W}_{GAM{E}_3}-\frac{1}{2}|$$

  (7)
  Then, we use (6) and (7) to obtain (8).

  $$\frac{1}{2}{P}_{AD}=|P{W}_{GAM{E}_1}-P{W}_{GAM{E}_3}|$$

  (8)
  We calculate (9) utilizing the triangular inequality.

  $$\begin{gathered} \frac{1}{2}{P}_{AD}=|P{W}_{GAM{E}_1}-P{W}_{GAM{E}_3}| \\ \le |P{W}_{GAM{E}_1}-P{W}_{GAM{E}_2}| \\ +|P{W}_{GAM{E}_2}-P{W}_{GAM{E}_3}| \end{gathered}$$

  $$\le \frac{q_{HA}^2}{2\left|HA\right|}+C{q}_S^{Sn}$$

  (9)
  We calculate (10) multiplying (9) by 2.

  $$P_{AD}\le \frac{q_{HA}^2}{\left|HA\right|}+2\left\{C{q}_S^{Sn}\right\}$$

  (10)
  We obtain the in Equation (10) which is the same as (1). It means that the adversary cannot distinguish random nonce and the session key using various security attacks, such as $EX$, $CoUD$, and $Sn$. Thus, we can prove the session key security of the proposed protocol.

7.2. BAN Logic

We analyze the mutual authentication of the proposed protocol using BAN logic [40]. Following [41,42,43], we define basic notations and descriptions of BAN logic in Table 2.

Table 2. Basic notations and decriptions.

Notation	Description
$A_i,A_j$	Principals
$SK$	Session key
$T_1,T_2$	Statements
$A_i| \equiv T_1$	$A_i$ believes $T_1$
$A_1| \sim T_1$	$A_i$ once said $T_1$
$A_i ⤇ T_1$	$A_i$ controls $T_1$
$A_i ⊲ T_1$	$A_i$ receives $T_1$
$\#T_1$	$T_1$ is fresh
${\left\{T_1\right\}}_S$	$T_1$ is encrypted with S
$A_i\stackrel{SH}{\leftrightarrow }{A}_j$	$A_i$ and $A_j$ have a shared key $SH$

7.2.1. Rules

In BAN logic, there are five rules, such as “Message meaning rule (MMR)”, “Nonce verification rule (NVR)”, “Jurisdiction rule (JR)”, “Belief rule (BR)”, and “Freshness rule (FR)”.

1. 

Message meaning rule (MMR):

$$\frac{A_i| \equiv A_i\stackrel{SH}{\leftrightarrow }{A}_j,A_i⊲{\left\{T_1\right\}}_{SH}}{A_i| \equiv A_j|\sim T_1}$$

2. 

Nonce verification rule (NVR):

$$\frac{A_i| \equiv \#\left(T_1\right),A_i|\equiv A_j|\sim T_1}{A_i| \equiv A_j|\equiv T_1}$$

3. 

Jurisdiction rule (JR):

$$\frac{A_i| \equiv A_j⤇T_1,A_i| \equiv A_j|\equiv T_1}{A_i| \equiv T_1}$$

4. 

Belief rule (BR):

$$\frac{A_i| \equiv (T_1,T_2)}{A_i| \equiv T_1}$$

5. 

Freshness rule (FR):

$$\frac{A_i| \equiv \#\left(T_1\right)}{A_i| \equiv \#(T_1,T_2)}$$

7.2.2. Goals

In our protocol, each participant authenticate the communication partner by establishing session key $SK$. Thus, goals of the proposed protocol can be shown as follows:

Goal 1: 

$UI| \equiv UI\stackrel{SK}{\leftrightarrow }CS$

Goal 2: 

$UI| \equiv CS| \equiv UI\stackrel{SK}{\leftrightarrow }CS$

Goal 3: 

$CS| \equiv UI\stackrel{SK}{\leftrightarrow }CS$

Goal 4: 

$CS| \equiv UI| \equiv CS\stackrel{SK}{\leftrightarrow }UI$

Goal 5: 

$CS| \equiv CS\stackrel{SK}{\leftrightarrow }SJ$

Goal 6: 

$CS| \equiv SJ| \equiv CS\stackrel{SK}{\leftrightarrow }SJ$

Goal 7: 

$SJ| \equiv CS\stackrel{SK}{\leftrightarrow }SJ$

Goal 8: 

$SJ| \equiv CS| \equiv SJ\stackrel{SK}{\leftrightarrow }CS$

7.2.3. Idealized Forms

In the proposed authentication phase, four messages are transmitted via open channels ($\{PI{D}_i,B_1,B_2,V_1,T{S}_1\}$, $\{M_1,B_3,V_2\}$, $\{B_6,B_7,B_8,V_3,V_4,T{S}_3\}$, $\{B_8,V_5,T{S}_4\}$). To analyze these messages, we convert them into idealized forms.

• $MS{G}_1:UI\to SJ:{\{r_i,I{D}_j,T{S}_1\}}_{k_i}$
• $MS{G}_2:SJ\to CS:\{{\{r_i,I{D}_j\}}_{k_i},{\{r_j,T{S}_2\}}_{k_j}\}$
• $MS{G}_3:CS\to SJ:\{{\{r_k,r_i,C_1,T{S}_3\}}_{k_j},{\{r_j,r_k,T{S}_3\}}_{r_i}\}$
• $MS{G}_4:SJ\to UI:{\{r_j,r_k,T{S}_4\}}_{r_i}$

7.2.4. Assumptions

In the proposed protocol, participants agree on the freshness of the random number and secret parameters. Therefore, we show the assumptions to analyze the proposed authentication phase.

$S_1$:

$CS| \equiv \#(T{S}_2)$

$S_2$:

$SJ| \equiv \#(T{S}_3)$

$S_3$:

$UI| \equiv \#(T{S}_4)$

$S_4$:

$CS| \equiv \#(r_i)$

$S_5$:

$CS| \equiv UI\stackrel{k_i}{\leftrightarrow }CS$

$S_6$:

$CS| \equiv SJ\stackrel{k_j}{\leftrightarrow }CS$

$S_7$:

$SJ| \equiv CS\stackrel{k_j}{\leftrightarrow }SJ$

$S_8$:

$UI| \equiv CS\stackrel{r_j}{\leftrightarrow }UI$

7.2.5. BAN Logic Proof

Step 1: 

We obtain $P_1$ using $MS{G}_2$.

$$P_1:CS⊲\{{\{r_i,I{D}_j\}}_{k_i},{\{r_j,T{S}_2\}}_{k_j}\}$$

Step 2: 

We use $S_5$, $S_6$, and MMR to obtain $P_2$ and $P_3$ from $P_1$.

$$\begin{gathered} P_2:CS|\equiv UI|\sim (r_i,I{D}_j) \\ {P}_3:CS|\equiv SJ|\sim (r_j,T{S}_2) \end{gathered}$$

Step 3: 

From $P_2$ and $P_3$, we use $S_1$, $S_4$, and FR to obtain $P_4$ and $P_5$.

$$\begin{gathered} P_4:CS|\equiv \#(r_i,I{D}_j) \\ {P}_5:CS|\equiv \#(r_j,T{S}_2) \end{gathered}$$

Step 4: 

From $P_2$, $P_3$, $P_4$ and $P_5$, we use NVR to obtain $P_6$ and $P_7$.

$$\begin{gathered} P_6:CS|\equiv UI|\equiv (r_i,I{D}_j) \\ {P}_7:CS|\equiv SJ|\equiv (r_j,T{S}_2) \end{gathered}$$

Step 5: 

We obtain $P_8$ using $MS{G}_3$.

$$P_8:SJ⊲\{{\{r_k,r_i,C_1,T{S}_3\}}_{k_j},{\{r_j,r_k,T{S}_3\}}_{r_i}\}$$

Step 6: 

We use $S_7$ and MMR to obtain $P_9$ from $P_8$.

$$P_9:SJ|\equiv CS|\sim (r_k,r_i,C_1,T{S}_3)$$

Step 7: 

From $P_9$, we use $S_2$ and FR to obtain $P_{10}$.

$$P_{10}:SJ|\equiv \#(r_k,r_i,C_1,T{S}_3)$$

Step 8: 

From $P_9$ and $P_{10}$, we use NVR to obtain $P_{11}$.

$$P_{11}:SJ|\equiv CS|\equiv (r_k,r_i,C_1,T{S}_3)$$

Step 9: 

Using $P_7$ and $P_{11}$, $CS$ and $SJ$ computes the session key $SK=h(C_1\Vert r_i\Vert r_j\Vert r_k)$.

Thus, we obtain the following:

$$\begin{gathered} P_{12}:SJ|\equiv CS|\equiv SJ\stackrel{SK}{\leftrightarrow }CS\hspace{1em}\mathbf{(}\mathbf{Goal} \mathbf{8}\mathbf{)} \\ {P}_{13}:CS|\equiv SJ|\equiv CS\stackrel{SK}{\leftrightarrow }SJ\hspace{1em}\mathbf{(}\mathbf{Goal} \mathbf{6}\mathbf{)} \end{gathered}$$

Step 10: 

Using JR into $P_{12}$ and $P_{13}$, We obtain the following goals:

$$\begin{gathered} P_{14}:SJ|\equiv SJ\stackrel{SK}{\leftrightarrow }CS\hspace{1em}\mathbf{(}\mathbf{Goal} \mathbf{7}\mathbf{)} \\ {P}_{15}:CS|\equiv CS\stackrel{SK}{\leftrightarrow }SJ\hspace{1em}\mathbf{(}\mathbf{Goal} \mathbf{5}\mathbf{)} \end{gathered}$$

Step 11: 

We obtain $P_{16}$ using $MS{G}_4$.

$$P_{16}:UI⊲{\{r_j,r_k,T{S}_4\}}_{r_i}$$

Step 12: 

We use $S_8$ and MMR to obtain $P_{17}$ from $P_{16}$.

$$P_{17}:UI|\equiv CS|\sim (r_j,r_k,T{S}_4)$$

Step 13: 

From $P_{17}$, we use $S_3$ and FR to obtain $P_{18}$.

$$P_{18}:UI\#(r_j,r_k,T{S}_4)$$

Step 14: 

From $P_{17}$ and $P_{18}$, we use NVR to obtain $P_{19}$.

$$P_{19}:UI|\equiv CS|\equiv (r_j,r_k,T{S}_4)$$

Step 15: 

Using $P_6$ and $P_{19}$, $UI$ and $SJ$ agrees the session key $SK=h(C_1\Vert r_i\Vert r_j\Vert r_k)$.

Thus, we obtain the following:

$$\begin{gathered} P_{20}:UI|\equiv CS|\equiv UI\stackrel{SK}{\leftrightarrow }CS\hspace{1em}\mathbf{(}\mathbf{Goal} \mathbf{2}\mathbf{)} \\ {P}_{21}:CS|\equiv UI|\equiv CS\stackrel{SK}{\leftrightarrow }UI\hspace{1em}\mathbf{(}\mathbf{Goal} \mathbf{4}\mathbf{)} \end{gathered}$$

Step 16: 

Using JR into $P_{20}$ and $P_{21}$, We obtain the following goals:

$$\begin{gathered} P_{22}:UI|\equiv CS\stackrel{SK}{\leftrightarrow }UI\hspace{1em}\mathbf{(}\mathbf{Goal} \mathbf{1}\mathbf{)} \\ {P}_{23}:CS|\equiv UI\stackrel{SK}{\leftrightarrow }CS\hspace{1em}\mathbf{(}\mathbf{Goal} \mathbf{3}\mathbf{)} \end{gathered}$$

7.3. Informal Security Analysis

7.3.1. Insider Attack

Malicious actor A, who has gone through the registration phase as a legitimate user, can attempt an insider attack using the acquired information. However, the attacker is unable to know the random values $(ri,rj,rk)$ and $k_j$. As a result, the attacker cannot calculate $C_1$, rendering the attack impossible.

7.3.2. Impersonation Attack

(1)

User impersonation: Adversary A needs to create a valid message $M_1=\{PI{D}_i,B_1,B_2,$$V_1,T{S}_1\}$ to impersonate the legitimate user $U_i$. While A might obtain $PI{D}_i$ from the user’s device, it is impossible for A to access the necessary $k_i$ and $SI{D}_i$ to calculate $B_1,B_2,V_1,T{S}_1$ needed to create the message. Therefore, A cannot generate the $M_1$ message on behalf of the user $U_i$ and transmit it to the cloud server and control server. Thus, the proposed scheme is secure against user impersonation attacks.

(2)

Cloud server impersonation: To execute this attack, A needs to send the message $M_2=\{M_1,B_3,V_2,T{S}_2\}$ to the control server on behalf of the cloud server $S_j$. Even if A intercepts the transmission of $M_1$ over an open channel, they cannot generate the necessary $B_3,V_2$ for the message until they know $k_j$. Therefore, the proposed scheme is secure against cloud server impersonation attacks.

7.3.3. Reply and MITM Attacks

All users, the cloud server, and the control server attempt to validate the received messages through $V_1^{\prime },V_2^{\prime },V_3^{\prime },V_4^{\prime }$. Also, the sent messages are masked with different random values for each session, ensuring freshness. Therefore, the proposed scheme is secure against reply attacks and MITM attacks.

7.3.4. Privileged Insider Attack

In this attack scenario, external entity A is considered a privileged insider, implying that A possesses the user’s registration request message $I{D}_i$ and confidential values such as $\{A_1,A_2,I{D}_{CS},Gen(·),Rep(·),{\tau }_i\}$ However, without the precise biometric information, ID, or PW values of the user, calculating $k_i=A_1\oplus (I{D}_i\left|\right|P{W}_i)$ or $SI{D}_i=A_2\oplus ({\sigma }_i\left|\right|P{W}_i)$ is not possible. As a result, the proposed scheme is secure against privileged insider attacks.

7.3.5. Ephemeral Security Leakage Attack

To prevent adversary A from carrying out valid attacks, such as obtaining the session key through this attack scenario, it is essential to ensure that the session key is preserved even if the random values used in the session are exposed. Therefore, assuming A knows the values of $r_i,r_j,r_k$, it is postulated here that even with this knowledge, A cannot calculate $SK$ without knowing $SI{D}_i,SI{D}_j$. Additionally, valid attacks like impersonating the user or cloud server using random values are not possible. Therefore, the proposed scheme is secure against ESL attacks.

7.3.6. Stolen Verifier Attack

We can assume that a malicious A, upon obtaining $\left\{A_3\right\}$ from the cloud server’s database, attempts to calculate the session key $SK=h\left(C_1\right|\left|r_i\right|\left|r_j\right|\left|r_k\right)$ or impersonate the cloud server. However, without the cloud server’s secret key $x_j$, A cannot deduce the value of $k_j$ from the stored $A_3$, nor can A determine the randomly generated values $r_i,r_j$, or $r_k$. Therefore, A is unable to compute the session key or impersonate the cloud server. Consequently, the proposed scheme is secure against verification table leakage attacks.

7.3.7. DoS Attack

The adversary A may intentionally attempt to send the message $M_1=\{PI{D}_i,B_1,B_2,V_1,$$T{S}_1\}$ repeatedly. However, to generate message $M_1$, A must go through the login process and pass the verification $RP{W}_i^{\prime }\stackrel{?}{=}RP{W}_i$. However, to create a valid $RP{W}_i^{\prime }=h(I{D}_i\left|\right|P{W}_i\left|\right|{\sigma }_i)$, A cannot have the required $I{D}_i,P{W}_i,{\sigma }_i$. Therefore, A cannot create and repeatedly send the message $M_1$, making the proposed scheme secure against DoS attacks.

7.3.8. User Anonymity and Untraceability

Due to the use of $PI{D}_i$ as a pseudo identity, the user’s identity $I{D}_i$ cannot be deduced by an adversary A. Additionally, the $PI{D}_i$ is updated as a new value with random elements for each session, making it impossible for A to compare $PI{D}_i$ values between previous and current sessions to compromise the user’s untraceability. Therefore, the proposed scheme provides user anonymity and untraceability.

7.3.9. Session Key Disclosure Attack

To calculate the session key $SK=h\left(C_1\right|\left|r_i\right|\left|r_j\right|\left|r_k\right)$, adversary A needs to have access to the values of $SI{D}_i$, $SI{D}_j$, $r_i$, $r_j$, and $r_k$. However, for A to discover $SI{D}_i$, $SI{D}_j$, they would need access to the secret key $x_{cs}$ and the random values $n_i$ and $r_k$. Additionally, random values like $r_i$, $r_j$, $r_k$ are used temporarily and exist only within a single session. Therefore, the proposed scheme is secure against session key disclosure attacks.

7.3.10. Perfect Forward Secrecy

If the control server’s secret key $x_{cs}$ is compromised, adversary A may attempt to calculate the session key $SK$ for a previous session. However, since $SK=h\left(C_1\right|\left|r_i\right|\left|r_j\right|\left|r_k\right)$ does not contain $x_{cs}$ and the values of $r_i,r_j,r_k$ are random and cannot be deduced, A cannot perform the calculation. Furthermore, without $n_i$ through $x_{cs}$, A cannot compute $SI{D}_i$. Therefore, the proposed scheme ensures perfect forward secrecy.

7.3.11. Mutual Authentication

In the login and authentication phases, the messages $\{PI{D}_i,B_1,B_2,V_1,T{S}_1\}$ and $\{M_1,B_3,V_2,T{S}_2\}$ included can be used by the control server to verify the legitimacy of the user and the cloud server through the transmitted $V_1$ and $V_2$. Additionally, messages $\{B_6,B_7,B_8,B_9,V_3,V_4,T{S}_3\}$ and $\{B_8,B_9,V_4,T{S}_4\}$ allow both the user and the cloud server to validate each other’s identity using $V_3$ and $V_4$. Due to the unavailability of $SI{D}_i$, $kj$ values, and random values to adversaries through the open channel, the transparency of authentication is ensured. Therefore, the provided scheme offers mutual authentication.

8. Performance Analysis

8.1. Security Features Comparison

We visually compare the safety elements of the proposed scheme and related schemes [11,21,44,45,46,47,48] and record them in Table 3, which includes various types of safety elements such as “insider attack”, “impersonation attack”, “stolen verification attack”, “ESL attack”, “privileged attack”, “perfect forward secrecy”, “reply attack”, “offline password-guessing attack”, “session key disclosure”, “mutual authentication”, “DoS attack”, “user anonymity”, and “untraceability”. Ultimately, the proposed scheme offers more security features compared to Wu et al.’s scheme, and it exhibits fewer features that are either unidentified or not provided, even when compared to the schemes of other related works.

Table 3. Security and functionality features(SFF) comparison.

SFF	[21]	[44]	[45]	[46]	[47]	[48]	[11]	Proposed
SP1	✓	✓	✓	✓	Δ	Δ	×	✓
SP2	×	✓	✓	×	✓	✓	×	✓
SP3	✓	✓	Δ	✓	Δ	Δ	×	✓
SP4	✓	✓	Δ	×	✓	✓	✓	✓
SP5	✓	✓	Δ	×	✓	✓	×	✓
SP6	✓	✓	Δ	✓	✓	Δ	✓	✓
SP7	×	✓	✓	✓	Δ	✓	✓	✓
SP8	✓	✓	×	✓	✓	Δ	✓	✓
SP9	×	✓	✓	×	Δ	Δ	×	✓
SP10	×	✓	✓	✓	Δ	✓	✓	✓
SP11	✓	✓	Δ	✓	Δ	Δ	✓	✓
SP12	×	✓	✓	✓	✓	✓	✓	✓
SP13	✓	✓	Δ	✓	✓	✓	×	✓

Note: SP1: insider attack; SP2: impersonation attack; SP3: stolen verification attack; SP4: ESL attack; SP5: privileged insider attack; SP6: perfect forward secrecy; SP7: reply attack; SP8 offline password-guessing attack SP9: session key disclosure; SP10: mutual authentication; SP11: DoS attack; SP12: user anonymity; SP13: untraceability; ✓: provides safety/functional features; ×: does not provides safety/functional features; Δ: not verified.

8.2. Communication Costs Comparison

We conducted a comparative analysis of communication costs between the related schemes [11,21,44,45,46,47,48] and the proposed scheme. Based on [11], we assume the bit lengths of hash function, timestamp, string, identity, random number, fuzzy extractor, and encryption operation to be 256, 32, 160, 160, 160, 8, and 256 bits, respectively. Therefore, during the MAKA phase of our proposed scheme, the exchanged message $M_1=\{PI{D}_i,B_1,B_2,V_1,T{S}_1\}$ requires (160 + 160 + 160 + 256 + 32 = 768 bits), message $M_2=\{M_1,B_3,V_2,T{S}_2\}$ requires (768 + 160 + 256 + 32 = 1216 bits), message $M_3=\{B_6,B_7,B_8,B_9,V_3,$$V_4,T{S}_3\}$ requires (160 + 160 + 160 + 160 + 256 + 256 + 32 = 1184 bits), and message $M_4=\{B_8,V_5,T{S}_4\}$ requires (160 + 160 + 256 + 32 = 608 bits). Table 4 and Figure 8 present a summary of the communication costs for the associated schemes [11,21,44,45,46,47,48] and the proposed scheme.

Table 4. Comparison analysis of communication costs.

Scheme	Total Cost (bits)	Number of Messages
Martinez-Pelaez et al. [21]	4608 bits	6
Wu et al. (2020) [44]	4416 bits	5
Kang et al. [45]	4320 bits	4
Huang et al. [46]	3232 bits	4
Alam-Kumar [47]	2912 bits	4
Wu et al. (2023) [48]	3360 bits	4
Wu el al. [11]	4001 bits	5
Proposed	3776 bits	4

Figure 8. Communication costs comparison [7,11,17,21,40,41,42,43,44,45,46,47,48].

8.3. Computation Costs Comparison

We conducted a comparative analysis of computation costs for the AKA phase of the proposed scheme and related schemes [11,21,44,45,46,47,48]. Based on [49], we designed the environment for computing costs. The experimental environment and the performance of operation costs, including the minimum, maximum, and average values, are summarized in Table 5. We represent hash function as $T_h$ and encryption/decryption operations of AES-256 as $T_e$. Using these values, we conducted a comparison of computation costs as shown in Table 6 and Figure 9.

Table 5. Hardware software enviroment and operation costs.

Hardware/Software	Operation	Max	Min	Average
Raspberry PI 4B with Linux Ubuntu 18.04.4 LTS with 64-bits, 8 GB, and MIRACL library	Hash function $T_h$	0.142 ms	0.022 ms	0.051 ms
	AES-256 $T_e$	0.021 ms	0.011 ms	0.012 ms

Table 6. Comparison analysis of user side computation costs.

Protocol	User Side	Max	Min	Average
[21]	$7T_h+3T_e$	≈1.057 ms	≈0.187 ms	≈0.393 ms
[44]	$12T_h$	≈1.704 ms	≈0.264 ms	≈0.612 ms
[45]	$8T_h$	≈1.136 ms	≈0.176 ms	≈0.408 ms
[46]	$8T_h$	≈1.136 ms	≈0.176 ms	≈0.408 ms
[47]	$8T_h$	≈1.136 ms	≈0.176 ms	≈0.408 ms
[48]	$10T_h$	≈1.42 ms	≈0.22 ms	≈0.51 ms
[11]	$10T_h$	≈1.42 ms	≈0.22 ms	≈0.51 ms
Proposed	$10T_h$	≈1.42 ms	≈0.22 ms	≈0.51 ms

Figure 9. Computation costs comparison on user side devices [7,11,17,21,40,41,42,43,44,45,46,47,48].

We can observe that the computational costs for users using the proposed scheme and users using Wu et al.’s scheme are the same. Next, we calculated the computational costs of the cloud server and control server for the proposed scheme and related schemes based on the environments provided in [49] as well. Table 7 represents the calculated computational costs for the proposed scheme and related schemes.

Table 7. Comparison analysis of cloud server side control server side computation costs.

Scheme	Cloud Server	Control Server	Total Average (ms)
[21]	$5T_h+3T_e$	$21T_h+2T_e$	≈1.386 ms
[44]	$8T_h$	$19T_h$	≈1.377 ms
[45]	$4T_h$	$11T_h$	≈0.765 ms
[46]	$4T_h$	$10T_h$	≈0.714 ms
[47]	$3T_h$	$6T_h$	≈0.459 ms
[48]	$5T_h$	$12T_h$	≈0.867 ms
[11]	$5T_h$	$13T_h$	≈0.918 ms
Proposed	$6T_h$	$16T_h$	≈1.122 ms

When comprehensively examining the results of the comparison with related schemes, we can elaborate as follows. Our proposed scheme offers more security elements compared to other schemes and is secure against various attacks such as insider attacks, impersonation attacks, stolen verification attacks, ESL attacks, privileged insider attacks, reply attacks, and offline password-guessing attacks. Simultaneously, it maintains reasonable user-side computation cost and communication cost suitable for the CloudIoT environment. However, it is noteworthy that to provide such robust security, additional computation operations on the server side have been introduced.

9. Conclusions

This study analyzed the key agreement protocol between cloud-enabled IoT devices and cloud servers as proposed by Wu et al. The scheme proposed by Wu et al. was found to be vulnerable to insider, privileged insiders, impersonation, and verification table leakage attacks and lacks user untraceability. In addition, it is inconvenient for users to update their passwords offline. To overcome these vulnerabilities and inconveniences, this study proposed a provably secure lightweight MAKA protocol for the cloud-based IoT environments.

The proposed protocol ensures safety against various attacks by preventing the exposure of critical parameters using user biometric information, and the cloud server’s secret key. Furthermore, user untraceability was ensured by updating the user’s pseudonym in every session and convenience was enhanced by adding an offline user password change and biometric template update phase. The safety of mutual authentication and the resulting session key was verified using the RoR model and BAN logic. Moreover, informal analysis was conducted to verify safety against attacks such as insider attacks, impersonation attacks, privileged attacks, ESL attacks, stolen verifier attacks and DoS attacks, while confirming security features such as user anonymity, untraceability, and perfect forward secrecy. The security features, communication costs, and computation costs of the proposed scheme were compared. This comparison demonstrated that the proposed scheme is rational in terms of communication and computation amounts in the cloud-based IoT environments, while being verified for safety.

In conclusion, the proposed scheme demonstrated robust safety and the ability to provide users with real-time services securely. Future research will focus on integrating the proposed scheme into real-world environments and various industrial settings where cloud-based IoT is applied.