Enhancing the Security: A Lightweight Authentication and Key Agreement Protocol for Smart Medical Services in the IoHT

Abstract

The Internet of Things (IoT) has witnessed significant growth with advancements in Internet and wireless technologies. In the medical field, the Internet of Health Things (IoHT) has emerged as an extension of the IoT, enabling the exchange of remote data and real-time monitoring of patients’ health conditions. Through the IoHT, doctors can promptly provide diagnoses and treatment for patients. As patient data are transmitted over public channels, security issues may arise, necessitating security mechanisms. Recently, Amintoosi et al. proposed an authentication protocol for smart medical services in the IoHT. However, their protocol exhibited security weaknesses, including vulnerabilities to privileged insider attacks. To address the security concerns, we propose an enhanced authentication and key agreement protocol. The security of our protocol is rigorously analyzed using the Real-Or-Random model, informal security analysis, and the AVISPA tool. Finally, the results of our analysis demonstrate that our proposed protocol ensures sufficient security while maintaining a performance level similar to existing protocols.

1. Introduction

The Internet of Things (IoT) [1,2,3] is a technology that enables the collection of real-time data and the connection of devices, thus serving as an infrastructure in people’s lives. With the advancements in the Internet, mobile communication, and wireless technology, the IoT can be applied to various environments, including smart home [4], smart grid [5], Internet of Vehicles [6,7], and artificial intelligence [8,9]. These environments take advantage of the information-gathering features of the IoT to solve problems existing in real life, so as to bring more benefits and convenience to people’s lives.

The Internet Health of Things (IoHT) [10,11,12] is an extension of the IoT specifically focused on healthcare. It combines modern communication and medical information technology to create a new mode of health management. The IoHT enables the real-time monitoring of patients’ health data, reducing the repetitive workload for medical staff. Simultaneously, it allows medical professionals to provide timely diagnosis and treatment based on the collected data, as well as deliver preventive or proactive healthcare services at a lower cost. The architecture of the IoHT, as illustrated in Figure 1, includes three main entities: users (doctors/nurses), gateway, and sensor nodes. Sensor nodes are distributed among patients and are responsible for collecting various health data, such as electrocardiogram readings, body temperature measurements, and blood oxygen saturation levels. The gateway serves as a semi-trusted entity that facilitates the real-time transmission of the collected data between the sensor nodes and the users. Users are medical staff (doctors/nurses) who have the ability to access patients’ health data, and use the collected data to analyze the condition and provide appropriate diagnosis and treatment plans for patients.

The security of medical data in IoHT is of utmost importance due to the sensitivity of the information involved. If patient health data and diagnostic reports are stolen by attackers through public channels, it can lead to privacy breaches and potential security attacks such as impersonation [13,14], replay [15,16], and man-in-the-middle (MITM) [17,18] attacks. To address these security concerns, authentication and key agreement (AKA) techniques can be employed to achieve mutual authentication [19,20] between communication entities and establish session keys, ensuring secure communication in IoHT. According to Diffie et al.’s study [21], AKA protocols should follow some general principles when being designed. These principles include the ideas that authentication and key exchange need to be linked together, asymmetry should be exhibited in the protocol, messages should avoid being used repeatedly to prevent replay attacks, entities should incorporate appropriate random numbers into encryption operations, etc.

In recent years, several AKA protocols have been proposed specifically for healthcare applications based on IoT. Challa et al. [22] put forward a secure AKA protocol for medical wireless sensor networks based on elliptic curve cryptography (ECC) in 2018. Unfortunately, Soni et al. [23] found their protocol violated user anonymity and was subjected to session key disclosure attacks. As a result, Soni et al. proposed an enhanced AKA protocol specifically designed for healthcare systems. Unfortunately, Xu et al. [24] demonstrated that this enhanced protocol violated perfect forward secrecy (PFS) and could not resist offline password guessing (OPG) and sensor node capture (SNC) attacks. Qiu et al. [25] put forward a robust AKA protocol based on a telecare medicine system. However, Shamshad et al. [20] found that this protocol was vulnerable to privileged insider (PI) and OPG attacks. Consequently, Shamshad et al. devised a security-enhanced authentication protocol for healthcare services. Sharma and Kalra [26] presented a secure AKA protocol based on IoHT, demonstrating its resilience against multiple security attacks. Unfortunately, Azrour et al. [27] discovered that this protocol suffered from impersonation and OPG attacks. Similarly, Azrour et al. proposed an enhanced protocol for remote healthcare services based on cloud-based IoT. Aghili et al. [28] developed a lightweight AKA protocol for an e-health system based on IoT. However, Amintoosi et al. [29] demonstrated that this protocol violated PFS and was susceptible to SNC and impersonation attacks.

In 2020, Merabet et al. [30] introduced a novel mutual authentication protocol based on IoHT, ensuring secure communication between machines and the cloud. Kumari et al. [31] proposed an efficient AKA protocol for smart healthcare and cloud environments, utilizing ECC. However, Wu et al. [32] demonstrated that their protocol suffered from several security vulnerabilities, including impersonation, known session specific temporary information (KSSTI), and desynchronization attacks. Subsequently, Wu et al. proposed an alternative AKA protocol for smart healthcare, addressing the identified security issues. Hajian et al. [33] devised an attack-resilient protocol for Medical Internet of Things (MIoT) applications. Unfortunately, Yu et al. [17] found that this protocol was susceptible to MITM, impersonation, and session key disclosure (SKD) attacks. Consequently, Yu et al. proposed an enhanced AKA protocol specifically designed for the MIoT environment, seeking to improve its security. Alladi et al. [34] designed a two-way AKA protocol for the healthcare environment, incorporating physical unclonable functions to enhance data security. Shuai et al. [35] put forward a robust AKA protocol for a private healthcare system, incorporating three factors to strengthen security. However, Xie et al. [36] identified that their protocol violated PFS and was vulnerable to PI attacks. Similarly, Xie et al. proposed a privacy-protected AKA protocol for IoT environments. Agrahari et al. [37] devised an AKA protocol for healthcare monitoring systems, ensuring the security of patient data during transmission. Al-Saggaf et al. [38] proposed a two-factor AKA protocol based on IoHT, utilizing quantum computing for enhanced security.

According to previous research, ensuring the security of medical data and user privacy in the IoHT is crucial. In light of this, Amintoosi et al. [29] proposed an authentication protocol for smart medical services, which not only achieves mutual authentication between communication entities, but also facilitates the establishment of session keys between them to ensure secure communication. However, during our investigation, we identified security vulnerabilities in their protocol. To address these security concerns, we have developed an enhanced AKA protocol specifically tailored for the IoHT environment. Our protocol aims to provide robust security measures to ensure the secure transmission of medical data and protect user privacy. The main contributions of our paper are summarized as follows:

(1)

We conducted a thorough review of Amintoosi et al.’s protocol and identified certain security weaknesses, particularly PI attacks.

(2)

In response to the identified weaknesses, we propose an enhanced AKA protocol for smart medical services in the IoHT. Our protocol utilizes lightweight primitives and facilitates the establishment of session keys between doctors and sensor nodes with the assistance of gateways, ensuring secure communication.

(3)

