# A Secure and Lightweight Three-Factor Remote User Authentication Protocol for Future IoT Applications

Authors: Bahaa Hussein Taher; Huiyu Liu; Firas Abedi; Hongwei Lu; Ali A. Yassin; Alzahraa J. Mohammed
Journal: Journal of Sensors
 (2021)

---

## Abstract

With the booming integration of IoT technology in our daily life applications such as smart industrial, smart city, smart home, smart grid, and healthcare, it is essential to ensure the security and privacy challenges of these systems. Furthermore, time-critical IoT applications in healthcare require access from external parties (users) to their real-time private information via wireless communication devices. Therefore, challenges such as user authentication must be addressed in IoT wireless sensor networks (WSNs). In this paper, we propose a secure and lightweight three-factor (3FA) user authentication protocol based on feature extraction of user biometrics for future IoT WSN applications. The proposed protocol is based on the hash and XOR operations, including (i) a 3-factor authentication (i.e., smart device, biometrics, and user password); (ii) shared session key; (iii) mutual authentication; and (iv) key freshness. We demonstrate the proposed protocol’s security using the widely accepted Burrows–Abadi–Needham (BAN) logic, Automated Validation of Internet Security Protocols and Applications (AVISPA) simulation tool, and the informal security analysis that demonstrates its other features. In addition, our simulations prove that the proposed protocol is superior to the existing related authentication protocols, in terms of security and functionality features, along with communication and computation overheads. Moreover, the proposed protocol can be utilized efficiently in most of IoT’s WSN applications, such as wireless healthcare sensor networks.


---

## Body

## 1. Introduction

The IoT has been a trend in the last few years, and it is expected to be so in the future [1]. In an IoT system, information is being sensed/collected by IoT sensing devices such as embedded systems, Radio Frequency Identification (RFID), wearable devices, and low powered IEEE 802.15.4 devices before being sent to another intermediary device/node (e.g., edge or fog computing node), IoT device, or to the cloud, via the Internet. In IoT, many devices can interact with each other over the Internet. A lot of IoT applications, already, have been deployed such as healthcare systems, smart cities, smart industrial, transportation systems, and smart homes [2, 3]. In these IoT applications, WSNs are most necessary and important [4]. The use of WSNs has greatly increased in providing services to activities and monitoring environments due to its low costs, ease of deployment, a wide range of applications, and flexibility [5]. Therefore, security and privacy are a significant challenge in any consumer technology deployment [6]. For example, let us highlight on an IoT healthcare application [7] as shown in Figure 1. In this scenario, the quality of healthcare service can be enhanced by allowing a medical practitioner to direct access to data that have sensed by the medical sensor nodes deployed in his patient’s body. This information can involve current vital reading such as blood pressure, cholesterol, C-reactive protein, and blood sugar level. Accordingly, based on this private and secret current information, a decision can be taken regarding the patient’s health condition to provide necessary remedial actions.Figure 1
Authentication model for future IoT WSN applications [7].In IoT, the sensor node/devices in WSN face a significant security challenge. Usually, those sensor nodes are deployed in places that are easy for people to touch. Nowadays, one of the most possible critical security attacks that easily happen is a node captured attack where the authentication information that is inside the sensor node is revealed by physical crack [8]. Furthermore, new remote user authentication that is also possible could be vulnerable to this attack because the malicious attacker possibly obtained all sensitive authentication information through this attack. Thus, the security issues in IoT WSN applications are significant and catch more attention. To satisfy this goal, we proposed a secure and lightweight remote user authentication and key agreement protocol to operate in an IoT WSN application environment.


### 1.1. Motivation

The IoT WSN has opened up many opportunities in various walks of life and particularly in healthcare, shipping, warehousing, and logistics, which have facilitated processes for consumers and businesses. This wide-ranging and rapid development has led to the emergence of great challenges that require the design of high-security protocols for IoT applications in order to preserve the sensitive information of users. Security is now the primary challenge facing the IoT WSN environment. In an IoT WSNs, remote users can access data from IoT sensor nodes via the Internet. Researchers have developed effective mechanisms to integrate wireless networks into the Internet of things environments [9, 10]. Sensor nodes are inherently resource-constrained devices in terms of limited processing capability, constrained communication bandwidth, and very low storage capacity due to the physical size and limited energy [11]. Therefore, designing a secure and efficient remote user authentication protocol for IoT WSN environments is a nontrivial challenge. In IoT environments, the security efficiency of remote user authentication is an important issue for transmitting information securely [12–14]. In addition, energy consumption and computational and communication efficiency are crucial due to the WSN resources energy limitation. Also, due to constrained sensors, adding resourceful gateway nodes can support the sensors, can provide quick on-demand delivery of information, and take care of most of the processing. The authentication of users or devices is a critical issue that must be considered in the context of IoT security. Most of the traditional authentication protocols are based on a password, a smart card, or both. These protocols are ineffective at present since attackers have modified the methodology of their attacks on IoT devices. The need for biometric-based approaches that are difficult to reproduce, such as those involving fingerprints, iris scanning, and facial patterns, has emerged as an additional factor that can enhance the security of Internet applications.


### 1.2. Attack Model

In our proposed protocol, we follow the widely accepted and more realistic Dolev-Yao threat (DY) model [15]. In this model, the communication between two entities is accomplished over a public (open) channel. Also, an adversary MA will have full control over the communication channel. Therefore, MA can alter, eavesdrop, insert, and delete forgery messages that are being transmitted during communication. In addition, it is assumed that MA can physically capture one or more IoT sensing nodes in IoT and can steal all sensitive information stored in the captured sensing nodes which utilize the strength analysis attacks.


### 1.3. Our Contribution

The main contributions of our proposal are as follows:(1)
We proposed a lightweight and secure remote user authentication protocol based on feature extraction of the user fingerprint and one-way hash function for IoT WSN applications which is suitable to use in wireless healthcare application. The proposed protocol is three factors: user password, smartphone, and biometrics to achieve our goal. We used biometrics to increase the security of the protocol due to difficulty to forge or steal or forget biometrics(2)
Level 3 feature extraction is done to overcome the problem of noise in fingerprint images in existing authentication schemes(3)
We prove our protocol secure using informal and formal security analysis through BAN logic and random oracle model(4)
We simulate the proposed protocol using the popular and widely accepted tool called AVISPA and demonstrate that the protocol is perfectly secure against active and passive attacks(5)
Comparative evaluation of our protocol with related protocols in terms of communication and computational overheads was performed


## 1.1. Motivation

The IoT WSN has opened up many opportunities in various walks of life and particularly in healthcare, shipping, warehousing, and logistics, which have facilitated processes for consumers and businesses. This wide-ranging and rapid development has led to the emergence of great challenges that require the design of high-security protocols for IoT applications in order to preserve the sensitive information of users. Security is now the primary challenge facing the IoT WSN environment. In an IoT WSNs, remote users can access data from IoT sensor nodes via the Internet. Researchers have developed effective mechanisms to integrate wireless networks into the Internet of things environments [9, 10]. Sensor nodes are inherently resource-constrained devices in terms of limited processing capability, constrained communication bandwidth, and very low storage capacity due to the physical size and limited energy [11]. Therefore, designing a secure and efficient remote user authentication protocol for IoT WSN environments is a nontrivial challenge. In IoT environments, the security efficiency of remote user authentication is an important issue for transmitting information securely [12–14]. In addition, energy consumption and computational and communication efficiency are crucial due to the WSN resources energy limitation. Also, due to constrained sensors, adding resourceful gateway nodes can support the sensors, can provide quick on-demand delivery of information, and take care of most of the processing. The authentication of users or devices is a critical issue that must be considered in the context of IoT security. Most of the traditional authentication protocols are based on a password, a smart card, or both. These protocols are ineffective at present since attackers have modified the methodology of their attacks on IoT devices. The need for biometric-based approaches that are difficult to reproduce, such as those involving fingerprints, iris scanning, and facial patterns, has emerged as an additional factor that can enhance the security of Internet applications.


## 1.2. Attack Model

In our proposed protocol, we follow the widely accepted and more realistic Dolev-Yao threat (DY) model [15]. In this model, the communication between two entities is accomplished over a public (open) channel. Also, an adversary MA will have full control over the communication channel. Therefore, MA can alter, eavesdrop, insert, and delete forgery messages that are being transmitted during communication. In addition, it is assumed that MA can physically capture one or more IoT sensing nodes in IoT and can steal all sensitive information stored in the captured sensing nodes which utilize the strength analysis attacks.


## 1.3. Our Contribution

The main contributions of our proposal are as follows:(1)
We proposed a lightweight and secure remote user authentication protocol based on feature extraction of the user fingerprint and one-way hash function for IoT WSN applications which is suitable to use in wireless healthcare application. The proposed protocol is three factors: user password, smartphone, and biometrics to achieve our goal. We used biometrics to increase the security of the protocol due to difficulty to forge or steal or forget biometrics(2)
Level 3 feature extraction is done to overcome the problem of noise in fingerprint images in existing authentication schemes(3)
We prove our protocol secure using informal and formal security analysis through BAN logic and random oracle model(4)
We simulate the proposed protocol using the popular and widely accepted tool called AVISPA and demonstrate that the protocol is perfectly secure against active and passive attacks(5)
Comparative evaluation of our protocol with related protocols in terms of communication and computational overheads was performed


## 2. Related Work

The general security requirements needed to secure an IoT WSN environment are authentication, integrity, confidentiality, availability, nonrepudiation, authorization, freshness, forward, and backward secrecy. Therefore, a remote user authentication scheme designed for an IoT WSN environment should be designed in a way that ensures it will withstand many attacks such as man-in-the-middle, online/offline guessing, replay, privileged insider, stolen/lost smart card, password change, and sensing device capture. Also, the designed scheme should reduce computation and communication costs and include the password/biometric update phase. Presume a scenario for a medical practitioner wandering the medical IoT environment. In such an assumption, we need to preserve certain information about this user such as achieving anonymity preservation to prevent other parties (users) from revealing the patient’s critical privacy information while he/she joins the system sessions. By way of explanation, user anonymity is one of important key features in the user authentication protocol [16]. Also, the untraceability feature is important in the IoT WSN applications to prevent an attacker from tracing a user during a session [17]. WSNs have become an important and necessary network infrastructure after modernization, and they can be generally used in many modern fields such as health monitoring, environments, and smart homes [18–21]. To gratify the security requirements of the IoT WSN environment, numerous user authentication protocols have been proposed. Shi and Gong [22] proposed a new user-authentication scheme using ECC for the WSNs. Unfortunately, the storage and computational overhead are relatively high so it is not applicable for healthcare application systems [23–25].Usually, the real-time users adopt to use easy-to-memorialize parameters, such as secret keys and identities, for their convenience, as explain in [23–25]; hence, user anonymity is not provided. For the enhancement security of IoT WSNs, studies in [26–30] presented lightweight remote user authentication schemes. Nonetheless, these contributions have need of improvements to resist attacks while persevering optimum communication and computation performance. In 2016, Arasteh et al. [31] proposed an authentication scheme for an IoT network that aimed to overcome the weaknesses of a scheme designed by Amin et al. [32]. In 2017, Dhillon and Kalra’s [33] proposed a lightweight 3FA scheme using a user password, biometric, and a mobile device. They pointed out that their scheme is secure against well-known attacks such as a denial of service, impersonation, offline password guessing, and stolen mobile device attacks. However, their scheme is still insecure against the mentioned attacks and does not afford a session key agreement. In the same year, Li et al. [34] and Zhang et al. [35] presented their authentication schemes with key agreement. They showed that their scheme was lightweight and appropriate for constrained IoT environments. In 2018, several studies were published on remote user authentication for the IoT environment [36–41]. The author in [36] presented an authentication scheme for ad hoc WSN to improve the security weakness of the scheme in [42] using ECC cryptograph. In Cyber-Physical Systems (CPS) and IoT, Lu et al. [37] presented a mutual authentication proposed scheme with user anonymity. Xu et al. [38] proved that Srinivas et al.’s [43] authentication schemes are vulnerable by many attacks and did not achieve user anonymity features. Moreover, Ryu et al. [39] reviewed Wu et al.’s [44] scheme and pointed out that Wu et al.’s scheme has two security weaknesses against outsider attackers. A new user authentication scheme was presented by Wazid et al. [40] for a hierarchical IoT network. These authors observed that their scheme involved lower computation and communication costs. Moreover, Chen et al. [41] presented an authentication scheme based on the fuzzy extractor. Nonetheless, the overhead in Chen’s scheme is costly.More recently, in 2019, articles on this subject were published by Dammak et al. [45], Gupta et al. [46], Lyu et al. [47], Ma et al. [48], Renuka et al. [49], and Li et al. [50]. However, these schemes still have weaknesses, particularly in terms of the computation and communication overheads, which are highly compared to those of our proposed scheme. In summary, most remote user authentication protocols either fail to achieve IoT WSN environment security requirements or they do not provide security functionality features such as dynamic anonymity and untraceability and biometric and password change procedures. To overcome the aforementioned weaknesses, we proposed a lightweight remote user authentication protocol suited for the IoT WSN application, which achieves user anonymity and untraceability.


