Journal of Sensors

Journal of Sensors / 2021 / Article
Special Issue

Sensors in Internet of Health Things Paradigm

View this Special Issue

Research Article | Open Access

Volume 2021 |Article ID 8871204 |

Bahaa Hussein Taher, Huiyu Liu, Firas Abedi, Hongwei Lu, Ali A. Yassin, Alzahraa J. Mohammed, "A Secure and Lightweight Three-Factor Remote User Authentication Protocol for Future IoT Applications", Journal of Sensors, vol. 2021, Article ID 8871204, 18 pages, 2021.

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

Academic Editor: ahmed alkhayyat
Received22 Aug 2020
Revised24 Oct 2020
Accepted28 Nov 2020
Published28 Apr 2021


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.

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.

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 [1214]. 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

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 [1821]. 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 [2325].

Usually, the real-time users adopt to use easy-to-memorialize parameters, such as secret keys and identities, for their convenience, as explain in [2325]; hence, user anonymity is not provided. For the enhancement security of IoT WSNs, studies in [2630] 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 [3641]. 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 hashing

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 Figure 1. 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.


Remote user
Identity of the user
The user password
Extracting user iris
,Random numbers generated by the user
The fingerprint of the user
Feature extraction level 3
IoT sensing nodes
The shared secret key of the IoT devices, generated by
The trusted gateway node
A secret key generated by the gateway
A secret key generated for the user
, , , , Timestamps
Shared session key
XOR operation
Concatenation operation
One-way hash function

The proposed protocol contains three participants: a remote user () who aims to maximize the services in the environment, a set of IoT sensor nodes (), and a trusted home authority/gateway (). 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 .

4.1. Remote User Registration Phase

User side: at this stage, who aims to access IoT resources must initially register in the . To complete the registration, executes the following steps: (Step 1)The selects his identity and password. Afterwards, inputs his/her fingerprint(Step 2)The computes level 3 feature extraction of the fingerprint as follows: (Step 3)The selects a random integer and computes a mask for the user’s identity, password, and fingerprint as follows: identity mask: , password mask: and fingerprint mask: (Step 4)The sends, , , and to the as a communication request to the GW node through a secure channel

Gateway side: on receiving a request message from, the performs the following steps. (Step 1) generates secret keys and . Following this, computes the security parameters , , and , prior to use(Step 2) calculates , , and (Step 3)The node submits , , , , and to . On receiving , saves it in the memory of the device. Figure 3 summarizes the different processing steps followed during this 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) generates a random number . known the shared secret of the and has a unique identity (Step 2) computes the parameters and for further calculation(Step 3) sends, , , and to the GW through a secure channel

GW node side: upon receiving the registration request from IoT sensor nodes, the calculates the following steps. (Step 1)Checks the timestamp condition . If the condition is unsatisfied, then the registration phase is terminated; otherwise, the executes the next step(Step 2)Computes, and on the basis of the previous message received from as (Step 3)Verifies whether or not. Therefore, if they are not unequal, the node is not illegitimate, and the terminates the session. Otherwise, executes the next step(Step 4)Computes the following parameters for further use, , , and (Step 5)Then, sends, , and to. Upon receiving the registration messages (, , and ) from the , checks the timestamp condition to verify for any external interference. If the condition is unsatisfied, then the session is terminated; otherwise, saves the parameters , . and 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 user can access any desired sensor node within the IoT network through the authentication phase. To start with the authentication phase, must login to the selected IoT service application, following the login steps that are implemented during this phase. (Step 1)First, the user uses the smartphone to open the applications and enters his/her password and level 3 feature extraction saved in the smartphone(Step 2)Then, the smartphone of calculates a masked for the password and the feature extraction as follows: and . Also, it computes and(Step 3)Next, the original values of and extract as follows: and (Step 4) computes the value of the following verification parameters and as and (Step 5)Then, the accurateness of and is verified with and . If =? and =?, 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: and(Step 7)Also, calculates for use in a security check later(Step 8)In the end, sends the login parameters to the desired IoT node. Upon completing step 8, the login phase is complete. The user 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 to , 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 from , performs the timestamp check on receive , i.e., . Also, check the security parameter , to authenticate the. If the condition is unsatisfied, then the login is terminated; otherwise, the process proceeds to the next step(Step 2) uses the stored values of and to calculate(Step 3)Next, calculates (Step 4) sends to the . can recognize the legitimacy of the and the node on the basis of the parameter and the transaction time. In this step, the node authenticates the(Step 5) verifies the received timestamp and authority of the , and the device simultaneously. If the condition is satisfied, then the proceeds to the next step; otherwise, the process is terminated(Step 6)Then, calculates the security parameters: , , and . Afterwards, the checks the quality of and. If they are equal, then authenticates the node and the user