To validate the security of our proposed protocol, we conducted a rigorous analysis using the Real-Or-Random (ROR) model, informal security analysis, and the automated validation of Internet security protocols and applications (AVISPA) tool.

(4)

Finally, we compare the performance and security of our proposed protocol with existing protocols. The comparison results demonstrate that our proposed protocol offers sufficient security with comparable performance to other protocols in the IoHT environment.

The structure of this paper is organized as follows. In Section 2, we review and analyze Amintoosi et al.’s protocol. We present the specific process and design details of the proposed enhanced security AKA protocol in the IoHT in Section 3. In Section 4, we demonstrate the security of our protocol through the ROR model, informal security analysis, and the AVISPA tool. A comparison of the proposed protocol with existing AKA protocols in the IoHT is involved in Section 5 and the conclusion is made in Section 6.

2. Review and Cryptanalysis of Amintoosi et al.’s Protocol [29]

2.1. Review of Amintoosi et al.’s Protocol [29]

Here, we only review the “registration” and the “login and authentication” phases of Amintoosi et al.’s protocol. Their protocol involves user, medical server, and sensor node. The notations used in this paper are shown in

Table 1. Notations.

Notations	Description
$U_i$	i-th user
$I{D}_i,TI{D}_i$	$U_i$’s identity and pseudo-identity
$P{W}_i$	Password of $U_i$
$MS$	Medical server
$SID$	$MS$’s identity
s	Private key of $MS$
$GWN$	Gateway node
k	$GWN$’s private key
$S_j$	j-th sensor
$ID{S}_j$	$S_j$’s identity
$X_j$	Secret key of $S_j$
$SK$	Session key
$T_i$	Timestamp
$a_i,b_i,c_j,r_i,r_j,r_s$	The random numbers
⊕	Bitwise XOR
$h(.)$	Secure-hash function
$\left|\right|$	Concatenation operation

.

2.1.1. Registration

The registration phase is divided into two phases, which are the user and sensor node registration phases.

User registration phase. The process of user registration is depicted in Figure 2, with the specific steps outlined as follows.

(1)

User $U_i$ chooses $I{D}_i$, $P{W}_i$, and $a_i$, and calculates $U{M}_i$ = $h(I{D}_i\Vert P{W}_i\Vert a_i)$. Next, $U_i$ sends $\{U{M}_i,I{D}_i\}$ to $MS$ via a secure channel.

(2)

On receiving the $\{U{M}_i,I{D}_i\}$, $MS$ firstly searches for the $I{D}_i$ stored in the database. If the $I{D}_i$ exists, the $U_i$ should be asked to send a new $I{D}_i$. Otherwise, $MS$ selects $b_i$ to compute $TI{D}_i=h(b_i\Vert I{D}_i)$, $U{N}_i=h(b_i\Vert I{D}_i\Vert TI{D}_i)$, $U{O}_i=h(SID\Vert s\Vert b_i)$, $U{P}_i=U{O}_i\oplus U{M}_i$, $U{Q}_i=h(U{N}_i\Vert U{O}_i)$, and $i=i+1$. Then, $MS$ stores $\{b_i,U{P}_i,U{Q}_i\}$ in smart card, and stores $\{U{P}_i,U{N}_i,U{Q}_i,I{D}_i\}$ in its database. Finally, $MS$ transmits smart card to $U_i$.

(3)

When $U_i$ receives the smart card, $\left\{a_i\right\}$ is added to it.

Sensor registration phase. Figure 3 depicts the sensor registration process, and the subsequent detailed steps are as follows.

(1)

Sensor $S_j$ selects $ID{S}_j$ and $c_j$ to calculate $S{M}_j$ = $h(ID{S}_j\Vert X_j\Vert c_j)$, and sends $\{S{M}_j,c_j,ID{S}_j\}$ to $MS$ via secure channel.

(2)

When $MS$ receives the $\{S{M}_j,c_j,ID{S}_j\}$, it computes $S{N}_j=h(ID{S}_j\Vert s\Vert c_j)$, and $j=j+1$. Then, $MS$ stores $\{S{M}_j,ID{S}_j,c_j\}$ in database, and transmits $\left\{S{N}_j\right\}$ to $S_j$.

(3)

$S_j$ receives the $\left\{S{N}_j\right\}$, and stores $\{S{N}_j,c_j\}$ in its memory.

2.1.2. Login and Authentication Phase

The login and authentication phase process is illustrated in Figure 4, as shown below in the specific steps.

(1)

First, $U_i$ inputs $I{D}_i^{*}$, $P{W}_i^{*}$, computes $U{M}_i^{*}=h(I{D}_i^{*}\Vert P{W}^{*}\Vert a_i)$, $U{O}_i^{*}=U{P}_i\oplus U{M}_i^{*}$, $TI{D}_i^{*}=h(b_i\Vert I{D}_i^{*})$, $U{N}_i^{*}=h(b_i\Vert I{D}_i^{*}\Vert TI{D}_i^{*})$, $U{Q}_i^{*}=h(U{N}_i^{*}\Vert U{O}_i^{*}\Vert U{M}_i^{*})$ and checks $U{Q}_i^{*}\stackrel{?}{=}U{Q}_i$. If it holds, $U_i$ chooses $r_i$ and $T_1$ to compute $W_1=h(U{N}_i\Vert U{O}_i\Vert T_1)\oplus r_i$, $V_1=h(U{N}_i\Vert U{O}_i\Vert r_i)$. Finally, $U_i$ transmits message $M_1=\{W_1,T_1,b_i,V_1\}$ to $MS$ via public channel.

(2)

After $MS$ receives $M_1$, it verifies freshness of $T_1$ by calculating $|T_1-T_c|\le \Delta T$. Then, $MS$ computes $U{O}_i=h(SID\Vert s\Vert b_i)$, $r_i=h(U{N}_i\Vert U{O}_i\Vert T_1)\oplus W_1$, $V_1^{*}=h(U{N}_i\Vert U{O}_i\Vert r_i)$ and checks $V_1^{*}\stackrel{?}{=}{V}_1$. If the two values do not correspond, the authentication process is suspended. Otherwise, $MS$ selects $r_s$, and calculates $W_2=h(r_i\Vert ID{S}_j\Vert c_j)\oplus r_s,S{N}_j=h(ID{S}_j\Vert s\Vert c_j)$, $V_2=h(S{N}_j\Vert S{M}_j\Vert r_s)$. Finally, $MS$ retrieves $T_2$ and transmits the message $M_2=\{r_i,W_2,V_2,T_2\}$ to $S_j$.

(3)

On $S_j$ receiving the $\{r_i,W_2,V_2,T_2\}$, it first verifies $T_2$. Next, $S_j$ computes $r_s=W_2\oplus h(r_i\Vert ID{S}_j\Vert c_j),S{M}_j^{*}=h(ID{S}_j\Vert X_j\Vert c_j),V_2^{*}=h(S{N}_j\Vert S{M}_j^{*}\Vert r_s)$ and checks $V_2^{*}\stackrel{?}{=}{V}_2$. If the two values are equal, $S_j$ chooses $r_j$, and computes $SK=h(r_s\Vert ID{S}_j\Vert r_j)$, $W_3=h(S{M}_j\Vert c_j\Vert S{N}_j)\oplus r_j$, $V_3=h(SK\Vert S{N}_j\Vert T_3)$. At last, $S_j$ transmits the message $M_3=\{W_3,V_3,T_3\}$ to $MS$.

