Secure and Lightweight Cluster-Based User Authentication Protocol for IoMT Deployment

Abstract

Authentication is considered one of the most critical technologies for the next generation of the Internet of Medical Things (IoMT) due to its ability to significantly improve the security of sensors. However, higher frequency cyber-attacks and more intrusion methods significantly increase the security risks of IoMT sensor devices, resulting in more and more patients’ privacy being threatened. Different from traditional IoT devices, sensors are generally considered to be based on low-cost hardware designs with limited storage resources; thus, authentication techniques for IoMT scenarios might not be applicable anymore. In this paper, we propose an efficient three-factor cluster-based user authentication protocol (3ECAP). Specifically, we establish the security association between the user and the sensor cluster through fine-grained access control based on Merkle, which perfectly achieves the segmentation of permission. We then demonstrate that 3ECAP can address the privilege escalation attack caused by permission segmentation. Moreover, we further analyze the security performance and communication cost using formal and non-formal security analysis, Proverif, and NS3. Simulation results demonstrated the robustness of 3ECAP against various cyber-attacks and its applicability in an IoMT environment with limited storage resources.

1. Introduction

The number of connected devices has grown exponentially due to advances in communications technology, resulting in what is known as the Internet of Things (IoT) [1,2,3]. IOT technology has continued to develop and innovate, profoundly changing traditional industrial models and people’s lifestyles, such as smart agriculture, smart healthcare, smart homes, and self-driving cars [4]. And healthcare is rapidly evolving, driven by an aging population, consumer demand for better services in more affordable prices, and a growing global focus on preventative health [5,6]. In recent years, IoMT has been recognized as one of the most important technologies in healthcare, which is used for systematic monitoring of patient status, enabling doctors to provide timely and appropriate treatment [7]. Specifically, IoMT sensors such as defibrillators, sphygmomanometers, and oximeters provide real-time monitoring and observation for patients’ temperature, pulse, blood pressure, respiration, and more [8]. Typically, sensors in IoMT are widely accessible and can be installed across geographies as the focus has been on making them multifunctional, low-cost, and available on hardware platforms when coordinated with back-end processing systems. With these new technologies, the prospect of IoMT sensors in healthcare is extremely promising.

Despite the convenience that IoMT brings to patients in terms of treating, diagnosing, and maintaining their health, once the information carried by these sensors is accessed by attackers, it can be a great threat to patient privacy and security [9]. One of the crucial factors to ensure the security of IoMT is node authentication. Usually, the generic architecture of IoMT consists of three node participants, i.e., user, gateway, and sensor. The sensor is placed in a designated area to collect environmental parameters and then transmits these parameters to the gateway through a wireless channel [10]. The user must be authenticated to access these data as the patient data provided by sensors are analyzed and collated to make appropriate and feasible decisions for the timely treatment of the patient.

Specifically, the IoMT system can be simplified into three dimensions, i.e., perception layer, network layer, and application layer [11]. (1) Perception layer: each patient is equipped with a variety of medical sensors used to sense and monitor vital statistics. In this layer, the attacker usually utilizes a device capture attack to obtain patient information inside sensors. (2) Network layer: similar to the OSI network and transport layer, it is responsible for authentication, communication and data transfer between sensors and users via an open channel/private network. However, it is vulnerable to man-in-the-middle attacks, impersonation attacks, replay attacks and so on. (3) Application layer: in this layer, legitimate users/medical staff can realize access to patient information through authentication with the sensors, and it is the top layer of the three-layer IoMT system architecture. However, the application layer is also vulnerable to many attacks such as insider privilege attacks, privilege escalation attacks, etc. Therefore, it is necessary to ensure the privacy and security of patient information in the multilayer architecture of an IoMT system.

Once the information is compromised, the corresponding patient information (including history of illness) may also be exposed to the attacker [12]. Worse, the attacker can even illegally sell this information, thus seriously compromising the patient’s personal privacy. In addition, insider attackers (i.e., medical staff) also pose a potential risk of IoMT information leakage. It is extremely necessary to implement permission segmentation according to access levels due to the differences in sensor data accessible to medical staff in different departments (e.g., neurology, gastroenterology, cardiovascular, etc.). Moreover, IoMT is susceptible to various types of attacks, including replay attacks, user privilege escalation attacks, smart card theft attacks, etc., which further compromise the security of the system. Therefore, it is urgent to design a new authentication protocol to ensure the security and privacy of IoMT.

Considering the security, low complexity, and low cost requirements of IoMT, we propose a new efficient cluster-based lightweight secure authentication protocol (3ECAP), with the ultimate goal of establishing a secure session key before participants transmit data. The specific contributions of this paper are as follows.

(1) 3ECAP implements IoMT user permission segmentation using fine-grained access control to establish a security association between the user and the sensor cluster, which reduces subsequent database access costs. Then, the user’s password, biometrics and smart card are used as the three factors for authentication, where biometrics are collected through a fuzzy extractor. In addition, the communication cost and computation cost of 3ECAP are further reduced by only performing hash and dissimilarity operations.

(2) The formal security analysis of 3ECAP is demonstrated through the widely used Real or Random (RoR) model and the formal automated verification tool Proverif. In addition, 3ECAP informal security analysis is also provided, which indicates that 3ECAP is not only resistant to most known attacks but also to privilege elevation attacks from insiders (see Section 6.2).

(3) Considering the limited resources of IoMT devices, compared to other schemes, our proposed authentication protocol is not only lightweight and efficient but also resistant to a variety of complex typical attacks.

The rest of this paper is structured as follows: Section 2 presents the literature survey. Some necessary mathematical background is provided in Section 3. The system model utilized in 3ECAP is given in Section 4. Section 5 describes the phases of the designed protocol (3ECAP). In Section 6, the security of 3ECAP is ensured by using formal and informal security analysis. Section 7 presents a comparative analysis of 3ECAP and other related protocols with respect to computational cost, latency, and security characteristics. Section 8 presents a simulation analysis of 3ECAP using a network simulation tool. The last section concludes the paper and gives some future research directions.

2. Related Work

In this section, research advances in the relevant areas are provided, including the methods used and advantages and limitations.

Wang et al. [13] proposed a cloud-assisted secure user authentication scheme with various attributes such as forward secrecy and multi-factor security. However, the scheme requires high computational costs and does not ensure user privacy. Masud et al. [14] proposed a lightweight anonymous user authentication protocol for IoT, which only uses lightweight cryptographic primitives (hash). The scheme establishes a secure session for legitimate users and prohibits unauthorized user access to IoT sensor nodes. Although the protocol has low computational and communication costs, it proved to be vulnerable to attacks such as impersonation and replay. In addition, relevant existing protocols [15,16,17] are designed for various IoT scenarios, e.g., IoMT, smart firefighting, smart transportation, etc., with provably secure protocols that provide mutual authentication for involved nodes. However, according to recent studies [18,19,20], the mentioned schemes are susceptible to attacks such as man-in-the-middle, denial-of-service, and internal privilege.

Zhang et al. [21] propose a password-based lightweight security authentication scheme that can flexibly achieve mutual authentication between the user and sensor. Unfortunately, studies have demonstrated that this authentication scheme based on only a single factor can be easily compromised and therefore cannot withstand attacks such as password guessing. To address these problems, Nandy et al. [22] and Singh et al. [23] have proposed security schemes based on multifactor privacy protection. However, Chaudhry et al. [24] point out that the public key of the sensor in the scheme of Nandy et al. [22] is invalid, due to the inability of the device to generate its own private key, and susceptible to clogging attacks. Moreover, the above schemes also require high communication costs.

Nyangaresi et al. [25] propose a lightweight key management and mutual authentication protocol based on Elliptic Curve Cryptography (ECC) for smart home environments. Li et al. [26] design a robust two-factor user authentication protocol based on ECC and prove that the construction of the proposed scheme can achieve user anonymity, forward secrecy of the session key, etc. However, since the above schemes use the ECC algorithm, this significantly increases the communication and computational costs to verify the protocol. Furthermore, Xie et al. [27] proposed a blockchain-based vehicle-to-infrastructure (V2I) authentication protocol using lightweight cryptographic primitives that guarantee sensor anonymity and untraceability. Son et al. [28] design a lightweight mutual authentication protocol for IoT sensors, in which the node performs cryptographic computation only when switching in order to improve the network transmission efficiency. Yang et al. [29] propose a mutual authentication scheme based on decentralized edge collaboration to provide continuous protection for zero-trust IoT and enable flexible updating for the sensor.

By reading and summarizing the above existing studies, we found that existing authentication protocols have low utility in IoMT, e.g., susceptibility to various attacks, high overhead algorithmic application, access control of user authority, high maintenance cost of protocol, and so on. Therefore, we intended to design a lightweight secure and reliable authentication protocol for IoMT to solve the above problems, and some of these research results have been published in the form of a conference [30]. Please note that 3ECAP is an extended version of the published conference paper. Compared to the previous version, 3ECAP contains more comprehensive authentication schemes, security analyses, simulations, graphs, results and utilities. The relevant changes are indicated in the text. Table 1 summarizes the relevant work described above.

Table 1.

Related works.

