LR-AKAP: A Lightweight and Robust Security Protocol for Smart Home Environments

Abstract

For the betterment of human life, smart Internet of Things (IoT)-based systems are needed for the new era. IoT is evolving swiftly for its applications in the smart environment, including smart airports, smart buildings, smart manufacturing, smart homes, etc. A smart home environment includes resource-constrained devices that are interlinked, monitored, controlled, and analyzed with the help of the Internet. In a distributed smart environment, devices with low and high computational power work together and require authenticity. Therefore, a computationally efficient and secure protocol is needed. The authentication protocol is employed to ensure that authorized smart devices communicate with the smart environment and are accessible by authorized personnel only. We have designed a novel, lightweight secure protocol for a smart home environment. The introduced novel protocol can withstand well-known attacks and is effective with respect to computation and communication complexities. Comparative, formal, and informal analyses were conducted to draw the comparison between the introduced protocol and previous state-of-the-art protocols.

1. Introduction

Human life is enviable. Science and technology play a vital role in providing safety to human life by developing safer devices using smarter technology. [1,2]. The advances in wireless and sensor technology have played an indispensable role in the rapid adaption of the smart home as an interesting new paradigm of the Internet of Things (IoT) [3,4,5,6,7,8]. This results in gaining a considerable amount of interest from both industry and academic fields alike [9].

A smart-home environment is used to assist individuals in various tasks by appending automation to them, like a smart meter, which can help users by showing the real-time consumption of power, voltage, and load [10,11] along with other interconnected devices. These devices can be various sensors, like a sensor to measure humidity, temperature, occupancy, and even to monitor the equipment. Multiple services can be provided by employing these services, such as turning on the air conditioner (AC) when an individual enters the room or turning on the lights when a person opens the door, and carbon dioxide (CO₂) sensors can be employed to monitor the environment and to trigger automatic responses to energy saving [12,13]. In addition, these various smart gadgets can be deployed to oversee the health of the elderly [14]. Smart-home devices can also be accessed through a user’s device, such as a smartphone, without the restriction of place or time.

An innovative irrigation system may assist in conserving tens of dollars each year in addition to thousands of gallons of water. Cyber Rain [15], for example, allows observing and controlling the system from any Internet-connected device and can be customized to fit any size yard. By analyzing the weather prediction for you and modifying the watering plan automatically when rain is noticed, systems like Cyber Rain save the Earth’s limited supply of freshwater. According to the company’s website, users of Cyber Rain reportedly consume 35% less water on average.

Linked feeders provide automatic pet care. Using linked timers, you may water your yard and inside plants. There are many different types of kitchen equipment useable, such as smart coffee machines that can mix a fresh cup automatically at a set time, smart refrigerators that keep track of expiration dates, generate grocery lists, or even create ingredients using ingredients already in the house, toasters, and delayed cookers, and washing machines and dryers for the laundry room [16].

A wide range of applications, from business to government and military uses, may be realized with secure and continuous user access to designated smart home appliances [17]. Due to the sensitive nature of the operations and inherited vulnerabilities of the public channel, such as real-time data manipulation, clogging, replay, jamming, etc., the use of these smart home appliances for such applications is otherwise regarded as problematic [18,19]. Although various security schemes for the smart-home environment have recently been developed, many of these schemes have turned out to be insecure or unworkable. Consequently, the current demand is for an authentication system that can guarantee both security and privacy. To support the automatic security proof of the suggested method, we used a well-known automated program, AVISPA. The research showed that the suggested system could withstand known assaults and offered excellent balance between security and effectiveness [20,21,22,23].

A typical architecture for a smart home is presented in Figure 1. The network model comprises four components that are (i) the end user ($U_i$), (ii) a trusted authority ($TA$), (iii) a gateway node ($GWN$), and (iv) smart devices ($SD$). The $SD$s have limited resources and can be used for various tasks such as controlling the temperature, turning on lights [20], etc. The $GWN$ is used as an access point and has enough computation power; it acts as a gateway for $U$ and $SD$. The $TA$ is trusted by all the parties involved in the communication. The responsibilities he $TA$ include (i) system parameters’ generation and assignment, (ii) smart device and user registration, and (iii) key maintenance and management.

This study is arranged as follows: Section 2 presents the motivation and contribution of our research. Section 3 shortly investigates the existing literature. Section 4 presents our proposed protocol. Moreover, Section 5 discusses the security analysis. Section 6 presents the performance analysis. In Section 7, the whole work is summed up.

2. Motivations and Contributions

This section concisely presents the primary contributions of this study:

• We suggested an authentication protocol based on a symmetric key to protect the user–smart device connection. The system was created using a mobile device, biometrics, and a password.
• The security of the proposed work was analyzed by using an automated security tool AVISPA.
• The analysis showed that the suggested system could withstand known attacks and offered an excellent balance between security and effectiveness.
• The computation cost of the proposed protocol was less than that of the protocols with the smart devices as they were resource-constrained and had limited computational power.
• The proposed protocol evaded the clock synchronization issue in timestamp-based two-way authentication protocols.
• Our presented protocol was compared to others in a similar field, showing that the proposed protocol was better in terms of security and performance analysis.

3. Related Work

Recently, various protocols have been introduced to provide security in smart home environments [24,25]. Every protocol has its strengths and weaknesses. Sciancalepore et al. [26] used ECQV and ECDH certificates to accomplish authentication. However, two distinct keys are required to run the scheme, and the efficiency of the key creation function relies on the key derivation function (KDF). Any problem in the KDF may result in a connection interruption between entities. All the keys are generated by using the master key; hence, disclosure of the master key may cause forward secrecy [27]. In [28], the authors present an authentication protocol for an IoT-enabled smart home. The authors state that their protocol is secure and lightweight against numerous attacks.

However, Ref. [27] found that their protocol lacks confidentiality and resistance against a Denial-of-Service attack (DoS) and some known key attacks. Additionally, the communication and computation costs are very high, which is not recommended for a resource-limited environment such as a smart-home environment. Dey and Hossain [29] presented a protocol using a new security model for smart homes. Gaba et al. [27] said that their protocol is efficient in computation and communication cost lacks message freshness and cannot resist a known-key attack.