(4)

$MS$ verifies the $T_3$ after receiving the $M_3$. Next, $MS$ computes $U{M}_i=U{O}_i\oplus U{P}_i$, $r_j=h(S{M}_j\Vert c_j\Vert S{N}_j)\oplus W_3$, $SK=h(r_s\Vert ID{S}_j\Vert r_j)$, $V_3^{*}=h(SK\Vert S{N}_j\Vert T_3)$ and checks $V_3^{*}\stackrel{?}{=}{V}_3$. If the two values are equal, the $MS$ selects a timestamp $T_4$ and computes $W_4=U{M}_i\oplus r_j$, $W_5=U{M}_i\oplus r_s$, $V_4=h(W_4\Vert W_5\Vert U{M}_i\Vert T_4)$. Next, $MS$ transmits message $M_4=\{W_4,W_5,V_4,T_4\}$ to $U_i$.

(5)

$U_i$ verifies the $T_4$ after receiving the $M_4$. If it is fresh, $U_i$ computes $V_4^{*}=h(W_3\Vert W_4\Vert U{M}_i\Vert T_4)$ and checks $V_4^{*}\stackrel{?}{=}{V}_4$. If the two values are equal, $U_i$ computes $r_j=U{M}_i\oplus W_4$, $r_s=U{M}_i\oplus W_5$, and then computes $SK=h(r_s\Vert ID{S}_j\Vert r_j)$.

2.2. Cryptanalysis of Amintoosi et al.’s Protocol

In this section, we point out that Amintoosi et al.’s protocol has certain security weaknesses, particularly PI attacks.

Attacker Model. According to the Dolev-Yao (DY) [39] and Canetti and Krawczyk (CK) [40] models, we define the following capabilities for an attacker ($\mathcal{A}$) to follow.

(1)

$\mathcal{A}$ possesses the capability to intercept, monitor, and manipulate messages that are transmitted through the public channel.

(2)

The medical server may have a malicious insider named $\mathcal{A}$ who can acquire data from the database.

(3)

$\mathcal{A}$ can utilize power analysis to obtain the data in the user’s smart card or smart device.

(4)

$\mathcal{A}$ can obtain temporary information value and long-term key.

2.2.1. Privileged Insider Attacks

Assume $\mathcal{A}$ obtains the data $\{S{M}_j,ID{S}_j,c_j\}$ from $MS$. Through the following steps, $\mathcal{A}$ can compute the $SK$ successfully. The process of the attack method is depicted in Figure 5, showing only the important portion. The parts marked in red indicate the data and messages obtained by $\mathcal{A}$, while the red boxes represent $\mathcal{A}$’s computational steps.

(1)

$\mathcal{A}$ can eavesdrop on the messages $M_2=\{r_i,W_2,V_2,T_2\}$, and $M_3=\{W_3,V_3,T_3\}$ on public channel.

(2)

Next, $\mathcal{A}$ can compute $r_s=W_2\oplus h(r_i\Vert ID{S}_j\Vert c_j)$ and $r_j=h(S{M}_j\Vert c_j\Vert S{N}_j)\oplus W_3$, respectively.

(3)

At last, $\mathcal{A}$ can compute $SK=h(r_s\Vert ID{S}_j\Vert r_j)$.

2.2.2. Incorrectness of $SK$

In the authentication phase of Amintoosi et al.’s protocol [29], $MS$ first transmits the $M_4$ to $U_i$. On receiving the $M_4$, $U_i$ calculates numbers $r_j$ and $r_s$ to establish the $SK$, where $SK=h(r_s\Vert ID{S}_j\Vert r_j)$. The $ID{S}_j$ is stored in the database of $MS$, and the $MS$ does not transmit the value $ID{S}_j$ to $U_i$. Thus, the $U_i$ cannot know the value $ID{S}_j$, and cannot establish the $SK$.

3. The Proposed Protocol

In response to the identified weaknesses of Amintoosi et al.’s protocol, we propose an enhanced AKA protocol in the IoHT (shown in Figure 1). The entities involved in the protocol include $U_i$, $GWN$, and $S_j$. Here, we use $GWN$ to replace the $MS$ in Amintioosi et al.’s protocol, because the functions of the $MS$ and the $GWN$ are the same, and the $GWN$ is commonly used in the IoHT environment. The initialization, registration, and login and authentication phases are included in our proposed protocol.

3.1. Initialization and Registration Phases

3.1.1. Initialization Phase

The smart device, gateway, and sensor nodes need to write basic arithmetic functions, such as $h(.)$, ⊕, and $\left|\right|$. Here, $GWN$ is a semi-trusted entity, which means that it possesses the ability to engage in misconduct, yet lacks the capacity to collaborate with other entities. Moreover, the $GWN$ chooses k as its private key, and is responsible for the pre-deployment of the sensor nodes. The sensor pre-deployment process is shown in Figure 6. The specific steps are described below.

(1)

$S_j$ chooses its $ID{S}_j$ and a random number $c_j$, and sends $\{ID{S}_j,c_j\}$ to $GWN$ via a secure channel.

(2)

When $GWN$ receives the $\{ID{S}_j,c_j\}$, it calculates $S{M}_j=h(ID{S}_j\Vert c_j\Vert k)$, $S{N}_j=h(ID{S}_j\Vert k)\oplus S{M}_j$. Then, $GWN$ stores $\{ID{S}_j,S{N}_j\}$ in its database. Finally, $GWN$ transmits $\left\{S{M}_j\right\}$ to $S_j$.

(3)

On receiving $\left\{S{M}_j\right\}$, $S_j$ computes $S{O}_j=h(ID{S}_j\Vert c_j)\oplus S{M}_j$. Next, $S_j$ stores $\{c_j,S{O}_j$} in its memory.

3.1.2. Doctor Registration Phase

In this phase, doctors need to register with the $GWN$ to become legitimate users $U_i$. The doctor registration process is described in Figure 7, and the specific steps are as follows.

(1)

First, $U_i$ chooses $I{D}_i$, $P{W}_i$, $a_i$, and calculates $TI{D}_i$ = $h(I{D}_i\Vert P{W}_i\Vert a_i)$. Next, $U_i$ transmits $\{TI{D}_i,a_i\}$ to $GWN$ via secure channel.

(2)

When $GWN$ receives the $\{TI{D}_i,a_i\}$, it chooses $b_i$ to compute $U{M}_i=h(TI{D}_i\Vert b_i\Vert a_i)$, $U{N}_i=a_i\oplus h(b_i\Vert k)$. Then $GWN$ stores $\{TI{D}_i,b_i,U{N}_i\}$ in database, and transmits $\left\{U{M}_i\right\}$ to $U_i$.

(3)

On receiving $\left\{U{M}_i\right\}$, $U_i$ calculates $RP{W}_i=h(P{W}_i\Vert a_i)$, $U{O}_i=a_i\oplus h(I{D}_i\Vert RP{W}_i)$, $U{P}_i=h(TI{D}_i\Vert RP{W}_i\Vert a_i)$, $U{Q}_i=U{M}_i\oplus h(a_i\Vert RP{W}_i)$. Finally, $U_i$ stores $\{U{O}_i,U{P}_i,U{Q}_i$} in smart device.

