Efficient IoT User Authentication Protocol with Semi-Trusted Servers

Abstract

Internet of Things (IoT) user authentication protocols enable secure authentication and session key negotiation between users and IoT devices via an intermediate server, allowing users to access sensor data or control devices remotely. However, the existing IoT user authentication schemes often assume that the servers (registration center and intermediate servers) are fully trusted, overlooking the potential risk of insider attackers. Moreover, most of the existing schemes lack critical security properties, such as resistance to ephemeral secret leakage attacks and offline password guessing attacks, and they are unable to provide perfect forward security. Furthermore, with the rapid growth regarding IoT devices, the servers must manage a large number of users and device connections, making the performance of the authentication scheme heavily reliant on the server’s computational capacity, thereby impacting the system’s scalability and efficiency. The design of security protocols is based on the underlying security model, and the current IoT user authentication models fail to cover crucial threats like insider attacks and ephemeral secret leakage. To overcome these limitations, we propose a new security model, IoT-3eCK, which assumes semi-trusted servers and strengthens the adversary model to better meet the IoT authentication requirements. Based on this model, we design an efficient protocol that ensures user passwords, biometric data, and long-term keys are protected from insider users during registration, mitigating insider attacks. The protocol also integrates dynamic pseudo-identity anonymous authentication and ECC key exchange to satisfy the security properties. The performance analysis shows that, compared to the existing schemes, the new protocol reduces the communication costs by over 23% and the computational overhead by more than 22%, with a particularly significant reduction of over 95% in the computational overhead at the intermediate server. Furthermore, the security of the protocol is rigorously demonstrated using the random oracle model and verified with automated tools, further confirming its security and reliability.

1. Introduction

The Internet of Things (IoT) is transforming the way we interact with the physical world by connecting everyday devices to the Internet, creating an intelligent and automated ecosystem [1]. The IoT is transforming multiple fields, including industry, agriculture, power grids, transportation, the environment, healthcare, smart homes, and security and surveillance. As illustrated in Figure 1, the IoT system is composed of IoT devices, gateways, servers, and remote users, which form the foundation to enable the acquisition, processing, and transmission of real-time data. In smart homes, smart healthcare, and industrial IoT application systems, users need to remotely access or control IoT devices and send them specific instructions [2]. Without effective user authentication, attackers can impersonate legitimate users and send fake malicious instructions to IoT devices, threatening the security of the entire system. IoT user authentication protocols enable secure authentication and session key negotiation between users and IoT devices through an intermediate server, allowing users to access or control IoT devices directly and securely. Therefore, establishing a robust IoT authentication mechanism is crucial to ensuring these systems’ security [3].

As illustrated in Figure 2, in the IoT user authentication protocols, after the devices and users register, each entity obtains its own long-term key. Subsequently, the user and the IoT device use these long-term keys, as well as the temporary keys generated during authentication, to generate authentication messages. These messages are then exchanged between the two entities for mutual authentication and negotiation of session keys. However, IoT devices are easily captured physically when they are usually deployed in unattended environments. Attackers may gain access to long-term secrets through side-channel attacks [4,5]. In addition, servers may suffer from data leakage and unauthorized access due to malware or misconfigurations [6,7]. Given that IoT systems often involve sensitive data, including user location information, network activities, and consumption habits, as well as potentially confidential corporate or national security information, authentication and authorized data access have become essential security requirements for IoT applications. In addition, the design of authentication protocols is particularly challenging as IoT devices are resource-limited, usually powered by batteries, and have limited computing, storage, and communication capabilities [8].

In recent years, numerous IoT user authentication protocols [9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26] have been proposed as shown in

Table 1. Summary of relevant ECC-based user AKA protocols.

Scheme	Year	Shortcomings
Jiang et al. [9]	2016	Prone to offline password guessing, ESL, and insider sensor impersonation attacks; lacking key privacy, FPS, and timely typo detection.
Wu et al. [10]	2017	Prone to offline password guessing, ESL, and insider sensor impersonation attacks; lacking untraceability, key privacy, and FPS.
Challa et al. [12]	2017	Prone to offline password guessing, impersonation, and insider IoT device impersonation attacks; lacking key privacy, anonymity, and untraceability; has high computation.
Li et al. [13]	2018	Prone to offline password guessing, replay, ESL, insider sensor impersonation, and impersonation attacks; lacking key privacy.
Li et al. [14]	2018	Prone to offline password guessing, insider sensor impersonation, and ESL attacks; lacking user untraceability and PFS.
Shuai et al. [15]	2019	Prone to offline password guessing, insider IoT device impersonation, and ESL attacks; lacking user untraceability, key privacy, and PFS.
Lu et al. [28]	2019	Based on the sensor ID and the information detected throughout the open channels, an attacker can quickly determine the session key.
Li et al. [17]	2020	Prone to insider sensor impersonation, impersonation, and ESL attacks; has poor usability.
Sadhukhan et al. [18]	2021	Prone to replay, ESL, man-in-the-middle, and DoS attacks; lacking user anonymity and timely typo detection.
Wazid et al. [19]	2021	Prone to offline password guessing, insider sensor impersonation, desynchronization, and man-in-the-middle attacks; lacking user untraceability and PFS; has high computation.
Srinivas et al. [20]	2021	Prone to session key compromise and device impersonation attacks; lacking user anonymity and PFS; has high computation.
Sutrala et al. [21]	2022	Prone to smart card/device loss and offline password guessing attacks; lacking user untraceability; has high computation.
Tanveer et al. [22]	2022	Prone to man-in-middle, insider sensor impersonation, and offline password guessing attacks; lacking user untraceability and PFS.
Chen et al. [24]	2023	Prone to insider sensor impersonation and ESL attacks; has poor usability.
Wang et al. [25]	2023	Prone to insider IoT device impersonation and ESL attacks.
Kumar et al. [26]	2024	Prone to insider sensor impersonation attacks and ESL attacks; lacking PFS and key privacy.

. However, the existing schemes generally assume that the servers (registration center (RC) and intermediate server) are fully trusted, overlooking the potential threat of insider attackers. In real applications, server data breaches and unauthorized port listening events are common due to issues such as misconfigurations, memory leaks, and malware. In addition, insider-infected actions (such as employees, contractors, or partners) pose significant security risks to IoT systems [6,7]. During registration, the RC generates long-term keys for the IoT devices and stores them on both the devices and the intermediate server. This setup allows insiders on the servers to access the keys, potentially enabling insider attacks. For example, insider users on the intermediate server can perform insider impersonation attacks [9,10,12,13,14,15,17,19,22,23,24,25,26] or derive session keys negotiated between users and IoT devices, resulting in protocols with no key privacy security [9,10,12,13,15,26]. Another critical issue is the handling of ephemeral secrets, which are often precalculated and stored in insecure memory [27]. Unfortunately, this risk is largely neglected in current IoT user authentication protocols [9,10,12,13,14,15,16,17,18,19,20,21,22,24,25,26], leaving these schemes vulnerable to ephemeral secret leakage (ESL) attacks. Furthermore, many protocols lack essential features, such as perfect forward security (PFS) and anonymity. They are also prone to offline password guessing attacks and are inefficient for resource-constrained IoT devices. More importantly, with the rapid growth regarding IoT devices, intermediate servers must manage a large number of users and device connections, which makes the performance of authentication schemes highly dependent on the server’s computational and processing capabilities [25]. However, there is still a lack of substantial research focused on optimizing server overhead in the current studies.

The design of security protocols is based on the underlying security model, where the attacker model defines the potential capabilities and goals of the attackers. This model not only determines the security assumptions of the protocol but also directly shapes the evaluation framework for security analysis. In the existing research, the Dolev–Yao security model [29] and the eCK security model [30] are the most widely accepted. The Dolev–Yao model assumes that the attacker has full control over the communication channel, allowing him to intercept, modify, forge, and replay messages. The eCK model extends this by allowing the attacker to access sensitive information, such as long-term keys, session keys, and ephemeral secrets. However, the eCK model focuses mainly on two-party single-factor authentication protocols and does not fully address multifactor or three-party authentication scenarios. In recent years, there has been growing attention regarding attacker models for multifactor user authentication protocols. Yoneyama [31] extended the eCK model to password-based three-party authentication key-exchange protocols but did not account for threats related to smart card loss and offline password guessing attacks. Wang et al. [32] studied the impact of the loss of smart cards and offline password guessing attacks on the security of two-factor authentication protocols, and their results have been adopted as a standard in many subsequent schemes. However, their work did not address the leakage of ephemeral secrets. In conclusion, the existing security models for IoT user authentication fail to fully cover key security threats, such as insider attacks and ephemeral secrets.

To address the issues in the existing IoT user authentication protocols, we introduce a new security model, IoT-3eCK. This model is based on real-world network threats, enhances the attacker’s capabilities, and refines the evaluation criteria for IoT user authentication protocols. In the IoT-3eCK model, the servers are assumed to be semi-trusted entities, and the attackers may be insiders from either the RC or the intermediate server. The attacker has access to the registration information of users, servers, and IoT devices and can acquire the ephemeral secrets of all the protocol participants, including users, servers, and IoT devices. Based on this new security model, we analyze the Wang et al. scheme [25], identifying the challenges posed by insider and ESL attacks and uncovering the causes of their vulnerabilities. Then, we propose a new IoT user authentication protocol that effectively defends against insider attacks while meeting various security requirements. The protocol integrates a dynamic pseudonym-based anonymous authentication mechanism with an ECC key-exchange mechanism, ensuring anonymity and other critical security properties while significantly reducing the computational overhead on the intermediate server. The performance analysis shows that, compared to the existing solutions, the proposed protocol reduces communication overhead by more than 23%, computational overhead by over 22%, and, most notably, computational overhead on the intermediate server by over 95%, greatly improving the system efficiency.

The main contributions of this paper are as follows.

(1)

A new security model, IoT-3eCK, is proposed, which enhances the attacker’s capabilities regarding IoT user authentication protocols and refines the evaluation criteria for these protocols.

(2)

Based on the new security model, analysis of the Wang et al. scheme [25] is provided, identifying the challenges of insider and ESL attacks and uncovering the causes of their vulnerabilities.

(3)