Reference	Method	Advantage (+)	Limitation (−)
Wang et al. [13]	ECC, hash, fuzzy extractor	+three-factor authentication +forward secrecy	−high computational cost −user privacy −lack of access control
Masud et al. [14]	hash, password	+lightweight authentication +node anonymity	−impersonation attack −replay attack −lack of access control
Sutrala et al. [15]	ECC, hash	+impersonation attack protection +MITM attack protection	−privilege-insider attack −high computational cost −lack of access control
Iqbal et al. [16]	hash, symmetric encryption	+privacy-preserving +node anonymous	−impersonation attack −replay attack −lack of access control
Wei et al. [17]	ECC, hash, pseudo random function	+privacy-preserving +system secret key update	−impersonation attack −lack of access control
Zhang et al. [21]	hash, password, homomorphic encryption	+key leakage protection +anonymity and untraceability	−password guessing attack −lack of access control −high resource cost
Nandy et al. [22]	hash, ECC, RSA or DSA	+privacy-preserving +forward secrecy −insider attack protection	−clogging attack −high resource cost −lack of access control
Singh et al. [23]	hash, fuzzy extractor, PUF	+two-factor authentication +physical layer security	−MITM attack −replay attack −high resource cost −privilege escalation attack
Nyangaresi et al. [25]	hash, ECC, password	+replay attack protection +impersonation attack protection +MITM attack protection	−anonymity and untraceability −device capture attack −high resource cost −lack of access control
Li et al. [26]	hash, ECC	+three-factor authentication +forward secrecy +device capture attack protection +impersonation attack protection	−high resource cost −untraceability −lack of access control
Xie et al. [27]	hash, ECC, PUF	+device capture attack protection +MITM attack protection +impersonation attack protection	−privilege-insider attack −forward secrecy −lack of access control
Son et al. [28]	hash, ECC, password	+anonymity and untraceability +ephemeral key leakage protection	−device capture attack −high calculation cost −lack of access control
Yang et al. [29]	hash, ECC, bilinear pairing	+device update +token forgery attack protection	−device capture attack −privacy disclosure −high resource cost −lack of access control

3. Preliminaries

3.1. One-Way Hash Function

A one-way hash function can transform an input message string of arbitrary length into a fixed-length output. It is widely used in areas such as the generation of message digests and message authentication codes, key encryption, and data integrity tests. Collision resistance is the main property and is defined as follows.

Definition 1.

Suppose a one-way hash function can be expressed as $h:{\{0,1\}}^{*}\to {\{0,1\}}^n$. Specifically, the hash function outputs a fixed-length binary string $h\left(m\right)\in {\{0,1\}}^n$ for an arbitrary-length input binary string $m\in {\{0,1\}}^{*}$. Assume $Ad{v}_{\mathcal{A}}^{HASH}\left(t\right)$ is defined as the probability of an adversary obtaining a hash collision in execution time t, then $Ad{v}_{\mathcal{A}}^{HASH}\left(t\right)=\mathrm{Pr}\left[(m,n){\in }_R\mathcal{A}:m\ne n,h\left(m\right)=h\left(n\right)\right]$, where $P_r\left[X\right]$ refers to the probability of a random event X occurring, and $(m,n){\in }_R\mathcal{A}$ means that both input strings m and n are randomly selected by $\mathcal{A}$. If an $(\theta ,t)$-adversary $\mathcal{A}$ attempts to attack the collision resistance of $h(·)$, it means that the maximum execution time of $\mathcal{A}$ is t and that $Ad{v}_{\left(A\right)}^{\mathrm{HASH}}\left(t\right)\le \theta$.

3.2. Fuzzy Extractor for Biometric Verification

The secret value in an encryption mechanism is a random string that requires uniform distribution and can be copied exactly. However, in the real world, it is difficult for the secret value to satisfy this. For example, biometric features, such as fingerprints, brain prints, etc., cannot be accurately copied due to a non-uniform distribution of random values. Thus, we select the fuzzy extraction method for the collection of biometric features [31].

Recently, the fuzzy extractor method has been widely used to extract biometric keys from user biometric input. This method can allow the input to have a certain amount of noise (or error), and as long as the input is similar, the same uniform random string can be extracted. The general structure is as follows.

(1) Gen: Given that the user inputs biometrics $BI{O}_i$, the gen process will generate a biometric key $r_i$ of l bits and the corresponding auxiliary public parameter $p_i$; that is, $Gen\left(BI{O}_i\right)=(r_i,p_i)$.

(2) Rep: Given a noisy user input biometric $BI{O}_i^{\prime }$, $Rep$ will return the original biometric key $r_i$ with the help of the auxiliary public data $p_i$ when the Hamming distance between the current biometric input $BI{O}_i^{\prime }$ and the original biometric input $BI{O}_i$ is less than a specific error tolerance threshold t; that is, $HamDis(BI{O}_i^{\prime },BI{O}_i)\le t$. Thus, $Rep(BI{O}_i^{\prime },p_i)=\left(r_i\right)$.

Considering the false-positive and false-negative events of biometric authentication, we make a note of $BI{O}_i$ and $BI{O}_i^{\prime }$. If both $BI{O}_i$ and $BI{O}_i^{\prime }$ originate from the same person, then the Hamming distance between the two will converge to 0. We assume that $Pr[HamDis(BI{O}_i^{\prime },BI{O}_i)\le t]\ge 1-\lambda n$, where $\lambda n$ means the false negative probability. If $BI{O}_i$ and $BI{O}_i^{\prime }$ originate from different people, then the Hamming distance between the two may be significant. We assume that $Pr[HamDis(BI{O}_1,BI{O}_2)\ge t^{\prime }]\ge 1-\lambda p$, $t^{\prime }\gg t$, where $\lambda p$ means the false positive probability.

4. System Model

4.1. Authentication Model

The IoMT-based authentication model is shown in Figure 1. In this model, patients suffering from different diseases are being treated in the hospital. Each hospital bed is equipped with a number of sensors to monitor and sense the real-time status of the patient (e.g., blood pressure, heart rate, etc.). Since the hospital contains different departments, such as brain, orthopedics, etc., as well as different types of medical staff in each department, such as doctors and nurses, they are all concerned with monitoring the patient’s physical condition. Specifically, only the nurse is required to handle a patient who needs a medication change, while the doctor is required to take quick emergency measures when the patient is in a life-threatening situation. Therefore, it is necessary to set the corresponding accessible sensor cluster for different user levels.

Figure 1.

Authentication model for IoMT.

Four different departments $C_1$, $C_2$, $C_3$, and $C_4$ exist in the hospital, as shown on the left side of Figure 1, and some sensor devices are deployed in them. For example, in $C_1$, seven sensors $\left\{D_1,D_2,...,D_7\right\}$ are deployed to detect real-time data of patients, where $\left\{D_1,D_2,D_3,D_4\right\}$ represents the accessible sensor cluster by a particular member of the medical staff $U_1$. Before authentication, both $U_1$ and $D_j$ need to complete registration with the help of $GW$, where $U_1$ also sends a sensor cluster to $GW$. Then, $U_1$ can authenticate with $D_j$ through $GW$. Once authenticated, $U_1$ can securely access the real-time data from $D_j$. Specifically, $U_1$ first sends a login request to $GW$. Then, $GW$ validates the login request and sends the access request to the accessible $D_j$. Finally, once the authentication is complete, $D_j$ sends a reply message to $U_1$ and generates a session key shared between the two. It is worth noting that the registration phase of 3ECAP is performed in a secure environment, whereas information is transmitted via a public channel in the authentication phase, which makes it vulnerable to anonymous attackers.

4.2. Threat Model

The protocol we designed uses the Dolev–Yao [32] threat model (DY model) for security analysis, where an adversary can not only intercept messages transmitted between participants but also perform deletion and modification operations. In addition, we consider the widely accepted RoR model [33], which is used to secure the session key generated by medical staff and sensors. Note that in the authentication model, suppose that the $GW$ is fully trusted and is deployed in a fixed location that is physically protected so that the likelihood of the $GW$ being captured is extremely low compared to that of the sensor device. In contrast, for some physically captured sensor devices, the corresponding secret information stored in these devices can be extracted by the adversary using power analysis attacks.

5. Proposed Scheme

In this section, we elaborate on a new protocol called 3ECAP for IoMT deployments. The protocol requires the following phases: (1) setup; (2) medical staff registration; (3) sensor registration; (4) login and authentication; (5) password and biometric update; and (6) new smart-device addition phase. In the setup phase, the public parameters of the protocol are selected by the fully trusted $GW$. Once the setup is complete, the medical staff and the sensor need to complete the registration in the system. In the login and authentication phase, a user (i.e., legal medical staff) $U_i$ and a sensor device $S{D}_j$, with the help of the $GW$, establish a shared key between $U_i$ and $S{D}_j$ for future communication. The proposed protocol also enables $U_i$ to change the password and biometric information without the need for $GW$. In addition, the protocol can support the addition of new sensor devices. The notations and their abbreviations are presented in Table 2 [30] for the analysis of 3ECAP.

Table 2.

Notations and abbreviations.

Noation	Description
$U_i$, $GW$, $S{D}_j$	$i_{th}$ user, $j_{th}$ sensor and gateway
$I{D}_i$, $I{D}_{GW}$, $SI{D}_j$	Identities of $U_i$, $GW$ and $S{D}_j$
$RI{D}_i$, $RI{D}_{GW}$, $RSI{D}_j$	Pseudo-identities of $U_i$, $GW$, and $S{D}_j$
$S{C}_i$, $BI{O}_i$	Smart card and biometrics of user
$AL$	User’s access list
$Gen(·)$, $Rep(·)$	Functions of the fuzzy extractor
$r_i$, $p_i$	Secret parameter and public parameter of $U_i$
$HamDis(BI{O}_i^{\prime },BI{O}_i)$	Hamming distance between $BI{O}_i^{\prime }$ and $BI{O}_i$
t	Fault tolerance threshold applied in $Rep(·)$
${\lambda }_n$, ${\lambda }_p$	False negative probability and false positive probability
$h(·)$	One-way collision-resistant hash function
⊕, $\parallel$	Bitwise XOR and concatenation operations
$T_1$, $T_2$, $T_3$	Current timestamps
$\Delta T$	Maximum transmission delay
${\alpha }_j$, ${\beta }_i$	Random numbers applied in the registration phase
a, b, c	Random numbers applied in the login and authentication phase
x	Master key for $GW$
$k_{GWj}$, $k_{jGW}$	Shared keys for $GW$ and $S{D}_j$
$\mathcal{A}$	Adversary
$P\to Q:M$	P sends the message M to Q