Kumar et al. [30] introduced a new authentication mechanism for an SH environment. In this scheme, the SK is created by utilizing a small token to achieve authentication and theusingntity. This protocol is secure against various well-known attacks and lightweight in terms of computation and communication costs. However, after analysis, it is evident that their protocol is vulnerable to time synchronization attacks, replay attacks, does not provide anonymity, and has unlink ability issues. Kumar et al. [31] presented a new improved protocol in which the session key is renewed continuously to resist replay attacks. However, their protocol’s computation and communication costs are still very high. Gope and Sikdar [32] introduced a new protocol and claim that it is secure against impersonation, traceability, and physical attacks. However, due to enormous use of hash operations and high communication complexities, their protocol is not recommended for smart-home environments.

Wazid et al. [33] presented a protocol for smart homes. In this study, the use of an XOR operation one-way hand function makes it accessible for smart sensors. In contrast, their scheme is susceptible to a stolen verifier attack because verifier table is stored on the GWN and is vulnerable to a synchronization attack because a time stamp is employed to stop a replay attack. Shuai et al. [34] presented a protocol using ECC for a smart-home environment. They eliminated the need of a verifier table for authentication. However, their protocol incurs high communication and computation costs, which is not recommended in a smart-home environment. Banerjee et al. [23] also proposed a scheme to secure smart-home environments. They stated that their scheme can bear well-known attacks but, in this study, it is shown that their scheme is prone to a stolen gateway node attack, a stolen verifier attack, a gateway node impersonation attack towards a smart device, a broadcast issue which causes inefficient resource utilization, a smart device impersonation and a parallel session attack, and a gateway node impersonation attack towards the user. In this study, a three-factor-based enhanced scheme is introduced to overcome the shortfalls.

4. Proposed Protocol

A lightweight and robust security protocol for smart-home environments (LR-AKAP) is presented, which not only withstands well-known active and passive attacks, but also attains the required functional qualities. The proposed protocol includes six processes: ($i)$ the initialization process, ($ii)$ the smart device enrolment process, ($iii)$ the gateway node enrolment process, ($iv)$ the user enrolment process, ($v)$ the login and authentication process, and ($vi)$ the password and biometric update process. Various notations used in this paper are listed in

Table 1. Notations guide.

Symbols	Representations
$I{D}_u,P{W}_u, Bi{o}_u$	$u^{\mathrm{th}}$ users biometric and password, user’s identity
$PI{D}_u$	Temporary identity of a user
$SD,SI{D}_d$	Smart sensor and its identity
$GWN,GI{D}_w$	Gateway node and its identity
$R_u,R_d$	Random numbers
$K$	$1024 \mathrm{b}$$\mathrm{it}-\mathrm{long} \sec \mathrm{ret} \mathrm{key} \mathrm{of} TA$
$S{K}_{du}\left(=S{K}_{ud}\right)$	$\mathrm{Session} \mathrm{key} \mathrm{between} U$$\mathrm{and} SD$
$h\left(.\right)$	Cryptographic one-way hash function
$T_u,T_{ta},T_w,T_d$	Current timestamps
$Gen\left(.\right),Rep\left(.\right)$	Fuzzy extractor probabilistic generation and deterministic reproduction function
$△T$	Maximum allowable transmission delay
$i\stackrel{?}{=}j$	$\mathrm{Checks} \mathrm{if} i$$\mathrm{equals} \mathrm{to} j$
$\left|\right|, \oplus$	Concatenation and bitwise XOR operators
$\mathcal{A},\mathcal{I},U_{\mathcal{A}}$	An adversary, intruder, and privileged insider

. The proposed architecture of the scheme is depicted in Figure 2.

4.1. Assumptions

The following are the assumptions which are taken into consideration to design the introduced protocol:

• The $GWN$ is trusted and there is no energy restriction. Nevertheless, the sensor nodes (smart devices) are powered by batteries, and they have very limited resources [35].
• An $\mathcal{A}$ may inaugurate only external attacks by employing powerful devices [36].
• The $GWN$ is under the user’s possession, and any wicked intruder cannot control it [37].

4.2. Adversarial Model

1.

A common adversarial model [17,18,19], Refs. [20,21,22] is considered in this article, where the adversary $\mathcal{A}$ has the subsequent capabilities:

2.

Public/open channel communication fully controlled by the T$\mathcal{A}$.

3.

$\mathcal{A}$ can detain, retransmit, and modify the old message. $\mathcal{A}$ can also cease or transmit a forged message.

4.

$\mathcal{A}$ can get the data saved in a smart card through power analysis [17,22].

5.

Any insider/privileged user or outsider can attempt to violate the privacy and security of the system.

6.

The private key of the $TA$ cannot be compromized.

4.3. Entities Involved in the Proposed Protocol

The network model is made up of four entities: smart device (SD) in the house, gateway node (GWN), end user (U), and trusted authoritie (TA). The smart devices are typically diverse and resource-constrained, and they may be utilized to allow a wide range of use cases including lighting control, surveillance systems, temperature management, and so on. The master node as a GWN installed in the house acts as a link between the user and smart gadgets. The users may remotely operate the various smart home gadgets based on their requirements. Others totally trust the TA’s processing and communication capabilities.

4.4. Proposed Protocol Processes

The proposed protocol is based on six phases as presented in the following subsections:

4.4.1. Initialization Process

In the initialization phase, the Trusted Authority $\left(TA\right)$ selects a private key $K$.

4.4.2. Smart Device Enrolment Process

$SD$ picks an identity $SI{D}_d$ and forwards to the $TA$. $TA$ computes $S_{GS}=h(SI{D}_d||K)$ and store $SI{D}_d$ in its own database describe in

Table 2. Proposed smart device enrollment process.

$\mathbf{Smart} \mathbf{Device} \left(\mathit{S}\mathit{D}\right)$	$\mathbf{Trusted} \mathbf{Authority} \left(\mathit{T}\mathit{A}\right)$
$\mathrm{Selects} \mathrm{an} \mathrm{identity} SI{D}_d$
$\stackrel{MS{G}_1=⟨SI{D}_d⟩}{\to }$
	$TA$ computes
	$S_{GS}=h(SI{D}_d||K)$
	$\mathrm{Store} SI{D}_d$ in own database.
	$\stackrel{MS{G}_2=⟨S_{GS}⟩}{\leftarrow }$