A secure and efficient IoT user authentication protocol is introduced. The proposed scheme offers security properties such as key privacy and perfect forward security and is resilient to insider attacks, ESL attacks, and other common threats.

(4)

The security of the protocol is formally proven using the random oracle model, and its correctness is verified with the ProVerif 2.0 automated verification tool. In addition, performance comparisons demonstrate significant reductions in communication and computation costs.

The paper is structured as follows. Section 2 reviews the related work. Section 3 presents the proposed new security model. Section 4 provides a cryptanalysis of the scheme by Wang et al. [25]. Section 5 outlines the proposed IoT user authentication protocol. Section 6, Section 7, Section 8 and Section 9 present the security analysis and performance comparison, respectively. Finally, Section 10 concludes the paper.

2. Related Work

With low computational complexity and high efficiency, many user authentication protocols based on symmetric cryptography [33,34,35] have been proposed. However, these proposals require users and designated IoT devices to share symmetric keys beforehand, which is impractical due to the large number of IoT devices. Physically Unclonable Functions (PUFs), a promising lightweight hardware security primitive, have been used in numerous user authentication protocols for the IoT [3,36,37]. In these schemes, each entity needs to register one or more challenge–response pairs of its individual PUF with the server beforehand to enable authentication between the registered entity and the server, which leads to inflexibility and inefficiency. Halevi et al. [38] and Wang et al. [39] also indicated that most symmetric cryptography and hash-based user authentication proposals are insecure when dealing with user anonymity, PFS, and smart card security breach attacks. Public-key technology is vital for improving security, but it has high computational and communication overhead. Elliptic curve cryptography (ECC) has been adopted in IoT user authentication to balance security and efficiency because it provides a smaller key size compared to other methods with the same level of security [40,41].

In recent years, many ECC-based IoT user authentication protocols have been introduced. In 2016, Jiang et al. [9] introduced a user authentication protocol for wireless sensor networks (WSNs), a critical component of the IoT. This protocol employs two-factor authentication through temporary credentials and claims to resist various attacks, ensuring both the anonymity and untraceability of communications. However, the protocol assumes that the servers are fully trusted, neglecting the security threat posed by insider attackers within the servers. During registration, the RC generates and preloads long-term secrets for the sensors, storing these credentials on the intermediate server. This design exposes the protocol to insider impersonation attacks and key privacy issues, where insider users of the servers can impersonate sensors to complete authentication and key agreement with users, as well as obtain the session key negotiated between the user and the sensor during the authentication process. In addition, the scheme does not account for the possibility that an attacker may gain access to the ephemeral secret, making it vulnerable to ESL attacks. Furthermore, the scheme is also susceptible to offline password guessing attacks and does not provide PFS and timely typo detection. In 2017, Wu et al. [10] indicated that Chang et al. [11] were unable to resist offline password guessing attacks and could not maintain PFS. Then, they presented an improved one for WSNs, but it lacks user untraceability, key privacy, and PFS and suffers from offline password guessing, ESL, and insider sensor impersonation attacks. Challa et al. [12] introduced signature-based user authentication for the IoT. However, it is incapable of withstanding attacks of offline password guessing, impersonation, and insider IoT device impersonation, as well as failing to provide key privacy, user anonymity, and untraceability. In 2018, Li et al. [13] presented an IoT user authentication protocol for industrial IoT to ensure legitimate access to sensitive sensor data. But, this proposal [13] suffers from offline password guessing, replay, insider sensor impersonation, and impersonation attacks and lacks key privacy. Li et al. [14] identified the deficiencies of the scheme [9] and then presented an enhanced scheme for WSNs. However, the enhanced scheme [14] is prone to offline password guessing, insider sensor impersonation, and ESL attacks and cannot offer user untraceability, key privacy, and PFS. In 2019, Shuai et al. [15] presented an IoT user authentication scheme for smart homes. However, this scheme is subject to offline password guessing, insider IoT device impersonation, and ESL attacks and is unable to offer user untraceability, key privacy, and PFS. Lu et al. [28] introduced an IoT user authentication scheme for WSNs. Moreover, this scheme had a design flaw: i.e., an attacker could quickly determine the session key based on the sensor ID and the information detected throughout the open channels. In 2020, Li et al. [17] stated that most of the existing AKA proposals could not fulfill local password change and PFS while being vulnerable to stolen smart card attacks, and then introduced an improved version. Unfortunately, the scheme [17] is prone to sensor impersonation and offline password guessing attacks with poor usability. The server must enumerate the stored information and then calculate the relevant values to determine the sender’s ID when a reply message is received during authentication.

In 2021, Sadhukhan et al. [18] presented an authentication scheme for remote IoT users, but it suffers from replay, ESL, man-in-the-middle, and DoS attacks and cannot offer user anonymity and timely typo detection. Wazid et al. [19] introduced an IoT user authentication protocol to secure 6G-enabled networks in a box deployed in industrial applications. Wang et al. [25] revealed that the scheme [19] fails to provide user untraceability and PFS; it is also vulnerable to offline password guessing, desynchronization, and man-in-the-middle attacks. Additionally, the scheme lacks key privacy and cannot withstand insider IoT device impersonation attacks. Srinivas et al. [20] proposed an IoT user authentication scheme for IoT big data collection. However, this scheme [20] is fragile to device impersonation attacks and device session key compromise attacks and cannot afford user anonymity and PFS [22]. In 2022, Sutrala et al. [21] introduced an IoT user authentication scheme for software-defined network-based industrial cyberphysical systems [21]. Later, Wang et al. [23] stated that the scheme [21] is not able to resist smart card/device loss attacks and offline password guessing attacks and cannot offer user untraceability. Tanveer et al. [22] analyzed previous related IoT user authentication protocols and then proposed an improved version for the Internet of Drones. However, the scheme [22] cannot maintain user untraceability, PFS, or resistance to man-in-the-middle attacks and offline password guessing attacks. In 2023, Chen et al. [24] introduced a two-factor user authentication protocol for multi-gateway WSNs. Unfortunately, this scheme suffers from insider sensor impersonation and ESL attacks. Wang et al. [25] analyzed Wazid et al. [19] and then proposed an IoT user authentication scheme for cloud-assisted IoT with four parties prone to insider IoT device impersonation and ESL attacks. In 2024, Kumar et al. [26] proposed an IoT user authentication scheme to access sensitive data from sensor nodes by executives in coal mining scenarios. But, this scheme is not resistant to insider sensor impersonation attacks and ESL attacks, lacking PFS and key privacy.

In summary, the previous IoT user authentication schemes suffered from insider sensor impersonation attacks. Furthermore, most of the schemes are vulnerable to ESL and offline password guessing attacks, lack essential security features such as PFS, key privacy, and anonymity, or are unsuitable for resource-constrained IoT due to inefficiencies.

3. Security Model Based on Semi-Trusted Servers

This section defines a practical security model, IoT-3eCK, based on the network model. The model enhances the attacker’s capabilities and introduces an evaluation framework consisting of 10 attributes and 12 security goals, which supports a comprehensive analysis of IoT user authentication schemes.

3.1. IoT User Authentication Network Model

As illustrated in Figure 1, the network model consists of remote users, intermediate servers, IoT devices, and adversaries. RCs are specialized servers that are responsible for overseeing key generation, distribution, management, and communication activities within an application system or group. We assume that an IoT user authentication protocol, $\mathbb{P}$, involves $U_i(1\le i\le r),S_j(1\le j\le s)$ and $S_k(1\le k\le t)$, where $r\gg s,t\gg s$, r, s, and t denote the number of users, servers, and IoT devices, respectively. The servers are considered semi-trusted, meaning they will reliably execute the protocol but may also collaborate with other participants to potentially gain private information. Each remote user can dynamically join different systems or groups by registering with a different RC. However, a sensor can belong to a single system or group.

3.2. Adversary Model

To characterize the insider threat, we introduce the attacker capability A7: assume that $\mathcal{A}$ is an insider user of RC, capable of corrupting servers, learning the long-term private key of the servers, and eavesdropping on and stealing messages during the registration, login, and authentication phases. To address the threat of ephemeral key disclosure, we introduce the attacker capability A8: assume that $\mathcal{A}$ can obtain ephemeral secrets of the user, sensor, and RC. The primary capabilities of $\mathcal{A}$ in the new adversary model, IoT-3eCK, for the IoT user authentication protocol are as follows:

A1.

$\mathcal{A}$ takes full control over communication channels, intercepting, modifying, blocking, and deleting messages exchanged between the user, the RC, and the IoT devices at will.

A2.

$\mathcal{A}$ can offline all items in the set ${\mathrm{D}}_{id}\times {\mathrm{D}}_{pw}$ of the space ${\mathrm{D}}_{id}$ and password space ${\mathrm{D}}_{pw}$ within polynomial time.

A3.

$\mathcal{A}$ is able to capture the previous session keys between the user and the sensor.

A4.

$\mathcal{A}$ can learn the user’s passwords, extract long-term secrets from the smart card, and obtain the user’s biometrics, but not all three at the same time.

A5.

$\mathcal{A}$ is able to compromise the sensor and extract its long-term secrets.

A6.

$\mathcal{A}$ can obtain the secret key of RC when evaluating forward secrecy.

A7.

The adversary $\mathcal{A}$ could be an insider user of the RC or compromise the server S, gaining access to its long-term private key and intercepting/stalling messages during any phase (registration, log-in, authentication).

A8.

$\mathcal{A}$ can obtain ephemeral secrets of the user, sensor, and RC.

3.3. Evaluation Criteria

Our evaluation criteria are modified from widely accepted frameworks [2,8,25,42,43]. To mitigate insider attacks, C1 and C2 are introduced. First, during the registration phase, the authentication secrets must be protected, ensuring that the long-term secrets of the user and sensor, as well as the user’s password and biometric data, are not accessible to insider users of the RC. Second, insider users of intermediate servers, including those in the RC, should not have access to the session keys established between the user and the sensor. Furthermore, C10 has been improved to include resistance to ESL attacks and insider impersonation attacks, further strengthening its defenses against known threats.

C1.

No registering confidential exposure: When registering the long-term secrets of the user and sensor, the user’s password and biometrics cannot be derived by the insider user of RC.