5.1. Setup Phase

During the system setup phase, some public parameters are initialized by $GW$. Specifically, $GW$ chooses a one-way hash function $h(·)$, a biometric key generation function $Gen(·)$ and a biometric key replication function $Rep(·)$, where $Gen(·)$ and $Rep(·)$ are used for bio-information extraction and recovery of medical staff, respectively. Then, $GW$ generates a unique master key x, an identity $I{D}_{GW}$, and also calculates the corresponding pseudo-identity $RI{D}_{GW}=h(I{D}_{GW}\parallel x)$.

5.2. Sensor Addition Phase

During the sensor addition phase, $GW$ generates a unique $SI{D}_j$ for the medical sensor $S{D}_j$, a random number ${\alpha }_j$, and then calculates the pseudo-identity $RSI{D}_j=h(SI{D}_j\parallel I{D}_{GW}\parallel {\alpha }_j)$. In addition, a secret pairwise key is established between $GW$ and $S{D}_j$ by means of the master key x of $GW$, where $k_{GWj}=h(I{D}_{GW}\parallel SI{D}_j\parallel x)$, which will be used for mutual authentication and message encryption between nodes in the subsequent login phase. Finally, $GW$ stores $\left\{RSI{D}_j,k_{GWj}\right\}$ into the database. Meanwhile, $SI{D}_j$ also saves $\left\{RSI{D}_j,k_{GWj}\right\}$ into the memory.

5.3. Medical Staff Registration Phase

In general, there are many disease departments in the medical system, such as neurology, orthopedics, brain and cardiovascular, etc. Each department is composed of many medical sensor devices that contain sensitive patient information. Therefore, in order to protect patient privacy, medical staff can only access patient information based on access permission for a specific cluster of sensor devices. The registration process for medical staff can also be divided into two phases, as follows.

(1) Fine-Grained Access Control: The purpose of fine-grained access control [30] is to restrict the access permission of the medical staff. For example, medical staff in a neurology department can only access information from sensors relevant to their department, where these sensors are connected to the patient to monitor individual status.

Our sensor cluster model can be simplified to a merkle tree, which consists of multiple leaf nodes $\left\{D_1,D_2,...,D_n\right\}$ and a single root node $Ve{r}_i$, where $\left\{D_1,D_2,...,D_n\right\}$ represents the sensor device nodes accessible to a particular medical staff. Assume that the number of leaf nodes $n=2^m$ for $m\ge 1$, $Ve{r}_i$ can be computed as follows.

Procedure 1: Denote the leaf nodes $D_1,D_2,...,D_n$ as $H_{\left(lo{g}_{2}n\right)\left(0\right)},H_{\left(lo{g}_{2}n\right)\left(1\right)},...,H_{\left(lo{g}_{2}n\right)(n-1)}$, respectively.

Procedure 2: $Ve{r}_i=H_{00}=h(H_{10}\parallel H_{11})$, where $H_{xy}=h(H_{(x+1)\left(2y\right)}\parallel H_{(x+1)(2y+1)})$ for $x=0,1,2,...,\left({log}_{2}n\right)-1$ and $y=0,1,2,...,n-1$.

$Ve{r}_i$ can also be calculated using auxiliary and leaf nodes, which can effectively reduce the computational complexity. As shown in Figure 2 [30], $Ve{r}_i=h(h(H_{21}\parallel H_{20})\parallel H_{11})$, utilizing auxiliary nodes $H_{20}$ and $H_{11}$, instead of $H_{22}$ and $H_{23}$.

Figure 2.

Merkle tree-based access list.

(2) Personal Information Registration

Step 1: $U_i$ chooses his or her identity $I{D}_i$, password $P{W}_i$, access list (generated from the cluster of accessible sensors) $AL=\left\{RSI{D}_1,RSI{D}_2,...,RSI{D}_j\right\}$ and imprints biological information $BI{O}_i$ on the specific acquisition device. The device then extracts the secret parameter $r_i$ and the public parameter $p_i$ with the help of the generating function $Gen(·)$, namely $Gen\left(BI{O}_i\right)=(r_i,p_i)$. Next, $U_i$ computes $RP{W}_i=h(P{W}_i\parallel r_i)$ and sends $\left\{I{D}_i,RP{W}_i,AL\right\}$ to $GW$ via a secure channel.

Step 2: After receiving the message $\left\{I{D}_i,P{W}_i,AL\right\}$, $GW$ computes $Ve{r}_i$ using the above $markle$ tree and auxiliary nodes and also computes the personal information $P_i=h(I{D}_i\parallel RP{W}_i)$. Moreover, $GW$ generates the current registration timestamp $T_{re}$, a random number ${\beta }_i$, and computes the pseudo-identity $RI{D}_i=h(I{D}_i\parallel I{D}_{GW}\parallel {\beta }_i)$ and the sensor device list $SD{L}_i=h(Ve{r}_i\parallel T_{re}\parallel RI{D}_i)$. Next, $GW$ stores $\left\{RI{D}_i,SD{L}_i\right\}$ in its memory. $GW$ also returns the message $\left\{P_i,RI{D}_i,SD{L}_i,RI{D}_{GW}\right\}$ to $U_i$ via a secure channel.

Step 3: Once the message is received from $GW$, $U_i$ calculates $H{P}_i=h(I{D}_i\parallel P{W}_i\parallel r_i)$, ${\beta }_i^{*}={\beta }_i\oplus H{P}_i$, $SD{L}_i^{*}=SD{L}_i\oplus h(H{P}_i\parallel {\beta }_i)$. Finally, $U_i$ stores the verifiable information $\left\{P_i,{\beta }_i^{*},SD{L}_i^{*}RI{D}_{GW},RI{D}_i,p_i\right\}$ into its own smart card $S{C}_i$; note that $SD{L}_i^{*}$ represents the cluster of sensor devices accessible to the particular user. Figure 3 illustrates the complete process of 3ECAP registration.

Figure 3.

Summary of medical staff registration phase.

5.4. Login and Authentication Phase

When $U_i$ wants to access the data of $S{D}_j$, he/she needs to login and authenticate to the $GW$ first. After the authentication process is complete, a secure session key is established between $U_i$ and $S{D}_j$ for subsequent communication. The following steps are essential under the proposed protocol.

Step 1: $U_i\to GW:\left\{A_i,B_i,C_i,RSI{D}_j,T_1\right\}$

Step 1.1: $U_i$ inputs $I{D}_i^{\prime }$, $P{W}_i^{\prime }$, and imprints $BI{O}_i^{\prime }$ at a biometric acquisition device. $S{C}_i$ then extracts the public parameter $p_i$ and recovers $r_i=Rep(BI{O}_i^{\prime },p_i)$ if $HamDis(BI{O}_i^{\prime },BI{O}_i)\le t$ is satisfied. Next, $S{C}_i$ computes $P_i^{\prime }=h(I{D}_i^{\prime }\parallel h(P{W}_i^{\prime }\parallel r_i))$ and verifies $P_i^{\prime }\stackrel{?}{=}{P}_i$. The login request is terminated if $P_i^{\prime }\ne P_i$.

Step 1.2: $S{C}_i$ then generates the current timestamp $T_1$, a random number a, and calculates $H{P}_i=h(I{D}_i^{\prime }\parallel P{W}_i^{\prime }\parallel r_i)$, ${\beta }_i^{\prime }={\beta }_i^{*}\oplus H{P}_i$, $SD{L}_i^{\prime }=SD{L}_i^{*}\oplus h(H{P}_i\parallel {\beta }_i^{\prime })$, $A_i=RI{D}_i\oplus h(RI{D}_{GW}\parallel T_1)$, $b_i=h(RI{D}_i\parallel T_1\parallel a)$, $B_i=h(RI{D}_i\parallel RI{D}_{GW}\parallel T_1)\oplus b_i$, $C_i=h(b_i\parallel SD{L}_i^{\prime }\parallel RI{D}_{GW}\parallel RSI{D}_j\parallel T_1)$. Finally, $S{C}_i$ sends the message $M_1=\left\{A_i,B_i,C_i,RSI{D}_j,T_1\right\}$ to $GW$ via a common channel, where $RSI{D}_j$ contains the information $U_i$ wants to obtain.

Step 2: $GW\to S{D}_j:\left\{D_i,E_i,F_i,T_2\right\}$

Step 2.1: Once $M_1$ is received from $U_i$, $GW$ first verifies the validity of $T_1$ under the condition of $\left|T_1^{*}-T_1\right|\le \Delta T$, where $T_1^{*}$ is the receive timestamp, and $\Delta T$ is the maximum time delay. The entire session is aborted if the condition is not met. Otherwise, $GW$ computes $RI{D}_i=A_i\oplus h(RI{D}_{GW}\parallel T_1)$ and finds the corresponding $SD{L}_i$ from the memory. Meanwhile, $GW$ also calculates $b_i=B_i\oplus h(RI{D}_i\parallel RI{D}_{GW}\parallel T_1)$, $C_i^{\prime }=h(b_i\parallel SD{L}_i\parallel RI{D}_{GW}\parallel RSI{D}_j\parallel T_1)$ and verifies $C_i^{\prime }\stackrel{?}{=}{C}_i$. If $C_i^{\prime }\ne C_i$, it indicates two possibilities, case 1: $U_i$ is an external attacker who does not have the key for the registration phase of the personnel information, and case 2: $U_i$ is an internal attacker who wants to access sensors beyond his/her own permission, i.e., the sensor cluster $SD{L}_i^{\prime }\ne SD{L}_i$.