$\mathrm{Store} SI{D}_d,S_{GS}$ into memory.

.

4.4.3. Gateway Node Enrollment Process

Given blow

Table 3. Proposed gateway node enrollment process.

$\mathbf{Gateway} \mathbf{Node} \left(\mathit{G}\mathit{W}\mathit{N}\right)$	$\mathbf{Trusted} \mathbf{Authority} \left(\mathit{T}\mathit{A}\right)$
$\mathrm{Selects} \mathrm{an} \mathrm{identity} GI{D}_w$
$\stackrel{MS{G}_1=⟨GI{D}_w⟩}{\to }$
	$TA$ computes
	$N_w=h(GI{D}_w||K)$
	$\mathrm{Stores} GI{D}_w$ in own database.
	$\stackrel{MS{G}_2=⟨N_w⟩}{\leftarrow }$
$\mathrm{Store} N_w$ into memory.

 $GWN$ selects an identity $GI{D}_w$ and sends it to $TA$. $TA$ computes $N_w=h(GI{D}_w||K)$ and stores $GI{D}_w$ in its own database and sends $N_w$ to the $GWN$, which it stores in its own memory.

4.4.4. User Enrollment Process

The subsequent procedure is adopted to register a user with the system in

Table 4. Proposed user enrollment process.

$\mathbf{User} \left(\mathit{U}\right)$	$\mathbf{Trusted} \mathbf{Authority} \left(\mathit{T}\mathit{A}\right)$
$\mathrm{choose} I{D}_u$$\mathrm{and} P{W}_u$.
$HI{D}_u=h\left(I{D}_u\right)$
$\stackrel{MS{G}_1=⟨HI{D}_u⟩}{\to }$
	$\mathrm{Generate} R_{t1}$$, PI{D}_u\in {\mathcal{Z}}_p$.
	$\mathrm{Calculate} A_u=h\left(HI{D}_u\left|\left|R_{t1}\right|\right|K\right)$.
	$\mathrm{Save} \{PI{D}_u,\left\{A_u{\}}_{E_k}\right\}$ tuple in own DB.
	$\stackrel{MS{G}_2=⟨A_u,PI{D}_u⟩}{\leftarrow }$
$\left({\sigma }_u,{\tau }_u\right)=Gen\left(Bi{o}_u\right)$,
$A_u^{*}=A_u\oplus {\sigma }_u\oplus P{W}_u$,
$V_u=h\left(I{D}_u\left|\left|P{W}_u\right|\right|{\sigma }_u\right)\oplus {\sigma }_u$,
$PI{D}_u^{*}=PI{D}_u\oplus {\sigma }_u$.
$\mathrm{Replace} A_u,PI{D}_u$$\mathrm{with} A_u^{*},V_u,PI{D}_u^{*},h\left(.\right),Gen\left(.\right),Rep\left(.\right),{\tau }_u,t$
$\mathrm{in} SC$.

:

Step 1.

$U$ picks $I{D}_u$ and $P{W}_u$ and computes $HI{D}_u=h\left(I{D}_u\right)$ and sends $HI{D}_u$ to the $TA$.

Step 2.

$TA$ generates $R_{t1}$, $PI{D}_u\in {\mathcal{Z}}_p$ and calculates $A_u=h\left(HI{D}_u\left|\left|R_{t1}\right|\right|K\right)$. Save $\{PI{D}_u,\left\{A_u{\}}_{E_k}\right\}$ tuple in own database. Send $A_u$, $PI{D}_u$ to $U$ through private channel.

Step 3.

On getting $MS{G}_2$, $U$ computes $\left({\sigma }_u,{\tau }_u\right)=Gen\left(Bi{o}_u\right)$, $A_u^{*}=A_u\oplus {\sigma }_u\oplus P{W}_u$, $V_u=h\left(I{D}_u\left|\left|P{W}_u\right|\right|{\sigma }_u\right)\oplus {\sigma }_u$, $PI{D}_u^{*}=PI{D}_u\oplus {\sigma }_u$. $SC$ replaces $A_u,PI{D}_u$ with $A_u^{*},V_u,h\left(.\right),Gen\left(.\right),Rep\left(.\right),{\tau }_u,t$ in $SC$.

4.4.5. Login and Authentication Process

The login and authentication phase describe in

Table 5. Proposed login and authentication process.