C2.

Key privacy: The insider user of RC or the intermediate server cannot access the session keys between the user and the sensor.

C3.

No password verifier-table: RC does not store user passwords or any derived password values in a database.

C4.

Password-friendly: The user should freely choose and change an easy-to-remember password locally.

C5.

Sound repairability: The scheme enables the easy revocation of smart cards, that is, the users are able to revoke their cards with unchanging identity.

C6.

Mutual authentication and key agreement: The user and the sensor can verify each other and agree on a shared session key.

C7.

Forward secrecy: The shared session key could not be captured even if the adversary obtained the long-term secrets of the user, the RC, and the sensor.

C8.

Timely typo detection: If a user enters an incorrect password or biometrics when logging in, he or she will be informed in time.

C9.

User anonymity: The scheme is designed to protect user identity and prevent user activities from being traced.

C10.

Resistance to known attacks: The scheme resists known attacks, including ESL attacks, insider impersonation attacks, unknown key share attacks, known key attacks, smart card loss attacks, stolen verifier attacks, impersonation attacks, desynchronization attacks, parallel session attacks, replay attacks, offline password guessing attacks, key control, and node capture attack.

4. Analysis of Wang et al.’s Protocol

Wang et al. [25] proposed a secure and efficient IoT user authentication protocol for cloud-assisted IoT systems. Participants include IoT devices, gateways, cloud servers, and external users. Security analysis concluded that this scheme is vulnerable to insider impersonation attacks and ESL attacks.

4.1. Review of Wang et al.’s Protocol

The notations used are listed in

Table 2. Notations of the protocols.

Notation	Description
$\mathcal{A}$	Adversary
$U_i,I{D}_{ui},P{W}_{ui},BI{O}_{ui}$	User and his/her identity, password, biometric
$S_j,I{D}_{sj}$	Sever (register left) and its identity
$S_k,I{D}_{sk}$	IoT device and its identity
$s/PK$	Private keys/public keys
r	Random numbers
T	Timestamps
$SSK$	The session key
$Gen\left(\right)/Rep\left(\right)$	Biometric key generation/reproduction algorithm
${\sigma }_{ui}$/${\tau }_{ui}$	Biometric secret key/public reproduction parameter
$et$	Fuzzy extractor error tolerance threshold value
$w_{sk},w_{sj}$	Shared secrets of RC and IoT device
$w{t}_{ui},w{t}_{sj}$	Shared secrets of RC and user
$T_{ui},L_{ui}$	User dynamic credentials and lists
x	Secret values shared by cloud servers and gateways
$y,Y$	Secret values shared by cloud servers and users
$X_{Gk},x_{Gk}$	Gateway’s secret key
$X_{sk}$	Secret key of IoT device

.

4.1.1. Registration Phase

In the registration phase, the IoT device is registered with the gateway, and both the gateway and the user are registered with the cloud server. The cloud server first selects an elliptical curve E, with a base point P. After initialization, the cloud server possesses long-term secret keys x and y($Y=y·P$), shared with the user and the gateway, respectively. The cloud server distributes the gateway secret key $X_{G_k}=h(x\parallel GI{D}_{G_k})$ to the gateway as an authentication credential. The gateway and the IoT devices $S_k$ share a secret key $X_{sk}=h(I{D}_{sk}\parallel x_{G_k})$, where $x_{G_k}$ is the long-term secret key of the gateway.

The user $U_i$ registration process is as follows:

R1.

$U_i$ first selects the identity $I{D}_{ui}$ and password $P{W}_{ui}$, and inputs the biometric factor $Bi{o}_{ui}$. Then, $U_i$ selects a random number $a^{\prime }$ and calculates $Gen\left(Bi{o}_{ui}\right)=({\delta }_{ui},{\tau }_{ui})$ and $RP{W}_{ui}=h(P{W}_{ui}\parallel {\delta }_{ui}\parallel a^{\prime })$. Next, $U_i$ sends the registration request $\{I{D}_{ui},RP{W}_{ui}\}$ to the cloud server.

R2.

The cloud server selects a timestamp $T_{rgui}$ and a random number $a_{ui}$ and then calculates $k_{ui}=h(I{D}_{ui}\parallel y\parallel T_{rgui})$ and $B_{ui}^{\prime }=h(RP{W}_{ui}\parallel I{D}_{ui})\oplus k_{ui}$. The cloud server stores $\{I{D}_{ui},T_{rgui},a_{ui},Honey-list=NULL\}$ in the database and sends $\{B_{ui}^{\prime },B_{ui}^{\prime }\oplus a_{ui},Y,P\}$ to $U_i$.

R3.

Upon receiving $\{B_{ui}^{\prime },B_{ui}^{\prime }\oplus a_{ui},Y,P\}$, $U_i$ selects a random number a and then calculates $k_{ui}=B_{ui}^{\prime }\oplus h(RP{W}_{ui}\parallel I{D}_{ui})$, $RP{W}_{ui}^{new}=h(P{W}_{ui}\parallel {\delta }_{ui}\parallel a)$, $A_i=h(I{D}_{ui}\parallel RP{W}_{ui}^{new}\parallel k_{ui})mod{n}_0$, $B_{ui}=h(RP{W}_{ui}^{new}\parallel I{D}_{ui})\oplus k_{ui}$, $a_{ui}=B_{ui}^{\prime }\oplus (B_{ui}^{\prime }\oplus a_{ui})$. Finally, $U_i$ stores $\{A_{ui},B_{ui},a,A_{ui}\oplus a_{ui},{\tau }_{ui},Y,P,n_0\}$.

4.1.2. Login and Authentication

If $U_i$ wants to access the IoT device $S_k$, $U_i$ can initiate the following login and authentication request to the gateway as follows:

A1.

$U_i$ inputs $\{I{D}_{ui}^{*},P{W}_{ui}^{*},Bi{o}_{ui}^{*}\}$ and calculates ${\delta }_{ui}^{*}=Rep(Bi{o}_{ui}^{*},{\tau }_{ui})$, $RP{W}_{ui}^{*}=h(P{W}_{ui}^{*}\parallel {\delta }_{ui}^{*}\parallel a)$, $k_{ui}^{*}=B_{ui}\oplus h(RP{W}_{ui}^{*}\parallel I{D}_{ui})$, and $A_{ui}^{*}=h(I{D}_{ui}^{*}\parallel RP{W}_{ui}^{*}\parallel k_{ui}^{*})mod{n}_0$. Then, $U_i$ verifies whether $A_i^{*}\ne A_i$ is valid. If it is true, $U_i$ selects $r_{ui}$ and computes $a_{ui}^{*}=(A_{ui}\oplus a_{ui})\oplus A_{ui}$, $M_1=r_{ui}·Y$, $M_2=r_{ui}·P$, $M_3=h(M_2\parallel M_1)\oplus (I{D}_{ui}^{*}\parallel a_{ui}^{*})$, $M_4=h(M_1\parallel M_2\parallel M_3)\oplus I{D}_{sk}$, and $M_5=h(k_{ui}^{*}\parallel I{D}_i^{*}\parallel M_1\parallel M_2\parallel I{D}_{sk})$. Finally, $U_i$ sends $\{M_2,M_3,M_4,M_5\}$ to the cloud server.

A2.

After receiving $\{M_2,M_3,M_4,M_5\}$, the cloud server first calculates $M_1^{\prime }=y·M_2$ and $I{D}_{ui}^{\prime }\parallel a_{ui}^{\prime }=M_3\oplus h(M_2\parallel M_1^{\prime })$. Then, it retrieves $\{T_{rgui},a_{ui}\}$ using $I{D}_{ui}^{\prime }$. If $a_{ui}\ne a_{ui}^{\prime }$, the cloud server terminates the session; otherwise, the cloud server calculates $k_{ui}^{\prime }=h(I{D}_{ui}^{\prime }\parallel y\parallel T_{r{g}_{ui}})$, $I{D}_{sk}^{\prime }=M_4\oplus h(M_1\parallel M_2\parallel M_3)$, and $M_5^{\prime }=h(k_{ui}^{\prime }\parallel I{D}_{ui}^{\prime }\parallel M_1^{\prime }\parallel M_2\parallel I{D}_{sk}^{\prime })$. If $M_5^{\prime }\ne M_5$, the cloud server terminates the session; otherwise, it determines the gateway to which $S_k$ belongs, selects a random number r, and calculates $X_{G_k}^{\prime }=h(x\parallel GI{D}_k)$, $M_6=h(X_{G_k}^{\prime }\parallel M_2)\oplus r$, $M_7=h(M_6\parallel r\parallel X_{G_k}^{\prime })\oplus I{D}_{sk}^{\prime }$, and $M_8=h(M_2\parallel M_6\parallel M_7\parallel r\parallel I{D}_{sk}^{\prime }\parallel X_{G_k}^{\prime })$. The cloud server then sends $\{M_2,M_6,M_7,M_8\}$ to the gateway.

A3.

Upon receiving $\{M_2,M_6,M_7,M_8\}$, the gateway first calculates $r^{\prime }=M_6\oplus h(X_{G_k}\parallel M_2)$, $I{D}_{sk}^{″}=M_7\oplus h(M_6\parallel r^{\prime }\parallel X_{G_k})$, and $M_8^{\prime }=h(M_2\parallel M_6\parallel M_7\parallel r^{\prime }\parallel I{D}_{sk}^{″}\parallel X_{G_k})$. Then, it verifies whether $M_8^{\prime }=M_8$. If it is true, the gateway selects a random number $r_g$ and computes $X_{sk}^{\prime }=h(x_{G_k}\parallel I{D}_{sk}^{\prime \prime })$, $M_9=h(X_{sk}^{\prime }\parallel M_2)\oplus r_g$, and $M_{10}=h(M_2\parallel M_9\parallel r_{g}t\parallel I{D}_{sk}^{″}\parallel X_{sk}^{\prime })$. The gateway then sends $\{M_2,M_9,M_{10}\}$ to $S_k$.

A4.