Step 2.2: If $C_i^{\prime }=C_i$, it indicates that the identity of $U_i$ is confirmed. Then, $GW$ generates the current timestamp $T_2$, a random number b and computes $D_i=b\oplus h(k_{GWj}\parallel T_2)$, $E_i=b_i\oplus h(b\parallel T_2)$, $F_i=h(RSI{D}_j\parallel k_{GWj}\parallel b_i\parallel b\parallel T_2)$, where $k_{GWj}$ is the symmetric key for $S{D}_j$ and is stored in the memory of $GW$. At last, $GW$ sends the message $M_2=\left\{D_i,E_i,F_i,T_2\right\}$ publicly to $S{D}_j$.

Step 3: $S{D}_j\to U_i:\left\{G_i,H_i,J_i,T_3\right\}$

Step 3.1: Once $S{D}_j$ receives message $M_2$ from $GW$, $S{D}_j$ verifies that timestamp $T_2$ matches condition $\left|T_2^{*}-T_2\right|\le \Delta T$. If the condition does not match, it indicates that the timeliness of $M_2$ is not guaranteed and the session will be closed. Otherwise, $S{D}_j$ calculates $b=D_i\oplus h(k_{GWj}\parallel T_2)$, $b_i=E_i\oplus h(b\parallel T_2)$ and $F_i^{\prime }=h(RSI{D}_j\parallel k_{GWj}\parallel b_i\parallel b\parallel T_2)$ using the stored symmetric key $k_{GWj}$. $S{D}_j$ then verifies that $F_i^{\prime }\stackrel{?}{=}{F}_i$.

Step 3.2: If $F_i^{\prime }\ne F_i$, the access request from $GW$ is terminated. Otherwise, $S{D}_j$ authenticates $GW$ successfully. Then, $S{D}_j$ generates the current timestamp $T_3$, a random number c and calculates $G_i=c\oplus b_i$, $H_i=c\oplus h(k_{GWj}\parallel T_2)=c\oplus d_i$, $J_i=h(RSI{D}_j\parallel d_i\parallel c\parallel T_3)$. Meanwhile, $S{D}_j$ also computes the secure session key $s{k}_{ji}=h(b_i\parallel d_i\parallel RSI{D}_j\parallel c\parallel T_3)$. Finally, $S{D}_j$ sends the message $M_3=\left\{G_i,H_i,J_i,T_3\right\}$ to $U_i$ via a public channel.

Step 4: Once $M_3$ is received at time $T_3^{*}$ by $U_i$, $S{C}_i$ verifies the validity of $T_3$ in this message with the condition of $\left|T_3^{*}-T_3\right|\le \Delta T$. If the condition fails, the session is immediately terminated by $U_i$. Otherwise, $S{C}_i$ calculates $c=G_i\oplus b_i$, $d_i=c\oplus H_i$ and $J_i^{\prime }=h(RSI{D}_j\parallel d_i\parallel c\parallel T_3)$ and verifies $J_i^{\prime }\stackrel{?}{=}{J}_i$. If $T_i^{\prime }=J_i$, it means that the identity of $S{D}_j$ is confirmed. Eventually, $S{C}_i$ computes the session key $s{k}_{ij}=h(b_i\parallel d_i\parallel RSI{D}_j\parallel c\parallel T_3)(=s{k}_{ji})$ shared with $S{D}_j$, which will be used to encrypt the data transmitted between $U_i$ and $S{D}_j$. Figure 4 illustrates the complete process of 3ECAP login and authentication.

Figure 4.

Summary of login and authentication phase.

5.5. Password and Bio-Information Update Phase

Usually, human biological characteristics change over time, for example, the characteristics of brain waves are completely different at different ages. Therefore, 3ECAP supports the modification of biological information for medical staff. In addition, we recommend that medical staff change their passwords regularly to ensure the security of their privacy (this part was not considered in the previous conference). The specific steps for password and bio-information modification are as follows.

Step 1: $U_i$ input $I{D}_i$ and $P{W}_i^{old}$ and imprint the old bio-information $BI{O}_i^{old}$ on the specific collection device. Meanwhile, $U_i$ inserts its smart card $S{C}_i$ in the system terminal. Then, $S{C}_i$ computes $r_i^{old}=Rep(BI{O}_i^{old},p_i)$ with the condition $HamDis(BI{O}_i^{old},BI{O}_i)\le t$, where $BI{O}_i$ is the biological information previously registered by $U_i$. Next, $S{C}_i$ computes $P_i^{old}=h(I{D}_i\parallel h(P{W}_i^{old}\parallel r_i^{old}))$ and verifies $P_i^{old}\stackrel{?}{=}{P}_i$. If $P_i^{old}=P_i$, $S{C}_i$ authenticates $U_i$ successfully. Otherwise, password and bio-information change requests are terminated by $S{C}_i$.

Step 2: After successful authentication, $U_i$ enters a new password $P{W}_i^{new}$ and imprints the new bio-information $BI{O}_i^{new}$ at the acquisition device. The device then extracts the corresponding secret parameter $r_i^{new}$ and public parameter $p_i^{new}$ using $Gen(·)$. Next, $S{C}_i$ calculates the old secret information $H{P}_i^{old}=h(I{D}_i\parallel P{W}_i^{old}\parallel r_i^{old})$, ${\beta }_i={\beta }_i^{*}\oplus H{P}_i^{old}$ and $SD{L}_i=SD{L}_i^{*}\oplus h(H{P}_i^{old}\parallel {\beta }_i)$. $S{C}_i$ also calculates the new secret information $P_i^{new}=h(I{D}_i\parallel h(P{W}_i^{new}\parallel r_i^{new}))$, $H{P}_i^{new}=h(I{D}_i\parallel P{W}_i^{new}\parallel r_i^{new})$, ${\beta }_i^{new}*={\beta }_i\oplus H{P}_i^{new}$, $SD{L}_i^{new}*=SD{L}_i\oplus h(H{P}_i^{new}\parallel {\beta }_i)$. $S{C}_i$ finally replaces $\left\{P_i,{\beta }_i^{*},SD{L}_i^{*},p_i\right\}$ with $\left\{P_i^{new},{\beta }_i^{new}*,SD{L}_i^{new}*,p_i^{new}\right\}$ in its memory.

5.6. New Smart Device Addition Phase

Usually, a sensor is installed in each sickbed to capture the real-time status of the patient (e.g., blood pressure, temperature, heartbeat, etc.). Hence, the number of sensors is generally fixed. However, when emergencies arise (for example, the outbreak of COVID-19), the original number of beds cannot meet the demand of patients. Therefore, 3ECAP can support the bulk addition of new sensors with the following steps (this part was not considered in the previous conference).

Step 1: Before new sensors are deployed, they need to register with the gateway. Specifically, $GW$ selects an identity $SI{D}_j^{new}$ and a random number ${\alpha }_j^{new}$ for $S{D}_j^{new}$ and computes the pseudo-identity $RSI{D}_j^{new}=h(SI{D}_j^{new}\parallel I{D}_{GW}\parallel {\alpha }_j^{new})$. Meanwhile, $GW$ computes $k_{GWj}^{new}=h(I{D}_{GW}\parallel SI{D}_j^{new}\parallel x)$. Then, $GW$ and $S{D}_j^{new}$ store $\left\{SI{D}_j^{new},RSI{D}_j^{new},k_{GWj}^{new}\right\}$ and $\left\{RSI{D}_j^{new},k_{GWj}^{new}\right\}$ into their own databases, respectively. Furthermore, after the registration of the sensor is complete, $GW$ needs to broadcast the addition regarding $S{D}_j^{new}$ so that $U_i$ can access the data therein.

Step 2: $U_i$ needs to update sensor device list $SD{L}_i$ with the help of $GW$ before accessing the bulk-added $\left\{RSI{D}_1^{new},RSI{D}_2^{new},...,RSI{D}_j^{new}\right\}$. $U_i$ first inputs $I{D}_i^{\prime }$, $P{W}_i^{\prime }$, $BI{O}_i^{\prime }$ and inserts $S{C}_i$. Then, $S{C}_i$ calculates $r_i=Rep(BI{O}_i^{\prime },p_i)$ if condition $HamDis(BI{O}_i^{\prime },BI{O}_i)\le t$ is satisfied. Next, $S{C}_i$ computes $P_i^{\prime }=h(I{D}_i^{\prime }\parallel h(P{W}_i^{\prime }\parallel r_i))$ and verifies $P_i^{\prime }\stackrel{?}{=}{P}_i$. If $P_i^{\prime }=P_i$, $S{C}_i$ sends $\left\{RI{D}_i,AL\right\}$ to $GW$ via a secure channel, where $AL$ consists of the old devices $\left\{RSI{D}_1,RSI{D}_2,...,RSI{D}_j\right\}$ and the newly added devices $\left\{RSI{D}_1^{new},RSI{D}_2^{new},...,RSI{D}_j^{new}\right\}$.

Step 3: Once the message $\left\{RI{D}_i,AL\right\}$ is received from $U_i$, $GW$ generates a new current registration timestamp $T_{re}^{new}$ and computes $SD{L}_i^{new}=h(Ve{r}_i^{new}\parallel T_{re}^{new}\parallel RI{D}_i)$, where $Ve{r}_i^{new}$ is calculated based on $AL$ using the $merkle$ tree. Then, $GW$ sends $SD{L}_i^{new}$ to $U_i$ via a secure channel.

Step 4: When $SD{L}_i^{new}$ is received from $GW$, $S{C}_i$ computes $H{P}_i=h(I{D}_i^{\prime }\parallel P{W}_i^{\prime }\parallel r_i)$, ${\beta }_i={\beta }_i^{*}\oplus H{P}_i$, $SD{L}_i^{new}*=SD{L}_i^{new}\oplus hH{P}_i\parallel {\beta }_i)$. Finally, $S{C}_i$ replaces $SD{L}_i^{*}$ with $SD{L}_i^{new}*$ in its memory.

6. Security Analysis

In this section, we verify the security reliability of 3ECAP using both formal and informal security analysis. Specifically, we first prove the security of session keys in the proposed protocol based on the ROR model. Then, we use informal security analysis to demonstrate that 3ECAP is secure in the face of access privilege escalation as well as other known attacks. In addition, we perform formal security verification using the popular automated verification tool Proverif.

