Practical Three-Factor Authentication Protocol Based on Elliptic Curve Cryptography for Industrial Internet of Things.

Because the majority of information in the industrial Internet of things (IIoT) is transmitted over an open and insecure channel, it is indispensable to design practical and secure authentication and key agreement protocols. Considering the weak computational power of sensors, many scholars have designed lightweight authentication protocols that achieve limited security properties. Moreover, these existing protocols are mostly implemented in a single-gateway scenario, whereas the multigateway scenario is not considered. To deal with these problems, this paper presents a novel three-factor authentication and key agreement protocol based on elliptic curve cryptography for IIoT environments. Based on the elliptic curve Diffie-Hellman problem, we present a protocol achieving desirable forward and backward secrecy. The proposed protocol applies to single-gateway and is also extended to multigateway simultaneously. A formal security analysis is described to prove the security of the proposed scheme. Finally, the comparison results demonstrate that our protocol provides more security attributes at a relatively lower computational cost.

1. Introduction

The emerging industrial Internet of things (IIoT) is a typical application scenario for wireless sensor network (WSN), where the IIoT is dedicated to affording the capacity to construct innovative services and applications within the industrial automation scenario [1]. The IIoT emphasizes extremely low latency, high security, and the ability to handle massive quantities of data [2]. Therefore, efficient authentication and key agreement mechanisms should be designed for the IIoT infrastructure to ensure security and privacy. In this manner, only authorized principals can access the IIoT resource, and these legal entities can interact over the channel using the session key that they have negotiated.

Considering authentication protocols for sensors with a low computing power, the literature [3,4] sacrifices security to build lightweight protocols, resulting in these schemes being vulnerable to certain attacks. It is clearly found that schemes using only a hash function, exclusive OR (XOR), and symmetric cryptography are unable to achieve forward and backward secrecy. Ma et al. [5] claimed that the public key cryptography algorithm was indispensable to achieve forward secrecy. After that, public key cryptography technology was widely implemented in authentication protocols, where using elliptic curve cryptography (ECC) or bilinear pairings was able to help protocols achieve forward and backward secrecy.

Figure 1 illustrates that a representative IIoT architecture usually consists of three categories of entities: industrial IoT sensing devices, an industrial central, and an engineering expert [6], which, respectively, represent sensors, the gateway, and the user in WSNs. IIoT sensing devices are leveraged to monitor the status of objects and gather data, which is subsequently forwarded to a gateway via a wireless channel. A user is able to access the data collected by the gateway in real time. Sensors, in general, have low processing power, limited computational capabilities, and restricted energy and storage capacity, whereas gateways have a strong capacity for data processing [7].

Figure 1

Architecture for an IIoT.

1.1. Literature Review

Das [8] first presented a password and smart-card-based two-factor user authentication protocol for WSNs using merely the hash function in 2009. Since then, some drawbacks to this scheme have been discovered by scholars. The presented schemes [9,10,11] identified some vulnerabilities in Das’s scheme [8], and they suggested various countermeasures to overcome these flaws. In 2014, Turkanvoic et al. [12] proposed a novel user and mutual authentication scheme for WSNs using only a hash function and XOR. These lightweight schemes consumed relatively fewer resources but sacrificed security.

In order to achieve more security attributes, a public-key infrastructure was considered in some schemes. In 2011, Yeh et al. [13] performed a cryptanalysis of Das’s scheme [8], and they discovered that there was no mutual authentication and no protection against an insider attack or forgery attack. As a result, they first implemented ECC to build the authentication protocol to address the current existing weaknesses. Shi and Gong [14] proposed a new ECC-based authentication protocol for WSNs in 2013, which addressed the shortcomings of the scheme in [13] that lacked a key agreement and forward secrecy. In 2016, Chang and Le [15] stated briefly that the scheme from Turkanovic et al. [12] suffered from an impersonation attack, stolen smart card attack, stolen-verifier attack, and failed to ensure backward secrecy, and they proposed an advanced scheme that used ECC to overcome these flaws. In 2018, Li et al. [16] indicated that the protocol in [15] lacked a proper mutual authentication and had other functionality defects. They [16] presented a three-factor user authentication protocol for the IIoT that addressed the protocol’s [15] shortcomings by utilizing ECC and symmetric cryptography. A majority of protocols, however, are designed for a single-gateway scenario, ignoring how to implement them in a multigateway scenario.