Upon receiving $\{M_2,M_9,M_{10}\}$, $S_k$ calculates $r_g^{\prime }=M_9\oplus h(X_{sk}\parallel M_2)$ and $M_{10}^{\prime }=h(M_2\parallel M_9\parallel r_g^{\prime }\parallel I{D}_{sk}\parallel X_{sk})$. If $M_{10}^{\prime }\ne M_{10}$, $S_k$ terminates the session; otherwise, $S_k$ selects a random number $r_{sk}$ and then calculates $M=r_{sk}·M_2$ and $M_{11}=r_{sk}·P$. Then, $S_k$ calculates the session key $S{K}_{ki}=h(M_2\parallel M_{11}\parallel M)$ and $M_{12}=h(M_2\parallel M_{11}\parallel r_g^{\prime }\parallel X_{sk}\parallel I{D}_{sk})$. Finally, $S_k$ sends $\{M_{11},M_{12}\}$ to the gateway.

A5.

After receiving the response from $S_k$, the gateway calculates $M_{12}^{\prime }=h(M_2\parallel M_{11}\parallel I{D}_{sk}^{″}\parallel r^{\prime }\parallel X_{G_k})$. If $M_{12}^{\prime }\ne M_{12}$, the gateway terminates the session; otherwise, the gateway calculates $M_{13}=h(M_{11}\parallel M_2\parallel I{D}_{sk}^{″}\parallel r^{\prime }\parallel X_{G_k})$ and sends $\{M_{11},M_{13}\}$ to the cloud server.

A6.

After receiving the response from the gateway, the cloud server calculates $M_{13}^{\prime }=h(M_{11}\parallel M_2\parallel I{D}_{sk}^{\prime }\parallel r\parallel X_{G_k}^{\prime })$. If $M_{13}^{\prime }\ne M_{13}$, the cloud server terminates the session; otherwise, it calculates $M_{14}=h(M_1^{\prime }\parallel M_2\parallel I{D}_{ui}^{\prime }\parallel I{D}_{sk}^{\prime }\parallel k_{ui}^{\prime }\parallel M_{11})$ and sends $\{M_{11},M_{14}\}$ to $U_i$.

A7.

Once $U_i$ receives the response from the cloud server, it calculates $M_{14}^{*}=h(M_1\parallel M_2\parallel I{D}_i\parallel I{D}_{sk}\parallel k\parallel M_{11})$. If $M_{14}^{*}=M_{14}$, $U_i$ calculates $S{K}_{ik}=h(M_2\parallel M_{11}\parallel r_i·M_{11})$ as the session key.

4.2. Flaws of Wang et al.’s Protocol

4.2.1. Vulnerability to Insider IoT Device Impersonation Attacks

Consider an attacker as an insider user of the gateway. The attacker first selects a random number $r_{sk}^{*}$ and computes $M^{*}=r_{sk}^{*}·M_2$, $M_{11}^{*}=r_{sk}^{*}·P$, and $S{K}_{ki}^{*}=h{M}_2\parallel M_{11}^{*}\parallel M^{*})$. The attacker then calculates $M_{13}^{*\prime }=h(M_{11}^{*}\parallel M_2\parallel I{D}_{sk}^{\prime }\parallel r\parallel X_{G_k}^{\prime })$ and sends $\{M_{11}^{*},M_{13}^{*}\}$ to the cloud server. Upon receiving $\{M_{11}^{*},M_{13}^{*}\}$, the cloud server computes $M_{13}^{*\prime }=h(M_{11}^{*}\parallel M_2\parallel I{D}_{sk}^{\prime }\parallel r\parallel X_{G_k}^{\prime })$. Since $M_{13}^{*\prime }=M_{13}^{*}$, the cloud server computes $M_{14}^{*}=h(M_1^{\prime }\parallel M_2\parallel I{D}_{ui}^{\prime }\parallel I{D}_{sk}^{\prime }\parallel k_i^{\prime }\parallel M_{11}^{*})$ and sends $\{M_{11}^{*},M_{14}^{*}\}$ to $U_i$. Upon receiving the response from the cloud server, $U_i$ calculates $M_{14}^{*\prime }=h(M_1\parallel M_2\parallel I{D}_{ui}\parallel I{D}_{sk}\parallel k\parallel M_{11}^{*})$. Clearly, $M_{14}^{*}=M_{14}^{*\prime }$, and $U_i$ computes $S{K}_{ik}^{*}=h(M_2\parallel M_{11}^{*}\parallel r_{ui}·M_{11}^{*})$ as the session key. Similarly, insider users of the cloud server can also initiate impersonation attacks.

4.2.2. Vulnerability to ESL Attacks

If $r_{ui}$ is compromised, the attacker can combine the channel messages $\{M_2,M_6,M_7,M_8\}$ and $\{M_{11},M_{14}\}$ to calculate $S{K}_{ik}=h(M_2\parallel M_{11}\parallel r_i·M_{11})$. Similarly, if $r_{sk}$ is leaked, the attacker can combine channel messages $\{M_2,M_6,M_7,M_8\}$ and $\{M_{11},M_{14}\}$ to compute $M=r_{sk}·M_2$, $M_{11}=r_{sk}·P$, and $S{K}_{ki}=h(M_2\parallel M_{11}\parallel M)$. Thus, the scheme is vulnerable to ESL attacks.

5. Proposed Protocol

The proposed protocol has four phases: system initialization, registration, login and authentication, and user password and biometric update.

5.1. System Initialization

The implementation of the system is carried out by RC $S_j$ online. Firstly, $S_j$ chooses an elliptic curve $E(a,b)$ over $Z_q^{*}=\{0,1,\cdots ,q-1\}$ with a base point P. In addition, a medium number $d={10}^8$ is chosen. Second, RC opts for its identifier $I{D}_{sj}\in Z_q^{*}$ and its long-term private key $s_{sj}\in Z_q^{*}$ and computes $P{K}_{sj}=s_{sj}·P$ as its public key. Then, RC chooses two one-way hash functions, $h(·):{\{0,1\}}^{*}\to {\{0,1\}}^{256}$ and $h1(·):{\{0,1\}}^{*}\to {\{0,1\}}^{64}$, for generating hashes and one-time credential identifiers, respectively. Finally, RC keeps $s_{sj}$ secure and issues the public parameters of the system $\{E(a,b),q,P,I{D}_{sj},d,h(·),h1(·)\}$.

5.2. Registration

5.2.1. IoT Device Registration

IoT device $S_k$ selects an RC $S_j$ to complete registration and obtain authentication credentials before the entry of the system. The registration process is as follows:

R1: 

$S_k$ selects its identifier $I{D}_{sk}\in Z_q^{*}$ and a random number $d_{sk}\in Z_q^{*}$ and then computes $D_{sk}=H(I{D}_{sk}\parallel d_{sk})·P$. Third, $S_k$ sends the registration requisition request message, {$I{D}_{sk},D_{sk}$}, to $S_j$ through secure channels.

R2: 

In response, $S_j$ checks if $I{D}_{sk}$ has been registered. If so, $S_k$ is required for a new request. Otherwise, RC opts for a random number $x_{sk}\in Z_q^{*}$ as the partial private key of $S_k$ and computes $P{K}_{sk}=D_{sk}+x_{sk}·P$ as the public key of $S_k$. After that, RC publishes $\{I{D}_{sk},P{K}_{sk}\}$ and replies $\{x_{sk},P{K}_{sk}\}$ to $S_k$ through secure channels. Lastly, RC computes $w_{sk}=h(s_{sj}·P{K}_{sk}\parallel I{D}_{sk})$ and stores $\left\{w_{sk}\right\}$ secretly.

R3: 

After receiving $\{x_{sk},P{K}_{sk}\}$, $S_k$ computes $s_{sk}=(h(I{D}_{sk}\parallel d_{sk})+x_{sk})modq$ as its private key. Then, $S_k$ checks whether $s_{sk}·P?=P{K}_{sk}$. If it holds, $S_k$ computes $w_{sj}=h(s_{sk}·P{K}_{sj}\parallel I{D}_{sk})$ and stores $\{I{D}_{sk},s_{sk},P{K}_{sk},w_{sj}\}$.

Remark 1.

$w_{sj}=h(s_{sk}·P{K}_{sj}\parallel I{D}_{sk})=h(s_{sk}{s}_{sj}·P\parallel I{D}_{sk})=h(s_{sj}·P{K}_{sk}\parallel I{D}_{sk})=w_{sk}$

5.2.2. User Registration and Revocation

Users can dynamically join different systems through the registration processes shown in Figure 3. The fuzzy verifier $LV=h(I{D}_{ui}\parallel P{W}_I{D}_{ui}\parallel {\sigma }_I{D}_{ui}\parallel s_I{D}_{ui})modd$ [2,44] is used to eliminate offline password guessing attacks. $T_{ui}$ is a temporary one-time credential assigned to the user $U_i$ and is marked with $flag=0$ to indicate that $T_{ui}$ has not been used. A corresponding untraceable list $L_{ui}=\{T_{ui},h1(L_{ui}\left[0\right]\parallel w{t}_{ui}),\cdots ,h1(L_{ui}[n-2]\parallel w{t}_{ui})\}$ is generated and stored in RC, where n represents the number of times a user is permitted to re-initiate the authentication. After registration, $U_i$ stores $\{e{s}_{ui},LV,{\tau }_{ui},P{K}_{ui},T_{ui},w{t}_{sj}\}$. $S_j$ publishes $\{I{D}_{ui},P{K}_{ui}\}$ and stores $\{w{t}_{ui},L_{ui}\}$ secretly. A user account can be updated with the same process if it is frozen.

5.3. Login and Authentication

This phase between the user $U_i$, the RC $S_j$, and the sensor $S_k$ is shown in Figure 4.

A1: 

To begin, $U_i$ inputs $I{D}_{ui}$, $P{W}_{ui}$, and $BI{O}_{ui}^{\prime }$. Then, $U_i$ calculates ${\sigma }_{ui}^{\prime }=Rep(BI{O}_{ui}^{\prime },{\tau }_{ui})$ and $s_{ui}^{\prime }=e{s}_{ui}\oplus h({\sigma }_{ui}^{\prime }\parallel P{W}_{ui})$ and obtains a verifier $L{V}^{\prime }=h(I{D}_{ui}\parallel P{W}_{ui}\parallel {\sigma }_{ui}^{\prime }\parallel s_{ui}^{\prime })modn$. Finally, $U_i$ verifies if $L{V}^{\prime }?=LV$. If this condition is not met, the log-in process will end.