$\mathbf{User} \left(\mathit{U}\right)$	$\mathbf{Trusted} \mathbf{Authority} \left(\mathit{T}\mathit{A}\right)$	$\mathbf{Gateway} \left(\mathit{G}\mathit{W}\mathit{N}\right)$	$\mathbf{Smart} \mathbf{Device} \left(\mathit{S}\mathit{D}\right)$
Insert SC, $\mathrm{Input} I{D}_u,P{W}_u,Bi{o}_u$, Calculate ${\sigma }_u=Rep\left(Bi{o}_u,{\tau }_u\right)$, $V_u\oplus {\sigma }_u\stackrel{?}{=}h\left(I{D}_u\left|\left|P{W}_u\right|\right|{\sigma }_u\right)$, $A_u=A_u^{*}\oplus {\sigma }_u\oplus P{W}_u$, $\mathrm{Choose} R_u\in {\mathcal{Z}}_p^{*}$$\mathrm{and} T_u$, $A_u^{**}=h(A_u||T_u)$, $PI{D}_u=PI{D}_u^{*}\oplus {\sigma }_u$, $SI{D}_d^{*}=SI{D}_d\oplus A_u\oplus R_u$, $R_u^{*}=R_u\oplus A_u$.
$\stackrel{MS{G}_1=⟨R_u^{*},SI{D}_d^{*},PI{D}_u,A_u^{**},T_u⟩}{\to }$
	$\mathrm{Check} \mathrm{if} \left|T_u-T_c\le \delta T\right|$ $\mathrm{Search} PI{D}_u$ in database. If exists, $\mathrm{then} \mathrm{fetch} \mathrm{related} {\left\{A_u\right\}}_{E_k}$, $A_u={\left\{A_u\right\}}_{D_k}$. $\mathrm{If} A_u^{**}\stackrel{?}{=}h(A_u||T_u)$ true, continue.
	$\mathrm{Select} PI{D}_u^{new}\in {\mathcal{Z}}_p$$\mathrm{and} T_{ta}$, $\mathrm{Replace} PI{D}_u$$\mathrm{with} PI{D}_u^{new}$ and compute $W_t=h(h(SI{D}_d\left|\right|K)\left|\left|PI{D}_u^{new}\right|\right|T_{ta})$  $V_t=h(N_w\left|\left|GI{D}_w\right|\right|PI{D}_u^{new}||T_{ta})$, $R_u=R_u^{*}\oplus A_u$, $R_u^{**}=R_u\oplus W_t$, $X_t=W_t\oplus N_w$. $\stackrel{MS{G}_2=⟨R_u^{**},V_t,X_t,PI{D}_u^{new},SI{D}_d,GI{D}_w,T_{ta}⟩}{\to }$ $\stackrel{MS{G}_3=⟨PI{D}_u^{new}⟩}{\leftarrow }$
		$\mathrm{Check} \mathrm{if} \left|T_{ta}-T_c\le \delta T\right|$ $V_t\stackrel{?}{=}h(N_w\left|\left|GI{D}_w\right|\right|PI{D}_u^{new}||T_{ta})$, $\mathrm{Create} \mathrm{timestamp} T_w$, $W_t=X_t\oplus N_w$, $V_w=h\left(SI{D}_d\left|\left|W_t\right|\right|T_w\right)$. $\stackrel{MS{G}_4=⟨R_u^{**},V_w,PI{D}_u^{new},SI{D}_d,T_{ta},T_w⟩}{\to }$
		$\mathrm{Check} \mathrm{if} \left|T_w-T_c\le \delta T\right|$ $\mathrm{Select} R_d\in {\mathcal{Z}}_p$$\mathrm{and} T_d$, $W_t^{*}=h\left(S_{GS}\left|\left|PI{D}_u^{new}\right|\right|T_{ta}\right)),$ $V_w\stackrel{?}{=}h\left(SI{D}_d\left|\left|W_t^{*}\right|\right|T_w\right),$ $R_u=R_u^{**}\oplus h(S_{GS}||T_{ta})$, $S{K}_{du}=h\left(R_u\left|\left|R_d\right|\right|PI{D}_u^{new}\left|\left|SI{D}_d\right|\right|T_d\right)$, $R_d^{*}=R_u\oplus R_d$, $V_d=h(S{K}_{du}||T_d)$. $X_d=h(W_t^{*}||T_d)$. $\stackrel{MS{G}_5=⟨V_d,X_d,R_d^{*},T_d⟩}{\leftarrow }$
		$\mathrm{Check} \mathrm{if} \left|T_d-T_c\le \delta T\right|$, $X_d\stackrel{?}{=}h(W_t||T_d)$ if true. $\mathrm{Select} \mathrm{timestamp} T_w^{*}$, $\stackrel{MS{G}_6=⟨V_d,R_d^{*},T_d,T_w^{*}⟩}{\leftarrow }$
$\mathrm{Check} \mathrm{if} \left|T_w^{*}-T_c\le \delta T\right|$  $PI{D}_u^{**}=PI{D}_u^{*}\oplus PI{D}_u\oplus PI{D}_u^{new}$  $\mathrm{Replace} PI{D}_u^{*}$$\mathrm{with} PI{D}_u^{**}$  $R_d=R_u\oplus R_d^{*}$, $S{K}_{ud}=h\left(R_u\left|\left|R_d\right|\right|PI{D}_u^{new}\left|\left|SI{D}_d\right|\right|T_d\right)$, $V_d\stackrel{?}{=}h(S{K}_{ud}||T_d)$.
$U and SD both Save the session-key S{K}_{ud}\left(=S{K}_{du}\right)$

includes the following steps:

Step 1.

Insert SC and input $I{D}_u,P{W}_u,Bi{o}_u$. Calculate ${\sigma }_u=Rep\left(Bi{o}_u,{\tau }_u\right)$ and check whether $V_u\oplus {\sigma }_u\stackrel{?}{=}h\left(I{D}_u\left|\left|P{W}_u\right|\right|{\sigma }_u\right)$; if true, further compute $A_u=A_u^{*}\oplus {\sigma }_u\oplus P{W}_u$. $SC$ chooses $R_u\in {\mathcal{Z}}_p$ and $T_u$ and computes $A_u^{**}=h(A_u||T_u)$, $PI{D}_u=PI{D}_u^{*}\oplus {\sigma }_u$, $SI{D}_d^{*}=SI{D}_d\oplus A_u\oplus R_u$, $R_u^{*}=R_u\oplus A_u$. Sends $MS{G}_1=⟨R_u^{*},SI{D}_d^{*},PI{D}_u,A_u^{**},T_u⟩$ to $TA$ by public channel.

Step 2.

First of all, $TA$ verifies the timeliness of the timestamp by inspecting the condition $\left|T_u-T_c\le \delta T\right|$, if so, searches $PI{D}_u$ in database, if it exists, then fetches related ${\left\{A_u\right\}}_{E_k}$ and computes $A_u={\left\{A_u\right\}}_{D_k}$ and checks if $A_u^{**}\stackrel{?}{=}h(A_u||T_u)$, and if true, then selects $PI{D}_u^{new}\in {\mathcal{Z}}_p$ and $T_{ta}$, replaces the $PI{D}_u$ with $PI{D}_u^{new}$, and computes $W_t=h(h(SI{D}_d\left|\right|K)\left|\left|PI{D}_u^{new}\right|\right|T_{ta})$, $V_t=h(N_w\left|\left|GI{D}_w\right|\right|PI{D}_u^{new}||T_{ta})$, $R_u=R_u^{*}\oplus A_u$, $R_u^{**}=R_u\oplus W_t$, $X_t=W_t\oplus N_w$. Sends message $MS{G}_2=⟨R_u^{**},V_t,X_t,PI{D}_u^{new},SI{D}_d,GI{D}_w,T_{ta}⟩$ to $GWN$ through public channel. Also sends $MS{G}_3=⟨PI{D}_u^{new}⟩$ back to $U$ via open channel.

Step 3.