The IoT sensor node must be successfully verified by the on the basis of the retrieved depending on. Therefore, performs the following: (Step 1) calculates and(Step 2) compares the original and the calculated to authenticate the . If the verification condition is unsuccessful, then the terminates the communication; otherwise, the continues to the next step(Step 3)Next, computes the security parameters: and (Step 4) submits to

Upon receiving the verification parameters from the , computes the following processes: (Step 1) verifies the timestamp. If the verification condition is unsatisfied, then the process is terminated; otherwise, it continues forward(Step 2)Then, checks the validity of with. If the condition is unsatisfied, then the process is terminated; otherwise, it proceeds to the next step(Step 3)Next, calculates , and , where is a random number generated once. Afterwards, computes the session key as (Step 4)At last, sends to the . When receives the verification parameter from , executes the following steps:(Step 1) performs timestamp checks, i.e., ? If not, then the process is terminated; otherwise, it continues to the next step(Step 2) retrieves (Step 3)Then, computes . Then, verifies if . If not, then is unsure of the authority of and the; otherwise, the computes the session key as 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) who must change his/her password opens the IoT application on a smart device and enters his/her old password and feature extraction ; then, he/she calculates the masked for each of and feature extraction of user biometrics as , (Step 2)Then, calculates and and proceeds to the next step(Step 3)Next, checks the equality of and with the original one and . If any conditions do not hold, the unsuccessfully enters his correct data, and the system will be terminated; otherwise, is a valid user, and then is permitted to change his/her password(Step 4) enters the new password and new fingerprint. Then, he/she calculates mask the hash function for each of them as and , correspondingly(Step 5)Then, updates the parameter on the basis of the new password as . Then, it calculates new as: (Step 6)At last, changes the old stored in the smart device memory with the new one , 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.


believes as a valid statement.
Principal sees the statement .
Principal once said the statement .
The formula is fresh.
and use the shared session key to communicate, and will never be discovered by any principal except and .
has jurisdiction over .
is hashed with the key .
is combined with the key .
is encrypted with the key .

There are five rules used which govern the BAN logic are listed as follows:

Rule 1: message meaning rules: OR

Rule 2: the nonce-verification rule:

Rule 3: the jurisdiction rule:

Rule 4: the freshness rule:

Using the above rules, we the following prove Theorem.

Theorem 1. The proposed protocol provides secure mutual authentication between and in the presence of the .

Proof. We define the following four goals:
Goal 1:
Goal 2:
Goal 3:
Goal 4:

The idealization form of the transmitted messages during the login and authentication phase under the proposed protocol is presented as follows: (M1): (M2): (M3): (M4): (M5): (M6): (M7): (M8): (M9):

We consider the following initial assumptions according to the proposed protocol description: (H1)(H2)(H3)(H4)(H5)(H6)(H7)(H8)(H9)(H10)(H11)(H12)(H13)(H14)(H15)(H16)(H17)(H18)(H19)(H20)(H21)(H22)(H23)

By 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:

Based on S1, H1, and rule 1, we get S2:

Based on H2 and rule 1, we get S3:

Based on S2, S3, and rule 2, we have S4:

Based on S4 and rule 5, we get S5:

Based on S5, H3, and rule 3, we can get S6:

From M2, we get


Based on S7, H4, and rule 1, we get


Based on H2, H5, and rule 4, we could get


Based on H2, H5, and rule 4, we have


Based on S5, S6, S10, and rule 5, we could get S12:

Based on S13, H7, and rule 1, we get


Based on H7 and rule 4, we have


Based on S14, S15, and rule 2, we get


Based on S16 and rule 5, we have S17:

Based on S17, H9, and rule 3, we could get S18:

From Mssg4, we get


Based on S19, H10, and rule 1, we get


Based on H8, H11, rule 4, we have


Based on S20, S21, and rule 2, we have


Based on S17, S18, S22, and rule 5, we could get S23:

Based on S23, H12, and rule 3, we get S24:

From Mssg5, we could get S25:

Based on S25, H13, and rule 1, we have


Based on H14 and rule 4, we have S27:

Based on S26, S27, and rule 2, we get S28:

Based on S28 and rule 5, we could get S29:

Based on S29, H15, and rule 3, we have S30:

Based on S30, S31, H13, and Rule 1, we get


Based on H14, H16, and rule 4, we obtain the following:


Based on S32, S33, and rule 2, we have the following:


Based on S17, S18, and S34, we get S35:

Based on S35, H17, and rule 3, we get S36:

From Mssg7, we get S37:

Based on S37, H13, and rule 1, we get:


Based on H14, H16, and rule 4, we get


From S38, S39, and rule 2, we get


Based on S17, S18, S35, and rule 5, we get goal 4:

Based on S36, H18, goal 4, and rule 3, it will lead to the following:

Goal 3:

From Mssg8, we get S41:

Based on S41, H19, and rule 1, we get


Based on H20, and rule 4, we get S43:

Based on S42, S43, and rule 2, we get


Based on S5, S6, S44, and rule 5, we have S45:

Based on S45, H21, and rule 3, we get S46:

From Mssg9, we have


Based on S47, H9, and rule 1, we get


Based on H20, H22, and rule 4, we get


From S48, S49, and rule 2, we have


Based on S45, S50, and rule 5, we have

Goal 2:

Finally, using S46, H23, goal 2, and rule 3, we obtain

Goal 1: .

Hence, the goals 1 and 2 assure mutual authentication among and in presence of

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 attacker MA attempts to compose the legal authentication request message or of the IoT sensing node and sent them to or on behalf of .For this motivation, MA tries to modify the exchanges message and to and by extracting the stored information. MA cannot obtain the value of as it is protected by a one-way hash function and the shared secret key , which is only known to the IoT sensor node. Also, MA cannot calculate as it protected by a one-way hash with the random number . 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 of . Moreover, if a malicious attacker attempts to adjust the parameter to a new one as , then the attacker will fail in the side due to a mismatch with calculated by the in the authentication phase with . 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 the and the through the login and authentication phase, the attacker will fail, because our proposed protocol uses timestamps, and the delay time of the timestamp is brief. Our proposed scheme also uses 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 identity and the password of the since these are masked by a hash function on the basis of a random number that is generated only once. Moreover, the attacker cannot identify the feature extraction 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 genuine . 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 the receives an authorization message from the node for security verification. Furthermore, we use timestamps, , , and 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 () 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 the with the aim of later connecting to any IoT node. Our proposed scheme can resist this type of attack because, as illustrated in Figure 4, the initially sends the authenticated message, , , , , and to the desired node to initiate the authenticated phase. Subsequently, the node returns this message to the (Figure 3.7). Then, verifies and . Accordingly, , as the first step, uses any IoT facility that is disconnected from the . 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 () transmitted from to the node and the authentication message () that transmitted from the node to . In this scenario, the attacker aims to modify the login message or authentication message to . 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 genuine using the communication messages and 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 , level 3 feature extraction that is generated only once, and the use of a strong hash function. If the adversary guesses , then, to legalize with ? and ?, he/she needs to know s identity as well as s biometric . Moreover, to guess , the adversary will need to guess and 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 the and the IoT node must agree on a secure session key to protect their successive communications. In our protocol, once receives the authentication request () from the , it computes the session key on the basis of mask nonce , and . Afterwards, sends the message () to the . Subsequently, receives the authenticated message and then calculates the session key , 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 a from being tracked by an attacker. The user information, identity, password, and fingerprint are masked by a hash function. The fingerprint 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 key on the basis of the nonce number which is generated once for each who desires to log in to the (IoT) nodes. We also created the random number and the 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. , the and the IoT node to validate each other. In our proposed protocol, after executing the necessary steps, sends the authentication message () to in the login phase (see Figure 3.7). Then, send the authentication message () to . Accordingly, the uses the authenticated message to validate the and the node . Therefore, the proposed protocol achieves mutual authentication.

Proposition 16. Provides Key Freshness

Proof. In our work, we generate a session key 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. Figure 5 provides the simulation results that obviously indicate that the proposed protocol is protected against man-in-the-middle and replay attacks.

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

Table 3 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.


User 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 and 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 only to calculate the parameters of a login and authentication request message. The IoT sensor node expends only 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 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].

ProtocolsUserSensor nodes nodesTotal costTotal estimation

[1]0.66 ms
[8]1.04 ms
[33]0.44 ms
[45]0.96 ms