A2: 

$U_i$ chooses a random $r_{ui}\in Z_q^{*}$ and generates the current timestamp $T_1$. Afterwards, $U_i$ calculates $A_{ui}=r_{ui}·P{K}_{ui}$. If $flag=1$, it indicates that $T_{ui}$ has been used. In this case, $U_i$ updates $T_{ui}$ to $T_{ui}=h1(T_{ui}\parallel w{t}_{sj})$. Third, $U_i$ encodes the identity of the desired sensor $S_k$ into dynamic identity as $CI{D}_{sk}=I{D}_{sk}\oplus h(A_{ui}\parallel w{t}_{sj}\parallel T_1)$. Finally, $U_i$ generates a verifier $V_{ui}=h(CI{D}_{sk}\parallel I{D}_{ui}\parallel A_{ui}\parallel T_1\parallel w{t}_{sj})$ and sends the request message $M1=\{A_{ui},T_{ui},CI{D}_{sk},T_1,V_{ui}\}$ to $S_j$.

A3: 

Upon receiving $M1$, $S_j$ verifies its freshness with the timestamp $T_1$. Next, $S_j$ verifies $U_i$ using temporary credentials $T_{ui}$. If $T_{ui}=L_{ui}\left[m\right](m\le n)$ and $V_{ui}=h(CI{D}_{sk}\parallel I{D}_{ui}\parallel A_{ui}\parallel T_1\parallel w{t}_{ui})$, then $S_j$ confirms that the sender is $U_i$ and updates the untraceable list for $T_{ui}$ as follows: $L_{ui}=\{L_{ui}[m+1],\cdots ,L_{ui}\left[n\right],h1(L_{ui}\left[n\right]\parallel w{t}_{ui}),\cdots \}$. Otherwise, $S_j$ will reject the session.

A4: 

$S_j$ generates the time stamp $T_2$ and encodes the identity of $U_i$ as $EI{D}_{ui}=I{D}_{ui}\oplus h(w_{sk}\parallel T_2)$. Finally, $S_j$ generates a verifier $V_{sj}=h(I{D}_{ui}\parallel I{D}_{sj}\parallel w_{sk}\parallel T_2)$ and sends the message $M2=\{A_{ui},T_2,EI{D}_{ui},V_{sj}\}$ to the IoT device $S_k$.

A5: 

Upon receiving M2, $S_k$ checks its freshness with the timestamp $T_2$. Following that, $S_k$ decodes $I{D}_{ui}=EI{D}_{ui}\oplus h(w_{sj}\parallel T_2)$. Finally, $S_k$ verifies the authenticity of $S_j$ by checking whether $V_{sj}?=h(I{D}_{ui}\parallel I{D}_{sj}\parallel w_{sj}\parallel T_2)$ and ensures the integrity of the message received. If not, $S_j$ will terminate the verification immediately.

A6: 

Firstly, $S_k$ selects a random $r_{sk}\in Z_q^{*}$ and generates the current timestamp $T_3$. After that, $S_k$ calculates $A_{sk}=r_{sk}·P{K}_{sk}$, $S_{ki}=(r_{sk}{s}_{sk}modq)·A_{ui}$, and obtains the session key shared with $U_i$ as $S{K}_{ki}=h(S_{ki}\parallel I{D}_{ui}\parallel I{D}_{sk})$. Then, $S_k$ encodes $EI{D}_{sk}=I{D}_{sk}\oplus h(A_{sk}\parallel S_{ki})$. Third, $S_j$ generates its verifier as $V_{sk}=h(I{D}_{sk}\parallel A_{sk}\parallel S_{ki}\parallel T_3)$. Finally, $S_j$ transmits the response message $M3=\{A_{sk},T_3,EI{D}_{sk},V_{sk}\}$ to $U_i$.

A7: 

Upon receiving M3, $U_i$ first checks its freshness with the timestamp $T_3$. After that, $U_i$ calculates $S_{ik}=(r_{ui}{s}_{ui}modq)·A_{sk}$. Third, $U_i$ verifies whether $I{D}_{sk}?=EI{D}_{sk}\oplus h(A_{sk}\parallel S_{ik})$ and $V_{sk}?=h(I{D}_{sk}\parallel T_{ui}\parallel A_{sk}\parallel S_{ik}\parallel T_3)$. If not, $U_i$ will terminate the session. Finally, $U_i$ obtains the session key shared with $S_k$ as $S{K}_{ik}=h(S_{ik}\parallel I{D}_{ui}\parallel I{D}_{sk})$ and updates $T_{ui}$ as $T_{ui}=h1(T_{ui}\parallel w{t}_{sj})$ with $flag=0$.

5.4. User Password and Biometric Update

A registered user $U_i$ can renew her password and biometric information following the steps outlined below.

$U_i$ first inputs $I{D}_{ui},P{W}_{ui}$, and $BI{O}_{ui}^{\prime }$ and then computes ${\sigma }_{ui}^{\prime }=Rep(BI{O}_{ui}^{\prime },{\tau }_{ui})$, $s_{ui}^{\prime }=e{s}_{ui}\oplus h({\sigma }_{ui}^{\prime }\parallel P{W}_I{D}_{ui})$, and $L{V}^{\prime }=h\left(h\right(I{D}_{ui}\parallel P{W}_I{D}_{ui}\parallel {\sigma }_{ui}^{\prime }\parallel s_{ui}^{\prime })modn)$. Third, $U_i$ checks if $L{V}^{\prime }?=LV$. If so, $U_i$ inputs $P{W}_{ui}^{new}$ and $BI{O}_{ui}^{new}$ and computes $({\sigma }_{ui}^{new},{\tau }_{ui})=Gent\left(BI{O}_{ui}^{new}\right)$, $e{s}_{ui}^{new}=s_{ui}\oplus h({\sigma }_{ui}^{new}\parallel P{W}_{ui}^{new})$, and $L{V}^{new}=h(I{D}_{ui}\parallel RP{W}_{ui}^{new}\parallel {\sigma }_{ui}^{new}\parallel s_I{D}_{ui})modn$. Finally, $U_i$ replaces $\{e{s}_{ui},LV\}$ with $\{e{s}_{ui}^{new},L{V}^{new}\}$.

6. Formal Security Analysis

This section provides the formal proof of the proposed protocol in the IoT-3eCK security model.

6.1. Relevant Definitions

Participants: The proposed protocol involves three participants: $U_i$, $S_j$, and $S_k$. Each participant has several instances denoted by $I_U^i$, $I_S^j$, and $I_S^k$$(i,j,k\in Z$), respectively. Any instance can be referred to as $I\in I_U^i\cup I_S^j\cup I_S^k$. A session identifier, $Sid$, is created by concatenating all messages sent and received for the current session. An instance can exist in three states. If the most recent expected protocol message is received, the instance enters the state $accept$. If an incorrect message is received, the instance transitions to the $reject$ state. An instance will become ⊥ if the input is not responded to.

Partners: Instances I and $I^{\prime }$ are considered $partners$ only if all three conditions are met: (i) Both instances are currently in the $accept$ state. (ii) They have mutually authenticated and shared the same $Sid$. (iii) They are partners with each other.

Freshness: An instance is considered fresh if $\mathcal{A}$ fails to obtain the session key $S{K}_{ki}$ (or $S{K}_{ik}$) between $U_i$ and $S_k$ by making $SKReveal\left(I\right)$, $ESReveal$ ($I)$, or $Corrupt\left(I\right)$ queries before performing a $Expire\left(I\right)$ query.

Adversary: Under the IoT-3eCK adversary model, $\mathcal{A}$ can interact with $U_i$, $S_j$, and $S_k$ through the following queries:

(1)

$Execute\left(\right)$: $\mathcal{A}$ can observe all messages transmitted between $U_i$, $S_j$, and $S_k$.

(2)

$Send(I,m)$: $\mathcal{A}$ can send a message m to I and receive a response.

(3)

$ESReveal\left(I\right)$: This query reveals the ephemeral secret key of I to $\mathcal{A}$.

(4)

$SKReveal\left(I\right)$: $\mathcal{A}$ can obtain the session key between I and its partner.

(5)

$UCorrupt\left(w\right)$: $\mathcal{A}$ can obtain the security credentials held by $U_i$.

• $w=0$: $\mathcal{A}$ acquires $P{W}_{ui}$ and $BI{O}_{ui}$.
• $w=1$: $\mathcal{A}$ acquires $P{W}_{ui}$ and $\{e{s}_{ui},LV,{\tau }_{ui},T_{ui},w{t}_{sj}\}$.
• $w=2$: $\mathcal{A}$ acquires $BI{O}_{ui}$ and $\{e{s}_{ui},LV,{\tau }_{ui},T_{ui},w{t}_{sj}\}$.

(6)

$RCCorrupt\left(\right)$: $\mathcal{A}$ can retrieve all the security credentials held by $S_j$.

(7)

$SCorrupt\left(\right)$: $\mathcal{A}$ can retrieve all the security credentials held by $S_k$.

(8)

$Test\left(I\right)$: This query is used to simulate the semantic security of the session key.

• If the session key is not established or I is not fresh, ⊥ will be returned.
• Otherwise, a coin $b\in \{0,1\}$ is flipped.

  −

  If $b=1$, I returns the session key to $\mathcal{A}$.

  −

  If $b=0$, I returns a random string of the same length as the session key.

(9)

$h\left(M\right)$: The query provides $\mathcal{A}$ with a randomly generated number that serves as the hash output of M.

(10)

$Expire\left(I\right)$: Once this query is executed, the session key held by I is deleted.

6.2. Provable Security Analysis

Before the security analysis, we first define the complexity assumptions. We then provide a formal proof to evaluate the security of the session key $S{K}_{ik}$ (or $S{K}_{ki}$) under the ROM model.

Let $E(a,b)$ denote a non-singular elliptic curve over a finite field $F_q$, G be an additive group of order q of $E(a,b)$, and P be the base point of the group.

Definition 1.