6.1. ROR Model-Based Formal Security Analysis

We consider random oracles under the formal security model, where the adversary/attacker $\mathcal{A}$ can make multiple oracle queries (this part was not considered in the previous conference).

(1) ROR model:

In the login and authentication phase of 3ECAP, three participants $U_i$, $GW$ and $S{D}_j$ are involved in this process. The model considers the following.

Participants: The instances i, k, and j corresponding to the participants $U_i$, $GW$, and $S{D}_j$ can be denoted as ${\omega }_{U_i}^i$, ${\omega }_{GW}^k$, and ${\omega }_{S{D}_j}^j$, respectively, which are called oracles.

Accepted state: An instance ${\omega }^i$ is in the accept state, indicating that it has received the last message. Once the messages sent and received by ${\omega }^i$ are sequentially ordered, it forms the session identifier side of ${\omega }^i$ for the running session.

Partnering: Two instances, called ${\omega }^i$ and ${\omega }^j$, are partners if the following conditions are met: (1) ${\omega }^i$ and ${\omega }^j$ are in the accepted state; (2) ${\omega }^i$ and ${\omega }^j$ have the same session identification (sid), i.e., $si{d}_{\omega }^i=si{d}_{\omega }^j$; and (3) ${\omega }^i$’s partner identification (pid) is ${\omega }^j$ and vice versa.

Freshness: Two instances, called ${\omega }^i$ and ${\omega }^j$, are fresh if the key $s{k}_{ij}$ ($=s{k}_{ji}$) established between $U_i$ and $S{D}_j$ is not disclosed by adversary $\mathcal{A}$ through reveal query.

Adversary: Since the ROR model is based on the DY threat model, adversary $\mathcal{A}$ can fully control all messages transmitted in the network, which means that $\mathcal{A}$ can eavesdrop, modify, delete, forge, or inject messages between two entities.

Execute (${\omega }^i$,${\omega }^k$,${\omega }^j$): The passive attack is modeled under this query, which allows $\mathcal{A}$ to intercept all communication records between participants $U_i$, $GW$, and $S{D}_j$.

Send (${\omega }^i$,m): This query is considered an active attack, where $\mathcal{A}$ can send a message m to an instance ${\omega }^i$ and also receive a response message.

Reveal (${\omega }^i$): When this query is executed, the session key $s{k}_{ij}$ (=$s{k}_{ji}$) established between ${\omega }^i$ and its partner is leaked to $\mathcal{A}$.

CorruptSC (${\omega }_{U_i}^i$): Once such a query is executed, the information stored in the smart card $S{C}_i$ of $U_i$ is disclosed to $\mathcal{A}$.

CorruptSD (${\omega }_{S{D}_j}^j$): Under this query, $\mathcal{A}$ can extract all the sensitive information stored in a sensor by a power analysis attack. Therefore, this query is modeled as an active attack. In addition, we also assume that both $CorruptSC$ and $CorruptSD$ provide a weak corruption model where the temporary keys and internal data of the instance are not corrupted.

Test (${\omega }^i$): The semantic security of the session key $sk$ (i.e., $s{k}_{ij}$ or $s{k}_{ji}$) established between instances can be modeled with this query. Once this query is executed, a coin c is tossed and the result is returned to $\mathcal{A}$. If $c=1$, the instance returns $sk$ or a random number of the same length as $sk$ if $c=0$; otherwise, it returns a null value.

It is worth noting that, according to [34], we perform a limit on the number of queries for $CorruptSC$ and $CorruptSD$ queries. However, $\mathcal{A}$ is allowed to execute multiple $Test$ queries. Furthermore, since $GW$ is absolutely secure in the network, $\mathcal{A}$ cannot obtain any information from $GW$ by $Corrupt$ query. All participants and $\mathcal{A}$ have access to a one-way collision-resistant hash function $h(·)$, which is modeled as a random oracle.

(2) Security Proof: The semantic security (or AKE security) of the session key $SK$ in 3ECAP is given in Theorem 1. Furthermore, similar proofs [35] and [34] follow Theorem 1.

Theorem 1.

If $\mathcal{A}$ is the adversary in polynomial time against 3ECAP in the RoR model, and $q_h$, $q_s$, and $q_e$ denote the number of Hash queries, Send queries, and Execute queries, respectively, then

$$Ad{v}_{3ECAP,\mathcal{D}}^{\mathrm{AKE}}\le {\displaystyle \frac{q_h^2}{2^{l_h}}}+{\displaystyle \frac{{(q_s+q_e)}^2}{2^{l_r}}}+2max\left(C^{\prime }{q}_s^{s^{\prime }},{\displaystyle \frac{q_s}{2^{l_b}}},{\lambda }_p{q}_s\right)$$

where $l_h$, $l_r$, and $l_b$ refer to the length of the hash output, the length of the random number, and the length of the user bio-secret parameter $r_i$, respectively. $\mathcal{D}$ is denoted as the password space and obeys the Zipf distribution, and $C^{\prime }$ and $s^{\prime }$ are the parameters of Zipf.

Proof. 

The security proof of the proposed protocol (3ECAP) is composed of a series of games: $G_0$, $G_1$, $G_2$, $G_3$. Suppose $Suc{c}_{\mathcal{A}}^{G_j}$ ($j=0,1,2,3$) represents an event in which $\mathcal{A}$ successfully guesses the random bit c of a tossed coin in the game $G_j$ and the corresponding probability of occurrence is denoted as $Pr\left[Suc{c}_j\right]$. □

Game $G_0$: This is the initial game where $\mathcal{A}$ performs a real attack simulation on 3ECAP in the ROR model. Thus, according to the definition of semantic security, we have

$$Ad{v}_{3ECAP,\mathcal{D}}^{\mathrm{AKE}}=\left|2Pr\left[Suc{c}_0\right]-1\right|.$$ (1)

Game $G_1$: It corresponds to a passive attack implemented by $\mathcal{A}$, where $\mathcal{A}$ can perform an $Execute$ query and intercept all messages $M_1=\left\{A_i,B_i,C_i,RSI{D}_j,T_1\right\}$, $M_2=\left\{D_i,E_i,F_i,T_2\right\}$ and $M_3=\left\{G_i,H_i,J_i,T_3\right\}$ transmitted in the public channel during the login and authentication phases of $U_i$. Once the game is over, $\mathcal{A}$ executes a $Test$ query and discriminates the genuine $sk$ from a random number based on the results returned by the query, where $sk=h(b_i\parallel d_i\parallel RSI{D}_j\parallel c\parallel T_3)$, $b_i=h(RI{D}_i\parallel T_1\parallel a)$ and $d_i=h(k_{GWj}\parallel T_2)$. Therefore, $\mathcal{A}$ needs the secret information $RI{D}_i$, $k_{GWj}$ and a to calculate the session key $sk$. However, this secret information cannot be obtained by $\mathcal{A}$ by eavesdropping on messages $M_1$, $M_2$ and $M_3$. Therefore, the probability of adversary $\mathcal{A}$ winning the game $G_1$ does not increase. Due to the indistinguishability of games $G_0$ and $G_1$, we have

$$Pr\left[Suc{c}_1\right]=Pr\left[Suc{c}_0\right].$$ (2)

Game $G_2$: Game $G_2$ is modeled as an active attack where the primary goal of $\mathcal{A}$ is to attempt to convince participating nodes that the forged message is legitimate. Suppose that $\mathcal{A}$ performs $q_h$ number of Hash queries with the help of $q_s$ number of the $Send$ queries. Based on the results of the birthday paradox, the collision probability of the Hash query is at most ${\displaystyle \frac{q_h^2}{2^{l_h}}}$. Since the random numbers a, b and c exist in messages $M_1$, $M_2$ and $M_3$, respectively, the collision probability of the random numbers is at most ${\displaystyle \frac{{(q_s+q_e)}^2}{2^{l_r}}}$. Hence, we obtain

$$\left|Pr\left[Suc{c}_2\right]-Pr\left[Suc{c}_1\right]\right|\le {\displaystyle \frac{q_h^2}{2^{l_h}}}+{\displaystyle \frac{{(q_s+q_e)}^2}{2^{l_r}}}.$$ (3)

Game $G_3$: This is the last game, where $\mathcal{A}$ executes $CorruptSC$ and $CorruptSD$ queries. Specifically, the information $\left\{P_i,{\beta }_i^{*},SD{L}_i^{*},RI{D}_{GW},RI{D}_i,p_i\right\}$ stored in $S{C}_i$ and the information $\left\{RSI{D}_j,k_{GWj}\right\}$ stored in $S{D}_j$ are obtained by $\mathcal{A}$ using $CorruptSC$ and $CorruptSD$, respectively. Note that the pseudo-identity $RSI{D}_j$ and $k_{GWj}$ of all sensors are different from each other. In 3ECAP, $U_i$ uses both password $P{W}_i$ and bio-information $BI{O}_i$ for authentication, which can be divided into two cases.

Case 1: Suppose that $\mathcal{A}$ attempts to guess the low entropy password using $q_s$ number of the send queries. Since the user’s password follows Zipf’s law [36,37], the probability of this case is $C^{\prime }{q}_s^{s^{\prime }}$.

Case 2: Assume that $\mathcal{A}$ tries to extract the biological key $r_i$ of $U_i$ from the obtained information. Since 3ECAP adopts the fuzzy extractor technique, $\mathcal{A}$ can only extract at most $l_b$ random bits, and the corresponding probability of guessing $r_i$ is approximately $2^{-l_b}$. In addition, we consider the probability of false positive ${\lambda }_p$ that occurs for biometric feature extraction. In general, for fingerprints, ${\lambda }_p\approx 2^{-14}$ [34].