In 2016, Aim and Biwas [17] solved some security flaws in the scheme from Turkanvoic et al. [12] and designed the first authentication protocols for a multigateway scenario. Later, Das et al. [18] indicated that there were no efficient online sensor node registration and password change phases in the literature [17], and they presented a new three-factor user authentication scheme applied to the multigateway WSN architecture using AES (Advanced Encryption Standard). In 2017, Wu et al. [19] demonstrated that the scheme in [17] suffered from tracking attacks due to the constant pseudo-identity and previously established session key that adversaries could calculate and presented a novel authentication scheme for multigateway WSNs. Srinivas et al. [20] showed that the protocol in [17] suffered from a stolen smart card attack, password guessing attack, and impersonation attack. They proposed an authentication scheme for multigateway WSNs that could withstand all the above-mentioned attacks. In 2018, Wang et al. [21] discovered that the scheme in [20] was still subject to offline password guessing attacks and node capture attacks and could not protect the user’s anonymity. Therefore, they described efficient countermeasures for these attacks. Since all the above-mentioned multigateway schemes use lightweight cryptographic primitives, it is impossible to achieve forward and backward secrecy. Accordingly, our scheme will solve this problem.

1.2. Network Model

Figure 2 demonstrates how the single-gateway model is implemented in our presented IIoT protocol. After the user logs in, they send the message to the home gateway node (HGWN). If the user can pass the authentication of the HGWN, the HGWN sends the message to the sensor. After the sensor authenticates, it computes the session key and sends a message to the HGWN. Finally, the HGWN sends a message to the user, who calculates the session key to communicate with the sensor. Through two rounds of complete information exchange, the user, HGWN, and sensor can realize mutual authentication.

Figure 2

Single-gateway model.

Nevertheless, in traditional single-gateway WSNs, high-speed data streams are prone to conflict during data aggregation, because the distance between edge sensors and the gateway node is too far, which may cause an increased communication cost and reduced performance. In this case, multigateway protocols are required, and Figure 3 shows the model we used. This architecture is an extension of Figure 2. The user sends the authentication message to the HGWN. Following that, the HGWN checks the validity of the received message. In the event that this procedure is successful, the HGWN sends a message to the FGWN. The FGWN transmits a message to the HGWN after confirming the message’s availability. Then, the HGWN checks the received message and delivers a message to the user. Following steps 1–4, the mutual authentication is achieved between the user and the FWGN. After that, user sends a message to the FGWN for further authentication. After the verification is successful, the FGWN transmits a message to the sensor. Subsequently, the sensor computes the session key and delivers a message to the FGWN. Finally, the user figures out the session key used for subsequent communication after confirming the message that the FGWN sent to it.

Figure 3

Multigateway model.

1.3. Motivations and Contributions

1. Intractable elliptic curve Diffie–Hellman problem (ECDHP) is applied to our protocol to guarantee the security of the session key. We extend our scheme to multigateway WNSs while considering the limitations of single-gateway WSNs.

2. The random oracle model (ROM) [22] helps us get the formal proof of the presented scheme. The result indicates that the probability of an adversary who can break the proposed protocol is negligible.

3. Scyther, an automated security protocol verification tool [23], is used to simulate and analyze the proposed protocol. The result demonstrates that the scheme is correct and secure against many adversary models.

2. Preliminaries

2.1. Elliptic Curve Cryptography

ECC was initially proposed by Koblitz [24] and Miller [25] in the 1980s, and an introduction to the basic knowledge of ECC is described in the following. Given a large prime number p and a finite field , let a set of elliptic curve points E over be defined by the equation: , where and . All points on and the point O at infinity come from an additive Abelian group G of order q, where P is the generator point of the group and , where n is an integer and . There are two corresponding mathematical problems in ECC defined as follows:

The elliptic curve discrete logarithm problem (ECDLP): Figure 4 demonstrates points distributed over an elliptic curve in finite field . Selecting two points Q and P in Figure 4, where satisfy , where k is between 0 and 96 at random. Given k and P, it is easy to figure out Q by a scalar multiplication and addition rules. Nevertheless, given Q and P, it is difficult to calculate k.

Figure 4

Points over the elliptic curve.

The elliptic curve Diffie–Hellman problem (ECDHP): It is scarcely possible to find when given and in polynomial time, where a and b are both between 0 and at random.

2.2. Threat Model

The proposed authentication and key agreement protocol was formally analyzed taking advantage of the Dolev–Yao threat model [26], which assumes that two communication principals interact over an insecure and open channel. The following are the properties of this model:

The used one-way hash function is unbreakable.

In a uniform protocol, an identical format is used by each entity that wishes to communicate.

An adversary can eavesdrop, intercept, replay, and even modify all the transmitted messages over an open and insecure channel.

2.3. Fuzzy Extractor

Biometric features are adopted to improve security in many schemes. Due to the uniqueness of biometric features, they can be effectively applied to authentication. Compared with low-entropy passwords, biometric features also have the advantages of being difficult to forge and not being easy to lose.

The fuzzy extractor was used to process the original biometric fingerprint, which can eliminate subtle differences between biometric features extracted by the same user at different points in time. A fuzzy extractor comprises two phases as follows Ref. [27]:

Probabilistic generation function : The original biometric fingerprint is the input of , and then the process outputs biometric identification key data and public parameter, namely .

Deterministic reproduction procedure : Using the public parameter and the fingerprint reproduces key data , namely .

3. The Proposed Scheme

In this section, the detailed process of the proposed scheme is demonstrated. The proposed scheme consists of the following phases: initialization phase, registration phase, user login phase, authentication and key agreement phase, and user password update phase.

3.1. Initialization Phase

All the parameters that are used in the proposed protocol are listed in Table 1. During the initialization phase, chooses an elliptic curve E over a prime finite field , a point and a subgroup G of , where G is an additive cyclic group of order q. Then, the generates its private key and public key , where and . Consistent with the above procedure, the chooses its private key and public key , where and . Finally, the hash function is chosen to be used in the scheme, where l is the length of the output length of the hash function.

Table 1

Symbol description.

Symbol	Description
SA	System administrator
U_i	ith user node
SN_j	jth sensor node
SC_i	Smart card of U_i
HGWN	Home gateway node
FGWN	Foreign gateway node
ID_i	Identity of U_i
SID_j	Identity of SN_j
PW_i	Password of U_i
BIO_i	Biometric information of U_i
k_h,K_h	Private key and public key of HGWN
k_f,K_f	Private key and public key of FGWN
r_h,r_hg,r_f,r_fg	Random numbers
a,b,c,d	Random numbers ∈Zq*
P	A point on the elliptic curve
T_1,T_2,...,T_8	Timestamps
ΔT	Acceptable maximum transmission delay
SK	Session key
h()	One-way hash function
⊕	Exclusive-or operation
||	Concatenation operation
Gen()	Fuzzy extractor probabilistic generation procedure
Rep()	Fuzzy extractor deterministic reproduction procedure

3.2. Registration Phase

The registration phase is divided into a user registration phase and a sensor registration phase. All the messages in this phase are transmitted via a secure channel.

3.2.1. User Registration Phase

The procedure is also shown in Figure 5.

Figure 5

User registration phase.

Step 1: selects their identity and password , and inputs biometric information . The fuzzy extractor is used to compute biometric key data and public parameter , namely . stores the public parameter in its memory. Then, figures out and , and sends to the nearest via a secure channel.

Step 2: Upon receiving from , the generates a random number and calculates , , and . The stores in its memory. Then, the sends to via a secure channel.

Step 3: Upon getting from , stores into its own .

3.2.2. Sensor Registration Phase

Sensor registration process is shown in Figure 6. assigns a unique identity to each sensor node. sends its own identity to the nearest via a secure channel for registration. Then, the calculates and stores in its memory. After that, the sends to via a secure channel. After receiving from the , stores in its own memory.