$GWN$ gets the $MS{G}_2$ from $TA$ and checks if $\left|T_{ta}-T_c\le \delta T\right|$, if true, computes $V_t\stackrel{?}{=}h(N_w\left|\left|GI{D}_w\right|\right|PI{D}_u^{new}||T_{ta})$, created timestamp $T_w$, and computed $W_t=X_t\oplus N_w$, $V_w=h\left(SI{D}_d\left|\left|W_t\right|\right|T_w\right)$. At the end, send message to the $SD$ message $MS{G}_4=⟨R_u^{**},V_w,PI{D}_u^{new},SI{D}_d,T_{ta},T_w⟩$ to $SD$ via open/insecure channel.

Step 4.

$SD$ verifies the freshness of $MS{G}_4$ by examining the condition $\left|T_w-T_c\le \delta T\right|$. If true, it selects $R_d\in {\mathcal{Z}}_p$ and $T_d$, checks if $V_w\stackrel{?}{=}h\left(SI{D}_d\left|\left|h\left(S_{GS}\left|\left|PI{D}_u^{new}\right|\right|T_{ta}\right)\right|\right|T_w\right),$ if true, then computes $R_u=R_u^{**}\oplus h(S_{GS}||T_{ta})$, $S{K}_{du}=h\left(R_u\left|\left|R_d\right|\right|PI{D}_u^{new}\left|\left|SI{D}_d\right|\right|T_d\right)$, $R_d^{*}=R_u\oplus R_d$, $V_d=h(S{K}_{du}||T_d)$, $X_d=h(W_t^{*}||T_d)$. At the end, sends the message $MS{G}_5=⟨V_d,X_d,R_d^{*},T_d⟩$ to $GWN$ by public/insecure channel.

Step 5.

$GWN$ examines the freshness of the message by inspecting the condition $\left|T_d-T_c\le \delta T\right|$, and if the condition is true, $GWN$ selects timestamp $T_w^{*}$ and sends the $MS{G}_6=⟨V_d,R_d^{*},T_d,T_w^{*}⟩$ to $U$ via open channel.

Step 6.

Upon getting the $MS{G}_6$, $U$ validates message freshness through condition $\left|T_w^{*}-T_c\le \delta T\right|$. If true, compute $PI{D}_u^{**}=PI{D}_u^{*}\oplus PI{D}_u\oplus PI{D}_u^{new}$, replace $PI{D}_u^{*}$ with $PI{D}_u^{**}$, $R_d=R_u\oplus R_d^{*}$, $S{K}_{ud}=h\left(R_u\left|\left|R_d\right|\right|PI{D}_u^{new}\left|\left|SI{D}_d\right|\right|T_d\right)$. $V_d\stackrel{?}{=}h(S{K}_{ud}||T_d)$, if true, the session key is saved for secure communication.

4.4.6. Biometric and Password Update Process

A registered user can update a biometric/password. To do so, the user needs to login first as described in the “Login and authentication process”. After a successful login, the user will adopt the subsequent procedure to update his/her biometric/password:

Step 1.

User will be prompted to enter a new password $P{W}_u^{new}$ biometric $Bi{o}_u^{new}$.

Step 2.

$SC$ will compute $\left({\sigma }_u^{new},{\tau }_u^{new}\right)=Gen\left(Bi{o}_u^{new}\right)$, $A_u^{new}=\left(A_u^{*}\oplus {\sigma }_u^{old}\oplus P{W}_u^{old}\right)\oplus \left({\sigma }_u^{new}\oplus P{W}_u^{new}\right)=A_u\oplus {\sigma }_u^{new}\oplus P{W}_u^{new}$, $V_u^{new}=\left(V_u\oplus h\left(I{D}_u\left|\left|P{W}_u^{old}\right|\right|{\sigma }_u^{old}\right)\oplus {\sigma }_u^{old}\right)\oplus \left(h\left(I{D}_u\left|\left|P{W}_u^{new}\right|\right|{\sigma }_u^{new}\right)\oplus {\sigma }_u^{new}\right)=V_u\oplus h\left(I{D}_u\left|\left|P{W}_u^{new}\right|\right|{\sigma }_u^{new}\right)\oplus {\sigma }_u^{new}$, $PI{D}_u^{new}=PI{D}_u^{*}\oplus {\sigma }_u^{old}\oplus {\sigma }_u^{new}$.

Step 3.

Finally, $SC$ will replace $A_u^{*},V_u,PI{D}_u^{*},{\tau }_u$ with $A_u^{new},V_u^{new},PI{D}_u^{new},{\tau }_u^{new}$.

5. Security Analysis

In the subsequent subsection, formal and informal security analyses for our proposed protocol are performed.

5.1. Informal Security Analysis

The introduced protocol is secure against well-known attacks as presented in the successive subsections:

5.1.1. Replay Attack

In the introduced protocol, timestamps $T_u,T_{ta},T_w,T_d$ and random numbers $R_u,R_d$ are employed to ensure that the introduced protocol is secure from replay attack. Hence, the replay message will be detected if a timestamp is expired, or a random/arbitrary number is inconsistent. So, a replay attack cannot be launched upon the introduced scheme.

5.1.2. Session Key Freshness Property

In the introduced protocol, a session key is constructed by some distinct identities, random numbers, and timestamps, and for each session, random numbers $R_u,R_d$ are unique. Hence, a novel key for every session ensures the key’s freshness.

5.1.3. User Anonymity and Untraceability

In the introduced protocol, the user identity is not shared even with the $TA$. Additionally, if an attacker tries to capture messages $MS{G}_1,MS{G}_2,MS{G}_3,MS{G}_4,MS{G}_5,MS{G}_6$, none of these messages utter any information about the user. Furthermore, the attacker will not be able to extract from the smart card, because he/she will need a password and a biometric to extract the password, and it is also wrapped by hash a function. In addition, in each session, all the values are unique as they are composed of random numbers, and consequently, they are novel for each authentication session. Hence, an adversary will not be able to recognize any specific user or the location of any specific user. Hence, the introduced protocol ensures the anonymity and untraceability of valid user.

5.1.4. Smart Card Stolen Attack

Assume an attacker steals an authorized user’s smart card or it is mishandled and discovered by an attacker, allowing him/her to get any sensitive data from the $SC$. An attacker can extract information $A_u^{*},V_u,PI{D}_u^{*},{\tau }_u,t$ from the $SC$. But to attain any confidential information from the $SC$, an attacker needs the information of $I{D}_u$, $P{W}_u$, and ${\sigma }_u$, and these values are unknown to $\mathcal{A}$. Hence, in the introduced protocol, a stolen $SC$ attack is not conceivable.