Therefore, based on case 1 and case 2, it follows that

$$\left|Pr\left[Suc{c}_3\right]-Pr\left[Suc{c}_2\right]\right|\le max\left(C^{\prime }{q}_s^{s^{\prime }},{\displaystyle \frac{q_s}{2^{l_b}}},{\lambda }_p{q}_s\right).$$ (4)

Since all queries are executed, $\mathcal{A}$ can only win the game by guessing bit c. This means that

$$Pr\left[Suc{c}_3\right]={\displaystyle \frac{1}{2}}.$$ (5)

From (1) and (2), it is given that

$${\displaystyle \frac{1}{2}}Ad{v}_{3ECAP,\mathcal{D}}^{\mathrm{AKE}}=\left|Pr\left[Suc{c}_1\right]-{\displaystyle \frac{1}{2}}\right|.$$ (6)

From (5) and (6), we have

$${\displaystyle \frac{1}{2}}Ad{v}_{3ECAP,\mathcal{D}}^{\mathrm{AKE}}=\left|Pr\left[Suc{c}_1\right]-Pr\left[Suc{c}_3\right]\right|.$$ (7)

Using the trigonometric inequality, we can obtain

$$\begin{array}{c}\hfill \left|Pr\left[Suc{c}_1\right]-Pr\left[Suc{c}_3\right]\right|\le \left|Pr\left[Suc{c}_1\right]-Pr\left[Suc{c}_2\right]\right|\\ \hfill +\left|Pr\left[Suc{c}_2\right]-Pr\left[Suc{c}_3\right]\right|.\end{array}$$ (8)

Finally, from (3), (4), (7) and (8), we have

$$Ad{v}_{3ECAP,\mathcal{D}}^{\mathrm{AKE}}\le {\displaystyle \frac{q_h^2}{2^{l_h}}}+{\displaystyle \frac{{(q_s+q_e)}^2}{2^{l_r}}}+2max\left(C^{\prime }{q}_s^{s^{\prime }},{\displaystyle \frac{q_s}{2^{l_b}}},{\lambda }_p{q}_s\right).$$

6.2. Informal Security Analysis

(1) Medical Staff Impersonation Attack: The adversary/attacker $\mathcal{A}$ who attempts to impersonate a legitimate medical staff needs to create a valid message $M_1=\left\{A_i,B_i,C_i,RSI{D}_j,T_1\right\}$, where $A_i=RI{D}_i\oplus h(RI{D}_{GW}\parallel T_1)$, $B_i=h(RI{D}_i\parallel RI{D}_{GW}\parallel T_1)\oplus b_i$, $C_i=h(b_i\parallel SD{L}_i\parallel RI{D}_{GW}\parallel RSI{D}_j\parallel T_1)$. Even if $\mathcal{A}$ can generate the timestamp $T_1^{\prime }$ and the random number $a^{\prime }$, $\mathcal{A}$ cannot recover $M_1$ due to the lack of the key secret information $RI{D}_i$, $RI{D}_{GW}$, $b_i$ and $SD{L}_i^{\prime }$. This indicates that 3ECAP is secure against a user impersonation attack.

(2) Gateway Impersonation Attack: In order to become a legitimate node by impersonating $GW$, adversary $\mathcal{A}$ needs to create a message $M_2=\left\{D_i,E_i,F_i,T_2\right\}$ to send to $S{D}_j$, where $D_i=b\oplus h(k_{GWj}\parallel T_2)$, $E_i=b_i\oplus h(b\parallel T_2)$, $F_i=h(RSI{D}_j\parallel k_{GWj}\parallel b_i\parallel b\parallel T_2)$. Even if $\mathcal{A}$ can generate the timestamp $T_2^{\prime }$ and the random number $b^{\prime }$, $\mathcal{A}$ will be unable to recover $M_2$ as the calculations of $\left\{D_i,E_i,F_i\right\}$ need the secret information $k_{GWj}$, $b_i$ and $RSI{D}_j$. Thus, 3ECAP is protected in a gateway impersonation attack.

(3) Sensor Impersonation Attack: Suppose that $\mathcal{A}$ attempts to generate a message $M_3=\left\{G_i,H_i,J_i,T_3\right\}$ on behalf of $S{D}_j$ to become a legitimate device node, where $G_i=c\oplus b_i$, $H_i=c\oplus d_i$, $J_i=h(RSI{D}_j\parallel d_i\parallel c\parallel T_3)$. Although $\mathcal{A}$ can generate timestamp $T_3^{\prime }$ and random number $c^{\prime }$ due to the absence of secret information $b_i$ and $d_i$, $\mathcal{A}$ also cannot recover $M_3$.

(4) Stolen Verifier Attack: Assume that $\mathcal{A}$ has stolen the medical staff’s smart card $S{C}_i$ and obtains the secret information $\left\{P_i,{\beta }_i^{*},SD{L}_i^{*},RI{D}_{GW},RI{D}_i,p_i\right\}$ stored in $S{C}_i$ using the power analysis attack, where $P_i=h(I{D}_i\parallel h(P{W}_i\parallel r_i))$, ${\beta }_i^{*}={\beta }_i\oplus H{P}_i$, $SD{L}_i^{*}=SD{L}_i\oplus h(H{P}_i\parallel {\beta }_i)$, $RI{D}_i=h(I{D}_i\parallel I{D}_{GW}\parallel {\beta }_i)$, $RI{D}_{GW}=h(I{D}_{GW}\parallel x)$. Suppose $\mathcal{A}$ guesses a password $P{W}_i^{\prime }$ and attempts to verify its authenticity using known information. However, verifying $P{W}_i^{\prime }$ requires guessing both the identity $I{D}_i$ and the secret information $r_i$ of $U_i$, which is computationally difficult to achieve due to the collision-resistant property of $h(·)$ (see Definition 1). Similarly, A cannot guess the bio-information $r_i$ correctly without $I{D}_i$ and $P{W}_i$. Moreover, it is not possible for $\mathcal{A}$ to compute other information, such as ${\beta }_i$ and $SD{L}_i$, in the absence of $H{P}_i$. Hence, 3ECAP is secure against a stolen smart card attack.

(5) Replay Attack: Suppose that adversary $\mathcal{A}$ intercepts messages $M_1$, $M_2$ and $M_3$ in a session and replays them after some time. The replay attack makes the participating nodes unable to recognize the authenticity of the messages and may lead to system breakdown as the number of replayed messages increases. However, due to the presence of timestamp T in $M_1$, $M_2$ and $M_3$, when a node receives a message, the first task for it is to verify the validity of T under the condition $\left|T^{*}-T\right|\le \Delta T$, where $T^{*}$ represents the reception timestamp. Therefore, 3ECAP is secure against a replay attack.

(6) Denial-of-Service Attack: In the login and authentication phase of medical staff $U_i$, $U_i$ first inserts the smart card $S{C}_i$ and imprints his or her bio-information $BI{O}_i^{\prime }$ on the acquisition device, and also enters the corresponding identity $I{D}_i^{\prime }$ and password $P{W}_i^{\prime }$. If the condition $HamDis(BI{O}_i^{\prime },BI{O}_i)\le t$ is not satisfied, the whole session is terminated. Otherwise, $S{C}_i$ computes $r_i=Rep(BI{O}_i^{\prime },p_i)$, $P_i^{\prime }=h(I{D}_i^{\prime }\parallel h(P{W}_i^{\prime }\parallel r_i))$, and verifies $P_i^{\prime }\stackrel{?}{=}{P}_i$. The session is also aborted if the equation does not hold. Therefore, it is clear that 3ECAP is capable of dealing with denial-of-service attacks.

(7) Sensor Device Capture Attack: Assume that $\mathcal{A}$ has captured $S{D}_j$ and obtained information $\left\{RSI{D}_j,k_{GWj}\right\}$ from it and attempts to compute the session key between $U_i$ and other uncaptured sensors $S{D}_j^{\prime }$ based on $\left\{RSI{D}_j,k_{GWj}\right\}$, where $RSI{D}_j=h(SI{D}_j\parallel I{D}_{GW}\parallel {\alpha }_j)$, $k_{GWj}=h(I{D}_{GW}\parallel SI{D}_j\parallel x)$. However, it is difficult for $\mathcal{A}$ to accomplish this task as these calculations require $SI{D}_j$ and ${\alpha }_j$, which are randomly generated by $GW$. Hence, 3ECAP is secure in the face of a sensor device capture attack.

(8) Man-in-the-Middle Attack: In this attack, adversary $\mathcal{A}$ intercepts the messages $M_1$, $M_2$ and $M_3$ in a particular session and attempts to modify them into another form, which can make it impossible for participating nodes, such as $U_i$, $GW$, and $S{D}_j$, to determine whether they are communicating with a legitimate node. Suppose $\mathcal{A}$ intercepts message $M_1=\left\{A_i,B_i,C_i,RSI{D}_j,T_1\right\}$ and forges a new message $M_1^{\prime }$ using the information in it, where $A_i=RI{D}_i\oplus h(RI{D}_{GW}\parallel T_1)$, $B_i=h(RI{D}_i\parallel RI{D}_{GW}\parallel T_1)\oplus b_i$, $C_i=h(b_i\parallel SD{L}_i^{\prime }\parallel RI{D}_{GW}\parallel RSI{D}_j\parallel T_1)$. Even if $\mathcal{A}$ has the ability to generate timestamp $T_1^{\prime }$ and random number $a^{\prime }$, $\mathcal{A}$ cannot forge message $M_1^{\prime }$, which can be recognized by participating nodes, due to the fact that these calculations require secret information $RI{D}_i$, $RI{D}_{GW}$, $b_i$ and $SD{L}_i^{\prime }$. Similarly, adversary $\mathcal{A}$ cannot forge $M_2^{\prime }$ and $M_3^{\prime }$. Therefore, 3ECAP is safe in responding to a man-in-the-middle attack.