Figure 6

Sensor registration phase.

3.3. User Login Phase

inserts their smart card to a terminal, and inputs identity , password and biometric information . Then, the terminal reproduces the biometric key data through the fuzzy extractor, namely . The terminal computes , , and . Subsequently, the terminal checks whether . If the equation is not held, at least one parameter is incorrect, which leads to the login request being refused by the terminal and no subsequent authentication process being performed. Otherwise, ’s login is successful, and the terminal generates a random number , and a timestamp . At last, the terminal computes , , , , , and . This process is demonstrated in Figure 7.

Figure 7

User login phase.

3.4. Authentication and Key Agreement Phase

In this section, two cases are considered: authentication and key agreement in a home region and a foreign region, respectively.

3.4.1. Authentication and Key Agreement in the HGWN

When a user and the sensor that they want to access are in the same region controlled by the same , as illustrated in Figure 8, each entity will execute the following steps.

Figure 8

Authentication and key agreement in the HGWN.

Step 1: sends the login request message to the .

Step 2: After receiving from , the checks whether is satisfied, where is the current timestamp the acquired and is the acceptable maximum transmission delay. If the inequality is not true, namely is not fresh, the aborts the current session. Otherwise, the computes and to find stored in its own memory. Subsequently, the calculates , , and , and checks whether . The current session is aborted if . Otherwise, the seeks from its own memory through , generates a random number , a timestamp , and calculates , . Finally, the sends to .

Step 3: When receives from the , obtains the current timestamp and verifies whether . If the inequality is not held, then terminates the current session. Otherwise, figures out , , and examines whether . The current session is terminated if . Otherwise, generates a random number , a timestamp , and figures out , , , , and . Lastly, transmits to the .

Step 4: After getting from , the acquires the current timestamp and verifies whether . If the verification fails, the aborts the current session. Otherwise, the calculates , , and checks whether . If , the aborts the current session. Otherwise, the generates a timestamp , calculates , and dispatches to .

Step 5: Upon receiving from the , obtains the current timestamp and checks whether . If the verification fails, the current session is rejected by . Otherwise, computes and checks whether . If , aborts the current session. Otherwise, computes , , and verifies whether . If not, declines to establish a session key with . Otherwise, and share an identical session key, and the authentication process is successfully completed.

3.4.2. Authentication and Key Agreement in the FGWN

When a user requires access to a sensor that is in a foreign region and registered in a , this phase can be completed with the assistance of the and the , as illustrated in Figure 9 and Figure 10.

Figure 9

Authentication and key agreement phase 1 in the FGWN.

Figure 10

Authentication and key agreement phase 2 in the FGWN.

Step 1: computes the login request message as in the User Login Phase Section and sends them to the .

Step 2: After receiving from , the obtains the current timestamp and verifies ’s validity, namely . If the verification fails, the aborts. Otherwise, the calculates , , , , and . Subsequently, the checks whether . The current session is aborted if . Next, if is not in the ’s database, the broadcasts the target sensor’s identity to the rest of the gateway nodes. If any finds in its database, it will react to the and broadcasts its own public key in WSNs. Subsequently, the generates a random number , timestamp , and computes , , , and . Finally, the dispatches to the corresponding .

Step 3: Upon receiving from the , the corresponding obtains the current timestamp and verifies whether . If not, the terminates the current session. Otherwise, the computes , , and , and examines whether . the terminates the current session if . Otherwise, the generates random numbers , , a timestamp , and calculates , , , , , and . Then, the transmits to the .

Step 4: Upon getting from the , the acquires the current timestamp and verifies whether . If the verification fails, the rejects the current session. Otherwise, the figures out , , , and , and checks whether . If , the rejects the current session. Otherwise, the generates a timestamp , calculates , , and dispatches to .

Step 5: After receiving from the , gets the current timestamp and checks whether . If not, the current session is rejected by . Otherwise, computes , and checks whether . If , rejects the current session. Otherwise, generates a timestamp and computes , , , and delivers to the .