## 3. Basic Preliminaries

In this section, we briefly discuss the properties of the one-way hash function, perceptual hashing, and level 3 feature extraction.(i)
Level 3 feature extraction of fingerprint: a fingerprint is the pattern of ridges and valleys on the outer surface of the fingertip, and each individual has unique fingerprints. Fingerprint identification involves three levels: the first level includes details such as thr pattern type and ridge-line flow; the second involves minutiae points for instant bifurcations, spurs, and terminations; and the third relates to the dimensional properties of a ridge, such as incipient ridges, creases, pores, and edge contours The third level contains all the dimensional properties of a ridge for instant sweat pores, initial ridges, edge, and the crispiness. Our proposed protocol therefore adopts the third level, since it is unique, unalterable, and perpetual. More detail can be found in [51].(ii)
One-way hash function: one-way hash function (1HF) is a mathematical function that is broadly used in many applications, such as disclose data integrity during transmission, generating message authentication codes (MAC), and digital forensic investigations. Cryptographic 1HF is highly sensitive to even small perturbations to the input. The 1HF is impossible to invert, i.e., it is difficult to regain the original text from the hash value. It produces hash values of 128 bits and higher. Generally, 1FH is used to generate digital signatures, which are used to recognize and authenticate the sender [52].(iii)
Perceptual hashing: when using biometrics for user authentication schemes, the standard encryption or hashing algorithms cannot be used to encrypt the biometric template. The biometric data such as fingerprint and voice. change with time and environment. Therefore, in designing a user authentication protocol using biometrics, the hashing or encryption algorithms cannot be utilized to encrypt the biometric template. To deal with this issue, researchers have proposed using perceptual hashing (p-hash) [53]. The advantage of using p-hash is capability tolerant to unimportant variation in the quality and format of the input. The hash value size that is generated by perceptual hashing differs from 64 to 128 bits [54]. In this paper, we adopted the perceptual hashing function proposed by Jie [55] in a previous study. The authors in [56] merge the image blocks which have low-frequency DCT coefficients and the color histogram as a perceptual feature, and this perceptual feature then compressed as interfeature with PCA and threshold the interfeature to generate a strong hash. Figure 2 shows the process of perceptual hashingFigure 2
Perceptual hashing based on block-DCT and PCA based image.


## 4. The Proposed Protocol

In this section, we propose an efficient and secure user authentication protocol for IoT WSN applications using the network model scenario presented in Figure1. We also mention that the proposed protocol is designed to be generic enough for most IoT WSN applications that require user authentication. A summary of the symbols used in this paper is given in Table 1. In this work, we utilize the current timestamps to ensure flexibility to replay attacks. In this work, we utilize the current timestamps to ensure flexibility to replay attacks. Consequently, the clocks of all protocol objects are assumed to be synchronized which is a typical assumption in the literature [7, 44, 57]. Our authentication protocol based on three factors, namely, password, user’s biometric, and smartphone focuses on the user in order to reduce the costs to the IoT nodes. Using a smart device such as a smartphone, the user can easily access the IoT nodes and the services they provide.Table 1
Symbols used.
NotationDescriptionUiRemote userIDiIdentity of the userPWiISiThe user passwordExtracting user irisRi,RkRandom numbers generated by the userFPiThe fingerprint of the userFX3Feature extraction level 3DkIoT sensing nodesXgDiThe shared secret key of the IoT devices, generated byDkGWThe trusted gateway nodeXgA secret key generated by the gatewayXguA secret key generated for the userTS1, TS2, TS3, TS4, TTimestampsSKShared session key⨁XOR operation∥Concatenation operationH.One-way hash functionThe proposed protocol contains three participants: a remote user (Ui) who aims to maximize the services in the environment, a set of IoT sensor nodes (Dk), and a trusted home authority/gateway (GW). Our work consists of four phases: registration, precomputation, authentication and key agreement, and password change phase. The registration phase was performed once, while the precomputation, authentication, and password change phase are executed whenever a remote user wishes to login or change his/her password. The proposed protocol enables the remote users to freely update his password and/or biometric information with the help of the smartphone without further involving GW.


### 4.1. Remote User Registration Phase

User side: at this stage, Ui who aims to access IoT resources must initially register in the GW. To complete the registration, Uiexecutes the following steps:
(Step 1)
TheUi selects his identity IDi and passwordPWi. Afterwards, Ui inputs his/her fingerprintFPi(Step 2)
TheUi computes level 3 feature extraction of the fingerprint as follows: FX3FPi=FeatExtFPi(Step 3)
TheUi selects a random integer Ri∈Zn+ and computes a mask for the user’s identity, password, and fingerprint as follows: identity mask: MIDi=HIDi⨁Ri, password mask: MPWi=HPWi⨁iRi, and fingerprint mask: MFPi=hFX3FPi(Step 4)
TheUi sendsMIDi, MPWi, MFPi, and FX3FPi to the GW as a communication request to the GW node through a secure channelGateway side: on receiving a request message fromUi, the GW performs the following steps.
(Step 1)
GW generates secret keys Xg and Xgu. Following this, GW computes the security parameters ai=HMIDi⨁Xg, bi=HMPWi⨁Xgu, and ci=HFX3FPi⨁Xgu, prior to use(Step 2)
GW calculates Factor=∑i=1LASCIIFX3FPi, ei=aifi⨁Xgu, and fi=bifi⨁Xgu(Step 3)
TheGW node submits M1=MIDi, ei, fi, Xgu, and MFPi to Ui. On receiving M1, Ui saves it in the memory of the device. Figure 3 summarizes the different processing steps followed during this phaseFigure 3
Summarize of the user registration phase.


### 4.2. IoT Sensor Node Registration

In this stage, each IoT sensor node is a registry. Any supplementary nodes can be added dynamically. This stage consists of the following steps.IoT node side:(Step 1)
Dk generates a random number Rk∈Zn+. Dk known the shared secret XgDk of the GW and has a unique identity IDDk∗(Step 2)
Dk computes the parameters MPWj=hXgDk∥Rk∥IDDk∗ and MDk=Rk⨁XgDk⨁Factori for further calculation(Step 3)
Dk sendsMPWj, MDk, IDDk∗, and TS1 to the GW through a secure channelGW node side: upon receiving the registration request from IoT sensor nodesDk, the Gw calculates the following steps.
(Step 1)
Checks the timestamp conditionTS1−T<△T. If the condition is unsatisfied, then the registration phase is terminated; otherwise, the GW executes the next step(Step 2)
ComputesRk′=MDk⨁XgDk⨁Factori, and MPWj′ on the basis of the previous message received from Ui as MPWj′=hXgDk∥Rk′∥IDDk∗(Step 3)
Verifies whetherMPWj=MPWj′ or not. Therefore, if they are not unequal, the node is not illegitimate, and the GW terminates the session. Otherwise, GW executes the next step(Step 4)
Computes the following parameters for further use,aj=hIDDk∗∥Xg, bj=hMPWj∥XgDk∥Factori, and cj=aj⨁bj(Step 5)
Then,GW sendsaj, cj, and TS2 toDk. Upon receiving the registration messages (aj, cj, and TS2) from the GW, Dk checks the timestamp condition TS2−T<△T to verify for any external interference. If the condition is unsatisfied, then the session is terminated; otherwise, Dk saves the parameters aj, cj. and TS2 into his device memory. Finally, the user registration phase is accomplished. Figure 3 shows the steps of the IoT sensor node registration phase


### 4.3. Precomputation and Login Phase

Once the registration is accomplished successfully, an authorized userUi can access any desired sensor node within the IoT network through the authentication phase. To start with the authentication phase, Ui must login to the selected IoT service application, following the login steps that are implemented during this phase.
(Step 1)
First, the userUi uses the smartphone to open the applications and enters his/her passwordPWi and level 3 feature extraction FX3FPi saved in the smartphone(Step 2)
Then, the smartphone ofUi calculates a masked for the password and the feature extraction as follows: MPWi′=hMPWi⨁Ri and MFPi′=hMFPi⨁Ri. Also, it computes bi∗∗=haiFactori⨁ei⨁MPWi⨁Xgn andci∗∗=hMFPi⨁biFactori⨁Factori(Step 3)
Next, the original values ofbi and ci extract as follows: bi∗=hMPWi⨁Xgu and ci∗=hMFPi⨁Xgu(Step 4)
Ui computes the value of the following verification parameters bi∗∗ and ci∗∗ as bi∗∗=haiFactori⨁ei⨁MPWi⨁Xgn and ci∗∗=hMFPi⨁biFactori⨁Factori(Step 5)
Then, the accurateness ofbi∗ and ci∗ is verified with bi∗∗ and ci∗∗. If bi∗=bi∗∗? and ci∗=ci∗∗?, then the login proceeds to the next step. Otherwise, the user is not legal and has entered incorrect credentials, and the process will terminate(Step 6)
On successful the user validation, it calculates the security parameters:UDk=hXgu∥TS1∥FactoriRi andUCi=Ri⨁ai(Step 7)
Also, calculatesFactori∗=Factori⨁TS1 for use in a security check later(Step 8)
In the end,Ui sends the login parameters M5=Factori∗,UDk,UCi,TS3,ei,fi to the desired IoT node. Upon completing step 8, the login phase is complete. The user Ui can select any node in the IoT environment


### 4.4. Authentication and Key Agreement Phase

To access the services of the IoT sensor nodes, the user will attempt to login to the proper node, after which the node will redirect the user login request toGW, which will carry out the necessary process to check the user’s authentication. When mutual validation is achieved between these three entities, a session key will be established between the user and the IoT sensor node. Figure 4 summarizes the login and the authentication phase. The following steps illustrate the processes of this phase.
(Step 1)
On receiving the login request message fromUi, Dk performs the timestamp check on receive TS3, i.e., TS3−T<∆T. Also, check the security parameter Factori∗?=Factori⨁TS1?, to authenticate theUi. If the condition is unsatisfied, then the login is terminated; otherwise, the process proceeds to the next step(Step 2)
Dk uses the stored values of ej and aj to calculatebj=ej⨁aj(Step 3)
Next,Dk calculates Aj=hXgDk∥TS1∥TS2⨁bj(Step 4)
Dk sends M6=UCi,UDk,ei,fi,TS3,TS4,Factori∗ to the GW. GW can recognize the legitimacy of the Ui and the node Dk on the basis of the parameter Factori∗ and the transaction time. In this step, the node Dk authenticates theGW(Step 5)
GW verifies the received timestampTS4−T<∆T and Factori∗?=Factori⨁TS1, authority of the Ui, and the device Dk simultaneously. If the condition is satisfied, then the GW proceeds to the next step; otherwise, the process is terminated(Step 6)
Then,GW calculates the security parameters: aj∗=hIDDk∥Xg, bj∗=ei⨁aj∗, and bj=Aj⨁hXgDk∥TS3∥TS4. Afterwards, the GW checks the quality of bj andbj∗. If they are equal, then GW authenticates the node Dk and the user UiFigure 4
Summarize of login and Authentication Phase.The IoT sensor nodeDk must be successfully verified by the GW on the basis of the retrieved Factori depending onMIDi. Therefore, GW performs the following:
(Step 1)
GW calculates Ri∗=UCi⨁hMIDi⨁Xg andUDk∗=hXgui∥TS3∥Factori∥Ri∗(Step 2)
GW compares the original UDk and the calculated UDk∗ to authenticate the Ui. If the verification condition is unsuccessful, then the GWterminates the communication; otherwise, the GW continues to the next step(Step 3)
Next,GW computes the security parameters: GPij=Factori∗⨁Ri∗⨁haj∗∥XgDk and Vi=hUDk∗∥TS3∥TS4∥TS5∥Xgu(Step 4)
GW submits M7=GPij,Vi,TS5 to DkUpon receiving the verification parametersM7 from the GW, DK computes the following processes:
(Step 1)
Dk verifies the timestampTS5−T<△T. If the verification condition is unsatisfied, then the process is terminated; otherwise, it continues forward(Step 2)
Then,DK checks the validity of GPij withFactori∗⨁Ri⨁haj∗∥XgDk. If the condition is unsatisfied, then the process is terminated; otherwise, it proceeds to the next step(Step 3)
Next,DK calculates cha=Ri⨁Factori⨁Mi, and Vi∗=hVi∥TS4⨁Mi, where M is a random number generated once. Afterwards, DK computes the session key as SK=hRi⨁Mi⨁Factori∗(Step 4)
At last,DK sends M8=Vi∗,TS3,TS4,TS5,TS6,cha to the Ui. When Ui receives the verification parameterM8 from DK, Ui executes the following steps:(Step 1)
Ui performs timestamp checks, i.e., TS6−T<△T? If not, then the process is terminated; otherwise, it continues to the next step(Step 2)
Ui retrieves Mi∗=cha⨁Ri⨁Factori∗(Step 3)
Then,Ui computes Vi∗∗=hhUDk∥TS3∥TS4∥TS5⨁Mi∗. Then, Ui verifies if Vi∗∗=Vi∗. If not, then Uiis unsure of the authority ofDK and theGW; otherwise, the Ui computes the session key as SK=hMi∗⨁Ri and the authentication and key agreement phase successfully