3.2. Login and Authentication Phase

In this section, the $U_i$, $GWN$, and $S_j$ achieve mutual authentication, and the $U_i$ and $S_j$ successfully establish a $SK$ with the assistance of the $GWN$. The login and authentication process is depicted in Figure 8, and the detailed login and authentication steps are as follows.

(1)

First, $U_i$ inputs $I{D}_i$, $P{W}_i$, and calculates $a_i^{*}=U{O}_i\oplus h(I{D}_i^{*}\Vert P{W}_i^{*})$, $TI{D}_i^{*}=h(I{D}_i^{*}\Vert P{W}_i^{*}\Vert a_i^{*})$, $RP{W}_i^{*}=h(P{W}_i^{*}\Vert a_i)$, $U{P}_i^{*}=h(TI{D}_i^{*}\Vert RP{W}_i^{*}\Vert a_i^{*})$. Then, $U_i$ checks $U{P}_i^{*}\stackrel{?}{=}U{P}_i$. If it is not equal, $U_i$ login fails. Otherwise, $U_i$ computes $U{M}_i=U{Q}_i\oplus h(a_i\Vert RP{W}_i)$, and chooses $r_i$ and its $ID{S}_j$. Next, $U_i$ calculates $R_i=h(I{D}_i\Vert a_i\Vert r_i)$, $W_1=R_i\oplus h(a_i\Vert U{M}_i)$, $W_2=ID{S}_j\oplus h(U{M}_i\Vert R_i)$, and retrieves the $T_1$ to compute $V_1=h(TI{D}_i\Vert ID{S}_j\Vert R_i\Vert T_1)$. Finally, $U_i$ sends message $M_1=\{TI{D}_i,W_1,W_2,V_1,T_1\}$ to $GWN$ via public channel.

(2)

Following the receipt of message $M_1$, $GWN$ initially verifies that timestamp $T_1$ is fresh. Next, $GWN$ retrieves $\{b_i,U{N}_i\}$ from the database using $TI{D}_i$ and calculates $a_i=U{N}_i\oplus h(b_i\Vert k)$, $U{M}_i=h(TI{D}_i\Vert k\Vert a_i)$, $R_i=W_1\oplus h(a_i\Vert U{M}_i)$, $ID{S}_j=W_2\oplus h(U{M}_i\Vert R_i)$, $V_1^{*}=h(TI{D}_i\Vert ID{S}_j\Vert R_i\Vert T_1)$ and checks $V_1^{*}\stackrel{?}{=}{V}_1$. If they are equal, $GWN$ retrieves $\left\{S{N}_i\right\}$ according to $ID{S}_j$ and computes $S{M}_j=S{N}_j\oplus h(ID{S}_j\Vert k)$, $W_3=R_i\oplus h(ID{S}_j\Vert S{M}_j)$. At last, $GWN$ retrieves the current timestamp $T_2$ to compute $V_2=h(TI{D}_i\Vert R_i\Vert S{M}_j\Vert T_2)$ and transmits message $M_2=\{TI{D}_i,W_3,V_2,T_2\}$ to $S_j$.

(3)

When $S_j$ receives the $M_2$, it checks freshness of $T_2$ by computing $|T_2-T_c|\le \Delta T$. Then, $S_j$ calculates $S{M}_j=S{O}_j\oplus h(ID{S}_j\Vert c_j)$, $R_i=W_3\oplus h(ID{S}_j\Vert S{M}_j)$, $V_2^{*}=h(TI{D}_i\Vert R_i\Vert S{M}_j\Vert T_2)$ and checks $V_2^{*}\stackrel{?}{=}{V}_2$. If it holds, $S_j$ chooses $r_j$ to calculate $R_j=h(ID{S}_j\Vert c_j\Vert r_j)$, $SK=h(R_i\Vert R_j)$, $W_4=R_j\oplus h(ID{S}_j\Vert S{M}_j)$. Finally, $S_j$ retrieves $T_3$ to compute $V_3=h(R_j\Vert S{M}_j\Vert T_3)$ and transmits message $M_3=\{W_4,V_3,T_3\}$ to $GWN$.

(4)

When $GWN$ receives the $M_3$, it verifies the freshness of $T_3$. Next, $GWN$ computes $R_j=W_4\oplus h(ID{S}_j\Vert S{M}_j)$, $V_3^{*}=h(R_j\Vert S{M}_j\Vert T_3)$ and checks $V_3^{*}\stackrel{?}{=}{V}_3$. If $V_3^{*}=V_3$, $GWN$ computes $W_5=R_j\oplus h(a_i\Vert R_i)$ and retrieves current timestamp $T_4$ to calculate $V_4=h(R_i\Vert U{M}_i\Vert R_j\Vert T_4)$. Finally, $GWN$ sends message $M_4=\{W_5,V_4,T_4\}$ to $U_i$.

(5)

$U_i$ verifies freshness of the $T_4$ after receiving $M_4$. Then, $U_i$ computes $R_j=W_5\oplus h(a_i\Vert R_i)$, $V_4^{*}=h(R_i\Vert U{M}_i\Vert R_j\Vert T_4)$ and checks $V_4^{*}\stackrel{?}{=}{V}_4$. If it holds, $U_i$ computes $SK=h(R_i\Vert R_j)$, which means that the $U_i$ and $S_j$ successfully establish a $SK$ with the assistance of the $GWN$.

4. Security Analysis

4.1. Formal Security Analysis

We show the security of our protocol using the well-known ROR model [41,42,43]. Real attacks are simulated in this model through a series of rounds of games.

4.1.1. Security Model

Three entities are included in our proposed protocol: $U_i$, $GWN$, and $S_j$. We use $I_{U_i}^x$ to represent the x-th user instance, $I_{GWN}^y$ represents the y-th gateway instance, and $I_{S_j}^z$ represents the z-th sensor node instance. Here, we define that $\mathcal{A}$ has certain capabilities in different games, but needs to follow the following queries.

(1)

$Execute\left(\mathcal{E}\right)$: This query means that $\mathcal{A}$ can intercept messages on the public channel, where $\mathcal{E}=\{I_{U_i}^x,I_{GWN}^y,I_{S_j}^z\}$.

(2)

$Send(\mathcal{E},M_i)$: $\mathcal{A}$ is able to acquire the response from $\mathcal{E}$ subsequent to transmitting message $M_i$ to $\mathcal{E}$.

(3)

$Hash\left(string\right)$: $\mathcal{A}$ may enter a $string$ to obtain its hash value by performing this query.

(4)

$Corrupt\left(\mathcal{E}\right)$: This query gives $\mathcal{A}$ access to the long-term key or temporary information of $\mathcal{E}$.

(5)

$Test\left(\mathcal{E}\right)$: The $\mathcal{A}$ would verify the validity of the $SK$ by flipping a coin c. When $c=1$, $\mathcal{A}$ obtains the $SK$. Otherwise, $\mathcal{A}$ obtains the random string.

4.1.2. Security Proof

Theorem 1.