Step 6: After receiving from , the obtains the current timestamp and checks whether is satisfied. If failed, the aborts the current session. Otherwise, the computes , , , and checks whether . The current session is aborted if . Otherwise, generates a random number , a timestamp , and calculates , . Finally, sends to .

Step 7: When receives from the , obtains the current timestamp and verifies whether . If not, aborts the current session. Otherwise, computes , , and examines whether . The current session is aborted if . Otherwise, generates a random number , a timestamp , and figures out , , , , and . After that, transmits to the .

Step 8: After getting from , the acquires the current timestamp and verifies whether . If the verification fails, the aborts the current session. Otherwise, the computes , , and checks whether . If , the aborts the current session. Otherwise, the generates a timestamp , calculates , and dispatches to .

Step 9: After receiving from the , obtains the current timestamp and checks whether . If not, rejects the current session. Otherwise, computes and checks whether . If , aborts the current session. Otherwise, figures out , , and verifies whether . If the verification fails, declines to establish a session key with . Otherwise, and share an identical session key, and the authentication process is successfully completed.

3.5. User Password Update Phase

inserts their smart card into the terminal, and enters identity , password , and biometric information . Then, the terminal reproduces the biometric key data and reads secret parameter in to calculate , , and . Next, the terminal checks . If the equation is not held, this update request is rejected. Otherwise, this request is acknowledged, and the subsequent phase is performed. In the update phase, enters a new password . Subsequently, the terminal computes and updates in .

4. Security Analysis

4.1. Formal Security Proof

The security of our protocol is proved under the ROM.

4.1.1. Formal Security Model

The security of the presented protocol dependent on the CK model [28].

Participants: In this model, the adversary controls the communication between all participants. For the single-gateway scenario, there are three types of participants in this protocol P: the user U, the gateway , and the sensor . Each principal has a large number of instances, which are usually treated as the actions of specific protocols run by each principal. , , and represent the ith instance of U, kth instance of , and jth instance of in P separately. Moreover, I denotes any other instance.

Queries: The interaction between and the protocol principals occurs merely through oracle queries, which simulate ’s capabilities to break P in a real attack. is allowed to execute the following queries.

: uses this query to simulate a passive attack, and they can obtain the entire transcript as a result of the conversation among U, , and .

: It models an active attack of , who forges a message m and sends it to instance . Subsequently, returns the processing outcomes of the message m to according to P. If the message m is invalid, the query is ignored.

: This query simulates that can obtain session key of any completed session.

: This query can be asked of an incomplete session and receives the internal state in return.

: This query can help obtain the private key of , which is usually used to simulate the forward secrecy of protocols. can obtain the private key of U, , and .

: asks this query to a fresh instance. Then, can continue to ask other queries, as long as the tested session remains fresh. In other words, if has been asked , , or , both and its partner cannot be asked by a query.

query is used to evaluate the semantic security of a session key. Only one test query is allowed to be executed during the whole game. To answer the test query, we imagine a challenger who flips a coin to define a bit b. If there is no session key established for instance , then ⊥ is returned. If the query has already been asked, then it outputs the same answer as above. Otherwise, if , returns the real session key. If , returns an entirely random string of the same length as the session key. The final output of is a bit , which is the guessing value of b. The adversary wins this game if and only if .

4.1.2. Security Proof

Suppose is the adversary who can break protocol P in polynomial time. and refer to the number of hash query oracles and send query oracles, respectively. represents the advantage of an adversary who can resolve the intractable in polynomial time. Now, the advantage of that breaks the semantic security of our authentication and key agreement (AKA) protocol is defined:

Game i (i = 0, 1, 2, 3, 4) is used to perform the whole procedure of P. The event signifies that guesses the bit b correctly to win the game. □

Game 0: In the random oracle model, the real attack on P is modeled, and the following formula can be obtained:

Game 1: carries out queries to model an eavesdropping attack. Even if we take queries into consideration, the probability of an adversary who can win the game has not increased.