### 4.5. Password and Biometric Change Phase

This phase is necessary to regularly update the user password to preserve high security. The proposed protocol allows the remote user to change his/her password easy.(Step 1)
Ui who must change his/her password opens the IoT application on a smart device and enters his/her old password MPWi and feature extraction MFP; then, he/she calculates the masked for each of and feature extraction of user biometrics as MPWi=hMPWi⨁Ri, MFPi=hMFPi⨁Ri(Step 2)
Then,Ui calculates bi∗∗=haiFactori⨁ei⨁MPWi⨁Xgn and ci∗∗=hMFPi⨁biFactori⨁Factori and proceeds to the next step(Step 3)
Next,Ui checks the equality of bi∗∗ and ci∗∗ with the original one bi∗=hMPWi⨁Xgu and ci∗=hMFPi⨁Xgu. If any conditions do not hold, the Ui unsuccessfully enters his correct data, and the system will be terminated; otherwise, Ui is a valid user, and then Ui is permitted to change his/her password(Step 4)
Ui enters the new password PWi∗ and new fingerprintFPi∗. Then, he/she calculates mask the hash function for each of them as MPWi∗=hPWi∗i⨁iRi and MFPi∗=hFPi∗⨁Ri, correspondingly(Step 5)
Then,Ui updates the parameter bi∗ on the basis of the new password as bi′=hMPWi∗⊕Xgu. Then, it calculates new fi as: fi′=bi′fi⨁Xgu(Step 6)
At last,Ui changes the old fi stored in the smart device memory with the new one fi′, and the phase terminates successfully


## 4.1. Remote User Registration Phase

User side: at this stage, Ui who aims to access IoT resources must initially register in the GW. To complete the registration, Uiexecutes the following steps:
(Step 1)
TheUi selects his identity IDi and passwordPWi. Afterwards, Ui inputs his/her fingerprintFPi(Step 2)
TheUi computes level 3 feature extraction of the fingerprint as follows: FX3FPi=FeatExtFPi(Step 3)
TheUi selects a random integer Ri∈Zn+ and computes a mask for the user’s identity, password, and fingerprint as follows: identity mask: MIDi=HIDi⨁Ri, password mask: MPWi=HPWi⨁iRi, and fingerprint mask: MFPi=hFX3FPi(Step 4)
TheUi sendsMIDi, MPWi, MFPi, and FX3FPi to the GW as a communication request to the GW node through a secure channelGateway side: on receiving a request message fromUi, the GW performs the following steps.
(Step 1)
GW generates secret keys Xg and Xgu. Following this, GW computes the security parameters ai=HMIDi⨁Xg, bi=HMPWi⨁Xgu, and ci=HFX3FPi⨁Xgu, prior to use(Step 2)
GW calculates Factor=∑i=1LASCIIFX3FPi, ei=aifi⨁Xgu, and fi=bifi⨁Xgu(Step 3)
TheGW node submits M1=MIDi, ei, fi, Xgu, and MFPi to Ui. On receiving M1, Ui saves it in the memory of the device. Figure 3 summarizes the different processing steps followed during this phaseFigure 3
Summarize of the user registration phase.


## 4.2. IoT Sensor Node Registration

In this stage, each IoT sensor node is a registry. Any supplementary nodes can be added dynamically. This stage consists of the following steps.IoT node side:(Step 1)
Dk generates a random number Rk∈Zn+. Dk known the shared secret XgDk of the GW and has a unique identity IDDk∗(Step 2)
Dk computes the parameters MPWj=hXgDk∥Rk∥IDDk∗ and MDk=Rk⨁XgDk⨁Factori for further calculation(Step 3)
Dk sendsMPWj, MDk, IDDk∗, and TS1 to the GW through a secure channelGW node side: upon receiving the registration request from IoT sensor nodesDk, the Gw calculates the following steps.
(Step 1)
Checks the timestamp conditionTS1−T<△T. If the condition is unsatisfied, then the registration phase is terminated; otherwise, the GW executes the next step(Step 2)
ComputesRk′=MDk⨁XgDk⨁Factori, and MPWj′ on the basis of the previous message received from Ui as MPWj′=hXgDk∥Rk′∥IDDk∗(Step 3)
Verifies whetherMPWj=MPWj′ or not. Therefore, if they are not unequal, the node is not illegitimate, and the GW terminates the session. Otherwise, GW executes the next step(Step 4)
Computes the following parameters for further use,aj=hIDDk∗∥Xg, bj=hMPWj∥XgDk∥Factori, and cj=aj⨁bj(Step 5)
Then,GW sendsaj, cj, and TS2 toDk. Upon receiving the registration messages (aj, cj, and TS2) from the GW, Dk checks the timestamp condition TS2−T<△T to verify for any external interference. If the condition is unsatisfied, then the session is terminated; otherwise, Dk saves the parameters aj, cj. and TS2 into his device memory. Finally, the user registration phase is accomplished. Figure 3 shows the steps of the IoT sensor node registration phase


## 4.3. Precomputation and Login Phase

Once the registration is accomplished successfully, an authorized userUi can access any desired sensor node within the IoT network through the authentication phase. To start with the authentication phase, Ui must login to the selected IoT service application, following the login steps that are implemented during this phase.
(Step 1)
First, the userUi uses the smartphone to open the applications and enters his/her passwordPWi and level 3 feature extraction FX3FPi saved in the smartphone(Step 2)
Then, the smartphone ofUi calculates a masked for the password and the feature extraction as follows: MPWi′=hMPWi⨁Ri and MFPi′=hMFPi⨁Ri. Also, it computes bi∗∗=haiFactori⨁ei⨁MPWi⨁Xgn andci∗∗=hMFPi⨁biFactori⨁Factori(Step 3)
Next, the original values ofbi and ci extract as follows: bi∗=hMPWi⨁Xgu and ci∗=hMFPi⨁Xgu(Step 4)
Ui computes the value of the following verification parameters bi∗∗ and ci∗∗ as bi∗∗=haiFactori⨁ei⨁MPWi⨁Xgn and ci∗∗=hMFPi⨁biFactori⨁Factori(Step 5)
Then, the accurateness ofbi∗ and ci∗ is verified with bi∗∗ and ci∗∗. If bi∗=bi∗∗? and ci∗=ci∗∗?, then the login proceeds to the next step. Otherwise, the user is not legal and has entered incorrect credentials, and the process will terminate(Step 6)
On successful the user validation, it calculates the security parameters:UDk=hXgu∥TS1∥FactoriRi andUCi=Ri⨁ai(Step 7)
Also, calculatesFactori∗=Factori⨁TS1 for use in a security check later(Step 8)
In the end,Ui sends the login parameters M5=Factori∗,UDk,UCi,TS3,ei,fi to the desired IoT node. Upon completing step 8, the login phase is complete. The user Ui can select any node in the IoT environment


## 4.4. Authentication and Key Agreement Phase

To access the services of the IoT sensor nodes, the user will attempt to login to the proper node, after which the node will redirect the user login request toGW, which will carry out the necessary process to check the user’s authentication. When mutual validation is achieved between these three entities, a session key will be established between the user and the IoT sensor node. Figure 4 summarizes the login and the authentication phase. The following steps illustrate the processes of this phase.
(Step 1)
On receiving the login request message fromUi, Dk performs the timestamp check on receive TS3, i.e., TS3−T<∆T. Also, check the security parameter Factori∗?=Factori⨁TS1?, to authenticate theUi. If the condition is unsatisfied, then the login is terminated; otherwise, the process proceeds to the next step(Step 2)
Dk uses the stored values of ej and aj to calculatebj=ej⨁aj(Step 3)
Next,Dk calculates Aj=hXgDk∥TS1∥TS2⨁bj(Step 4)
Dk sends M6=UCi,UDk,ei,fi,TS3,TS4,Factori∗ to the GW. GW can recognize the legitimacy of the Ui and the node Dk on the basis of the parameter Factori∗ and the transaction time. In this step, the node Dk authenticates theGW(Step 5)
GW verifies the received timestampTS4−T<∆T and Factori∗?=Factori⨁TS1, authority of the Ui, and the device Dk simultaneously. If the condition is satisfied, then the GW proceeds to the next step; otherwise, the process is terminated(Step 6)
Then,GW calculates the security parameters: aj∗=hIDDk∥Xg, bj∗=ei⨁aj∗, and bj=Aj⨁hXgDk∥TS3∥TS4. Afterwards, the GW checks the quality of bj andbj∗. If they are equal, then GW authenticates the node Dk and the user UiFigure 4
Summarize of login and Authentication Phase.The IoT sensor nodeDk must be successfully verified by the GW on the basis of the retrieved Factori depending onMIDi. Therefore, GW performs the following:
(Step 1)
GW calculates Ri∗=UCi⨁hMIDi⨁Xg andUDk∗=hXgui∥TS3∥Factori∥Ri∗(Step 2)
GW compares the original UDk and the calculated UDk∗ to authenticate the Ui. If the verification condition is unsuccessful, then the GWterminates the communication; otherwise, the GW continues to the next step(Step 3)
Next,GW computes the security parameters: GPij=Factori∗⨁Ri∗⨁haj∗∥XgDk and Vi=hUDk∗∥TS3∥TS4∥TS5∥Xgu(Step 4)
GW submits M7=GPij,Vi,TS5 to DkUpon receiving the verification parametersM7 from the GW, DK computes the following processes:
(Step 1)
Dk verifies the timestampTS5−T<△T. If the verification condition is unsatisfied, then the process is terminated; otherwise, it continues forward(Step 2)
Then,DK checks the validity of GPij withFactori∗⨁Ri⨁haj∗∥XgDk. If the condition is unsatisfied, then the process is terminated; otherwise, it proceeds to the next step(Step 3)
Next,DK calculates cha=Ri⨁Factori⨁Mi, and Vi∗=hVi∥TS4⨁Mi, where M is a random number generated once. Afterwards, DK computes the session key as SK=hRi⨁Mi⨁Factori∗(Step 4)
At last,DK sends M8=Vi∗,TS3,TS4,TS5,TS6,cha to the Ui. When Ui receives the verification parameterM8 from DK, Ui executes the following steps:(Step 1)
Ui performs timestamp checks, i.e., TS6−T<△T? If not, then the process is terminated; otherwise, it continues to the next step(Step 2)
Ui retrieves Mi∗=cha⨁Ri⨁Factori∗(Step 3)
Then,Ui computes Vi∗∗=hhUDk∥TS3∥TS4∥TS5⨁Mi∗. Then, Ui verifies if Vi∗∗=Vi∗. If not, then Uiis unsure of the authority ofDK and theGW; otherwise, the Ui computes the session key as SK=hMi∗⨁Ri and the authentication and key agreement phase successfully


## 4.5. Password and Biometric Change Phase

