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

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.


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 2 ) 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 ( ), (ii) a trusted authority ( ), (iii) a gateway node ( ), and (iv) smart devices ( ). The s have limited resources and can be used for various tasks such as controlling the temperature, turning on lights [20], etc. The is used as an access point and has enough computation power; it acts as a gateway for and . The is trusted by all the parties involved in the communication. The responsibilities he 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.  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.

Motivations and Contributions
This section concisely presents the primary contributions of this study:

1.
We suggested an authentication protocol based on a symmetric key to protect the usersmart device connection. The system was created using a mobile device, biometrics, and a password.

2.
The security of the proposed work was analyzed by using an automated security tool AVISPA.

3.
The analysis showed that the suggested system could withstand known attacks and offered an excellent balance between security and effectiveness. 4.
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.

5.
The proposed protocol evaded the clock synchronization issue in timestamp-based two-way authentication protocols. 6.
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.

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 smarthome 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.

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. The proposed architecture of the scheme is depicted in Figure 2.

Symbols Representations
ID u , PW u , Bio u u th users biometric and password, user's identity PID u Temporary identity of a user SD, SID d Smart sensor and its identity GW N, GID w Gateway node and its identity R u , R d Random numbers K 1024 bit − long sec ret key of TA SK du (= SK ud ) Session key between U and SD h(.) Cryptographic one-way hash function T u , T ta , T w , T d Current timestamps  [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.

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: ( ) the initialization process, ( ) the smart device enrolment process, ( ) the gateway node enrolment process, ( ) the user enrolment process, ( ) the login and authentication process, and ( ) the password and biometric update process. Various notations used in this paper are listed in Table 1. The proposed architecture of the scheme is depicted in Figure 2.

Symbols
Representations , , users biometric and password, user's identity Temporary identity of a user

Assumptions
The following are the assumptions which are taken into consideration to design the introduced protocol: The GW N 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].

2.
An A may inaugurate only external attacks by employing powerful devices [36].

3.
The GW N is under the user's possession, and any wicked intruder cannot control it [37].

3.
A can detain, retransmit, and modify the old message. A can also cease or transmit a forged message.

4.
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.

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.

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

Initialization Process
In the initialization phase, the Trusted Authority (TA) selects a private key K.

Smart Device Enrolment Process
SD picks an identity SID d and forwards to the TA. TA computes S GS = h(SID d ||K) and store SID d in its own database describe in Table 2. Table 2. Proposed smart device enrollment process.

Smart Device (SD) Trusted Authority (TA)
Selects an identity SID d

Gateway Node Enrollment Process
Given blow Table 3 GW N selects an identity GID w and sends it to TA. TA computes N w = h(GID w ||K) and stores GID w in its own database and sends N w to the GW N, which it stores in its own memory. Table 3. Proposed gateway node enrollment process.

Gateway Node (GWN) Trusted Authority (TA)
Selects an identity GID w

User Enrollment Process
The subsequent procedure is adopted to register a user with the system in Table 4: Step 1. U picks ID u and PW u and computes H ID u = h(ID u ) and sends H ID u to the TA.
Step 2. TA generates R t1 , PID u ∈ Z p and calculates Step 3. On getting Table 4. Proposed user enrollment process.

User (U) Trusted Authority (TA)
choose ID u and PW u .

Login and Authentication Process
The login and authentication phase describe in Table 5 includes the following steps: Step 1. Insert SC and input ID u , PW u , Bio u . Calculate σ u = Rep(Bio u , τ u ) and check Step 2. First of all, TA verifies the timeliness of the timestamp by inspecting the condi- = h(A u T u ) , and if true, then selects PID new u ∈ Z p and T ta , replaces the PID u with PID new u , and computes Step 3. GW N gets the MSG 2 from TA and checks if |T ta − T c ≤ δT|, if true, computes At the end, sends the message GW N examines the freshness of the message by inspecting the condition |T d − T c ≤ δT|, and if the condition is true, GW N selects timestamp T * w and sends the Step 6. Upon getting the MSG 6 , U validates message freshness through condition , if true, the session key is saved for secure communication. Table 5. Proposed login and authentication process.

User (U) Trusted Authority (TA) Gateway (GWN) Smart Device (SD)
U and SD both Save the session − key SK ud (= SK du )

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 PW new u biometric Bio new u .

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

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

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.

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.

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 MSG 1 , MSG 2 , MSG 3 , MSG 4 , MSG 5 , MSG 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.

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 , PID * u , τ u , t from the SC. But to attain any confidential information from the SC, an attacker needs the information of ID u , PW u , and σ u , and these values are unknown to A. Hence, in the introduced protocol, a stolen SC attack is not conceivable.