5.1.5. Impersonation Attack

If an attacker tries to imitate a $U$, $GWN$, or $SD$ towards any other legal participant, to do so, a valid request messages is required. To impersonate as a $U$, $\mathcal{A}$ tries to create a login request message $MS{G}_1=R_u^{*},SI{D}_d^{*},PI{D}_u,A_u^{**},T_u$. However, the attacker cannot generate a true login message because it necessitates the information of $R_u,A_u$. Therefore, the introduced protocol can resist an impersonation attack.

5.1.6. Man-in-the-Middle Attack

Assume an attacker seizes the message and tries to modify a login request or any other message transferring over the public channel. To do this, the attacker requires the knowledge of secret parameters as described in Section 5.1.5. Therefore, the introduced scheme can withstand this attack.

5.1.7. Perfect Forward Secrecy

The shared session key in the introduced protocol includes random nonces included by both $U$ and $SD$. So, if the private key $K$ is in the knowledge of the adversary, he/she still cannot produce previously shared session keys. Hence, the introduced protocol has the feature of perfect forward secrecy.

5.2. AVISPA Tool Based Automated Formal Security Analysis

AVISPA, a tool relying on the Dolev–Yao threat model, was introduced by Armando et al. [38]. In this situation, the attacker can edit, transmit, and alter messages. This tool is well-accepted for assessing various security protocols. AVISPA uses a “high level protocol specification language (HLPSL)” to describe and design security protocols. The HLPSL requirements are broken down into roles. During the execution of a protocol, several roles are utilized to express the activities of a single agent. Each agent performs a specific role throughout the execution of a protocol. HLPSL’s main objective is to verify security properties including message, agent secrecy and authentication. The security protocol is considered to determine its level of security considering the predetermined objectives.

5.2.1. AVISPA Model Checkers

• On-the-fly model checker (OFMC): OFMC uses lazy data types to develop an efficient on-the-fly model for security protocols with limitless state spaces.
• Constraint-logic-based attack searcher (CL-AtSe): The input of (CL-AtSe) is a protocol stated as a set of restrictions that help identify security protocol assaults in the form of a collection of rewriting rules (IF format).
• SAT-based model checker (SATMC): Depending on the transitional state of the IF specification, creates a propositional formula. According to the propositional formula, every violation of security that might result in an attack is considered.
• “Tree automata-based on automatic approximations for the analysis of security protocols“ (TA4SP) model checker: By accurately estimating the attacker’s capabilities, it exposes the protocol’s weakness and predicts its accuracy.

5.2.2. AVISPA Simulation Steps

Automated validation of the protocol was carried out to demonstrate that the introduced protocol could resist reply and man-in-the-middle attacks. The subsequent steps were executed to simulate our protocol in AVISPA:

• Firstly, the scheme was implemented through High-Level Protocols Specification Language (HLPSL) [33], next, the HLPSL2IF translator was employed to interpret HLPSL into Intermediate Format (IF).
• Additionally, to declare that whether protocol was safe or not, the interpreted IF was provided in Output Format (OF). The HLPSL role specification for the user, smart device, trusted authority and gateway node are depicted in Figure 3, Figure 4, Figure 5 and Figure 6, respectively.

5.2.3. Simulation Details

Setting simulated security goals is the first step in building the HLPSL script for our scheme. Our major goal was to keep certain values, such as $\{S{K}_{uita}, K, R_u, R_d, R_t\}$, secret. Furthermore, we defined the six roles, which are: (1) the trusted authority’s role, (2) the user’s role, (3) the gateway node’s role, (4) the smart device’s role, (5) the role session that combines the basic roles (role_TA, role_USERS, role_GWN, and role_SD), (6) the role environment that incorporates numerous sessions and consists of functions and global variables and outlines the security goals of the protocol.

Figure 3. Role specification for the user.

Figure 3. Role specification for the user.

In Figure 3, the requirement for the role_User that is executed by the user is illustrated. In this role, the $U_u$ knows every agent $\left(GWN, SD, TA\right)$ and the symmetric-key $S{K}_{uita}$ that is joint among the $U_u$, $TA$, the hash function $H\left(.\right)$, and the Dolev–Yao $dy$ model-based send/receive channels $\left(SND,RCV\right)$. To start the protocol, $U_u$ receives a start message $\left(RCV\left(start\right)\right)$ as an indication at the first state (state 0). To register, $U_u$ creates the identity $I{D}_u$ and retransmits $HI{D}_u^{\prime }$ after being encrypted with $S{K}_{uita}$ to the $TA$. $U_u$ gets $H\left(H\left(HI{D}_u\left|\left|R_t^{\prime }\right|\right|K\right)\right)$ and $PI{D}_u^{\prime }$ encrypted with $S{K}_{uita}$ coming from the $TA$, and the registration process is completed. Next, $U_u$ generates some fresh nonces $\left\{R_u^{\prime },T_u^{\prime }\right\}$ and computes $\left\{A_u^{\prime },A_{u2}^{\prime },SI{D}_d^{\prime }\right\}$. Next, $U_u$ transmits $\left\{R_{u1}^{\prime },SI{D}_d^{\prime },PI{D}_u^{\prime },A_{u2}^{\prime },T_u^{\prime }\right\}$ to $TA$ and receives a message from the $TA$ containing $PI{D}_{unew}^{\prime }$. $U_u$ receives the message $\{H\left(H\left(R_u.R_d^{\prime }.PI{D}_{unew}.SI{D}_d.T_d^{\prime }\right).T_d^{\prime }\right).xor\left(R_u,R_d^{\prime }\right).PI{D}_{unew}.T_d^{\prime }.T_{w1}^{\prime }\}$ coming from the $SD$ at the next transition. Figure 4. demonstrates the specification for the role_SD which is played by the $SD$. In this role, the $SD$ recognizes all the agents $\left(U_i, TA, GWN\right)$, the symmetric-key $S_{GS}$ which is shared among the $SD$ and the $TA$, the hash function $H\left(.\right)$, and the Dolev–Yao-model-based send/receive channels $\left(SND, RSV\right)$.

Figure 4. Role specification for a smart device.

Figure 4. Role specification for a smart device.