This phase is necessary to regularly update the user password to preserve high security. The proposed protocol allows the remote user to change his/her password easy.(Step 1)
Ui who must change his/her password opens the IoT application on a smart device and enters his/her old password MPWi and feature extraction MFP; then, he/she calculates the masked for each of and feature extraction of user biometrics as MPWi=hMPWi⨁Ri, MFPi=hMFPi⨁Ri(Step 2)
Then,Ui calculates bi∗∗=haiFactori⨁ei⨁MPWi⨁Xgn and ci∗∗=hMFPi⨁biFactori⨁Factori and proceeds to the next step(Step 3)
Next,Ui checks the equality of bi∗∗ and ci∗∗ with the original one bi∗=hMPWi⨁Xgu and ci∗=hMFPi⨁Xgu. If any conditions do not hold, the Ui unsuccessfully enters his correct data, and the system will be terminated; otherwise, Ui is a valid user, and then Ui is permitted to change his/her password(Step 4)
Ui enters the new password PWi∗ and new fingerprintFPi∗. Then, he/she calculates mask the hash function for each of them as MPWi∗=hPWi∗i⨁iRi and MFPi∗=hFPi∗⨁Ri, correspondingly(Step 5)
Then,Ui updates the parameter bi∗ on the basis of the new password as bi′=hMPWi∗⊕Xgu. Then, it calculates new fi as: fi′=bi′fi⨁Xgu(Step 6)
At last,Ui changes the old fi stored in the smart device memory with the new one fi′, and the phase terminates successfully


## 5. Security Analysis

We evaluate the security strength of the proposed protocol using both formal and informal security analysis in this section. First, we prove that the proposed protocol provides mutual authentication between the remote user and the IoT sensor node using the BAN logic verification. First, we prove that the proposed protocol provides mutual authentication between the remote user and the IoT sensor node using the BAN logic verification. Then, we prove that the proposed protocol is resistant to other well-known attacks using informal security analysis. After that, we perform a formal security analysis using the popular widely accepted automated verification tool, AVISP.


### 5.1. Mutual Authentication Proof through BAN Logic

We use the widely recognized BAN logic [58] to prove that the mutual authentication is achieved between the registered legitimate remote user and an accessed IoT sensor node with the help of a trusted gateway node. Table 2 shows the symbols used of BAN logic and their respective abbreviations, where P and Q represent the principals, and X denotes a statement.Table 2
BAN logic symbols and their respective abbreviations.
SymbolsAbbreviationP∣≡XP believes X as a valid statement.P⊲XPrincipalP sees the statement X.P∣~XPrincipalP once said the statement X.#XThe formulaX is fresh.P⟷KQP and Q use the shared session key K to communicate, and K will never be discovered by any principal except P and Q.P⟹XP has jurisdiction over X.XKX is hashed with the key K.XKX is combined with the key K.XKX is encrypted with the key K.There are five rules used which govern the BAN logic are listed as follows:Rule 1: message meaning rules:P∣≡P↔KQ,P⊲XK/P∣≡Q∣∼X OR P∣≡P⇌YQ,P⊲XY/P∣≡Q∣∼XRule 2: the nonce-verification rule:P∣≡#X,P∣≡Q∣∼X/P∣≡Q∣≡XRule 3: the jurisdiction rule:P≡Q⇒X,,P∣≡Q∣≡X/P∣≡XRule 4: the freshness rule:P∣≡#X/P∣≡#X,YUsing the above rules, we the following prove Theorem.Theorem 1.
The proposed protocol provides secure mutual authentication betweenUi and Dk in the presence of the GW.Proof.
We define the following four goals:
Goal 1:Ui∣≡Nk∣≡UiDk.⟷SK
Goal 2:Ui∣≡UiDk⟷SK
Goal 3:Dk∣≡Ui∣≡UiDk⟷SK
Goal 4:Dk∣≡UiDk⟷SKThe idealization form of the transmitted messages during the login and authentication phase under the proposed protocol is presented as follows:(M1)
Ui⟷viaDkGW: IDi,Tm1,Ui↔IDiDKXgu(M2)
Ui⟷viaNkGW: UDK,UCi,ei,fi,SIDiUi↔IDiDK,Ui↔XguDKXgu(M3)
Dk⟶GW: SIDi,TS2,Factori,Dk↔SIDiGWXgNk(M4)
Dk⟶GW: UDK,UCi,ei,fi,Tm1,Tm2,Dk↔riGW,Dk↔SIDiGWXgNk(M5)
GW⟶D: TS3,Dk↔XgDkGWXgDk(M6)
GW⟶D: TS3,TS4,TS5,SPij,Dk↔XgNkGW,Dk↔ri∗GWXgDk(M7)
Ui↔viaGWDk: TS3,ri∗,Dk↔SIDiGW,Dk↔ri∗GWXgDk(M8)
GW↔viaDkUi: TS3,ri∗,Ui↔IDiGW,Ui↔ri∗GWXgNk(M9)
Dk⟶Ui: TS3,Ts4,Ts5,,Ts6,Vi∗,Dk↔SIDiGW,ri∗,Ui↔KlGSKWe consider the following initial assumptions according to the proposed protocol description:(H1)
GW∣≡Ui↔XgGW(H2)
GW∣≡#Ts1(H3)
GW∣≡Ui∣⟹Ui↔IDiGW(H4)
GW∣≡Ui↔SIDi=hIDi⨁Ri⊕riGW(H5)
GW∣≡#ri(H6)
GW∣≡Ui∣⟹Ui↔riGW(H7)
GW∣≡Ui↔XguGW(H8)
GW∣≡#Ts2(H9)
GW∣≡Dk∣⟹Dk↔SIDiGW(H10)
GW∣≡Dk↔XgDkGW(H11)
GW∣≡#ri∗(H12)
GW∣≡Nk∣⟹Dk↔ri∗GW(H13)
Dk∣≡Dk↔XgDkGW(H14)
Dk∣≡#Ts3(H15)
GW∣≡D∣⟹Dk↔XgGW(H16)
Dk∣≡#ri∗(H17)
Dk∣≡GW∣⟹Dk↔ri∗GW(H18)
Dk∣≡Ui∣⟹Dk↔ri∗GW(H19)
Ui∣≡Ui↔SIDi=hIDi⨁Ri⊕riGW(H20)
Ui∣≡#Ki(H21)
Ui∣≡GW∣⟹Ui↔KiGW(H22)
Ui≡#Tm4(H23)
Ui∣≡Dk∣⟹Ui↔KiGWBy analyzing the messages M1-M9 and assumptions H1-H23 based on the BAN logic rules, the goals (goal 1-goal 4) are provided as follows:From M1, we get S1:GW⊲IDi,Tm1,Ui↔IDiDKXgBased on S1, H1, and rule 1, we get S2:GW∣≡∼IDi,Tm1,Ui↔IDiDXgBased on H2 and rule 1, we get S3:GW∣≡#IDi,Tm1,Ui↔IDiDkXgBased on S2, S3, and rule 2, we have S4:GW≡Ui≡IDi,Tm1,Ui↔IDiDKXgBased on S4 and rule 5, we get S5:GW∣≡Ui∣≡Ui↔IDiGWBased on S5, H3, and rule 3, we can get S6:GW∣≡Ui↔IDiGWFrom M2, we getS7:GW⊲UDK,UCi,Factori∗,ei,fi,SIDiUi↔IDiDK,Ui↔XguDKXguBased on S7, H4, and rule 1, we getS8:GW∣≡Ui∣∼UDK,UCi,Factori∗,ei,fi,SIDiUi↔IDiDK,Ui↔XguDKXguBased on H2, H5, and rule 4, we could getS9:GW∣≡#UDK,UCi,Factori∗,ei,fi,SIDiUi↔IDiDK,Ui↔XguDKXguBased on H2, H5, and rule 4, we haveS10:GW∣≡#UDK,UCi,Factori∗,ei,fi,SIDiUi↔IDiDK,Ui↔XguDKXguBased on S5, S6, S10, and rule 5, we could get S12:GW∣≡Ui∣≡Ui↔riGWBased on S13, H7, and rule 1, we getS14:GW≡Nk∼UDK,UCi,Factori∗,ei,fi,SIDiUi↔IDiDK,Ui↔XguDKXgDkBased on H7 and rule 4, we haveS15:GW∣≡#UDK,UCi,Factori∗,ei,fi,SIDiUi↔MIDiDK,Ui↔XguDKXgDkBased on S14, S15, and rule 2, we getS16:GW∣≡Dk∣≡SIDi,TS2,Factori,Nki↔MIDiGWBased on S16 and rule 5, we have S17:GW∣≡Dk∣≡Dki↔MIDiGWBased on S17, H9, and rule 3, we could get S18:GW∣≡Dki↔MIDiGWFrom Mssg4, we getS19:GW⊲UDK,UCi,ei,fi,Tm1,Tm2Factori∗,Dk↔riGW,Dk↔SIDiGWXgDkBased on S19, H10, and rule 1, we getS20:GW∣≡Dk∣∼UDK,UCi,ei,fi,Tm1,Tm2,Dk↔riGW,Dk↔SIDiGWXgDkBased on H8, H11, rule 4, we haveS21:GW∣≡#UDK,UCi,ei,fi,Tm1,Tm2,Dk↔riGW,Dk↔SIDiGWXgDkBased on S20, S21, and rule 2, we haveS22:GW∣≡Dk∣≡UDK,UCi,ei,fi,Tm1,Tm2,,Dk↔riGW,Dk↔SIDiGWXgDkBased on S17, S18, S22, and rule 5, we could get S23:GW∣≡Dk∣≡Dk↔riGWBased on S23, H12, and rule 3, we get S24:GW∣≡Dk↔riGWFrom Mssg5, we could get S25:Dk⊲TS3,Dk↔XDNkGWXgDkBased on S25, H13, and rule 1, we haveS26:Dk∣≡GW∣∼TS3,Dk↔XgDkGWXgDkBased on H14 and rule 4, we have S27:Dk∣≡#TS3,Dk↔XgDkGWXgDkBased on S26, S27, and rule 2, we get S28:Dk∣≡GW∣≡TS3,Dk↔XgDkGWXgDkBased on S28 and rule 5, we could get S29:Dk∣≡GW∣≡Dk↔XgDkGWBased on S29, H15, and rule 3, we have S30:Dk∣≡Dk↔XgDkGWBased on S30, S31, H13, and Rule 1, we getS32:Nk∣≡GW∣∼Ts1,Tm2,Ts3,SPij,Dk↔XgDkGW,Dk↔ri∗GWXgDkBased on H14, H16, and rule 4, we obtain the following:S33:Dk∣≡#Ts1,Ts2,Ts3,SPij,Dk↔XgDkGW,Dk↔ri∗GWXgDkBased on S32, S33, and rule 2, we have the following:S34:Dk∣≡GW∣≡Ts1,Ts2,TS3,SPij,Dk↔XgDkGW,Dk↔ri∗GWXgDkBased on S17, S18, and S34, we get S35:Dk∣≡GW∣≡Dk↔ri∗GWBased on S35, H17, and rule 3, we get S36:Dk∣≡Dk↔ri∗GWFrom Mssg7, we get S37:Dk⊲Ts3,ri∗,Dk↔SIDiGW,Dk↔ri∗GWXgDkBased on S37, H13, and rule 1, we get:S38:Dk∣≡Ui∣∼Ts3,ri∗,Dk↔SIDiGW,Dk↔ri∗GWXgDkBased on H14, H16, and rule 4, we getS39:Dk∣≡#Ts3,ri∗,Dk↔SIDiGW,Dk↔ri∗GWXgDkFrom S38, S39, and rule 2, we getS40:Dk∣≡Ui∣≡Ts3,ri∗,Dk↔SIDiGW,Dk↔ri∗GWXgDkBased on S17, S18, S35, and rule 5, we get goal 4:Dk∣≡Ui∣≡Ui↔SKDkBased on S36, H18, goal 4, and rule 3, it will lead to the following:Goal 3:Dk∣≡Ui↔SKDkFrom Mssg8, we get S41:Ui⊲Ts3,ri∗,Ui↔IDiGW,(Ui↔ri∗GWXgDkBased on S41, H19, and rule 1, we getS42:Ui∣≡GW∣∼Ts3,ri∗,Ui↔IDiGW,Ui↔ri∗GWXgDkBased on H20, and rule 4, we get S43:Ui∣≡#Ts3,ri∗,Ui↔IDiGW,Ui↔ri∗GWXgDkBased on S42, S43, and rule 2, we getS44:Ui∣≡GW∣≡Ts3,ri∗,Ui↔IDiGW,Ui↔ri∗GWXgDkBased on S5, S6, S44, and rule 5, we have S45:Ui∣≡GW∣≡Ui↔ri∗GWBased on S45, H21, and rule 3, we get S46:Ui∣≡Ui↔ri∗GWFrom Mssg9, we haveS47:Ui⊲Ts1,Ts2,Ts3,,Ts4,Vi∗,Nk↔SIDiGW,ri∗,Ui↔KlGWSKBased on S47, H9, and rule 1, we getS48:Ui∣≡∼Ts1,Ts2,Ts3,,Ts4,Vi∗,Dk↔SIDiGW,ri∗,Ui↔KlGWSKBased on H20, H22, and rule 4, we getS49:Ui∣≡#Ts1,Ts2,Ts3,,Ts4,Vi∗,Dk↔SIDiGW,ri∗,Ui↔KlGWSKFrom S48, S49, and rule 2, we haveS50:Ui∣≡Nk∣≡Ts1,Ts2,Ts3,,Ts4,Vi∗,Dk↔SIDiGW,ri∗,Ui↔KlGWSKBased on S45, S50, and rule 5, we haveGoal 2:Ui∣≡Nk∣≡Ui↔SKDkFinally, using S46, H23, goal 2, and rule 3, we obtainGoal 1:Ui∣≡Ui↔SKDk.Hence, the goals 1 and 2 assure mutual authentication amongUiand Nk in presence of GW