The advantage that $\mathcal{A}$ breaking the proposed protocol ($\mathcal{P}$) in polynomial time ξ is $Ad{v}_{\mathcal{A}}^{\mathcal{P}}\left(\xi \right)\le \frac{q_h^2}{\left|Hash\right|}+2C^{\prime }·q_s^{s^{\prime }}$ under ROR model. Here, $q_h$, $q_s$, $\left|Hash\right|$ denote the hash query, send query, and the space of the hash function, respectively. In addition, $C^{\prime }$ and $s^{\prime }$ are two constants.

Proof 

We define four games $G{M}_0$-$G{M}_3$ to prove the proposed protocol’s security, and these games simulate the real process of $\mathcal{A}$ attacking the protocol. Here, $Suc{c}_A^{G{M}_i}\left(\xi \right)$ indicates that the $\mathcal{A}$ wins the i-th game, and $Ad{v}_{\mathcal{A}}^{\mathcal{P}}$ is defined as the advantage of $\mathcal{A}$ breaking the protocol. The $\mathcal{A}$ simulates detailed queries as shown in

Table 2. Simulation of queries.

Query	Description
$Send(\mathcal{E},M_i)$	For $Send(I_{U_i}^x$, start). Assume $I_{U_i}^x$ is in a normal state and selects $r_i,ID{S}_j$, and $T_1$ to compute $R_i=h(I{D}_i\Vert a_i\Vert r_i)$, $W_1=R_i\oplus h(a_i\Vert U{M}_i)$, $W_2=ID{S}_j\oplus h(U{M}_i\Vert R_i)$, $V_1=h(TI{D}_i\Vert ID{S}_j\Vert R_i\Vert T_1)$. Next, the query returns the $M_1=\{PI{D}_i,W_1,W_2,V_1,T_1\}$.
	On $Send(I_{GWN}^y,(PI{D}_i,W_1,W_2,V_1,T_1))$. Assume that $I_{GWN}^y$ computes $U{M}_i,R_i,ID{S}_j$ and checks $V_1$ in a normal state. Next, $I_{GWN}^y$ calculates $S{M}_j,W_3,V_2$. Then, $I_{GWN}^y$ selects $T_2$. The query is answered by $M_2=\{TI{D}_i,W_3,V_2,T_2\}$.
	For $Send(I_{S_j}^z,(TI{D}_i,W_3,V_2,T_2))$. On receiving the message $\{TI{D}_i,W_3,V_2,T_2\}$, $I_{S_j}^z$ computes $S{M}_j,R_i,$ and checks the $V_2$. Then, $I_{S_j}^z$ calculates $R_j,SK,W_4,V_3$. Next, $I_{S_j}^z$ returns the output $M_3=\{W_4,V_3,T_3\}$.
	For $Send(I_{GWN}^y,(W_4,V_3,T_3))$. Assume that $I_{GWN}^y$ computes $R_j$, and checks $V_3$ in a normal state. If the $V_3$ holds, $I_{GWN}^y$ calculates $W_5,V_4$ and selects $T_4$. Then, the query returns the $M_4=\{W_5,V_4,T_4\}$.
	On $Send(I_{U_i}^x,W_5,V_4,T_4$). Upon receiving the message ($W_5,V_4,T_4$), $I_{U_i}^x$ computes $R_j$ and checks $V_4$. If the $V_4$ is correct, $I_{U_i}^x$ computes $SK$, which means that the $I_{U_i}^x$ accepts and terminates.
$Execute\left(\mathcal{E}\right)$	Continue to use $Send$ queries to simulate the process for $Execute\left(\mathcal{E}\right)$. $(TI{D}_i,W_1,W_2,V_1,T_1)$⟵$Send$($I_{U_i}^x$, start), $(TI{D}_i,W_3,V_2,T_2$) ⟵$Send$($I_{GWN}^y,(TI{D}_i,W_1,W_2,V_1,T_1))$, $(W_4,V_3,T_3)$ ⟵ $Send$($I_{S_j}^z,(TI{D}_i,W_3,V_2,T_2))$, $(W_5,V_4,T_4)$ ⟵ $Send$($I_{GWN}^y,(W_4,V_3,T_3))$. The query returns $(TI{D}_i,W_1,W_2,V_1,T_1)$, ($TI{D}_i,W_3,V_2,T_2$), $(W_4,V_3,T_3)$ and ($W_5,V_4,T_4$).
$Corrupt\left(\mathcal{E}\right)$	If the $I_{U_i}^x$ is accepted, this query outputs $\{U{O}_i,U{P}_i,U{Q}_i\}$ in the smart device.
$Test\left(\mathcal{E}\right)$	Flip the coin c. If the result is 1, the $SK$ will be returned. Otherwise, a random string of the same length as $SK$ will be returned.

. The following are the detailed processes in the proof.

$G{M}_0$: In $G{M}_0$, the $\mathcal{A}$ performs real attacks to break the proposed protocol. The $\mathcal{A}$ starts the game by flipping the c. Hence, we have

$$Ad{v}_{\mathcal{A}}^{\mathcal{P}}\left(\xi \right)=|2Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_0}\left(\xi \right)\right]-1|.$$

(1)

$G{M}_1$: In $G{M}_1$, $\mathcal{A}$ can eavesdrop on the transmitted messages $M_1=\{TI{D}_i,W_1,W_2,V_1,T_1\}$, $M_2=\{TI{D}_i,W_3,V_2,T_2\}$, $M_3=\{W_4,V_3,T_3\}$ and $M_4=\{W_5,V_4,T_4\}$ by executing the $Execute\left(\right)$ query. After $G{M}_1$, $\mathcal{A}$ validates the $SK=h(R_i\Vert R_j)$ through executing the $Test\left(\right)$ query. Since $\mathcal{A}$ cannot obtain the values $R_i$ and $R_j$, $\mathcal{A}$ cannot compute the $SK$. Therefore, the result of $G{M}_1$ is no different from $G{M}_0$.

$$Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_1}\left(\xi \right)\right]=Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_0}\left(\xi \right)\right].$$

(2)

$G{M}_2$: The $Send\left(\right)$ and $Hash\left(\right)$ queries are added to $G{M}_2$. The $\mathcal{A}$ wants to tamper with the eavesdropped messages, but the authentication values $V_1,V_2,V_3,$ and $V_4$ in the message are composed of private values and are protected by hash function. Thus, since $\mathcal{A}$ cannot obtain the private value and cannot crack the hash function, the intercepted message cannot be tampered with. Furthermore, no hash collision occurs because each session’s random numbers are distinct. Hence, in accordance with the birthday paradox, we have

$$|Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_2}\left(\xi \right)\right]-Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_1}\left(\xi \right)\right]|\le \frac{q_h^2}{2\left|Hash\right|}.$$

(3)

$G{M}_3$: In $G{M}_3$, $\mathcal{A}$ obtains the data $\{U{O}_i,U{P}_i,U{Q}_i\}$ in the smart device by executing the Corrupt ($I_{U_i}^x$) query. Then, $\mathcal{A}$ utilizes these data and intercepted messages to attempt to deduce the correct $P{W}_i$. Since $\mathcal{A}$ cannot obtain the values $RP{W}_i$ and $a_i$, $\mathcal{A}$ cannot compute correct $U{P}_i$ and cannot obtain the $P{W}_i$, where $U{P}_i=h(TI{D}_i\Vert RP{W}_i\Vert a_i)$. From Zipf’s law [44], we can obtain