Impersonation Attack
If an attacker tries to imitate a U, GW N, or SD towards any other legal participant, to do so, a valid request messages is required. To impersonate as a U, A tries to create a login request message MSG 1 = R * u , SID * d , PID 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.

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.

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.

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.

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

3.
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. 4.
"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.

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:

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

2.
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 Figures 3-6, respectively.

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 {SK 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. 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. In Figure 3, the requirement for the role_User that is executed by the user is illustrated. In this role, the knows every agent ( , , ) and the symmetric-key that is joint among the , , the hash function (. ), and the Dolev-Yao model-based send/receive channels ( ,  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 (GW N, SD, TA) and the symmetric-key SK uita that is joint among the U u , TA, the hash function H(.), and the Dolev-Yao dy model-based send/receive channels (SND, RCV). To start the protocol, U u receives a start message (RCV(start)) as an indication at the first state (state 0). To register, U u creates the identity ID u and retransmits H ID u after being encrypted with SK uita to the TA. U u gets H(H(H ID u ||R t ||K)) and PID u encrypted with SK uita coming from the TA, and the registration process is completed. Next, U u generates some fresh nonces {R u , T u } and computes A u , A u2 , SID d . Next, U u transmits R u1 , SID d , PID u , A u2 , T u to TA and receives a message from the TA containing PID unew . U u receives the message H H R u .R d .PID unew .SID d .T d .T d .xor R u , R d .PID unew .T d .T w1 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 (U i , TA, GW N), the symmetric-key S GS which is shared among the SD and the TA, the hash function H(.), and the Dolev-Yao-model-based send/receive channels (SND, RSV).  Figure 4. demonstrates the specification for the role_SD which is played by the . In this role, the recognizes all the agents ( , , ), the symmetric-key which is shared among the and the , the hash function (. ), and the Dolev-Yao-model-based send/receive channels ( , ).     The TA knows every single agent (U u , SD, GW N), the symmetric-key SK uita , S GS , and N w which are common among the U u and the TA, SD, and TA, and among GW N and TA, respectively. Furthermore, TA has the knowledge of the H(.) and Dolev-Yao-model-based send/receive channels (SND, RSV). 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 GW N. GW N identifies all the agents (U u , SD, TA), the symmetric-key N w that is shared amongst the GW N and the TA, the H(.), and Dolev-Yao-model-based send/receive channels (SND, RSV). role_GWN that is played by the . identifies all the agents ( , , ), the symmetric-key that is shared amongst the and the , the (. ), and Dolev-Yao-model-based send/receive channels ( , ).   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 ( , , , ), respectively. The symmetric key shared among the and is presented by . The hash function is presented by the constant ℎ. 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 ( , , , ). The simulation objectives are declared with the help of goal keywords: We are concerned about verifying the secrecy of the subsequent parameters: _ , _ , _ , . 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 (TA, USERS, GW N, SD), respectively. The symmetric key shared among the TA and U u is presented by SK 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 (USERS, TA, GW N, SD). 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.

Simulation Result
Simulation outcomes depicted in Figures 8 and 9 revealed that the introduced protocol was according to the design specifications and could hold out against replay and manin-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.

Simulation Result
Simulation outcomes depicted in Figures 8 and 9 revealed that the introduced protocol was according to the design specifications and could hold out against replay and man-inthe-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.

Simulation Result
Simulation outcomes depicted in Figures 8 and 9 revealed that the introduced protocol was according to the design specifications and could hold out against replay and manin-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.

Functionality Comparison
The functionality analysis was performed with respect to the existing and proposed protocols as presented Table 6. 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, is the compared feature/security requirement, ✓ shows that the specified parameter exists in this study, and the protocol can resist an attack. Moreover, 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.

Functionality Comparison
The functionality analysis was performed with respect to the existing and proposed protocols as presented Table 6. 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 th compared feature/security requirement, shows that the specified parameter exists in this study, and the protocol can resist an attack. Moreover, × 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.

Comparison of Communication Overhead
In Table 7, 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 (160 + 160) = 320 bits, and size of symmetric enc/decryption block was 128 bits [43,44], respectively.   The communication cost of M sg1 = R * u , SID * d , PID u , A * * u , T u was 128 + 128 + 128 + 160 + 32 = 608 bits, M sg2 = R * * u , V t , X t , PID new u , SID d , GID w , T ta was 160 + 160 + 160 + 128 + 128 + 128 + 32 = 896 bits, M sg3 = PID new u was 832 bits, M sg4 = R * * u , V w , PID new u , SID 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.

Computation Overhead Comparison
This section compares the computation cost of different protocols. Table 8 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 . As represented in Table 9, 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.

Computation Overhead Comparison
This section compares the computation cost of different protocols. Table 8 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 f e ≈ T ecm . As represented in Table 9, 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.

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

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.