### 5.2. Informal Security Analysis

In this section, we present an informal security analysis to prove that the proposed protocol is withstanding against various well-known malicious attacks. Besides, it provides the most security functionality requirement.Proposition 2.
Resistance to the IoT sensor node capture attack.Proof.
Assume that a malicious attackerMA attempts to compose the legal authentication request message M6=UCi,UDk,TS3,TS4ei,fiFactori∗ or M7=Vi∗,TS4,TS6,cha of the IoT sensing node Nk and sent them to Uior GW on behalf of Nk.For this motivation, MA tries to modify the exchanges message M6 and M7 to M6i=UCi′,UDK′,Factori∗′,ei′,fi′,TS3′,TS4′ and M7i=Vi∗′,TS4,′,TS6,′ by extracting the stored information. MA cannot obtain the value of MIDi as it is protected by a one-way hash function and the shared secret key XgNk, which is only known to the IoT sensor nodeNk. Also, MA cannot calculate Vi∗ as it protected by a one-way hash with the random number Mi. Therefore, our proposed protocol resists node compromise attacks.Proposition 3.
Resistance to impersonation attacks.Proof.
In our proposed protocol, the attacker cannot extract or impersonate the level 3 feature extraction of the fingerprint ofUi. Moreover, if a malicious attacker attempts to adjust the parameter UDk=hXgu∥TS1∥Factori⨁Ri to a new one as UDk′, then the attacker will fail in the GW side due to a mismatch with UDk calculated by the GW in the authentication phase with UDk′. Therefore, the proposed protocol resists impersonation attacks.Proposition 4.
Resistance to replay attacks.Proof.
Assuming that a malicious attack aims to retransmit a message gained by eavesdropping on an efficient communication channel between theUi and the Dk through the login and authentication phase, the attacker will fail, because our proposed protocol uses timestampsTS3,TS4,TS5,TS6, and the delay time of the timestamp is brief. Our proposed scheme also uses Factori∗ which is stored on the basis of level 3 feature extraction. Therefore, the proposed protocol provides an efficient security against replay attacks.Proposition 5.
Resistance to stolen smart device attacks.Proof.
In the case where the user’s smart device is stolen or lost, the attacker aims to access the sensitive information stored in the device’s memory using a power examination attack. Our proposed protocol provides efficient security against this kind of attack. The attacker cannot determine the identityIDi and the password PWi of the Ui since these are masked by a hash function on the basis of a random number Ri that is generated only once. Moreover, the attacker cannot identify the feature extraction FPi given the hash function. Accordingly, our proposed protocol provides an efficient security against stolen smart device attacks.Proposition 6.
Resistance to password change attacks.Proof.
To change the user password, a malicious attack must use the personal fingerprint of a genuineUi. Thus, the attacker cannot change the password. Assuming that a user’s smart device is stolen or lost or is used by an attacker through another method, the attacker still cannot change the password, since this process requires the old password. Therefore, our proposed protocol resists password changes attacks.Proposition 7.
Resistance to denial-of-service attacks.Proof.
In our proposed scheme, this kind of attack is infeasible because theUi receives an authorization message from the nodeDk for security verification. Furthermore, we use timestampsTS3, TS4, TS5, and TS6 to mitigate any crucial request.Proposition 8.
Resistance to parallel session attacks.Proof.
If a malicious attack aims to build a parallel session of the scheme, then the attacker will fail even if he/she interrupts the communication message (M5=Factori∗,UDk,UCi,TS3,ei,fi) due to our utilization of level 3 feature extraction and the timestamp used in the login and authentication phases.Proposition 9.
Resistance to gateway node bypass attacks.Proof.
In this kind of attack, the attacker aims to impersonate theGW with the aim of later connecting to any IoT nodeDk. Our proposed scheme can resist this type of attack because, as illustrated in Figure 4, the Ui initially sends the authenticated messageFactori∗, UDk, UCi, TS3, ei, and fi to the desired node Dk to initiate the authenticated phase. Subsequently, the node Dk returns this message to the GW (Figure 3.7). Then, GW verifies Dk and Ui. Accordingly, Ui, as the first step, uses any IoT facility that is disconnected from the GW. Therefore, the propose protocol provides an efficient security against gateway node bypass attacks.Proposition 10.
Resistance to MITM attacks.Proof.
As previously explained in Section 4, this type of attack aims to intercept communication between two legitimate parties and to modify, delete or delay messages. We suppose that a malicious attack intercepts the login message (M5=Factori∗,UDk,UCi,TS3,ei,fi) transmitted from Ui to the node Dk and the authentication message (M6=UCi,UDk,ei,fi,TS3,TS4,Factori∗) that transmitted from the node Dk to GW. In this scenario, the attacker aims to modify the login message or authentication message to M5′,M6′. However, the attacker cannot predict the shared secret key needed to modify these messages. Moreover, each message communicated in the login and authentication phases has a timestamp with a short delay, thereby preventing an attacker from changing the messages. Therefore, our proposed scheme resists MITM attacks.Proposition 11.
Resistance to Off-line Guessing Attacks.Proof.
In our proposed scheme, a malicious attacker cannot gain an advantage by using off-line password-guessing attacks because the attacker cannot obtain the real passwords of a genuineUi using the communication messages M5=Factori∗,UDk,UCi,TS3,ei,fi and M6=UCi,UDk,ei,fi,TS3,TS4,Factori∗ in the login and authentication phases, respectively. Even if the user’s smart device is stolen, the attacker cannot predict the password due to the nature of the hash function. Furthermore, the attacker cannot deduce the user fingerprint because the fingerprint is stored on the basis of a random number Ri, level 3 feature extraction that is generated only once, and the use of a strong hash function. If the adversary guesses PWi′, then, to legalize PWi′ with bi∗=bi∗∗? and ci∗=ci∗∗?, he/she needs to know Ui’s identity as well as Ui’s biometric Bi. Moreover, to guess PWi, the adversary will need to guess IDi and Bi along with the password. However, revealing of user biometric information or stealing it or forging it is not achievable; hence, the proposed protocol withstands offline-password-guessing attacks.Proposition 12.
Provides key agreement.Proof.
This feature indicates that theUi and the IoT node Dk must agree on a secure session key to protect their successive communications. In our protocol, once Dk receives the authentication request (M7=GPij,Vi,TS5) from the GW, it computes the session key SK=HRi⨁Mi⨁Factori∗ on the basis of mask nonce Mi, Ri and Factori∗. Afterwards, Dk sends the message (M8=Vi∗,TS3,TS4,TS5,TS6,cha) to the Ui. Subsequently, Ui receives the authenticated message and then calculates the session key SK=hMi∗⨁Ri, and both session keys are equal as shown in Figure 3.6. Therefore, our proposed protocol supports a secure session key.Proposition 13.
Provides user anonymity.Proof.
Anonymity means protecting the information of aUi from being tracked by an attacker. The user information, identityIDi, passwordPWi, and fingerprint FPi are masked by a hash function. The fingerprint FPi is calculated on the basis of the hash function of level 3 feature extraction. Accordingly, if a particular attacker attempts to interrupt the message exchange between the entities, then the attacker will fail to trace the user information.Proposition 14.
Provides forward secrecy.Proof.
In our protocol, we created the session keySK=hRi⨁Mi⨁Factori∗ on the basis of the nonce number Mi which is generated once for each Ui who desires to log in to the (IoT) nodes. We also created the random numberRi and theFactori which is not saved as a plaintext. Therefore, a malicious attack cannot obtain the session key by any way.Proposition 15.
Provides mutual authentication.Proof.
An authentication mechanism requires each entity in the IoT environment,, i.e.GW, the Ui and the IoT nodeDk to validate each other. In our proposed protocol, after executing the necessary steps, Ui sends the authentication message (M5=Factori∗,UDk,UCi,TS3,ei,fi) to Dk in the login phase (see Figure 3.7). Then, Dk send the authentication message (M6=UCi,UDk,TS3,TS4,ei,fi,Factori∗) to GW. Accordingly, the GW uses the authenticated message to validate the Ui and the node Dk. Therefore, the proposed protocol achieves mutual authentication.Proposition 16.
Provides Key FreshnessProof.
In our work, we generate a session keySK=hRi⨁Mi⨁Factori∗ that consists of fresh timestamps that are different in each session. Accordingly, our proposed protocol achieves key freshness. A security analysis of possible attacks against this model is presented below, and it is shown that our proposed protocol can resist several well-known attacks.


### 5.3. Formal Security Analysis Using the AVISPA Tool

AVISPA is a powerful automated validation tool which provides a wide applications range for constructing cryptographic protocols analysis models, verification, and validation. To validate the protocol using the AVISPA tool, firstly, the protocol is coded by using HLPSL language. Then, translate the HLPSL code in intermediate format (IF) by the HLPSL2IF translator. Finally, the IF specification as input is given to the back ends. After the IF execution, the back-end displays the result of the simulation of the protocol by analyzing to output format (OF), with an explanation of whether the protocol is safe or unsafe against man-in-the-middle and replay attacks. Also, back ends confirm the security features of the protocol such as the flexibility against most of the known attacks, authentication, and the secrecy of keys. Note that AVISPA performs the Dolev-Yao threat model [59, 60]. More details of the AVISPA tool and HLPSL can be found in [61].To implement and simulate the proposed protocol on AVISPA, we have concentrated on the major tool SPAN Version 1.6 based on a computer system which is consist of Windows 10 Enterprise operating system (64 bit) that is supported by Ubuntu 10.10 light on Virtual machine, Intel (R) Core (TM) i7-7500U CPU @ 2.70 GHz 2.90 GHz processor, and 8 GB RAM. In AVISPA, there is a role for each entity, and these roles are independent of each other. AVISPA has an implementation in the form of four back ends, namely, TA4SP (Tree Automata based on Automatic Approximations for the Analysis of Security Protocols), OFMC (On-the-fly Model-Checker), CL-AtSe (Constraint Logic-based Attack Searcher), and SATMAC (SAT-based Model checker) [62]. We have evaluated the proposed protocol against man-in-the-middle and replay attacks under the OFMC and CL-AtSe back ends using SPAN.The user registration, login, and authentication phases for the proposed protocol are implemented in HLPSL utilizing three basic roles for a remote user, the IoT sensor node, and the gateway node. The compulsory roles for the environment, session, and goal are also defined. Figure5 provides the simulation results that obviously indicate that the proposed protocol is protected against man-in-the-middle and replay attacks.Figure 5
The simulation results under OFMC and CL-AtSe back ends.


## 5.1. Mutual Authentication Proof through BAN Logic