$$|Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_3}\left(\xi \right)\right]-Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_2}\left(\xi \right)\right]|\le C^{\prime }·q_{send}^{s^{\prime }}.$$

(4)

Finally, $\mathcal{A}$ wants to win the game by guessing bit c to obtain the correct $SK$. Thus, we can obtain

$$Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_3}\left(\xi \right)\right]=\frac{1}{2}.$$

(5)

According to $G{M}_0$ to $G{M}_3$, we have

$$\begin{array}{cc}\hfill \frac{Ad{v}_{\mathcal{A}}^{\mathcal{P}}\left(\xi \right)}{2}& =|Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_0}\left(\xi \right)\right]-\frac{1}{2}|\hfill \\ \hfill & =|Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_0}\left(\xi \right)\right]-Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_3}\left(\xi \right)\right]|\hfill \\ \hfill & =|Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_1}\left(\xi \right)\right]-Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_3}\left(\xi \right)\right]|\hfill \\ \hfill & \le \sum _{i=0}^2|Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_{i+1}}\left(\xi \right)\right]-Pr\left[Suc{c}_{\mathcal{A}}^{G{M}_i}\left(\xi \right)\right]|\hfill \\ \hfill & =\frac{q_h^2}{2\left|Hash\right|}+C^{\prime }·q_{send}^{s^{\prime }}.\hfill \end{array}$$

(6)

Thus, we can obtain

$$Ad{v}_{\mathcal{A}}^{\mathcal{P}}\left(\xi \right)\le \frac{q_h^2}{\left|Hash\right|}+2C^{\prime }·q_{send}^{s^{\prime }}.$$

(7)

□

4.2. Informal Security Analysis

4.2.1. Perfect Forward Secrecy (PFS)

We use two methods to show that the proposed protocol ensures PFS.

Method 1: Suppose $\mathcal{A}$ can obtain the k of $GWN$, and attempts to calculate the $SK$. First, $\mathcal{A}$ needs to calculate the value $R_i$, $ID{S}_j$ and $R_j$, where $R_i=W_1\oplus h(a_i\Vert U{M}_i)$ and $R_j=W_4\oplus h(ID{S}_j\Vert S{M}_j)$. Then $\mathcal{A}$ uses these values to calculate the $SK$. Since $\mathcal{A}$ cannot obtain $a_i$, $U{M}_i$ and $S{M}_j$, $\mathcal{A}$ cannot calculate the $SK$.

Method 2: We use Ge et al.’s method [45] to demonstrate that $\mathcal{A}$ cannot calculate the $SK$. The specific proof steps are as follows.

(1)

First, the composition of the session key requires variables $\{R_i,R_j\}$, where $SK=h(R_i\Vert R_j)$. Based on the rules of Ge et al. [45], we add these variables around $SK$ and use arrows to point to $SK$. Then, we proceed step by step to analyze the newly added variables. For example, the composition of $R_i$ requires $\{r_i,I{D}_i,a_i\}$ or $\{a_i,W_1,U{M}_i\}$ or $\{W_3,ID{S}_j,S{M}_j\}$.

(2)

Then, coloring is employed to denote nodes that involve long-term secrets or are transmitted over public channels. These nodes are $k,W_1,W_3,W_4,W_5$, which means that $\mathcal{A}$ can obtain these variables.

(3)

Finally, we remove the incoming edges of all colored nodes, and judge whether the proposed protocol ensures PFS through the remaining nodes. From Figure 9, we can see that the $\mathcal{A}$ does not have the required variables to compute the $SK$.

Thus, our proposed protocol ensures PFS.

4.2.2. Privileged Insider (PI) Attacks

Suppose that $\mathcal{A}$ is an insider in the gateway and has access to data $\{TI{D}_i,b_i,U{N}_i\}$ and $\{ID{S}_j,S{N}_j\}$ in its database. Then, $\mathcal{A}$ attempts to compute the values $R_i$ and $R_j$ using these data, where $R_i=W_1\oplus h(a_i\Vert U{M}_i)$ and $R_j=W_4\oplus h(ID{S}_j\Vert S{M}_j)$. Because $a_i,U{M}_i$ and $S{M}_j$ are confidential to $\mathcal{A}$, the $\mathcal{A}$ cannot compute $R_i$ and $R_j$, and then cannot calculate the $SK$. Therefore, our protocol prevents PI attacks.

4.2.3. Sensor Node Capture (SNC) Attacks

Assume $\mathcal{A}$ can capture the $\{c_j,S{O}_j\}$ in the memory of the $S_j$, and attempt to calculate the values $R_i$ and $R_j$. However, since $\mathcal{A}$ cannot obtain $ID{S}_j$, $S{M}_j$, and $R_j$, $\mathcal{A}$ cannot compute $R_i$ and $R_j$, and thus the $\mathcal{A}$ does not obtain the correct $SK$. So our protocol can withstand SNC attacks.

4.2.4. Offline Password Guessing (OPG) Attacks

Suppose $\mathcal{A}$ obtains the data $\{U{O}_i,U{P}_i,U{Q}_i\}$ from a smart device and tries to enumerate the correct password using a password dictionary. Since the $\mathcal{A}$ cannot obtain the $RP{W}_i$ and $a_i$, and does not calculate the correct value $U{P}_i$, where $U{P}_i=h(TI{D}_i\Vert RP{W}_i\Vert a_i)$, $\mathcal{A}$ cannot obtain the correct $P{W}_i$. Thus, our protocol can prevent OPG attacks.

4.2.5. Session Key Disclosure (SKD) Attacks

$\mathcal{A}$ can only obtain the private values $R_i$ and $R_j$ in order to compute the $SK=\{R_i\Vert R_j\}$. However, $\mathcal{A}$ cannot obtain the $I{D}_i,a_i$ and $r_i$, so $R_i$ cannot be calculated, where $R_i=h(I{D}_i\Vert a_i\Vert r_i)$. Similarly, the $\mathcal{A}$ cannot obtain $ID{S}_j,c_j$ and $r_j$, and cannot calculate $R_j$, where $R_j=h(ID{S}_j\Vert c_j\Vert r_j)$. Thus, the correct $SK$ remains undisclosed to $\mathcal{A}$. The proposed protocol is immune to SKD attacks.

4.2.6. Correctness of $SK$

In our proposed protocol, the entities involved in establishing the session key include $U_i$, $GWN$, and $S_j$. The required values for the $SK$ are $R_i$ and $R_j$, where $SK=h(R_i\Vert R_j)$, $R_i=h(I{D}_i\Vert a_i\Vert r_i)$ and $R_j=h(ID{S}_j\Vert c_j\Vert r_j)$. The $U_i$ transmits the computed $R_i$ to the $GWN$, which securely forwards it to the $S_j$. Upon receiving $R_i$, the $S_j$ independently computes $R_j$ to establish the $SK$. Similarly, the $S_j$ transmits $R_j$ to the $GWN$, which then forwards this value to the $U_i$. When receiving $R_j$, the $U_i$ is able to successfully establish the $SK$. Therefore, our protocol ensures the correctness of $SK$.

4.2.7. Man-In-The-Middle (MITM) Attacks