(9) Insider Privilege Attack: There may be a scenario in which a privileged internal personnel of the trusted $GW$ serves as an internal attacker $\mathcal{A}$. This attack can be divided into two cases as follows.

Case 1: Assume that $\mathcal{A}$ obtains $RI{D}_i$ of $U_i$ during the medical staff registration phase, where $RI{D}_i=h(I{D}_i\parallel I{D}_{GW}\parallel {\beta }_i)$. Without knowing the identity $I{D}_i$ of $U_i$ and the random number ${\beta }_i$, it is difficult for A to guess one of them correctly from $RI{D}_i$ due to the collision resistance property of $h(·)$.

Case 2: Suppose that $\mathcal{A}$ intercepts message $\left\{P_i,RI{D}_i,SD{L}_i,RI{D}_{GW}\right\}$ at the time of medical staff registration, which is initially sent by $GW$ to $U_i$ via a secure channel, where $P_i=h(I{D}_i\parallel RP{W}_i)$, $SD{L}_i=h(Ve{r}_i\parallel T_{re}\parallel RI{D}_i)$, $RI{D}_{GW}=h(I{D}_{GW}\parallel x)$. However, $\mathcal{A}$ cannot obtain any information from the message, due to the lack of $I{D}_i$, $RP{W}_i$, $Ve{r}_i$, $T_{re}$, $I{D}_{GW}$, x and the collision resistance property of $h(·)$. Hence, 3ECAP has the capability to cope with a privileged-insider attack.

(10) Privilege Escalation Attack: In this attack, medical staff $U_i$, authorized by $GW$, wants to gain data from other devices, which are out of $U_i$’s access list, by upgrading his/her access privilege. For this purpose, the access list $AL$ for $U_i$ needs to be changed from $AL=\left\{RSI{D}_1,RSI{D}_2,...,RSI{D}_j\right\}$ to $A{L}^{\prime }=\left\{RSI{D}_1^{\prime },RSI{D}_2^{\prime },...,RSI{D}_j^{\prime }\right\}$, such that $A{L}^{\prime }\ne AL$ and $Ve{r}_i^{\prime }=Ve{r}_i$, when $U_i$’s sensor device list is $SD{L}_i=h(Ve{r}_i\parallel T_{re}\parallel RI{D}_i)$. Although $U_i$ gains $T_{re}$, he or she cannot upgrade $AL$ while keeping $SD{L}_i$ unchanged, as explained below.

Note: Let $f_j(·)$ be a function for the calculation of the root hash of a $merkle$ tree consisting of j leaf nodes. Also let $\left\{RSI{D}_1,RSI{D}_2,...,RSI{D}_j\right\}$ be denoted as $\left\{D_1,D_2,...,D_j\right\}$. Then, we prove that $f_j(·)$ has the property of collision resistance by mathematical induction, same as $h(·)$. In order not to lose generality, assume that $j=2^m$ for $m\ge 1$. Given $AL=\left\{D_1,D_2\right\}$ for $m=1$, we have

$$f_2(D_1,D_2)=h(H_{10}\parallel H_{11})$$ (9)

where $H_{10}=D_1$ and $H_{11}=D_2$. It is obvious that $f_2(·)$ is a collision-resistant function, same as $h(·)$. Suppose the same is true when $m=k$, that is, there is no

$$f_{2^k}(D_1,D_2,...,D_{2^k})=f_{2^k}(D_1^{\prime },D_2^{\prime },...,D_{2^k}^{\prime })$$ (10)

where $\left\{D_1,D_2,...,D_j\right\}\ne \left\{D_1^{\prime },D_2^{\prime },...,D_j^{\prime }\right\}$. Then, when $m=k+1$, we have

$$f_{2^{k+1}}(D_1,D_2,...,D_{2^{k+1}})=h(H_{10}\parallel H_{11})$$ (11)

$$H_{10}=f_{2^k}(D_1,D_2,...,D_{2^k})$$ (12)

$$H_{11}=f_{2^k}(D_{2^k+1},D_{2^k+2},...,D_{2^{k+1}}).$$ (13)

Therefore, it follows from (9), (10), (11), (12) and (13) that $f_j(·)$ is as collision resistant as $h(·)$. Let $AL=\left\{D_1,D_2,...,D_j\right\}$ and $A{L}^{\prime }=\left\{D_1^{\prime },D_2^{\prime },...,D_j^{\prime }\right\}$, where $j=2^m$ for $m\ge 1$ and $\left\{D_1,D_2,...,D_j\right\}\ne \left\{D_1^{\prime },D_2^{\prime },...,D_j^{\prime }\right\}$. Next, $Ve{r}_i=f_j(D_1,D_2,...,D_j)$ and $Ve{r}_i^{\prime }=f_j(D_1^{\prime },D_2^{\prime },...,D_j^{\prime })$. Due to the collision-resistant nature of $f_j(·)$, it is not feasible to find $A{L}^{\prime }$, where $A{L}^{\prime }\ne AL$, such that $Ve{r}_i=Ve{r}_i^{\prime }$ is satisfied.

Suppose $U_i$ obtains the registration timestamp $T_{re}$ and extracts the pseudo-identity $RI{D}_i$ by power analysis attack, which is stored in $S{C}_i$. Then, $U_i$ expands the permissions to $A{L}^{\prime }=\left\{D_1^{\prime },D_2^{\prime },...,D_j^{\prime }\right\}$ and computes $Ve{r}_i^{\prime }=f_j(D_1^{\prime },D_2^{\prime },...,D_j^{\prime })$ and $SD{L}_i^{\prime }=h(Ve{r}_i^{\prime }\parallel T_{re}\parallel RI{D}_i)$. However, in step 2.1 of the authentication phase, $GW$ uses $SD{L}_i$ stored in the database to compute $C_i^{\prime }=h(b_i\parallel SD{L}_i\parallel RI{D}_{GW}\parallel RSI{D}_j\parallel T_1)$ and verify $C_i^{\prime }\stackrel{?}{=}{C}_i$, where $C_i$ belongs to $M_1$ and is sent by $U_i$ to $GW$. It is clear that $C_i^{\prime }\ne C_i$ because of the collision-resistant property of $f_j(·)$ and $h(·)$ such that the whole session is terminated. Thus, 3ECAP is protected against a privilege escalation attack.

(11) Anonymity and Untraceability: In 3ECAP, all messages $M_1=\left\{A_i,B_i,C_i,RSI{D}_j,T_1\right\}$, $M_2=\left\{D_i,E_i,F_i,T_2\right\}$ and $M_3=\left\{G_i,H_i,J_i,T_3\right\}$ of a particular session are set with timestamps $T_1$, $T_2$ and $T_3$, respectively, and also with random numbers a, b and c, which ensure that the participants $U_i$, $GW$ and $S{D}_j$ in the session are not tracked by the adversary. Furthermore, 3ECAP uses pseudo-identities $RI{D}_i$, $RI{D}_{GW}$ and $RSI{D}_j$ to transmit information in the public channel instead of the original identities $I{D}_i$, $I{D}_{GW}$ and $SI{D}_j$, respectively, of the participating nodes in the session. Therefore, the anonymity of all participants in 3ECAP can be guaranteed.

6.3. Formal Verification with Proverif

Proverif is a formal automatic verification cryptographic protocol tool based on the Dolev–Yao model developed by Bruno Blanchet, which is able to describe various cryptographic primitives such as shared key cryptography and public key cryptography (encryption and digital signatures), Hash functions and Diffie–Hellman key exchange protocols. In addition, Proverif can handle an infinite session concurrent protocol and infinite message space, which overcomes the problem of state space explosion. When applying the Proverif tool to verify a cryptographic protocol, the tool gives a sequence of attacks if the protocol is vulnerable. All details about the usage of Proverif are in [38].

Four different channels, $sch1$, $sch2$, $ch1$ and $ch2$, are defined in Proverif, where $sch1$ and $sch2$ are secure channels for node registration and $ch1$ and $ch2$ are public channels for medical staff login and authentication. In addition, we define three processes for $U_i$, $GW$, and $S{D}_j$, respectively, and use $process!User|!GW|!Device$ to implement the parallel operation of the three entities.

The results of the Proverif execution are shown in Table 3 [30] and Figure 5. The first two rows demonstrate that both weak $I{D}_i$ and $P{W}_i$ can cope with guessing attacks. The last two rows imply that the generated session keys between $U_i$ and $S{D}_j$ are robust against common attacks. Therefore, 3ECAP is secure under formal verification.

Table 3.

Results for code.

Secure channel	$sch1$, $sch2$
Public channel	$ch1$, $ch2$
Process	$User$, $GW$, $Device$
RESULT Weak secret IDi is true (bad not derivable).
RESULT Weak secret PWi is true (bad not derivable).
RESULT not attacker(skij[]) is true.
RESULT not attacker(skji[]) is true.

Figure 5.

Results of executing Proverif.

7. Comparative Analysis

In this section, a comparative analysis of the calculation cost, communication and security features of 3ECAP and related protocols for Li et al. [26], Xie et al. [27], Son et al. [28] and Yang et al. [29] is shown.

7.1. Calculation Costs Comparison

The calculation costs required for 3ECAP and other protocols in the login and authentication phases are provided in this section. Assume that $T_h$, $T_{as}$, $T_{bp}$, $T_{ecc}$ and $T_f$ represent the time required for the hash function (SHA-256), asymmetric encryption/decryption (RSA-1024), bilinear pairing, ECC point multiplication and fuzzy extractor, respectively. Based on the available experimental results of Challa et al. [39], the time required to use these functions are $T_h=0.019$ ms, $T_{as}=19.536$ ms, $T_{bp}=44.517$ ms, $T_{ecc}=2.61$ ms and $T_f=1.71$ ms. Specifically, the various calculation costs required for the user, gateway, and sensor in each protocol are shown in Table 4 and Figure 6. The calculation cost of 3ECAP for the $U_i$, $GW$, and $S{D}_j$ are, respectively, $T_f+10T_h$, $6T_h$ and $6T_h$. The total calculation cost of 3ECAP is only $24.14$ ms compared to other protocols, which is especially suitable for the communication requirements for IoMT.