We use the widely recognized BAN logic [58] to prove that the mutual authentication is achieved between the registered legitimate remote user and an accessed IoT sensor node with the help of a trusted gateway node. Table 2 shows the symbols used of BAN logic and their respective abbreviations, where P and Q represent the principals, and X denotes a statement.Table 2
BAN logic symbols and their respective abbreviations.
SymbolsAbbreviationP∣≡XP believes X as a valid statement.P⊲XPrincipalP sees the statement X.P∣~XPrincipalP once said the statement X.#XThe formulaX is fresh.P⟷KQP and Q use the shared session key K to communicate, and K will never be discovered by any principal except P and Q.P⟹XP has jurisdiction over X.XKX is hashed with the key K.XKX is combined with the key K.XKX is encrypted with the key K.There are five rules used which govern the BAN logic are listed as follows:Rule 1: message meaning rules:P∣≡P↔KQ,P⊲XK/P∣≡Q∣∼X OR P∣≡P⇌YQ,P⊲XY/P∣≡Q∣∼XRule 2: the nonce-verification rule:P∣≡#X,P∣≡Q∣∼X/P∣≡Q∣≡XRule 3: the jurisdiction rule:P≡Q⇒X,,P∣≡Q∣≡X/P∣≡XRule 4: the freshness rule:P∣≡#X/P∣≡#X,YUsing the above rules, we the following prove Theorem.Theorem 1.
The proposed protocol provides secure mutual authentication betweenUi and Dk in the presence of the GW.Proof.
We define the following four goals:
Goal 1:Ui∣≡Nk∣≡UiDk.⟷SK
Goal 2:Ui∣≡UiDk⟷SK
Goal 3:Dk∣≡Ui∣≡UiDk⟷SK
Goal 4:Dk∣≡UiDk⟷SKThe idealization form of the transmitted messages during the login and authentication phase under the proposed protocol is presented as follows:(M1)
Ui⟷viaDkGW: IDi,Tm1,Ui↔IDiDKXgu(M2)
Ui⟷viaNkGW: UDK,UCi,ei,fi,SIDiUi↔IDiDK,Ui↔XguDKXgu(M3)
Dk⟶GW: SIDi,TS2,Factori,Dk↔SIDiGWXgNk(M4)
Dk⟶GW: UDK,UCi,ei,fi,Tm1,Tm2,Dk↔riGW,Dk↔SIDiGWXgNk(M5)
GW⟶D: TS3,Dk↔XgDkGWXgDk(M6)
GW⟶D: TS3,TS4,TS5,SPij,Dk↔XgNkGW,Dk↔ri∗GWXgDk(M7)
Ui↔viaGWDk: TS3,ri∗,Dk↔SIDiGW,Dk↔ri∗GWXgDk(M8)
GW↔viaDkUi: TS3,ri∗,Ui↔IDiGW,Ui↔ri∗GWXgNk(M9)
Dk⟶Ui: TS3,Ts4,Ts5,,Ts6,Vi∗,Dk↔SIDiGW,ri∗,Ui↔KlGSKWe consider the following initial assumptions according to the proposed protocol description:(H1)
GW∣≡Ui↔XgGW(H2)
GW∣≡#Ts1(H3)
GW∣≡Ui∣⟹Ui↔IDiGW(H4)
GW∣≡Ui↔SIDi=hIDi⨁Ri⊕riGW(H5)
GW∣≡#ri(H6)
GW∣≡Ui∣⟹Ui↔riGW(H7)
GW∣≡Ui↔XguGW(H8)
GW∣≡#Ts2(H9)
GW∣≡Dk∣⟹Dk↔SIDiGW(H10)
GW∣≡Dk↔XgDkGW(H11)
GW∣≡#ri∗(H12)
GW∣≡Nk∣⟹Dk↔ri∗GW(H13)
Dk∣≡Dk↔XgDkGW(H14)
Dk∣≡#Ts3(H15)
GW∣≡D∣⟹Dk↔XgGW(H16)
Dk∣≡#ri∗(H17)
Dk∣≡GW∣⟹Dk↔ri∗GW(H18)
Dk∣≡Ui∣⟹Dk↔ri∗GW(H19)
Ui∣≡Ui↔SIDi=hIDi⨁Ri⊕riGW(H20)
Ui∣≡#Ki(H21)
Ui∣≡GW∣⟹Ui↔KiGW(H22)
Ui≡#Tm4(H23)
Ui∣≡Dk∣⟹Ui↔KiGWBy analyzing the messages M1-M9 and assumptions H1-H23 based on the BAN logic rules, the goals (goal 1-goal 4) are provided as follows:From M1, we get S1:GW⊲IDi,Tm1,Ui↔IDiDKXgBased on S1, H1, and rule 1, we get S2:GW∣≡∼IDi,Tm1,Ui↔IDiDXgBased on H2 and rule 1, we get S3:GW∣≡#IDi,Tm1,Ui↔IDiDkXgBased on S2, S3, and rule 2, we have S4:GW≡Ui≡IDi,Tm1,Ui↔IDiDKXgBased on S4 and rule 5, we get S5:GW∣≡Ui∣≡Ui↔IDiGWBased on S5, H3, and rule 3, we can get S6:GW∣≡Ui↔IDiGWFrom M2, we getS7:GW⊲UDK,UCi,Factori∗,ei,fi,SIDiUi↔IDiDK,Ui↔XguDKXguBased on S7, H4, and rule 1, we getS8:GW∣≡Ui∣∼UDK,UCi,Factori∗,ei,fi,SIDiUi↔IDiDK,Ui↔XguDKXguBased on H2, H5, and rule 4, we could getS9:GW∣≡#UDK,UCi,Factori∗,ei,fi,SIDiUi↔IDiDK,Ui↔XguDKXguBased on H2, H5, and rule 4, we haveS10:GW∣≡#UDK,UCi,Factori∗,ei,fi,SIDiUi↔IDiDK,Ui↔XguDKXguBased on S5, S6, S10, and rule 5, we could get S12:GW∣≡Ui∣≡Ui↔riGWBased on S13, H7, and rule 1, we getS14:GW≡Nk∼UDK,UCi,Factori∗,ei,fi,SIDiUi↔IDiDK,Ui↔XguDKXgDkBased on H7 and rule 4, we haveS15:GW∣≡#UDK,UCi,Factori∗,ei,fi,SIDiUi↔MIDiDK,Ui↔XguDKXgDkBased on S14, S15, and rule 2, we getS16:GW∣≡Dk∣≡SIDi,TS2,Factori,Nki↔MIDiGWBased on S16 and rule 5, we have S17:GW∣≡Dk∣≡Dki↔MIDiGWBased on S17, H9, and rule 3, we could get S18:GW∣≡Dki↔MIDiGWFrom Mssg4, we getS19:GW⊲UDK,UCi,ei,fi,Tm1,Tm2Factori∗,Dk↔riGW,Dk↔SIDiGWXgDkBased on S19, H10, and rule 1, we getS20:GW∣≡Dk∣∼UDK,UCi,ei,fi,Tm1,Tm2,Dk↔riGW,Dk↔SIDiGWXgDkBased on H8, H11, rule 4, we haveS21:GW∣≡#UDK,UCi,ei,fi,Tm1,Tm2,Dk↔riGW,Dk↔SIDiGWXgDkBased on S20, S21, and rule 2, we haveS22:GW∣≡Dk∣≡UDK,UCi,ei,fi,Tm1,Tm2,,Dk↔riGW,Dk↔SIDiGWXgDkBased on S17, S18, S22, and rule 5, we could get S23:GW∣≡Dk∣≡Dk↔riGWBased on S23, H12, and rule 3, we get S24:GW∣≡Dk↔riGWFrom Mssg5, we could get S25:Dk⊲TS3,Dk↔XDNkGWXgDkBased on S25, H13, and rule 1, we haveS26:Dk∣≡GW∣∼TS3,Dk↔XgDkGWXgDkBased on H14 and rule 4, we have S27:Dk∣≡#TS3,Dk↔XgDkGWXgDkBased on S26, S27, and rule 2, we get S28:Dk∣≡GW∣≡TS3,Dk↔XgDkGWXgDkBased on S28 and rule 5, we could get S29:Dk∣≡GW∣≡Dk↔XgDkGWBased on S29, H15, and rule 3, we have S30:Dk∣≡Dk↔XgDkGWBased on S30, S31, H13, and Rule 1, we getS32:Nk∣≡GW∣∼Ts1,Tm2,Ts3,SPij,Dk↔XgDkGW,Dk↔ri∗GWXgDkBased on H14, H16, and rule 4, we obtain the following:S33:Dk∣≡#Ts1,Ts2,Ts3,SPij,Dk↔XgDkGW,Dk↔ri∗GWXgDkBased on S32, S33, and rule 2, we have the following:S34:Dk∣≡GW∣≡Ts1,Ts2,TS3,SPij,Dk↔XgDkGW,Dk↔ri∗GWXgDkBased on S17, S18, and S34, we get S35:Dk∣≡GW∣≡Dk↔ri∗GWBased on S35, H17, and rule 3, we get S36:Dk∣≡Dk↔ri∗GWFrom Mssg7, we get S37:Dk⊲Ts3,ri∗,Dk↔SIDiGW,Dk↔ri∗GWXgDkBased on S37, H13, and rule 1, we get:S38:Dk∣≡Ui∣∼Ts3,ri∗,Dk↔SIDiGW,Dk↔ri∗GWXgDkBased on H14, H16, and rule 4, we getS39:Dk∣≡#Ts3,ri∗,Dk↔SIDiGW,Dk↔ri∗GWXgDkFrom S38, S39, and rule 2, we getS40:Dk∣≡Ui∣≡Ts3,ri∗,Dk↔SIDiGW,Dk↔ri∗GWXgDkBased on S17, S18, S35, and rule 5, we get goal 4:Dk∣≡Ui∣≡Ui↔SKDkBased on S36, H18, goal 4, and rule 3, it will lead to the following:Goal 3:Dk∣≡Ui↔SKDkFrom Mssg8, we get S41:Ui⊲Ts3,ri∗,Ui↔IDiGW,(Ui↔ri∗GWXgDkBased on S41, H19, and rule 1, we getS42:Ui∣≡GW∣∼Ts3,ri∗,Ui↔IDiGW,Ui↔ri∗GWXgDkBased on H20, and rule 4, we get S43:Ui∣≡#Ts3,ri∗,Ui↔IDiGW,Ui↔ri∗GWXgDkBased on S42, S43, and rule 2, we getS44:Ui∣≡GW∣≡Ts3,ri∗,Ui↔IDiGW,Ui↔ri∗GWXgDkBased on S5, S6, S44, and rule 5, we have S45:Ui∣≡GW∣≡Ui↔ri∗GWBased on S45, H21, and rule 3, we get S46:Ui∣≡Ui↔ri∗GWFrom Mssg9, we haveS47:Ui⊲Ts1,Ts2,Ts3,,Ts4,Vi∗,Nk↔SIDiGW,ri∗,Ui↔KlGWSKBased on S47, H9, and rule 1, we getS48:Ui∣≡∼Ts1,Ts2,Ts3,,Ts4,Vi∗,Dk↔SIDiGW,ri∗,Ui↔KlGWSKBased on H20, H22, and rule 4, we getS49:Ui∣≡#Ts1,Ts2,Ts3,,Ts4,Vi∗,Dk↔SIDiGW,ri∗,Ui↔KlGWSKFrom S48, S49, and rule 2, we haveS50:Ui∣≡Nk∣≡Ts1,Ts2,Ts3,,Ts4,Vi∗,Dk↔SIDiGW,ri∗,Ui↔KlGWSKBased on S45, S50, and rule 5, we haveGoal 2:Ui∣≡Nk∣≡Ui↔SKDkFinally, using S46, H23, goal 2, and rule 3, we obtainGoal 1:Ui∣≡Ui↔SKDk.Hence, the goals 1 and 2 assure mutual authentication amongUiand Nk in presence of GW


## 5.2. Informal Security Analysis