Figure 5 explains the requirement for role_TA, which is executed by the $TA.$ The $TA$ knows every single agent $\left(U_u, SD, GWN\right)$, the symmetric-key $S{K}_{uita}$, $S_{GS}$, and $N_w$ which are common among the $U_u$ and the $TA$, $SD,$ and $TA$, and among $GWN$ and $TA$, respectively. Furthermore, $TA$ has the knowledge of the $H\left(.\right)$ and Dolev–Yao-model-based send/receive channels $\left(SND, RSV\right)$. The remaining part of the requirement defines the various states of the protocol implemented by the TA. Figure 6 displays the specification for role_GWN that is played by the $GWN$. $GWN$ identifies all the agents $\left(U_u, SD, TA\right)$, the symmetric-key $N_w$ that is shared amongst the $GWN$ and the $TA$, the $H\left(.\right)$, and Dolev–Yao-model-based send/receive channels $\left(SND, RSV\right)$.

Figure 5. Role specification for TA.

Figure 5. Role specification for TA.

Figure 6. Role specification for GWN.

Figure 6. Role specification for GWN.

Session, environment, and goal roles’ specifications are depicted in Figure 7. In the session role, all roles (role_TA, role_USERS, role_SD, role_GWN) are combined. More than one session is started from the environment role. The constants (ta, users, gwn, sd) represents the agents $\left(TA,USERS,GWN,SD\right)$, respectively. The symmetric key shared among the $TA$ and $U_u$ is presented by $S{K}_{uita}$. The hash function $H$ is presented by the constant $h$. The applicable parameters that are supposed to be known by the intruder are defined in the intruder knowledge part. We undertake that the intruder has the knowledge of all the agents $\left(USERS, TA, GWN, SD\right)$. The simulation objectives are declared with the help of goal keywords: We are concerned about verifying the secrecy of the subsequent parameters: $R\_u, R\_t, R\_d, K$.

5.2.4. Simulation Result

Simulation outcomes depicted in Figure 8 and Figure 9 revealed that the introduced protocol was according to the design specifications and could hold out against replay and man-in-the-middle attacks. Based on the AVISPA backend model checker, OFMC and CL-AtSe simulation results are presented. With depth $8$ piles in $0.72$ s, $198$ nodes were scrutinized in the OFMC backend. The CL-AtSe backend inspected $0$ states, the computation and interpretation consumed for the backend were $0.08$ s and $0.00$ s, respectively.

6. Comparative Analysis

This section provides the comparison of our proposed protocol with the existing protocols, which includes those of Banerjee et al. [23], Shuai et al. [34], Yu and Li [39], Naoui et al. [40], Fakroon et al. [41], and Dey and Hossain [29].

6.1. Functionality Comparison

The functionality analysis was performed with respect to the existing and proposed protocols as presented

Table 6. Comparison of functionality features.

	[23]	[29]	[34]	[39]	[40]	[41]	Our
Fua	✓	×	✓	✓	✓	✓	✓
Fsna	✓	×	✓	✓	✓	✓	✓
Fu	✓	×	✓	✓	✓	✓	✓
Fpara	✓	✓	✓	✓	✓	✓	✓
Fsas	✓	×	✓	✓	✓	✓	✓
Fra	✓	×	×	✓	×	×	✓
Ffopga	✓	−	×	✓	×	×	✓
Fsia	✓	−	×	✓	×	×	✓
Fepd	×	✓	✓	✓	✓	✓	✓
Frpca	✓	−	×	✓	×	✓	✓
F3fa	✓	×	×	✓	×	×	✓
Fpska	×	×	×	✓	×	✓	✓
Fsgvvn	×	✓	✓	✓	✓	✓	✓
Fsva	×	✓	✓	✓	✓	✓	✓
Fuia	×	✓	✓	✓	✓	✓	✓
Fgwn	×	✓	✓	✓	✓	✓	✓
Fsdi	×	✓	✓	✓	✓	✓	✓
Fgwnia	×	✓	✓	✓	✓	✓	✓
Ffasv	✓	✓	✓	×	✓	✓	✓

Note: Fua: user anonymity; Fsna: sensor node anonymity; Fu: untraceability; Fpara: protection against reply attack; Fsas: secure against stolen smart-card attack; Fra: resilience against ESL attack under the CK-adversary model; Fopga: offline password guessing attack; Fsia: smart-card impersonation attack; Fepd: efficient protocol design; Frpca: resist password change attack; F3fa: three-factor authentication; Fpska: parallel session key attack; Fsgvvn: stolen GvVN attack; Fsva: stolen verifier attack; Fuia: user impersonation attack; Fgwn: GWN impersonation attack towards smart device; Fsdi: smart device impersonation; Fgwnia: GWN impersonation attack towards user; Ffasv: formal automated security verification.

. As per comparison, the proposed protocol rendered superior security along with enhanced security features in contrast to those of [23] and other compared protocols. Here, $F_n$ is the $n^{\mathrm{th}}$ compared feature/security requirement, $✓$ shows that the specified parameter exists in this study, and the protocol can resist an attack. Moreover, $\times$ presents whether the protocol is not able to resist an attack or lacks a specific feature, whereas the − sign shows that a certain security/feature requirement is not applicable.

6.2. Comparison of Communication Overhead

In

Table 7. Communication cost comparison.

Protocol	# of Messages	# of Bytes
[23]	4	(68 + 40 + 56 + 72) = 236
[29]	5	(132 + 132 + 52 + 52 + 52) = 420
[34]	4	(132 + 64 + 40 + 68) = 304
[39]	8	(84 + 124 + 164 + 164) × 2 = 1072
[40]	3	(104 + 52 + 56) = 212
[41]	4	(100 + 52 + 52 + 84) = 288
Our	6	(76 + 112 + 16 + 72 + 60 + 44) = 380

, the communication expenses estimate is presented. In order to compare, the sizes of various parameters taken were as follows: identities were considered as $128$ bits, a timestamp was $32$ bits, random nonces were $128$ bits, a hash digest was $160$ bits (if SHA-1 is employed [42]), cost for ECC point was $\left(160+160\right)=320$ bits, and size of symmetric enc/decryption block was $128$ bits [43,44], respectively.