Table 4.

Calculation costs comparison.

Protocol	User	Gateway	Sensor Device	Total Cost	Rough Estimation
3ECAP	$T_f+10T_h$	$6T_h$	$6T_h$	$T_f+22T_h$	$24.14$ ms
Li et al. [26]	$T_f+3T_{ecc}+8T_h$	$T_{ecc}+8T_h$	$2T_{ecc}+4T_h$	$T_f+6T_{ecc}+20T_h$	$33.14$ ms
Xie et al. [27]	$12T_h+5T_{ecc}$	$10T_h+6T_{ecc}$	$7T_h+2T_{ecc}$	$29T_h+13T_{ecc}$	$34.481$ ms
Son et al. [28]	$15T_h+3T_{ecc}$	$8T_h+3T_{ecc}+T_{as}$	$10T_h+2T_{as}$	$33T_h+6T_{ecc}+3T_{as}$	$69.159$ ms
Yang et al. [29]	$5T_h+7T_{ecc}+3T_{bp}$	$2T_h+2T_{ecc}+4T_{bp}$	$2T_h+2T_{ecc}+3T_{bp}$	$9T_h+11T_{ecc}+10T_{bp}$	$474.051$ ms

Figure 6.

Comparison of calculation and communication cost [26,27,28,29].

7.2. Communication Costs Comparison

To measure the communication cost of the login and authentication phase, we assume that the identity, hash digest, random nonce, ECC point multiplication, asymmetric encryption/decryption (RSA-1024), and timestamp are 160 bits, 160 bits, 128 bits, 320 bits, 512 bits and 32 bits, respectively. Therefore, the total communication cost in 3ECAP is 1696 bits. The protocols of Li et al. [26], Xie et al. [27], Son et al. [28] and Yang et al. [29] require 2720, 2496, 3136, and 4080 bits (b) of communication cost, respectively. The details are shown in Table 5.

Table 5.

Communication costs comparison.

Messages	3ECAP	[26]	[27]	[28]	[29]
$U_i\to GW$	672 b	800 b	960 b	672 b	684 b
$GW\to S{D}_j$	512 b	640 b	1088 b	672 b	2684 b
$S{D}_j\to GW$	—	640 b	—	—	—
$GW\to U_i$	—	640 b	—	—	—
$S{D}_j\to U_i$	512 b	—	448 b	1792 b	712 b
Total cost	1696 b	2720 b	2496 b	3136 b	4080 b

7.3. Security Features Comparison

The comparative analysis of thesecurity and functional features of 3ECAP and other related protocols is presented in Table 5. It can be observed that 3ECAP provides improved security and more functional features compared to the other four protocols. For example, the protocol by Li et al. [26] directly uses the identity of the participating nodes for information transmission, which can be easily tracked by the adversary. Moreover, in IoMT, the permission of different levels of users should be divided, which is not involved in the four other protocols. In contrast, 3ECAP divides several sensors into corresponding clusters based on the user’s access list and stores $SD{L}_i$ in a smart card and gateway, which not only achieves permission segmentation but also eliminates part of the subsequent database validation. Therefore, 3ECAP clearly outperforms other related protocols according to the comparison of all the features in Table 6.

Table 6.

Security features comparison.

Feature	3ECAP	[26]	[27]	[28]	[29]
User impersonation attack	✔	✔	✔	×	✔
Gateway impersonation attack	✔	✔	✔	×	✔
Sensor device impersonation attack	✔	✔	✔	×	✔
Stolen verifier attack	✔	—	✔	×	✔
Replay attack	✔	✔	✔	✔	✔
Denial-of-service attack	✔	✔	×	×	×
Sensor device capture attack	✔	×	✔	×	×
Man-in-the-middle attack	✔	×	✔	✔	✔
Insider privilege attack	✔	×	✔	×	✔
Privilege escalation attack	✔	×	×	×	×
Anonymity	✔	—	×	✔	×
Untraceability	✔	✔	×	×	×
Forward secrecy	✔	✔	✔	✔	×
Mutual authentication	✔	✔	✔	✔	×
Session key agreement	✔	×	✔	✔	✔
Biometric update	✔	✔	×	×	×
Password change	✔	✔	✔	×	×
Sensor device addition	✔	—	—	—	—
Two/three factor authentication	3	3	3	2	2
Fine-grained access control	✔	×	×	×	×
Formal analysis	✔	✔	✔	×	✔
Authentication based on Proverif/AVISPA tool	✔	✔	✔	×	×

✔: The protocol securely resists a particular attack or supports a particular feature; ×: the protocol is insecure against a particular attack or does not support a particular feature; —: not applied in the protocol.

8. NS3 Simulation

In this section, we attempt to measure the performance of 3ECAP in terms of network throughput (in bytes/second) and end-to-end delay (EED, in seconds) using the widely accepted NS3 tool (this part was not considered in the previous conference).

8.1. Simulation Parameters and Scenario

Table 7 [30] lists the basic network parameters used in the NS3 simulation. We used the Ubuntu 18.04.4 LTS platform. The simulation of the user, gateway, and sensor was executed on 2.4GHz Wi-Fi media. The gateway was set at the origin. The users were permitted to move randomly in any direction at a speed of 3 m within a 150 m² area centered at the origin. Sensors were randomly distributed on an 80-m ring and centered on the gateway. We then set the size of the messages transmitted between the nodes, i.e., $M_1=84$ bytes, $M_2=64$ bytes, and $M_3=64$ bytes.

Table 7.

Simulation parameters.

Parameter	Description
Platform	NS3 3.27/Ubuntu 18.04.4 LTS
Mobility	random (3 m/s)
Simulation time	1200 s
Scenarios	No. of users	No. of devices
1	10	5
2	5	10
3	8	10
4	5	15
5	5	20
6	8	50

In this scenario, a complete message transfer consists of (the NS3 simulation does not involve specific cryptographic operations) (1) the user first sends an authentication request $M_1$ to a gateway in order to access the device; (2) the gateway receives the request and then forwards $M_2$ to the device; and (3) once it receives the message from gateway, the device sends the message $M_3$ to the user. Through 1, 2 and 3, the information interaction between a user and a device can be accomplished. Meanwhile, since there is more than one user and device in the scenario, they can all authenticate each other through the gateway. Therefore, it can be assumed that there are multiple message transfers at a given moment. And the main purpose of using NS3 is to show how the total throughput and delay change with the number of participating nodes.

We also set the simulation time for this scenario to 1200 s, which is a relatively appropriate setting that is sufficient to reflect the simulation results of 3ECAP. Finally, we configure a different number of users and devices, and the simulation parameters and results are shown in Table 7 [30] and Figure 7.

Figure 7.

NS3-based 3ECAP simulation results.

8.2. Discussion of Simulation Results

(1) Impact on Network Throughput: The total throughput of 3ECAP in the six scenarios is represented by bar charts in Figure 7. The throughput is calculated as ${\varrho }_d/({\sigma }_s-{\sigma }_r)$, where the total amount of data received in the simulated environment is ${\varrho }_d$, the time to send the first packet is ${\sigma }_s$, and the time to receive the last packet is ${\sigma }_r$. It is observed that as the number of participating nodes, including users and sensors, increases, the network throughput in the network also increases accordingly.

(2) Impact on End-to-End Delay: The total delay of 3ECAP in the six scenarios is represented by the discounted graph in Figure 7. EED delay can be expressed as ${\sum }_{i=1}^{{\nu }_p}(T_{si}-T_{ri})/{\nu }_p$, where $T_{si}$ and $T_{ri}$ represent the sending time and receiving time, respectively, when the ith packet is transmitted, and the total number of packets transmitted during the simulation is ${\nu }_p$. It follows from the figure that when the number of participating nodes increases, the number of messages transmitted will increase, which may cause network congestion to the extent that the EED delay increases.

9. Conclusions

Considering the aspects of security, low cost, and access control for IoMT sensors, in this paper, we propose a new efficient cluster-based user authentication protocol (3ECAP). In 3ECAP, three factors, i.e., password, biometric and smart card, are employed to resist a single-factor incidental guessing attack. In addition, 3ECAP enables user-specific privilege segmentation through fine-grained access control and can address the resulting privilege escalation attack. Furthermore, provable security based on the ROR model, formal verification based on the Proverif tool, as well as non-formal analysis are provided in this paper, and the results demonstrate the robustness of 3ECAP in the face of most attacks. Finally, the comparison and analysis with the latest related protocols indicate that 3ECAP provides higher security and lower computation and communication costs; therefore, it is very suitable for the practical deployment of the IoMT.

Future research directions related to this paper are as follows: (1) implementing and evaluating 3ECAP in real IoMT environments, (2) providing a flexible on-line sensor device addition phase, and (3) supporting dynamic updating of user-accessible lists based on sensor clusters in order to maintain forward and backward secrecy.

Author Contributions

Conceptualization, X.S. and Y.X.; methodology, X.S.; software, X.S.; validation, X.S. and Y.X.; formal analysis, X.S.; investigation, X.S.; resources, X.S. and Y.X.; data curation, X.S.; writing—original draft preparation, X.S.; writing—review and editing, X.S. and Y.X.; visualization, X.S.; supervision, X.S. and Y.X.; project administration, X.S. and Y.X.; funding acquisition, X.S. All authors have read and agreed to the published version of the manuscript.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

Data are contained within the article.

Conflicts of Interest

The authors declare no conflicts of interest.

Funding Statement

The work of this paper was funded by the National Natural Science Foundation of China No. 62371246 and the Practice Innovation Program of Jiangsu Province No. KYCX22_0936.