In this section, we present an informal security analysis to prove that the proposed protocol is withstanding against various well-known malicious attacks. Besides, it provides the most security functionality requirement.Proposition 2.
Resistance to the IoT sensor node capture attack.Proof.
Assume that a malicious attackerMA attempts to compose the legal authentication request message M6=UCi,UDk,TS3,TS4ei,fiFactori∗ or M7=Vi∗,TS4,TS6,cha of the IoT sensing node Nk and sent them to Uior GW on behalf of Nk.For this motivation, MA tries to modify the exchanges message M6 and M7 to M6i=UCi′,UDK′,Factori∗′,ei′,fi′,TS3′,TS4′ and M7i=Vi∗′,TS4,′,TS6,′ by extracting the stored information. MA cannot obtain the value of MIDi as it is protected by a one-way hash function and the shared secret key XgNk, which is only known to the IoT sensor nodeNk. Also, MA cannot calculate Vi∗ as it protected by a one-way hash with the random number Mi. Therefore, our proposed protocol resists node compromise attacks.Proposition 3.
Resistance to impersonation attacks.Proof.
In our proposed protocol, the attacker cannot extract or impersonate the level 3 feature extraction of the fingerprint ofUi. Moreover, if a malicious attacker attempts to adjust the parameter UDk=hXgu∥TS1∥Factori⨁Ri to a new one as UDk′, then the attacker will fail in the GW side due to a mismatch with UDk calculated by the GW in the authentication phase with UDk′. Therefore, the proposed protocol resists impersonation attacks.Proposition 4.
Resistance to replay attacks.Proof.
Assuming that a malicious attack aims to retransmit a message gained by eavesdropping on an efficient communication channel between theUi and the Dk through the login and authentication phase, the attacker will fail, because our proposed protocol uses timestampsTS3,TS4,TS5,TS6, and the delay time of the timestamp is brief. Our proposed scheme also uses Factori∗ which is stored on the basis of level 3 feature extraction. Therefore, the proposed protocol provides an efficient security against replay attacks.Proposition 5.
Resistance to stolen smart device attacks.Proof.
In the case where the user’s smart device is stolen or lost, the attacker aims to access the sensitive information stored in the device’s memory using a power examination attack. Our proposed protocol provides efficient security against this kind of attack. The attacker cannot determine the identityIDi and the password PWi of the Ui since these are masked by a hash function on the basis of a random number Ri that is generated only once. Moreover, the attacker cannot identify the feature extraction FPi given the hash function. Accordingly, our proposed protocol provides an efficient security against stolen smart device attacks.Proposition 6.
Resistance to password change attacks.Proof.
To change the user password, a malicious attack must use the personal fingerprint of a genuineUi. Thus, the attacker cannot change the password. Assuming that a user’s smart device is stolen or lost or is used by an attacker through another method, the attacker still cannot change the password, since this process requires the old password. Therefore, our proposed protocol resists password changes attacks.Proposition 7.
Resistance to denial-of-service attacks.Proof.
In our proposed scheme, this kind of attack is infeasible because theUi receives an authorization message from the nodeDk for security verification. Furthermore, we use timestampsTS3, TS4, TS5, and TS6 to mitigate any crucial request.Proposition 8.
Resistance to parallel session attacks.Proof.
If a malicious attack aims to build a parallel session of the scheme, then the attacker will fail even if he/she interrupts the communication message (M5=Factori∗,UDk,UCi,TS3,ei,fi) due to our utilization of level 3 feature extraction and the timestamp used in the login and authentication phases.Proposition 9.
Resistance to gateway node bypass attacks.Proof.
In this kind of attack, the attacker aims to impersonate theGW with the aim of later connecting to any IoT nodeDk. Our proposed scheme can resist this type of attack because, as illustrated in Figure 4, the Ui initially sends the authenticated messageFactori∗, UDk, UCi, TS3, ei, and fi to the desired node Dk to initiate the authenticated phase. Subsequently, the node Dk returns this message to the GW (Figure 3.7). Then, GW verifies Dk and Ui. Accordingly, Ui, as the first step, uses any IoT facility that is disconnected from the GW. Therefore, the propose protocol provides an efficient security against gateway node bypass attacks.Proposition 10.
Resistance to MITM attacks.Proof.
As previously explained in Section 4, this type of attack aims to intercept communication between two legitimate parties and to modify, delete or delay messages. We suppose that a malicious attack intercepts the login message (M5=Factori∗,UDk,UCi,TS3,ei,fi) transmitted from Ui to the node Dk and the authentication message (M6=UCi,UDk,ei,fi,TS3,TS4,Factori∗) that transmitted from the node Dk to GW. In this scenario, the attacker aims to modify the login message or authentication message to M5′,M6′. However, the attacker cannot predict the shared secret key needed to modify these messages. Moreover, each message communicated in the login and authentication phases has a timestamp with a short delay, thereby preventing an attacker from changing the messages. Therefore, our proposed scheme resists MITM attacks.Proposition 11.
Resistance to Off-line Guessing Attacks.Proof.
In our proposed scheme, a malicious attacker cannot gain an advantage by using off-line password-guessing attacks because the attacker cannot obtain the real passwords of a genuineUi using the communication messages M5=Factori∗,UDk,UCi,TS3,ei,fi and M6=UCi,UDk,ei,fi,TS3,TS4,Factori∗ in the login and authentication phases, respectively. Even if the user’s smart device is stolen, the attacker cannot predict the password due to the nature of the hash function. Furthermore, the attacker cannot deduce the user fingerprint because the fingerprint is stored on the basis of a random number Ri, level 3 feature extraction that is generated only once, and the use of a strong hash function. If the adversary guesses PWi′, then, to legalize PWi′ with bi∗=bi∗∗? and ci∗=ci∗∗?, he/she needs to know Ui’s identity as well as Ui’s biometric Bi. Moreover, to guess PWi, the adversary will need to guess IDi and Bi along with the password. However, revealing of user biometric information or stealing it or forging it is not achievable; hence, the proposed protocol withstands offline-password-guessing attacks.Proposition 12.
Provides key agreement.Proof.
This feature indicates that theUi and the IoT node Dk must agree on a secure session key to protect their successive communications. In our protocol, once Dk receives the authentication request (M7=GPij,Vi,TS5) from the GW, it computes the session key SK=HRi⨁Mi⨁Factori∗ on the basis of mask nonce Mi, Ri and Factori∗. Afterwards, Dk sends the message (M8=Vi∗,TS3,TS4,TS5,TS6,cha) to the Ui. Subsequently, Ui receives the authenticated message and then calculates the session key SK=hMi∗⨁Ri, and both session keys are equal as shown in Figure 3.6. Therefore, our proposed protocol supports a secure session key.Proposition 13.
Provides user anonymity.Proof.
Anonymity means protecting the information of aUi from being tracked by an attacker. The user information, identityIDi, passwordPWi, and fingerprint FPi are masked by a hash function. The fingerprint FPi is calculated on the basis of the hash function of level 3 feature extraction. Accordingly, if a particular attacker attempts to interrupt the message exchange between the entities, then the attacker will fail to trace the user information.Proposition 14.
Provides forward secrecy.Proof.
In our protocol, we created the session keySK=hRi⨁Mi⨁Factori∗ on the basis of the nonce number Mi which is generated once for each Ui who desires to log in to the (IoT) nodes. We also created the random numberRi and theFactori which is not saved as a plaintext. Therefore, a malicious attack cannot obtain the session key by any way.Proposition 15.
Provides mutual authentication.Proof.
An authentication mechanism requires each entity in the IoT environment,, i.e.GW, the Ui and the IoT nodeDk to validate each other. In our proposed protocol, after executing the necessary steps, Ui sends the authentication message (M5=Factori∗,UDk,UCi,TS3,ei,fi) to Dk in the login phase (see Figure 3.7). Then, Dk send the authentication message (M6=UCi,UDk,TS3,TS4,ei,fi,Factori∗) to GW. Accordingly, the GW uses the authenticated message to validate the Ui and the node Dk. Therefore, the proposed protocol achieves mutual authentication.Proposition 16.
Provides Key FreshnessProof.
In our work, we generate a session keySK=hRi⨁Mi⨁Factori∗ that consists of fresh timestamps that are different in each session. Accordingly, our proposed protocol achieves key freshness. A security analysis of possible attacks against this model is presented below, and it is shown that our proposed protocol can resist several well-known attacks.


## 5.3. Formal Security Analysis Using the AVISPA Tool

AVISPA is a powerful automated validation tool which provides a wide applications range for constructing cryptographic protocols analysis models, verification, and validation. To validate the protocol using the AVISPA tool, firstly, the protocol is coded by using HLPSL language. Then, translate the HLPSL code in intermediate format (IF) by the HLPSL2IF translator. Finally, the IF specification as input is given to the back ends. After the IF execution, the back-end displays the result of the simulation of the protocol by analyzing to output format (OF), with an explanation of whether the protocol is safe or unsafe against man-in-the-middle and replay attacks. Also, back ends confirm the security features of the protocol such as the flexibility against most of the known attacks, authentication, and the secrecy of keys. Note that AVISPA performs the Dolev-Yao threat model [59, 60]. More details of the AVISPA tool and HLPSL can be found in [61].To implement and simulate the proposed protocol on AVISPA, we have concentrated on the major tool SPAN Version 1.6 based on a computer system which is consist of Windows 10 Enterprise operating system (64 bit) that is supported by Ubuntu 10.10 light on Virtual machine, Intel (R) Core (TM) i7-7500U CPU @ 2.70 GHz 2.90 GHz processor, and 8 GB RAM. In AVISPA, there is a role for each entity, and these roles are independent of each other. AVISPA has an implementation in the form of four back ends, namely, TA4SP (Tree Automata based on Automatic Approximations for the Analysis of Security Protocols), OFMC (On-the-fly Model-Checker), CL-AtSe (Constraint Logic-based Attack Searcher), and SATMAC (SAT-based Model checker) [62]. We have evaluated the proposed protocol against man-in-the-middle and replay attacks under the OFMC and CL-AtSe back ends using SPAN.The user registration, login, and authentication phases for the proposed protocol are implemented in HLPSL utilizing three basic roles for a remote user, the IoT sensor node, and the gateway node. The compulsory roles for the environment, session, and goal are also defined. Figure5 provides the simulation results that obviously indicate that the proposed protocol is protected against man-in-the-middle and replay attacks.Figure 5
The simulation results under OFMC and CL-AtSe back ends.


## 6. Comparative Study

The proposed protocol is compared with the recent user authentication protocols proposed in the IoT environment such as the protocols of Banerjee et al. [1], Yang et al. [8], Dhillon and Kalra [33], Dammak et al. [45], Li et al. [50], and Farkoon et al. [60].


### 6.1. Security Functionality Comparisons

Table3 summarizes the comparison of the functionality features of the recent user authentication protocols [1, 8, 33, 45, 50, 60]. It can be observed that the proposed protocol offers improved security and functionality features, in comparison to the other recent protocols.Table 3
Functionality comparison of our protocol with other recent related protocols.
Properties[1][8][33][45][50][60]OurUser anonymity✓✗✓✗✓✓✓Mutual authentication✓✓✓✓✓✓✓Key agreement✗—✓✓✓✗✓Resistance to impersonation attack✓✓✗✗✗✗✓Resistance to MITM attack✓✗✓✓✗✓✓Replay attack✓✓✗✓✗✓✓Resistance to password guessing attack✓✓✓✓✓✗✓Resistance to GW bypassing attack✗✓✓✗✗✗✓Resistance to parallel session attack✗✓✓✗✗✗✓Resistance to smart device stolen attack✓✗✗✗✓✓✓Resistance to DOS attack✓✓✓✓✓✗✓Resistance to insider attack✓✗✓✓✗✓✓Password change phase✓✓✓✓✓✓✓Forward secrecy✓✗✗✗✗✗✓Key freshness✗✓✗✓✓✗✓BAN logic security analysis✓✗✗✓✓✓✓


### 6.2. Computation Overhead Comparison