Assume that $\mathcal{A}$ can intercept messages $M_1,M_2,M_3$ and $M_4$. Here, we take $M_1=\{TI{D}_i,W_1,W_2,V_1,T_1\}$ as an example. The $\mathcal{A}$ attempts to tamper with the authentication value $V_1$, where $V_1=h(TI{D}_i\Vert ID{S}_j\Vert R_i\Vert T_1)$. However, due to the fact that values $ID{S}_j$ and $R_j$ are confidential to the $\mathcal{A}$, $\mathcal{A}$ cannot calculate the $V_1$. Thus, the request message sent by $\mathcal{A}$ cannot be authenticated by the $GWN$. Similarly, $\mathcal{A}$ cannot obtain private values to tamper with messages $M_2,M_3$, and $M_4$. Thus, it is impossible for MITM attacks to break our protocol.

4.2.8. Mutual Authentication

In the proposed protocol, entities verify each other’s legitimacy by the authentication values $\{V_1,V_2,V_3,V_4\}$, where $V_1=h(TI{D}_i\Vert ID{S}_j\Vert R_i\Vert T_1)$, $V_2=h(TI{D}_i\Vert R_i\Vert S{M}_j\Vert T_2)$, $V_3=h(R_j\Vert S{M}_j\Vert T_2)$, and $V_4=h(R_i\Vert U{M}_i\Vert R_j\Vert T_4)$. Here, the $GWN$ is to determine the legitimacy of the $U_i$ by verifying $V_1$. The $S_j$ judges the legitimacy of the $GWN$ by verifying $V_2$. The $GWN$ is used to determine the legitimacy of the $S_j$ by verifying $V_3$. The $U_i$ is to determine the legitimacy of the $GWN$ by verifying $V_4$. Since the message sent by one entity to another entity can be verified, our protocol can achieve mutual authentication.

4.3. AVISPA

The AVISPA [46] is an instrument for formal verification that automatically analyzes the cryptographic protocol’s security. AVISPA is based on the DY model, which allows $\mathcal{A}$ to have attack capabilities during the simulation, and it uses High-Level Protocol Specification Language (HLPSL). In this paper, AVISPA is used to simulate the whole process of the proposed protocol.

We define the role specification for $U_i$, $GWN$ and $S_j$ as shown in Figure 10a–c, respectively. Additionally, the role specifications for the session, goal, and environment are shown in Figure 10d. Here, we take the role of $U_i$ as an example to explain. In the registration and authentication phases, it is essential for the user to recognize the involvement of three agents: “user agent (UA), gateway agent (GA), and sensor agent (SA)”. “(SND, RCV)” represent the send and receive channels, where “(dy)” means that the channel follows the DY model. “RCV(start)” indicates that the entire protocol starts running. “RCV(H(H(IDi.PWi.Ai’).K.Ai’)-SKuaga)” indicates that the user receives the message $\left\{U{M}_i\right\}$ transmitted from the gateway. The “SKuaga” encrypts transmitted messages, and this indicates that the message is transmitted via secure channel. Furthermore, “SND(H(IDi.PWi.Ai’).W1’.W2’.V1’.T1’)” signifies that the user transmits the message $\{TI{D}_i,W_1,W_2,V_1,T_1\}$ to the gateway via a public channel. In “State 3”, it becomes evident that the user has successfully established a session key with the sensor. Finally, we use the widely recognized On-the-Fly Model-Checker (OFMC) and Constraint Logic-based Attack Searcher (CL-AtSe) backends to verify the security of the proposed protocol, and the simulated results are depicted in Figure 11. It can be clearly seen that whether it is in the results of OFMC or CL-AtSe backend, the summary display is “SAFE”, which means that our proposed protocol can resist replay and MITM attacks.

5. Security and Performance Comparisons

We compare the security and performance of our proposed protocol to five IoHT authentication protocols [23,29,33,35,47].

5.1. Security Comparisons

In terms of security comparison, √ means that the protocol is resistant to that attack, while × means that the protocol does not satisfy that security property. The primary security properties include S1, mutual authentication; S2, PFS; S3, PI attacks; S4, OPG attacks; S5, SKD attacks; S6, SNC attacks; S7, MITM attacks; S8, correctness of $SK$.

The security comparison results are presented in

Table 3. Security comparison results.

Security Properties	Soni et al. [23]	Hajian et al. [33]	Shuai et al. [35]	Amintoosi et al. [29]	Wu et al. [47]	Ours
S1	√	× [17]	√	√	√	√
S2	× [24]	√	× [36]	√	√	√
S3	√	√	× [36]	×	√	√
S4	× [24]	√	√	√	√	√
S5	√	× [17]	√	√	√	√
S6	× [24]	√	√	√	√	√
S7	√	× [17]	√	√	√	√
S8	√	√	√	×	√	√

. It is clear that our protocol and Wu et al.’s protocol [47] satisfies all security properties. However, Soni et al.’s protocol [23] violated PFS and suffered from OPG and SNC attacks. Hajian et al.’s protocol [33] failed to provide mutual authentication, leaving it vulnerable to SKD and MITM attacks. Similarly, Shuai et al.’s protocol [35] also violated PFS and suffered from PI attacks. Amintoosi et al.’s protocol [29], like the others, exhibited security weaknesses, specifically being susceptible to PI attacks and unable to ensure the correctness of $SK$.

5.2. Performance Comparisons

The protocol compares three aspects of communication, computational, and storage costs in performance comparison. When comparing communication and computational costs, we exclusively consider the login and authentication phases of the protocols. On the other hand, in the comparison of storage costs, our focus is solely on the registration phase.

5.2.1. Computational Cost Comparisons

For the computational cost, we use three different devices to obtain the runtime of the cryptographic primitives. The configurations of these three experimental devices are shown in

Table 4. Configuration of simulated devices.

	Lenovo Laptop	Desktop Computer	MI 8
Operating System	Windows 10	Windows 10	Android system
CPU	Intel(R) Core(TM) i7-6700HQ CPU @ 2.60 GHz	Intel(R) Core(TM) i5-9500 CPU @ 3.00 GHz	Qualcomm Snapdragon 845
Running Memory	8 GB	16 GB	6 GB

, where we denote that the laptop simulates $U_i$, the desktop computer simulates $GWN$, and the Xiaomi mobile phone MI 8 simulates $S_j$. The software we use is IntelliJ idea 2020.3, and we use the Java language and cryptographic library JPBC-2.0.0 [48] to write programs. In addition, since the cost of ⊕ and ‖ in the protocol is too small, its computational size is ignored. The times of various operations are displayed in

Table 5. Running time of operations.

Definitions	Operations	${\mathit{U}}_{\mathit{i}}$ (ms)	$\mathit{GWN}$ (ms)	${\mathit{S}}_{\mathit{j}}$ (ms)
$T_{pm}$	Point scalar multiplication	0.4326	0.3672	0.5543
$T_{sd}$	Symmetric key encryption/decryption	0.1864	0.1482	0.2458
$T_h$	Hash function	0.0032	0.0028	0.0043

, where the running time of the operation runs 20 times in the software and takes the average value of the results. In addition, since the running time of the hash function and the fuzzy extraction are similar, we take one of them to calculate. The results of the comparison are presented in

Table 6. Computational cost comparison.