Elliptic Curve Discrete Logarithm (ECDL) Hardness Assumption: Given $<P,xP\in G>$, finding $x\in Z_q^{*}$ is computationally hard, and the probability that $\mathcal{A}$ is able to resolve the problem, ${\mathrm{Adv}}_{\mathrm{ECDL}}\left(\mathcal{A}\right)$, is negligible for sufficiently small ϵ,

$$Ad{v}_{\mathrm{ECDL}}\left(\mathcal{A}\right)=Pr[\mathcal{A}(P,xP)=x:x\in Z_q^{*}]<ϵ$$

(1)

Definition 2.

Computational Diffie–Hellman (CDH) Hardness Assumption: Given $<xP,yP\in G>$, figuring out $xyP\in G$ is computationally hard, and the probability of $\mathcal{A}$ resolving the problem is negligible for sufficiently small ϵ,

$$Ad{v}_{\mathrm{CDH}}\left(\mathcal{A}\right)=Pr[\mathcal{A}(xP,yP)=xyP:x,y\in Z_q^{*}]<ϵ$$

(2)

Definition 3.

The security of $S{K}_{ik}$ (or $S{K}_{ki}$) is modeled by the game $Gam{e}_{\mathrm{UA}}(I,\mathcal{A})$. In this game, $\mathcal{A}$ is allowed to perform one $Test\left(I\right)$ query, where I is both $\mathrm{accept}$ and $\mathrm{fresh}$, and I returns a single bit $b^{\prime }$. $\mathcal{A}$ can issue many other queries to I.

Let $Pr\left[Succ\right(A\left)\right]$ denote the probability that $\mathcal{A}$ successfully wins the game $Gam{e}_{\mathrm{UA}}(I,\mathcal{A})$. The advantage of $\mathcal{A}$ in breaking the semantic security of $S{K}_{ik}$ (or $SS{K}_{ki}$) is defined as

$$Ad{v}_{\mathrm{UA}}\left(A\right)=|2Pr[b^{\prime }=b]-1|=|2PrSucc\left(A\right)-1\mid$$

(3)

Definition 4.

In the context of the adversarial model eCK, a user authentication scheme is semantically secure if $Ad{v}_{\mathrm{UA}}\left(\mathcal{A}\right)$ is negligible for any adversary.

Theorem 1.

Let $\mathcal{A}$ be an adversary that can break the semantic security of $S{K}_{ik}$ (or $SS{K}_{ki}$) by creating up to $q_e$$Execute\left(\right)$ queries and $q_h$$h\left(\right)$ and $q_s$$Send\left(\right)$ queries, all within polynomial time t. Let the random numbers and hash outputs be l-bit values, the password dictionary space be N, following Zipf’s law as in [17], and the biometric secret key have a length of $lb$ bits with a false-positive probability of ${\epsilon }_{fp}$. Then, the advantage of $\mathcal{A}$ is that

$$\begin{array}{cc}\hfill Ad{v}_{\mathrm{UA}}\left(\mathcal{A}\right)\le & {\displaystyle \frac{(q_h^2+3q_h+3q_s)}{2^l}}+{\displaystyle \frac{{(q_s+q_e)}^2}{2(q-1)}}+(2max\{{\displaystyle \frac{q_s}{2^{lb}}},{\displaystyle \frac{q_s}{2^{lb}}}+q_s{\epsilon }_b,C^{\prime }{q}_s^{s^{\prime }}\}+{\displaystyle \frac{3q_s}{2^l}}\hfill \\ \hfill & +{\displaystyle \frac{3q_s}{q-1}})max\{Ad{v}_{\mathrm{ECDL}}\left(\mathcal{A}\right),Ad{v}_{\mathrm{CDH}}\left(\mathcal{A}\right)\}\hfill \end{array}$$

(4)

where $C^{\prime }$ and $s^{\prime }$ are Zipf’s parameters.

Proof. 

The semantic security of $SS{K}_{ik}$ (or $SS{K}_{ki}$) is defined by a series of games ${\mathrm{Game}}_I(i=0,1,\cdots ,5)$. In these games, $S_i$ represents the value of b in the $Test\left(I\right)$ query correctly predicted by $\mathcal{A}$, and $Pr\left[S_i\right]$ denotes the probability that the event $S_i$ will occur.

$Gam{e}_0$: The game begins by simulating a real attack in ROM mode. Thus, we have the following:

$$Ad{v}_{UA}\left(A\right)=\mid 2Pr\left[S_0\right]-1\mid$$

(5)