In this section, we compare our proposed protocol in terms of computation overhead with those of recent related protocols [1, 8, 33, 45, 50, 60]. The protocol comprises four phases: user and sensor node registration phase, login phase, key agreement and authentication phase, and password and biometrics change phase. In the IoT WSN environment, the performance of the user authentication protocol mainly is affected by the login and authentication phase [2]. These two phases are the major part of the user authentication protocol and is what chiefly characterize it from the different user authentication protocols in IoT WSNs. Consequently, we focused our discussion of computation overheads during the login and authentication phase. The computational costs are the time consumed by the user and service provider in the process [9]. For computation overheads analysis, we utilized the notations Th and Tm to indicate the time complexity of the hash function and elliptic curve cryptography (ECC) algorithm, respectively. The computational costs of the OXR operation are usually neglected because it requires a minimal number of computations.In the login and authentication phase of our protocol, the remote user requires only8Th to calculate the parameters of a login and authentication request message. The IoT sensor node expends only 3Th bits to verify the login request and to calculate the parameters of the key agreement message. As for the gateway node, it requires the gateway node which requires only 7Th bits to verify whether the verification equations hold. Our proposed protocol uses only the XOR and one-way hash function operations to design simple user authentication and key agreement protocol. However, Li et al.’s protocol [50] provides authentication and key agreement protocol that is designed using an asymmetric encryption ECC algorithm. The time complexity of the asymmetric ECC encryption operation is greater than that of a one-way hash function. According to the practical example of the computational costs in an environment with a CPU of 3.2 GHz and with 3.0 GB of RAM, the time complexity of one-way hash operations requires 0.02 ms when using SHA-1 and for the ECC encryption operation which requires 0.45 ms when using ECC-160 [63]. Therefore, the total computational overheads of our protocol are 0.36 ms. Table 4 summarizes the computational overheads of our proposed protocol and the existing protocols in [1, 8, 33, 45, 50, 60] with approximate time (in milliseconds). It is clear that the proposed protocol requires less overall computation costs. The energy consumption of the IoT sensor node in our work is 0.06 ms which is 50%, 81.25%, 25%, 87.75%, 62.5%, and 95.8% lower than the computation times in the protocols of [1, 8, 33, 45, 50, 60].Table 4
Computation overhead comparison.
ProtocolsUserSensor nodesGW nodesTotal costTotal estimation[1]4Th24Th5Th33Th0.66 ms[8]16Th16Th20Th52Th1.04 ms[33]9Th6Th7Th22Th0.44 ms[45]20Th8Th20Th48Th0.96 ms[50]13Th+3Tm4Th+2Tm8Th+Tm24Th+6Tm3.18 ms[60]13Th4Th13Th30Th0.6 msOurs8Th3Th7Th18Th0.36 msConsequently, the total energy consumed of the IoT sensor node by our protocol is 0.36 ms. Therefore, our proposed protocol is more efficient and suitable for constrained sensor devices in the IoT WSNs environment. Table4 presents the energy consumption of the IoT sensor node of our proposed protocol with those of [1, 8, 33, 45, 50, 60] along with total improvements of computational costs of the present protocols. From Table 5, it can be observed that the computational costs for the resource-limited IoT sensing device in our protocol is less in comparison to that of the recent existing protocols. The proposed protocol achieves superior performance because it consumes less energy compared to recent related protocols and is highly efficient. As the sensors nodes deployed in IoT networks have low battery life, low storage, and limited processing capability, the energy consumption of these IoT sensor nodes must be optimized. The IoT sensor nodes energy depends on two factors: the number of cryptographic operations to be performed and the amount of data being transmitted. Our proposed protocol minimized the number of cryptographic computations, therefore, more data can be transmitted via IoT sensor nodes. For the evaluation of the proposed protocol, the workload is not taken into consideration. In the future, the proposed protocol will be executed for different workloads in Cloud computing and IoT environments.Table 5
Energy consumption of the IoT sensor node and improvement.
ProtocolsEnergy consumption of the IoT sensor nodeEnergy consumption improvement %Protocol improvement %[1]0.48 ms87.7545.4[8]0.32 ms81.2565.3[33]0,12 ms5018.1[45].016 ms62.562.5[50]0.43 ms95.888.67[60]0.08 ms2540Ours0.06 ms——


### 6.3. Communication Overhead Comparison

For communication overhead computation, we assumed that the timestamp, hash digest (assuming SHA-1 hashing algorithm is applied), identity, a random nonce, and the secret key are 128 bits, while the ECC operations are 160 bits. There are four exchanges messages betweenUi, Nk, and GW in proposed protocol that are M5=MIDi,UDk,UCi,TS3, M6=UCi,UDk,TS4, M7=GPij,Vi,TS5, and M8={Vi∗,TS4,TS6}, where MIDi, UDk, UCi, GPIJ, and Vi are the hash function output. TS3, TS4, TS5, and TS6 are timestamps. According to our above assumption, each parameter is 128 bits. Therefore, the communication overhead of the proposed protocol is 128×13=1664 bits. Table 6 summarizes the communication overheads and the number of exchanged messages for all protocols in addition to the proposed protocol. We observe that the proposed protocol obtains less communication overhead as compared to the protocols in [1, 8, 33, 45, 50, 60] and incurs greater overhead than the protocol in [60]. Although the protocol [60] bears the less overhead but did not achieve the desired functionality and security features such as resistance to impersonation attacks, password guessing attacks, DOS attacks, preserved user anonymity, and forward secrecy in contrast to our protocol which achieved all functionality and security features (see Table 3).Table 6
Communication overhead comparison.
ProtocolsCommunication in bits[1]2176[8]3840[33]3200[45]2560[50]1792[60]1408Ours1664


## 6.1. Security Functionality Comparisons

Table3 summarizes the comparison of the functionality features of the recent user authentication protocols [1, 8, 33, 45, 50, 60]. It can be observed that the proposed protocol offers improved security and functionality features, in comparison to the other recent protocols.Table 3
Functionality comparison of our protocol with other recent related protocols.
Properties[1][8][33][45][50][60]OurUser anonymity✓✗✓✗✓✓✓Mutual authentication✓✓✓✓✓✓✓Key agreement✗—✓✓✓✗✓Resistance to impersonation attack✓✓✗✗✗✗✓Resistance to MITM attack✓✗✓✓✗✓✓Replay attack✓✓✗✓✗✓✓Resistance to password guessing attack✓✓✓✓✓✗✓Resistance to GW bypassing attack✗✓✓✗✗✗✓Resistance to parallel session attack✗✓✓✗✗✗✓Resistance to smart device stolen attack✓✗✗✗✓✓✓Resistance to DOS attack✓✓✓✓✓✗✓Resistance to insider attack✓✗✓✓✗✓✓Password change phase✓✓✓✓✓✓✓Forward secrecy✓✗✗✗✗✗✓Key freshness✗✓✗✓✓✗✓BAN logic security analysis✓✗✗✓✓✓✓


## 6.2. Computation Overhead Comparison

In this section, we compare our proposed protocol in terms of computation overhead with those of recent related protocols [1, 8, 33, 45, 50, 60]. The protocol comprises four phases: user and sensor node registration phase, login phase, key agreement and authentication phase, and password and biometrics change phase. In the IoT WSN environment, the performance of the user authentication protocol mainly is affected by the login and authentication phase [2]. These two phases are the major part of the user authentication protocol and is what chiefly characterize it from the different user authentication protocols in IoT WSNs. Consequently, we focused our discussion of computation overheads during the login and authentication phase. The computational costs are the time consumed by the user and service provider in the process [9]. For computation overheads analysis, we utilized the notations Th and Tm to indicate the time complexity of the hash function and elliptic curve cryptography (ECC) algorithm, respectively. The computational costs of the OXR operation are usually neglected because it requires a minimal number of computations.In the login and authentication phase of our protocol, the remote user requires only8Th to calculate the parameters of a login and authentication request message. The IoT sensor node expends only 3Th bits to verify the login request and to calculate the parameters of the key agreement message. As for the gateway node, it requires the gateway node which requires only 7Th bits to verify whether the verification equations hold. Our proposed protocol uses only the XOR and one-way hash function operations to design simple user authentication and key agreement protocol. However, Li et al.’s protocol [50] provides authentication and key agreement protocol that is designed using an asymmetric encryption ECC algorithm. The time complexity of the asymmetric ECC encryption operation is greater than that of a one-way hash function. According to the practical example of the computational costs in an environment with a CPU of 3.2 GHz and with 3.0 GB of RAM, the time complexity of one-way hash operations requires 0.02 ms when using SHA-1 and for the ECC encryption operation which requires 0.45 ms when using ECC-160 [63]. Therefore, the total computational overheads of our protocol are 0.36 ms. Table 4 summarizes the computational overheads of our proposed protocol and the existing protocols in [1, 8, 33, 45, 50, 60] with approximate time (in milliseconds). It is clear that the proposed protocol requires less overall computation costs. The energy consumption of the IoT sensor node in our work is 0.06 ms which is 50%, 81.25%, 25%, 87.75%, 62.5%, and 95.8% lower than the computation times in the protocols of [1, 8, 33, 45, 50, 60].Table 4
Computation overhead comparison.
ProtocolsUserSensor nodesGW nodesTotal costTotal estimation[1]4Th24Th5Th33Th0.66 ms[8]16Th16Th20Th52Th1.04 ms[33]9Th6Th7Th22Th0.44 ms[45]20Th8Th20Th48Th0.96 ms[50]13Th+3Tm4Th+2Tm8Th+Tm24Th+6Tm3.18 ms[60]13Th4Th13Th30Th0.6 msOurs8Th3Th7Th18Th0.36 msConsequently, the total energy consumed of the IoT sensor node by our protocol is 0.36 ms. Therefore, our proposed protocol is more efficient and suitable for constrained sensor devices in the IoT WSNs environment. Table4 presents the energy consumption of the IoT sensor node of our proposed protocol with those of [1, 8, 33, 45, 50, 60] along with total improvements of computational costs of the present protocols. From Table 5, it can be observed that the computational costs for the resource-limited IoT sensing device in our protocol is less in comparison to that of the recent existing protocols. The proposed protocol achieves superior performance because it consumes less energy compared to recent related protocols and is highly efficient. As the sensors nodes deployed in IoT networks have low battery life, low storage, and limited processing capability, the energy consumption of these IoT sensor nodes must be optimized. The IoT sensor nodes energy depends on two factors: the number of cryptographic operations to be performed and the amount of data being transmitted. Our proposed protocol minimized the number of cryptographic computations, therefore, more data can be transmitted via IoT sensor nodes. For the evaluation of the proposed protocol, the workload is not taken into consideration. In the future, the proposed protocol will be executed for different workloads in Cloud computing and IoT environments.Table 5
Energy consumption of the IoT sensor node and improvement.
ProtocolsEnergy consumption of the IoT sensor nodeEnergy consumption improvement %Protocol improvement %[1]0.48 ms87.7545.4[8]0.32 ms81.2565.3[33]0,12 ms5018.1[45].016 ms62.562.5[50]0.43 ms95.888.67[60]0.08 ms2540Ours0.06 ms——


## 6.3. Communication Overhead Comparison

For communication overhead computation, we assumed that the timestamp, hash digest (assuming SHA-1 hashing algorithm is applied), identity, a random nonce, and the secret key are 128 bits, while the ECC operations are 160 bits. There are four exchanges messages betweenUi, Nk, and GW in proposed protocol that are M5=MIDi,UDk,UCi,TS3, M6=UCi,UDk,TS4, M7=GPij,Vi,TS5, and M8={Vi∗,TS4,TS6}, where MIDi, UDk, UCi, GPIJ, and Vi are the hash function output. TS3, TS4, TS5, and TS6 are timestamps. According to our above assumption, each parameter is 128 bits. Therefore, the communication overhead of the proposed protocol is 128×13=1664 bits. Table 6 summarizes the communication overheads and the number of exchanged messages for all protocols in addition to the proposed protocol. We observe that the proposed protocol obtains less communication overhead as compared to the protocols in [1, 8, 33, 45, 50, 60] and incurs greater overhead than the protocol in [60]. Although the protocol [60] bears the less overhead but did not achieve the desired functionality and security features such as resistance to impersonation attacks, password guessing attacks, DOS attacks, preserved user anonymity, and forward secrecy in contrast to our protocol which achieved all functionality and security features (see Table 3).Table 6
Communication overhead comparison.
ProtocolsCommunication in bits[1]2176[8]3840[33]3200[45]2560[50]1792[60]1408Ours1664


## 7. Conclusion

In this paper, we presented a secure and lightweight three-factor remote user authentication protocol designed for future IoT WSN application. The proposed protocol grants the legitimate remote user that mutually authenticates with the IoT sensor node through a trusted gateway node. The symmetric session key SK is established by the end of successful mutual authentication between the user and the IoT sensor node for future secure communications. The security of the proposed protocol is formally using the popular widely accepted BAN logic. Furthermore, informal security verification demonstrates that the proposed protocol resists the most well-known attacks. The formal security using the AVISPA simulation is evaluated, and the results showed that our protocol is safe. Finally, the performance analysis comparison in terms of computation and communication overheads demonstrated that our protocol showed high efficiency and performance compared to those of recent related protocols and is more suitable for practical IoT WSN environments.



---

*Source: 8871204-2021-04-28.xml*