Game 2: Hash oracles are added to the foundation of 1 by 2. This game models the active attack, and attempts to trick a legitimate principal into accepting the modified message. When the collision happens between the constructed information and the real authentication information, gets the secret information and wins the game. According to the birthday paradox, the maximum probability of the hash oracle collision is , and we have:

Game 3: queries are added. This game models the active attack, and attempts to trick a legitimate principal into accepting the modified message. Therefore, we have:

Game 4: In this game, asks queries eavesdropping on all exchanged messages , , , and . executes to obtain the private key of this entity, where I is equal to U, , and successively, and thus can obtain all the private keys. can be executed in this game. It will answer an if the target instance has formed an . executes to get the internal state of an incomplete session. In order to compute the session key, has to resolve the intractable to get a or b from or . Let be the advantage of , who can resolve the in polynomial time. As a result, we get:

At the end of 4, all the queries are simulated, so what can do is to guess the bit b to win the game after performing query. Now, we have the following:

According to Equations (2)–(7), we can obtain Equation (1). It indicates that the adversary has negligible advantage in winning the game. Therefore, our protocol is secure under the random oracle model.

4.2. Formal Verification Using Scyther

Scyther is a tool for the formal analysis of security protocols under the perfect cryptography assumption, in which it is assumed that all cryptographic functions are perfect. In this section, we formally analyze the security of the proposed protocol based on Scyther in the and . The results in Figure 11 and Figure 12 illustrate that the scheme is correct and secure against many adversary models under the Scyther security checks.

Figure 11

Simulation result in HGWN.

Figure 12

Simulation result in FGWN.

4.3. Informal Security Analysis

4.3.1. Mutual Authentication

In the home region, the authenticates by relying on , where is possessed by and can be recovered by the from and its private key . authenticates the using contained in , which can only be calculated by and . Any other principals cannot obtain . The verifies dependent on , where is possessed by and can be recovered by the from and . verifies the using contained in , which can be calculated by the and stored in ’s memory. can verify the legitimacy of using .

In the foreign region, there is a similar process as above. The authenticates by relying on the secret parameter only shared by both parties. authenticates the using contained in . The and implement mutual authentication using and , respectively, which are both the secret parameters and can only be computed by themselves and verified by the other party. The authenticates dependent on , where is possessed by and can be retrieved by the from and its private key . authenticates the by relying on contained in , which can be calculated by the and retrieved by . verifies the using contained in , which can be only calculated by the using and stored in ’s memory. The verifies dependent on , where is possessed by and can be retrieved by the from and . can verify the legitimacy of using .

4.3.2. Session Key Agreement

is established between and in the home region. Similarly, in the foreign region, and share a common session key . The established can be used for subsequent communication between and .

4.3.3. Forward and Backward Secrecy

Forward secrecy is used to guarantee that previously established session keys remain secure in the event that the long-term private keys are compromised. Identically, backward secrecy affords the guarantee that a session key that will be established in the future remains secure even if the long-term private keys are compromised.

The proposed protocol uses the to achieve forward and backward secrecy. In the home region, and share a common session key , which is related to the random numbers a and b generated by and , respectively. In the foreign region, and share a common session key , which is related to the random numbers a and d generated by and , respectively. If all the long-term private keys of , , , and are compromised by an adversary, since the adversary has to resolve the intractable to get or from , , or , , respectively, the previous or future session key is still secure. Consequently, forward and backward secrecy can be guaranteed.

4.3.4. User Anonymity and Untraceability

In the proposed protocol, the real identity cannot be acquired by the adversary from the interaction messages. In the home region, there is only the legitimate gateway node who, in possession of private key , can calculate to recover ’s pseudonym and sensor’s identity . Simultaneously, considering the one-way nature of the hash function, it is difficult for the adversary to acquire from and from , respectively. In the foreign region, the adversary without gateway node’s private key cannot compute to recover . Likewise, considering the one-way nature of hash function, the adversary is unable to get from . As a result, user anonymity can be achieved. In addition, because of the login request message being updated at each session round, the adversary is unable to trace a specific user. Therefore, the user’s untraceability is guaranteed.

4.3.5. Illegal Login Detection