Protocols	${\mathit{U}}_{\mathit{i}}$ (ms)	$\mathit{GWN}$ (ms)	${\mathit{S}}_{\mathit{j}}$ (ms)
Soni et al. [23]	$T_f+12T_h+3T_{pm}$ ≈ 1.3394	$11T_h+3T_{pm}$ ≈ 1.1324	$5T_h$ ≈ 0.0215
Hajian et al. [33]	$12T_h$ ≈ 0.0384	$7T_h$ ≈ 0.0196	$9T_h$ ≈ 0.0387
Shuai et al. [35]	$T_f+7T_h+2T_{sd}$ ≈ 0.3984	$10T_h+2T_{sd}$ ≈ 0.3244	$4T_h$ ≈ 0.0172
Amintoosi et al. [29]	$8T_h$ ≈ 0.0256	$10T_h$ ≈ 0.0280	$6T_h$ ≈ 0.0258
Wu et al. [47]	$T_f+15T_h$ ≈ 0.0512	$21T_h$ ≈ 0.0588	$9T_h$ ≈ 0.0387
Ours	$12T_h$ ≈ 0.0384	$12T_h$ ≈ 0.0336	$7T_h$ ≈ 0.0301

, and more clearly shown in Figure 12.

The computational costs of a few $U_i$ in each protocol are illustrated in Figure 13a. Soni et al.’s protocol [23] utilizes point scalar multiplication and fuzzy extractor, and Shuai et al.’s protocol [35] relies on symmetric key encryption/decryption. As a result, both of them incur relatively high computational costs for $U_i$ compared to the other protocols in the comparison. On the other hand, the computational costs of $U_i$ in the remaining protocols show little variation and are relatively lower compared to Soni et al.’s and Shuai et al.’s protocols. Figure 13b depicts the computational costs of a few $S_j$ in each protocol. In our proposed protocol, the computational costs of $S_j$ are higher than in some other protocols, but still lower than the costs in Hajian et al. [33] and Wu et al. [47]. It is worth noting that Hajian et al.’s protocol is the same as that in Wu et al.’s work. Overall, Soni et al.’s and Shuai et al.’s protocols have relatively higher computational costs for $U_i$ due to their specific cryptographic operations.

To verify the scalability of the protocol, we gradually increased the number of $U_i$ from 20 to 100, while simultaneously increasing the number of $S_j$ from 50 to 250. The results of computational cost as the counts of $U_i$ and $S_j$ surged are presented in Figure 13c,d, respectively. The results demonstrate that our protocol can maintain reasonable computational costs as the quantity of entities grows, ensuring the protocol retains stable performance and efficiency. As a result, our proposed protocol can guarantee scalability.

5.2.2. Communication Cost Comparisons

In the comparison of communication costs, the lengths of the identity, timestamp, hash function, random number, point multiplication, and symmetrically encrypted ciphertext are defined to be 160, 32, 256, 128, 320, and 256 bits, respectively. Here, the communication cost is illustrated using our protocol as an example. The messages $M_1=\{TI{D}_i,W_1,W_2,V_1,T_1\}$, $M_2=\{TI{D}_i,W_3,V_2,T_2\}$, $M_3=\{W_4,V_3,T_3\}$, and $M_4=\{W_5,V_4,T_4\}$, in which $TI{D}_i$ is identity, $\{W_1,W_2,W_3,W_4,W_5\}$ are random numbers, $\{V_1,V_2,V_3,V_4\}$ are hash values, $\{T_1,T_2,T_3,T_4\}$ are timestamps. Based on the above calculation, our proposed protocol’s communication cost is $2\times 160+5\times 128+4\times 256+4\times 32=2112$ bits. Soni et al.’s protocol [23] is $7\times 128+4\times 256+5\times 32+320=2400$ bits, Hajian et al.’s protocol [33] is $4\times 160+3\times 128+8\times 256+7\times 32=3296$ bits, Shuai et al.’s protocol [35] is $160+128+6\times 256+4\times 32=1952$ bits, Amintoosi et al.’s protocol [29] is $6\times 128+5\times 256+4\times 32=2176$ bits, and Wu et al.’s protocol [47] is $11\times 128+4\times 256+4\times 32=2560$ bits. Based on the data presented in

Table 7. Communication cost comparisons.

Protocols	Rounds	Communication Cost
Soni et al. [23]	4	2400 bits
Hajian et al. [33]	5	3296 bits
Shuai et al. [35]	4	1952 bits
Amintoosi et al. [29]	4	2176 bits
Wu et al. [47]	4	2560 bits
Ours	4	2112 bits

and Figure 14, it is evident that our proposed protocol exhibits a slightly higher communication cost compared to Shuai et al.’s protocol [35]. However, our proposed protocol still maintains lower communication costs compared to Soni et al. [23], Hajian et al. [33], Wu et al. [47], and Amintoosi et al. [29].

5.2.3. Storage Cost Comparisons

In the comparison of storage costs, the lengths required for various parameters are consistent with the assumptions in Section 5.2.2. Here, we take the registration phases of our proposed protocol as an example. The storage costs required for $U_i$, $GWN$, and $S_j$ are $128\times 2+256=512$ bits, $128\times 3+160\times 2=704$ bits, and $128\times 2=256$ bits, respectively. The storage cost required for our proposed protocol is 1472 bits. The total storage costs for each protocol are presented in

Table 8. Storage cost comparisons.

Protocols	Storage Cost
Soni et al. [23]	1632 bits
Hajian et al. [33]	2336 bits
Shuai et al. [35]	1728 bits
Amintoosi et al. [29]	2208 bits
Wu et al. [47]	1792 bits
Ours	1472 bits

. From Figure 15, it is evident that Hajian et al.’s protocol [33] demands the highest storage costs. In contrast, our proposed protocol requires the minimum storage costs.

Based on the security and performance comparison results, we can confidently assert the following:

• Security comparison: Our proposed protocol, along with Wu et al.’s protocol, demonstrates the ability to withstand all known attacks. In contrast, other protocols in the comparison exhibit varying degrees of vulnerability to certain attacks.
• Performance comparison: Despite having the same security level of as Wu et al.’s protocol, our protocol outperforms theirs in terms of computational and storage costs, while also possessing scalability. Additionally, while our computational cost is slightly higher compared to Amintoosi et al.’s protocol, our communication and storage costs are lower than theirs.

6. Conclusions

In this paper, we emphasized the significance of ensuring secure data transmission within the IoHT environments. We conducted a comprehensive review of the AKA protocols employed in the IoHT context. Subsequently, we thoroughly analyzed Amintoosi et al.’s protocol and identified various security weaknesses, notably PI attacks. In response to these issues, we proposed an enhanced AKA protocol specifically tailored for the IoHT environment. Then, we subjected it to rigorous security analysis using the ROR model, informal security analysis, and the AVISPA tool. Finally, we compared the security and performance aspects of our proposed protocol with existing protocols. The comparison results revealed that our protocol outperforms other protocols in terms of security while maintaining a comparable level of performance, thereby enhancing the feasibility of its practical application. The potential challenge lies in the slightly higher computational and communication costs of the proposed protocol, but this is acceptable in practical applications. Consequently, in future research, we will focus on further enhancing the security and performance of AKA protocols in the IoHT to address evolving needs.