The communication cost of $M_{sg1}=⟨{\overline{R}}_u^{*},SI{D}_d^{*},PI{D}_u,A_u^{**},T_u⟩$ was $⟨128+128+128+160+32⟩=608$ bits, $M_{sg2}=⟨R_u^{**},V_t,X_t,PI{D}_u^{new},SI{D}_d,GI{D}_w,T_{ta}⟩$ was $⟨160+160+160+128+128+128+32⟩=896$ bits, $M_{sg3}=⟨PI{D}_u^{new}⟩$ was $832$ bits, $M_{sg4}=⟨R_u^{**},V_w,PI{D}_u^{new},SI{D}_d,T_{ta},T_w⟩$ was $⟨128+160+128+128+32+32⟩=576$ bits, $M_{sg5}=⟨V_d,X_d,R_d^{*},T_d⟩$ is $⟨160+160+128+32⟩=480$ bits, and cost for $M_{sg6}=⟨V_d,R_d^{*},T_d,T_w^{*}⟩$ was $⟨160+128+32+32=352⟩$ bits. Summing all these, the total cost of communication of the introduced protocol through the login and authentication phase becomes $380$ bytes. In addition, Table 7 shows that the communication cost of the introduced protocol was less than that of those in comparison [39,42] and slightly higher than that of [23,34,40,41], but this is justifiable as the introduced protocol provides better security than these other protocols do. Figure 10 also depicts the communication cost of our proposed protocol.

6.3. Computation Overhead Comparison

This section compares the computation cost of different protocols.

Table 8. Approximate computation time of various operations.

Notation	Operation	Mobile Device	Gateway/TA	Smart Device
$T_h$	Hash function	0.009	$0.004$	0.006
$T_{ecm}$	ECC multiplication	5.116	0.926	4.107
$T_{sym}$	Symmetric enc/dec	0.017	0.008	0.013
$T_{bp}$	bilinear pairing	17.36	$4.038$	12.52

shows the approximate computation times expected for different cryptographic procedures and their notations. Based on a real-time environment, an experiment was conducted over a smartphone using MIRACL Library. The smartphone Redmi Note 8 presented as a mobile/user device with the specification of Octa-core Max 2.01 GHz processor, 4 GB RAM, MIUI version 11.0.7, and the underlying Android version was 9. For GSS, over the Ubuntu 16.0 LTS operating system, an HP EliteBook 8460P with 4 GB RAM and an Intel Core i7-2620 M 2.7 GHz processor was used. Additionally, to replicate the smart devices, a Pi3 B+ with Cortex-A53(ARMv8) 64-bit SoC @ 1.4 GHz processor and 1 GB LPDDR2 SDRAM RAM was used. The simulation results on each device are given in Table 8, which shows the approximate computation times expected for different cryptographic procedures in ms and their notations [45]. We assumed here that $T_{fe}\approx T_{ecm}$.

As represented in

Table 9. Computation cost comparison.

Protocol	$\mathit{U}$	$\mathit{T}\mathit{A}/\mathit{R}\mathit{A}$	$\mathit{G}\mathit{W}\mathit{N}$	$\mathit{S}\mathit{D}$	Total Cost
[23]	$10T_h+1T_{fe}$	$-$	$10T_h$	$4T_h$	$24T_h+1T_{fe}$
	≈5.206 ms	−	≈0.04 ms	≈0.024 ms	≈5.27 ms
[34]	$6T_h+1T_{ecm}$	$-$	$7T_h+1T_{ecm}$	$3T_h$	$16T_h+3T_{ecm}$
	≈5.17 ms	−	≈5.114 ms	≈0.018 ms	≈10.302 ms
[39]	$7T_h+14T_{ecm}$	$-$	$12T_h+19T_{ecm}+4T_{bp}$	$7T_h+14T_{ecm}$	$26T_h+47T_{ecm}+4T_{bp}$
	≈71.687 ms	−	≈33.794 ms	≈57.54 ms	≈163.021 ms
[40]	$12T_h+3T_{sym}+2T_{ecm}$	$-$	$13T_h+4T_{sym}+2T_{ecm}$	$1T_h+1T_{sym}$	$26T_h+7T_{sym}+4T_{ecm}$
	≈10.391 ms	−	≈1.936 ms	≈0.019 ms	≈12.346 ms
[41]	$4T_h$	$-$	$5T_h$	$24T_h$	$33T_h$
	≈0.036 ms	−	≈0.02 ms	≈0.144 ms	≈0.2 ms
[29]	$4T_h+2T_{ecm}+3T_{sym}$	$-$	$-$	$3T_h+2T_{ecm}+3T_{sym}$	$7T_h+4T_{ecm}+6T_{sym}$
	≈10.319 ms	−	−	≈8.271 ms	≈18.59 ms
Our	$1T_{fe}+4T_h$	$1T_{sym}+4T_h$	$3T_h$	$6T_h$	$1T_{fe}+15T_h+1T_{sym}$
	5.152 ms	≈0.024 ms	≈0.012 ms	≈0.036 ms	≈5.224 ms

, the computation cost of the proposed protocol is a bit high as compared to those of [23,41]. However, it is justified when compared to the security provided by the introduced protocol, as it is shown in Table 6 that these protocols lack some security features. Figure 11 also depicts the computation cost of the introduced protocol.

7. Conclusions

The Internet of Things (IoT) is turning into the mainstream with each passing day. Applications of the IoT are not limited to only military or industrial use; nowadays, the IoT is employed in homes, agriculture, and even in the medical field. IoT privacy and security issues gradually increase. To subdue the privacy and security issues related to smart homes, various schemes have been introduced and claimed as robust and with anonymous authentication protocols for a smart-home environment. In this paper, we introduced a protocol to overcome the vulnerabilities found in a previous protocol. In the introduced protocol, no parameters are stored in the verifier table whose disclosure can lead to system compromise, a $TA$ is also included to authenticate the users, and a broadcasting issue is also mitigated to improve resource utilization. Security and comparative analyses of the introduced protocol were performed to show that the introduced protocol was secure and provided better security features with low communication and computation costs. Authentication schemes for a smart-home environment should be lightweight and secure. Many schemes proposed earlier are lightweight but not secure because in achieving lightweight features they neglect security. Similarly, some schemes are more secure but not lightweight, which is undesirable for a smart-home environment. Hence, there is a need to work on both factors at the same time.