A user needs to input their identity, password, and biometric information to complete login, and if the terminal declines this session, at least one of these three items is incorrect. In our protocol, when the incoming information is invalid, the identification parameter cannot be recovered correctly, which leads to the login request being aborted by the terminal. This mechanism guarantees the system can check illegal login requests quickly.

4.3.6. Stolen Smart Card Attack

The secret parameters are stored in ’s smart card, where , , , and is generated by . If ’s smart card is lost and obtained by the adversary, then the adversary can get , but they are still unable to acquire the correct identity, password, and biometric key data. The adversary cannot compute a correct through without . The biometric key data also cannot be recovered correctly without a real . Furthermore, even in this case, there is no chance for an adversary to get the password. As a result, the login request message cannot be figured out without the correct . Our protocol can be resistant to stolen smart card attack.

4.3.7. Replay Attack

The timestamp mechanism is used to guarantee the freshness of transmitted messages in our scheme. When the message is exchanged, the node first checks whether the time difference between the received timestamp and its own timestamp is within the acceptable maximum delay allowed by the system. Expired messages will be rejected. As a result, the protocol is capable of defending against replay attack.

4.3.8. Privileged Insider Attack

During the registration phase, user transmits to the via a secure channel. It is assumed that an internal malicious privileged node who executes privileged insider attack in order to get user’s password after getting . However, the obtained values are hash values consisting of password and biometric key data. Considering the one-way nature of the hash function, it is intractable for the privileged node to extract from . Therefore, our protocol can be resistant to privileged insider attack.

4.3.9. Desynchronization Attack

In the proposed protocol, the user does not store the same secret values with the gateway node. All participants in the protocol are not required to update any information when a session is accomplished. Accordingly, the protocol can resist a desynchronization attack.

4.3.10. Impersonation Attack

In our protocol, in order to forge a user, a valid login request is necessary. Nevertheless, the adversary has no capacity to figure out the true without the correct . As a result, the adversary fails to impersonate a legitimate user.

In addition, when the fake gateway node receives the correct login request, it cannot retrieve the true without the real private key. Therefore, the adversary is also unable to impersonate a legitimate gateway node.

Moreover, if the adversary wants to forge a sensor node, they need to recover and generate , which all depend on that is only computed by the and stored in the sensor’s memory. Consequently, this scheme is protected against a sensor impersonation attack.

5. Performance and Security Comparison

In order to illustrate the balance between the security and usability of our protocol, the comparative consequences of the security and overhead of our scheme with other associated schemes are as follows, where Case-1 and Case-2 represent the protocol designed in the home region and the foreign region, respectively. According to [17,29,30,31], all operations were implemented in MATLAB on a four-core, 3.2 GHz computer with 8 GB of memory.

5.1. Security Features Comparison

The statistics of the security attributes that each scheme can satisfy are summarized in Table 2, where ✓ represents that this literature can satisfy this corresponding security attribute in Table 2, whereas × represents that it cannot achieve. All the indicators listed in Table 2 were achieved by our scheme. Moreover, none of the studies in the literature [13,17,18,19,20] has the capability to achieve forward and backward secrecy. However, the implementation of ECC in our scheme enables ours to accomplish forward and backward secrecy.

Table 2

Security comparison.

Security Properties	[13]	[17]	[18]	[19]	[20]	Ours
Mutual authentication	×	✓	✓	✓	✓	✓
Session key agreement	✓	✓	✓	×	×	✓
Forward and backward secrecy	×	×	×	×	×	✓
User anonymity	✓	×	×	×	×	✓
Untraceability property	×	×	✓	×	×	✓
Illegal login detection	×	✓	✓	×	✓	✓
Stolen smart card attack	×	×	✓	✓	✓	✓
Replay attack	✓	✓	✓	✓	✓	✓
Insider attack	✓	✓	✓	×	✓	✓
Desynchronization attack	×	×	✓	✓	×	✓
Impersonation attack	×	×	✓	×	✓	✓

5.2. Communication Cost Comparison