$Gam{e}_1$: In this game, $\mathcal{A}$ can be the $Execute\left(\right)$ query to obtain $M1$, $M2$, and $M3$ exchanged between $(U_i$, ${\mathrm{S}}_j$, and ${\mathrm{S}}_k$. Then, $\mathcal{A}$ can use $SKReveal\left(I\right)$ and $Test\left(I\right)$ to verify whether the calculated key $SS{K}_{ki}$ (or $S{K}_{ik}$) is genuine or not. Since $S{K}_{ki}$ (or $S{K}_{ik}$) cannot be determined directly from these messages, there is no distinguishable difference between $Gam{e}_0$ and $Gam{e}_1$. Therefore,

$$Pr\left[S_1\right]=Pr\left[S_0\right]$$

(6)

Three lists are used to store related results: $L_h$ for the inputs and outputs of $h\left(\right)$ queries, $L_h^{\mathcal{A}}$ for the answers to $h\left(\right)$ queries asked by $\mathcal{A}$, and $L_E$ for the inputs and outputs of $Execute\left(\right)$ queries.

${Game}_2$: The game ends when message transcripts and hash queries collide. The components of messages $M1$, $M2$, and $M3$ are evenly distributed. Based on the birthday paradox, we obtain

$$|Pr\left[S_2\right]-Pr\left[S_1\right]|\le {\displaystyle \frac{{(q_s+q_e)}^2}{2(q-1)}}+{\displaystyle \frac{q_h^2}{2^{l+1}}}$$

(7)

$Gam{e}_3$: In this game, $\mathcal{A}$ attempts to forge the messages $M1$, $M2$, and $M3$ without access to the oracle. The process is as follows:

• Constructing M1: $\mathcal{A}$ needs to issue $h\left(\right)$ queries to successfully construct $M1$. Thus, the following values must be in $L_h^{\mathcal{A}}$: ($A_{ui}\parallel B_{ui},\ast ),(I{D}_{sk}\parallel I{D}_{ui}\parallel B_{ui}\parallel T_{ui}\parallel \ast ,V_{ui})$. The probability of success is ${\displaystyle \frac{(q_h+q_s)}{2^l}}$.
• Constructing M2: Similarly, we have $(\ast \parallel T_{sj},\ast )$, $(I{D}_{ui}\parallel I{D}_{sj}\parallel \ast \parallel T_{sj},V_{sj})\in L_h^{\mathcal{A}}$, and the probability is ${\displaystyle \frac{(q_h+q_s)}{2^l}}$.
• Constructing M3: Again, we have $(A_{sk}\parallel \ast ,\ast )$, $(I{D}_{sk}\parallel I{D}_{ui}\parallel \ast \parallel T_{sk}\parallel V_{sk})\in L_h^{\mathcal{A}}$, and the probability is ${\displaystyle \frac{(q_h+q_s)}{2^l}}$.

Thus, $Gam{e}_3$ is indistinguishable from game $Gam{e}_2$ unless $\mathcal{A}$ successfully constructs $M1$, $M2$, and $M3$. Thus,

$$|Pr\left[S_3\right]-Pr\left[S_2\right]|\le {\displaystyle \frac{3(q_h+q_s)}{2^l}}$$

(8)

$Gam{e}_4$: This game terminates if $\mathcal{A}$ is able to retrieve $S{K}_{ki}$ (or $S{K}_{ik}$). If $\mathcal{A}$ manages to compute the session key, this implies that it has solved the ECDL or ECD problems. Furthermore, the tuple $(r_{ui}{s}_{ui}{r}_{sk}{s}_{sk}·P\parallel I{D}_i\parallel I{D}_j)$ must be stored in $L_h^{\mathcal{A}}$. The following cases may occur for $\mathcal{A}$ to compute $S{K}_{ki}$ or $S{K}_{ik}$:

(1)

$\mathcal{A}$ issues $UCorrupt\left(w\right)$ and $SCorrupt\left(\right)$.

• $w=0$: $\mathcal{A}$ acquires $P{W}_{ui}$ and $BI{O}_{ui}$, and then $\mathcal{A}$ guesses $s_{ui}$ in $Send\left(\right)$ queries with a success probability of ${\displaystyle \frac{q_s}{2^l}}$.
• $w=1$: $\mathcal{A}$ acquires $P{W}_{ui}$ and $\{e{s}_{ui},LV,{\tau }_{ui},T_{ui},w{t}_{sj}\}$, and then $\mathcal{A}$ attempts to obtain $BI{O}_{ui}$ using two methods. $\mathcal{A}$ can guess ${\delta }_{ui}$ in $Send\left(\right)$ queries with $lb$ bits with probability ${\displaystyle \frac{q_s}{2^{lb}}}$, or replace $BI{O}_{ui}$ with collected biometric data with a probability of $q_s·{\epsilon }_b$, where ${\epsilon }_b$ is the probability of similarity of the biometric data. So, the probability is ${\displaystyle \frac{q_s}{2^{lb}}}+q_s·{\epsilon }_b$.
• $w=2$: $\mathcal{A}$ acquires $BI{O}_{ui}$ and $\{e{s}_{ui},LV,{\tau }_{ui},T_{ui},w{t}_{sj}\}$, and then $\mathcal{A}$ attempts to guess $P{W}_{ui}$ in $q_s$ queries. According to Zipf’s law, the probability of password distribution is $C^{\prime }{q}_s^{s^{\prime }}$, where $C^{\prime }$ and $s^{\prime }$ are Zipf’s parameters.

Next, $\mathcal{A}$ issues an $SCorrupt\left(\right)$ to obtain $s_{sk}$ of ${\mathrm{S}}_k$, and then $\mathcal{A}$ attempts to guess $r_{sk}$ using $q_s$ queries with the probability of ${\displaystyle \frac{q_s}{q-1}}$.

(2)

$\mathcal{A}$ issues $UCorrupt\left(w\right)$ and $ESReveal\left(S_k\right)$.

Firstly, $\mathcal{A}$ issues a $UCorrupt\left(w\right)$ query as summarized above. Next, $\mathcal{A}$ issues an $ESReveal\left(S_k\right)$ query to obtain the ephemeral secret $r_{sk}$ of ${\mathrm{S}}_k$. Then, $\mathcal{A}$ attempts to guess $s_{sk}$ within $q_s$ attempts, with a probability of ${\displaystyle \frac{q_s}{2^l}}$.

(3)

$\mathcal{A}$ issues $ESReveal\left(U_i\right)$ and $SCorrupt\left(\right)$.

Firstly, $\mathcal{A}$ obtains $r_{ui}$ and $s_{sk}$. Then, $\mathcal{A}$ attempts to guess $s_{sk}$ and $r_{sk}$.

(4)

$\mathcal{A}$ issues $ESReveal\left(U_i\right)$ and $ESReveal\left(S_k\right)$.

Firstly, $\mathcal{A}$ obtains $r_{ui}$ and $r_{sk}$. Then, $\mathcal{A}$ tries to guess $s_{sk}$ and $s_{sk}$.

In all the above cases, $\mathcal{A}$ cannot figure out $S{K}_{ik}$ (or $S{K}_{ik}$) unless it has solved the problem of ECDL or ECD. Hence,

$$\begin{array}{c}\hfill |Pr\left[S_4\right]-Pr\left[S_3\right]|\le (2max\{{\displaystyle \frac{q_s}{2^l}},{\displaystyle \frac{q_s}{2^{lb}}}+q_s{\epsilon }_b,C^{\prime }{q}_s^{s^{\prime }}\}+\\ \hfill {\displaystyle \frac{3q_s}{(q-1)}}+{\displaystyle \frac{3q_s}{2^l}})max\{Ad{v}_{\mathrm{ECDL}}\left(\mathcal{A}\right),Ad{v}_{\mathrm{CDH}}\left(\mathcal{A}\right)\}\end{array}$$

(9)

$Gam{e}_5$: This game emulates $Gam{e}_4$, but the $Test\left(\right)$ query will terminate if $\mathcal{A}$ issues an $h(S_{ik}\parallel I{D}_{ui}\parallel I{D}_{sk})$ query. The probability of $\mathcal{A}$ acquiring ${SK}_{ik}$ is at most $q_h^2/2^{l+1}$. Therefore,

$$|Pr\left[S_5\right]-Pr\left[S_4\right]|\le q_h^2/2^{l+1}$$

(10)

Without proper input to the $h\left(\right)$ query, $\mathcal{A}$ cannot differentiate the actual session key from a random one. Therefore,

$$Pr\left[S_5\right]=1/2$$

(11)

Given all the probabilities and conditions above, Theorem 1 holds. □

7. Automatic Verification Using ProVerif

ProVerif is a powerful tool for the formal verification of cryptographic protocols. Written in Prolog, it uses Horn clauses and $PI$ algorithms to perform its tasks. ProVerif is capable of precisely modeling a variety of cryptographic primitives, including shared-key cryptography, public-key cryptography, hash functions, and Diffie–Hellman key-exchange protocols, along with supporting rewriting rules and equations. The tool can demonstrate several important security properties, such as reachability properties, correspondence assertions, and observational equivalence.

The proposed scheme has been verified formally using ProVerif.

Table 3. Codes for users with ProVerif.

let User=

new dui:bitstring;

let MIDui = Mul (Hash (con (dui, PWui)), P) in

out (schij, (IDui, MIDui));

in (schij, (uxui:bitstring,uPKui: bitstring, uTui: bitstring));

let sui = Add (Hash (con (dui, PWui)), uxui) in

let PKui = Mul (sui, P) in

if PKui = uPKui then

let esui = xor (sui, Hash (con (BIOui, PWui))) in

let LV = Mod (Hash (con (con (con (IDui, PWui), BIOui), sui)), d) in

let wsj = Hash (con (Mul (sui, uPKsj), IDui)) in

!

(

event startAuthSk;

let usui = xor (esui, Hash (con (BIOui, PWui))) in

let uLV = Mod (Hash (con (con (con (IDui, PWui), BIOui), usui)), n) in

if uLV = LV then

new TSSeedui:bitstring;

let T1 = generate_Timeline (TSSeedui) in

let Aui = Mul(rui,PKui) in

let EIDsk = xor (IDsk, Hash (con(con (Aui, Bui),)wsj)) in

let Vui = Hash(con(con(con(con(EIDsk, IDui), Aui), T1), wsj)) in

out (chij, (Aui,uTui, EIDsk, T1, Vui));

in (chki, (sAsk: bitstring,sT3: bitstring,sEIDsk: bitstring,

sTui: bitstring,sVsk:bitstring));

let Sik = Mul (mul (rui, sui), sAsk) in

let uIDsk = xor (sEIDsk, Hash (con(sAsk,Sik))) in

let uTui = Hash (con (xor (sTui, Hash (con(sAsk,Sik))),wsj)) in

let uVsk = Hash (con (con (con(con (uIDsk, IDui),sAsk), Sik), sT3))

in

if uVsk = sVsk then

let SKik = Hash (con (con (Sik,IDui), uIDsk))in

event endAuthUi;

0

).

illustrates the processes for $U_i$, as outlined in Section 4. In this setup, $schij$ represents a private channel that facilitates communication between $U_i$ and $S_j$ during the registration phase, while $chij$ and $chki$ are public channels, with $U_i$ and $S_j$ communicating over $chij$ and $U_i$ and $S_k$ communicating over $chki$ during login and authentication. The three participants execute their respective processes, and the scheme is simulated to run in parallel as $\left(\right(!User\left)\right|(!Sk)\left|\right(!RC\left)\right)$.

As shown in

Table 4. Simulation results.

Result	Target
RESULT Weak secret IDui is true (bad not derivable)	Anonymity
RESULT Weak secret IDsK is true (bad not derivable)	Anonymity
RESULT not attacker(sui[]) is true	Long-term secret security
RESULT not attacker(ssj[]) is true	Long-term secret security
RESULT not attacker(ssk[]) is true	Long-term secret security
RESULT not attacker(rui[]) is true	Ephemeral secret security
RESULT not attacker(rsk[]) is true	Ephemeral secret security
RESULT not attacker (SSKik[]) is true	Session key security
RESULT not attacker (SSKki[]) is true	Session key security
RESULT inj-event(endAuthUi) ⇒ inj-event(startAuthUi) is true	Consistent
RESULT inj-event(endAuthSk) ⇒ inj-event(startAuthSk) is true	Consistent

, queries and results confirm that $\mathcal{A}$ is unable to break the authentication process or determine session keys, ephemeral keys, and long-term keys. The proposed scheme ensures high levels of anonymity, consistency, and mutual authentication.

8. Analysis of Security Features

8.1. User Anonymity and Untracibility

During authentication, each $T_{ui}$ is used only once, regardless of whether authentication is successful, and the values of $T_{ui}$ and other authentication parameters are unique for each session. Furthermore, due to the secrecy of $w_{sj}$ and $w_{ui}$, even insider users of RC cannot determine $T_{ui}$. As a result, the scheme ensures anonymity and untraceability.

8.2. Perfect Forward Security

Even if long-term secrets $s_{ui}$ and $s_{sk}$ are compromised, $\mathcal{A}$ is still unable to deduce the session key $S{K}_{ik}$, for $S{K}_{ik}=h(S_{ik}\parallel I{D}_{ui}\parallel I{D}_{sk})$, where $S_{ik}=\left(r_{ui}{s}_{ui}\mathrm{mod}q\right)·A_{sk}$ and $A_{sk}=r_{sk}·P{K}_{sk}$. This is due to the fact that the ephemeral secrets $r_{ui}$ and $r_{sk}$ are unknown to $\mathcal{A}$. Also, even if $\mathcal{A}$ is aware of $s_{ui}$ and $s_{sk}$, he/she cannot deduce $S{K}_{ki}$.

8.3. Key Privacy

During registration, the system does not store or expose password-related data, nor are any password authentication tables maintained. The user information $\{I{D}_{ui},P{K}_{ui},T_{ui},w{t}_{ui}\}$ maintained by RC does not consist of the user’s password and its variants. The long-term keys of $U_i$ and $S_k$ are neither generated by the RC nor known to it. Furthermore, the component of session keys $S_{ik}=(r_{ui}{s}_{ui}modq)·A_{sk}$ and $S_{ki}=(r_{sk}{s}_{sk}modq)·A_{ui}$ does not involve RC. Due to the hardness of the ECDL and ECD problems, $\mathcal{A}$ cannot figure out $s_{ui}$ and $s_{sk}$ even if $S_{ik}$ or $S_{ki}$ are exposed. In a nutshell, no insider user of RC can break the security of the proposal.

8.4. Ephemeral Secret Leakage Attack Resistance

Resistance to ESL attacks comprises the fact that, even if $\mathcal{A}$ captures the ephemeral keys, $r_{ui}$ and $r_{sk}$, he/she is unable to obtain the session key $S{K}_{ik}$ or $SS{K}_{ki}$. For $S{K}_{ik}=h(S_{ik}\parallel D_{ui}\parallel I{D}_{sk})$, where $S_{ik}=(r_{ui}{s}_{ui}modq)·A_{sk}$ and $A_{sk}=r_{sk}·P{K}_{sk}$, even if $r_{ui}$ and $r_{sk}$ are compromised, $\mathcal{A}$ cannot deduce $S{K}_{ik}$ because the long-term keys $s_{ui}$ and $s_{sk}$ are unknown to him. Also, even if $\mathcal{A}$ is aware of $r_{ui}$ and $r_{sk}$, she cannot deduce $SS{K}_{ki}$.

8.5. IoT Node Capture Attack Resistance

Sensors may be positioned in unattended environments and physically captured by $\mathcal{A}$. The credentials $\{I{D}_{sk},s_{sk},P{K}_{sk},I{D}_{sj},w_{sj}\}$ can then be easily retrieved. In the protocol, different sensors have different credentials. Therefore, it only leads to the disclosure of session keys between $S_k$ and user $U_i$, but not between the uncorrupted sensor $S_k^{\prime }$ and user $U_i^{\prime }$. In other words, the proposed scheme is resistant to IoT node capture attacks and limits the impact of such compromises to the specific nodes affected.

8.6. Timely Typo Detection

The parameter $LV$ stored on the user’s device enables immediate validation of user inputs. If the user inputs an incorrect ID or password, the computed value $L{V}^{\prime }$ will differ from the stored value $LV$. As a result, the log-in request will be rejected, ensuring prompt detection and mitigation of typographical errors during authentication.

9. Performance Comparison

9.1. Security Feature Comparison

As shown in

Table 5. Security feature comparison.

Scheme	F1	F2	F3	F4	F5	F6	F7	F8	F9	F10	F11	F12	F13	F14	F15
[17]	✓	✓	×	✓	×	✓	×	×	✓	✓	✓	✓	✓	✓	✓
[19]	×	×	×	×	✓	✓	×	×	✓	✓	✓	✓	×	✓	✓
[20]	×	×	×	×	✓	✓	×	×	✓	×	✓	✓	✓	✓	✓
[21]	×	×	✓	×	✓	✓	×	✓	✓	×	✓	✓	✓	✓	✓
[22]	×	✓	✓	×	✓	✓	×	×	✓	✓	✓	✓	×	✓	✓
[25]	✓	✓	✓	✓	×	✓	×	✓	✓	✓	✓	✓	✓	✓	✓
[26]	✓	×	×	✓	×	✓	×	✓	✓	✓	✓	✓	✓	✓	✓
Ours	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓

F1: Anonymity and untraceability; F2: PFS; F3: key privacy; F4: offline password guessing attack resistance; F5: ephemeral secret leakage attack resistance; F6: smart card loss attack resistance; F7: insider impersonation attack resistance; F8: man-in-the-middle attack resistance; F9: replay attack resistance; F10: IoT node capture attacks; F11: password-friendly; F12: timely typo detection; F13: mutual authentication and key agreement; F14: password/biometric update locally; F15: no password authentication table. ✓: supporting a functional feature or ensuring security; ×: lacking a functional feature or not ensuring security.

, the comparison of security features indicates that the proposal offers better security and functionality than the related scheme [17,19,20,21,22,25,26]. Compared to existing schemes, the recommended approach effectively provides anonymity, untraceability, PFS, key privacy, and resistance to insider impersonation, ESL, man-in-the-middle, and other attacks.

9.2. Communication Cost

Assume that the lengths of the random number (R), hash output (H), identity (ID), ECC point (G), and timestamp (TS) are 128, 256, 256, 384, and 32 bits, respectively. In the proposed scheme, three messages $M1$, $M2$, and $M3$ are transmitted during the login and authentication phase, where $M1=\{A_{ui},TI{D}_{ui},CI{D}_{sk},T_1,V_{ui}\}$, $M2=\{A_{ui},T_2,EI{D}_{ui},V_{sj}\}$, and $M3=\{A_{sk},T_3,EI{D}_{sk},V_{sk}\}$. The lengths of $M1$, $M2$, and $M3$ are $384+128+128+32+256=928$ bits, $384+32+128+256=800$ bits, and $384+32+128+256=800$ bits. The total communication cost is $\{928+800+800=2528\}$ bits. The communication overheads of [17,19,20,21,22,25,26] are 3584, 4384, 3296, 3872, 3680, 3456, and 3392 bits, respectively.

Table 6. Communication costs.

Scheme	User	TA	Sensor	Total (bit)	Total (↓%)
Ours	G + H + TS + 2ID = 928	G + H + TS + ID = 800	G + H + TS + ID = 800	2528	-
[17]	G + H + 2ID = 896	2G + 4H = 1792	G + 2H = 896	3584	29.5%
[19]	G + 3H + TS + 2ID = 1440	G + 3H + 2TS + 3ID = 1600	G + 3H + 2TS + ID = 1344	4384	41.1%
[20]	G + 3H + TS + ID = 1312	G + 2H + TS = 928	G + 2H + TS + ID = 1056	3296	23.3%
[21]	G + 2H + TS + 3ID = 1312	G + 3H + 2TS + ID = 1344	2G + H + 2TS + ID = 1216	3872	34.7%
[22]	G + 2H + TS + 2ID = 1184	2G + H + R + TS + ID = 1440	2G + H + TS = 1056	3680	31.3%
[25]	G + H + R + 2ID = 1152	2G + 2H + R + ID = 1644	G + H = 640	3456	26.8%
[26]	G + H + TS + 2ID = 928	2G + 2H + 2R + 2TS + 2ID = 2122	H + TS = 384	3328	24.0%

↓: reduction in the overhead of our scheme over existing schemes.

shows that the proposed scheme reduces communication costs from 23% to 42%.

9.3. Computation Cost

To compare the computational overhead of different schemes, the run times of other cryptographic primitives are tested. A laptop with Intel Core i5-8250U 1.60 GHZ + 16 GB RAM (Intel Corporation, Santa Clara, CA, USA) and Windows 11 serves as the server. A Raspberry Pi 3 Model B+ (Raspberry Pi Ltd., Cambridge, UK) board with ARM Cortex-A53 1.4 GHz + 1 GB RAM (ARM Ltd., Cambridge, UK) serves as the sensor node and user. When p = $2^{192}$, the elliptic curve is Curve25519, and the point length is 384 bits; the average running time is shown in

Table 7. Run times of different cryptographic primitives.

Notation	Cryptographic Primitive	RC	User/Sensor
$T_{em}$	ECC point multiplication	$1.774$	$3.747$
$T_{ea}$	ECC point addition	$0.026$	$0.041$
$T_h$	Hash operation	$0.016$	$0.032$
$T_{ae}$	AEGIS	$0.033$	$0.051$
$T_{fe}\approx T_{em}$	Fuzzy extractors	$1.774$	$3.747$

.

Table 8. Computation costs.

Scheme	User (ms)	RC (ms)	RC (↓%)	Sensor (ms)	Total (ms)	Total (↓%)
Ours	$T_{fe}+2T_{em}+8T_h\approx 11.497$	$5T_h\approx 0.08$	-	$2T_{em}+5T_h\approx 7.654$	$19.231$	-
[17]	$T_{fe}+3T_{em}+9T_h\approx 15.276$	$T_{em}+8T_h\approx 1.902$	95.8%	$2T_{em}+4T_h\approx 7.622$	$24.8$	22.5%
[19]	$T_{fe}+5T_{em}+T_{ea}+19T_h\approx 23.131$	$5T_{em}+T_{ea}+T_h\approx 8.912$	99.1%	$4T_{em}+T_{ea}+12T_h\approx 15.413$	$47.456$	59.5%
[20]	$T_{fe}+5T_{em}+T_{ea}+17T_h\approx 23.067$	$2T_{em}+10T_h\approx 3.708$	97.8%	$4T_{em}+T_{ea}+8T_h\approx 15.285$	$42.06$	54.3%
[21]	$T_{fe}+5T_{em}+3T_{ea}+16T_h\approx 23.117$	$3T_{em}+2T_{ea}+9T_h\approx 5.518$	98.6%	$4T_{em}+2T_{ea}+8T_h\approx 15.326$	$43.961$	56.3%
[22]	$3T_{ae}+T_{fe}+3T_{em}+6T_h\approx 15.333$	$3T_{ae}+T_{em}+2T_h\approx 1.905$	95.8%	$2T_{ae}+2T_{em}+3T_h\approx 7.692$	$24.93$	22.9%
[25]	$3T_{am}+T_{fe}+8T_h\approx 15.244$	$T_{em}+10T_h\approx 1.934$	95.9%	$2T_{em}+4T_h\approx 7.622$	$24.8$	22.5%
[26]	$3T_{em}+T_{ea}+T_{fe}+11T_h\approx 15.381$	$4T_{ae}+T_{ea}+9T_h\approx 7.266$	98.9%	$2T_{ae}+6T_h\approx 7.686$	$30.333$	36.6%

↓: reduction in the overhead of our scheme over existing schemes.

illustrates that our scheme reduces computation costs by comparing 22% to 56% with the related scheme. In particular, the computational overhead of the intermediate server is reduced by more than 95%. These results highlight significant optimization of resource consumption in the proposed scheme, particularly in resource-constrained IoT environments and scenarios where the intermediate server is connected to many nodes.

10. Conclusions

In IoT systems such as smart homes and smart healthcare, IoT user authentication protocols enable secure authentication and session key negotiation between users and IoT devices through an intermediate server, thereby ensuring that users can securely access sensor data directly or control IoT devices remotely. However, the existing IoT user authentication schemes typically assume that the server is fully trusted, ignoring the risk of potential attacks from inside entities. For example, an insider user may launch an insider impersonation attack and steal the session key negotiated between the user and the end device. In addition, most of the existing protocols lack key security properties, such as effective defense against ESL attacks and offline password guessing attacks, as well as perfect forward security. Furthermore, as the scale of IoT devices grows dramatically, intermediate servers need to manage a large number of user and device connections, making the performance of authentication schemes highly dependent on the computational power of the servers.

The design of security protocols is based on the security model, and the existing security model for IoT user authentication still has limitations, making it difficult to comprehensively deal with insider attacks and temporary random number leakage. To enhance the security of IoT user authentication protocols, this paper proposes a new security model for IoT user authentication, IoT-3eCK, which assumes that the intermediate server is semi-trusted and enhances the attacker model to improve the security requirements of IoT user authentication protocols. Based on this security model, this paper designs an enhanced and efficient IoT user authentication protocol. In the registration phase, the protocol ensures that long-term secrets, user passwords, and biometric data of users and end devices are not deduced by insider users in the registration center, effectively preventing internal attacks. In the authentication phase, the protocol combines a dynamic pseudo-identity anonymization mechanism and an ECC key-exchange mechanism to ensure that the protocol satisfies additional security properties. The performance analysis shows that, compared to the existing schemes, the protocol reduces the communication cost by more than 22% and the computational overhead by more than 23%, especially on the intermediate server side by more than 95%, which significantly improves system efficiency. In addition, the security of the new protocol is rigorously proved using a randomized predicate machine model and verified using an automated verification tool.