In order to calculate the communication cost, we assumed that the identity, random number, hash digest, ECC point, and timestamp were 160 bits, 160 bits, 160 bits, 320 bits, and 32 bits, respectively. Additionally, the symmetric encryption/decryption using AES-128 required 128 bits for a 128-bit plaintext block. We evaluated the communication overhead between our protocol and other relevant protocols [13,17,18,19,20] during the login and authentication phases according to the overall quantity of transmitted messages. Table 3 shows the comparison results. Compared with [19], the transmitted number of messages was identical to our scheme, and there were similar communications costs as ours, but our scheme met more security attributes. As we can see, in order to compare with previous protocols [13,17,18,19,20], we chose SHA-1 [32] as the hash function. However, to achieve more security, we recommend using SHA-256 [32] as the hash function.

Table 3

Communication cost comparison.

Scheme		Number of Messages	Communication Cost (bits)
[13]	Case-1	2	1504
[17]	Case-1	4	2528
	Case-2	5	3008
[18]	Case-1	3	2784
	Case-2	6	4704
[19]	Case-1	4	2688
	Case-2	8	4480
[20]	Case-1	4	2368
	Case-2	7	3904
Ours	Case-1	4	2848
	Case-2	8	4416

5.3. Computation Cost Comparison

Table 4 lists the approximate required computational time of various cryptographic operations, which were used as a comparative standard. Table 5 compares the computational overhead of our scheme and other relevant schemes during the login, authentication, and key agreement phases. The total cost of the proposed scheme increased slightly. Nevertheless, most of the cost was calculated on the gateway side with strong computational power rather than the resource-limited sensor side. Accordingly, integrated with both security and communication cost, our protocol was relatively secure with an acceptable overhead.

Table 4

Execution time of various cryptographic operations.

Symbol	Description	Approximate Computation Time (s)
T_h	Hash function	0.00032
T_ecm	ECC point multiplication	0.0171
T_eca	ECC point addition	0.0044
T_sym	Symmetric encryption/decryption	0.0056
T_fe	Fuzzy extractor function	0.0171

Table 5

Computational cost comparison.

Protocols		User	HGWN	FGWN	Sensor	Total (s)
[13]	Case-1	4T_h+2T_ecm+1T_eca	4T_h+6T_ecm+3T_eca	-	3T_h+2T_ecm+2T_eca	0.20092
[17]	Case-1	7T_h	8T_h	-	5T_h	0.00640
	Case-2	8T_h	1T_h	7T_h	5T_h	0.00672
[18]	Case-1	9T_h+1T_fe+1T_sym	5T_h+2T_sym	-	3T_h+1T_sym	0.04494
	Case-2	10T_h+1T_fe+2T_sym	0	5T_h+2T_sym	4T_h+1T_sym	0.05118
[19]	Case-1	9T_h	11T_h	-	4T_h	0.00768
	Case-2	11T_h	7T_h	7T_h	4T_h	0.00928
[20]	Case-1	10T_h	14T_h	-	7T_h	0.00992
	Case-2	14T_h	6T_h	17T_h	6T_h	0.01376
Ours	Case-1	9T_h+1T_fe+3T_ecm	8T_h+2T_ecm	-	5T_h+3T_ecm	0.16094
	Case-2	12T_h+1T_fe+4T_ecm	8T_h+6T_ecm+2T_eca	10T_h+7T_ecm+2T_eca	5T_h+3T_ecm	0.38780

6. Conclusions

In this paper, we designed an authentication protocol based on ECC using three factors, applied to the IIoT environment. The proposed scheme was appropriate for single-gateway scenarios, and we also extended it to multigateway scenarios. Furthermore, forward and backward secrecy was realized in our scheme utilizing the intractable ECDHP. The formal security analysis under the ROM indicated that the proposed protocol was able to satisfy semantic security. We simulated our scheme using the formal verification tool Scyther, and the result showed that our scheme was secure. The informal security analysis proved our protocol was capable of satisfying most common security properties. Finally, compared with other representative protocols, the comparative results of security attributes, communication, and computation cost in Table 2, Table 3 and Table 5 clearly showed that our protocols could achieve many security attributes at a reasonable computation cost.