Abstract
The massive heterogeneous devices and open channels of the Internet of Things (IoT) lead to low efficiency and privacy leakage in the authentication process, which brings great challenges to identity authentication. This paper focuses on the anonymous authentication between the IoT edge device and the cloud server. In this work, we first propose a novel lightweight anonymous authentication protocol (LAAP) to meet security and efficiency requirements. Especially, the proposed protocol uses dynamic pseudonyms to prevent the traceable attacks caused by fixed identity identification and also uses symmetric encryption to optimize the server’s search for anonymous device information, and the time complexity is reduced from to . Then, the formal security analysis and informal security analysis are provided to prove the security of the proposed protocol. Finally, extensive numerical results indicate that the proposed LAAP protocol is superior to the benchmarks in terms of computing overhead and communication overhead, while the storage overhead is consistent with the lowest level among other protocols.
1. Introduction
The Internet of Things (IoT) aims to connect massive sensing devices through wireless networks to realize information interaction between the physical world and the virtual world. With the wide application of IoT, it has been involved in all walks of life, such as the Internet of Vehicles, Internet of Medical Things, and Smart City. According to GSMA forecast, the number of IoT devices worldwide will reach about billion in [1]. Due to the limited storage, computing, communication, and power capabilities of IoT sensing devices, combining edge-embedded devices with cloud computing creates a new paradigm called CloudIoT [2]. Under this paradigm, embedded devices can rely on the processing power of cloud computing and use various services provided by cloud computing. However, when an embedded device establishes a communication connection with a cloud server, security is the primary concern.
In recent years, privacy and data security issues caused by IoT terminal devices have frequently occurred. On June 8, 2020, security experts disclosed a new UPnP vulnerability named “Call Stranger” [3], which affects the security of billions of devices, including the TV and network equipment of ASUS, Belkin, Dell, Samsung, TP-Link, and other companies. The vulnerability could be exploited by a remote, unauthenticated attacker. In September 2021, researchers discovered a high-level security vulnerability CVE-2021-36260 in Hikvision IP camera/NVR device firmware. The attack can fully control the device through the shell and obtain any information of the owner and further laterally attack the internal network without leaving any daily login information [4]. The report released by the Unit team [5] shows that 98% of IoT devices leak user privacy due to unencrypted traffic, 57% of devices are vulnerable to moderate or severe attacks, and devices have become the preferred target for attackers.
Authentication can guarantee the identity legitimacy of communication parties in the IoT and is a key technology to solve security problems. The authentication process usually involves two parts, i.e., identity authentication and key negotiation. Identity authentication is to ensure the legitimacy of the identities of both communication parties. Key negotiation is used to establish a session key for subsequent security access and secure data transmission. Note that security authentication protocols need to consider the following principles: (1) for lightweight, most IoT devices cannot support complex authentication protocols because of their limited computing resource [6]; (2) for privacy protection, during the interaction of the device, the advanced techniques (e.g., anonymity and blockchain) need to be adopted to prevent malicious attackers from obtaining the private information of the devices and users [7].
1.1. Related Work
To implement the security authentication of IoT devices, various protocols and methods were studied. Kalra and Sood in [8] proposed a two-way authentication scheme to realize mutual authentication and meet essential security requirements. Considering the security defects and structural problems of the protocol [8], the improved protocols in [9, 10] were proposed to defend against server emulation attacks. Rostampour et al. then proposed a privacy-preserving anonymous authentication protocol named ECCbAP in [11]; the results indicated that the proposed protocol can achieve the untraceable purpose by traversing the registry. Then, the authors in [12] proposed an authentication protocol based on bilinear pairing to solve the problems of privacy protection and authentication table theft. Subsequently, the enhanced IoT mutual authentication protocol and improved ECC-based authentication protocol were proposed in [13, 14], respectively. To defend against more types of attacks including known temporary information attacks, DoS attacks, Panda and Chattopadhyay proposed an anonymous authentication scheme integrating a password validator in [15]. Further, Bhuarya et al. in [16] proposed an enhanced authentication scheme to defend known session-specific temporary information attack, where the hypertext transfer protocol (HTTP) cookies were used to authenticate clients. However, the large exponential powers employed by these protocols leads to a large amount of computation.
The dynamic pseudonym is an effective method to solve traceable problems. A pseudonym ID is used to conduct authentication between client and server and is dynamically updated after completion of authentication. Das et al. first proposed an authentication protocol [17] where dynamic ID technology was used to avoid the risk of ID theft. However, the protocol suffers from smart card theft attacks. Then, Jiang and Das et al. devoted to solving the problem in [18, 19], respectively. Notice when the above schemes are attacked asynchronously, i.e., the attacker blocks the exchange messages of the authentication protocol, and the interaction between the authentication parties is out of sync, such that the protocol cannot work. Thus, Gope et al. in [20–23] studied the authentication scheme based on emergency ID and secret key technology to solve the problem of asynchronous attack. In such schemes, clients and servers share a set of emergency IDs and keys in addition to dynamic pseudonyms. Once the dynamic pseudonyms are out of sync, emergency IDs and keys are used to interact. However, the emergency IDs and keys occupy a large amount of storage space, and once the emergency ID and emergency key are used up, the device must be reregistered. Recently, some researchers devoted to designing grant-free access scheme for M2M communications [24] and used the advanced methods to realize the authentication, e.g., deep learning [25, 26] and blockchain [27, 28]. However, they are not suitable for IoT devices with limited computing overhead.
1.2. Motivation and Contribution
To sum up, it can be found that the mentioned authentication protocols based on identity and pseudonym do not consider the privacy protection and cannot resist traceable attacks. For example, if the long-term key is leaked, the attacker can simulate the session key negotiation between the terminal and the server and occupy the position of the legitimate device. As a result, the legitimate device cannot carry out normal session key negotiation. Furthermore, during authentication process, the server needs to traverse the password verifier table to find the relevant registration information, and the search time increases linearly with the number of devices. The protocols with privacy protection cannot take into account both authentication efficiency and security while realizing anonymity. Dynamic pseudonym schemes are vulnerable to asynchronous attacks. Therefore, this paper focuses on the authentication between the edge server and device in the IoT and designs a new authentication protocol to realize the privacy protection and improve the efficiency of authentication. Our main contributions can be summarized as follows: (i)We propose a lightweight anonymous authentication protocol (LAAP) based on elliptic curve cryptography (ECC) to implement security authentication between the servers and devices. Dynamic pseudonym is used to defend against traceable attacks caused by fixed identity identification. Besides, symmetric encryption is used to optimize the server’s search for anonymous device information, and the time complexity is reduced from to (ii)We provide the formal analysis and informal analysis to validate the security of the proposed protocol. The analysis shows that the proposed protocol can satisfy the anonymity and defend against asynchronous attacks. We also perform random oracle models and AVISPA Tool to prove the security of the certification process(iii)We provide extensive simulation results to testify the authentication efficiency of the proposed protocol. The results indicate that the proposed scheme outperforms the benchmarks in terms of computation overhead, communication overhead, and storage overhead
Organization of this paper is as follows: In Section 2, we introduce the preliminaries. In Section 3, we present details of our proposed authentication protocol. Security analysis and performance evaluation are given in Sections 4 and 5, respectively. At last, Section 6 offers our conclusions and potential future works.
2. Preliminaries
In this section, we first introduce the system model and then introduce the related elliptic curve cryptography and the corresponding mathematical problems.
2.1. System Model
In this work, we focus on the authentication between cloud server () and embedded devices () in the IoT shown as Figure 1. The embedded device can be small devices (e.g., environmental sensors, cameras, and smart meters) or large-scale devices (e.g., intelligent vehicles and smart charging piles). The cloud server has powerful computing resources and storage resources, so that it can provide various services for embedded devices. For example, in mobile edge computing networks [29], the device first uploads data to the cloud server and then uses the computing resources to process its data. The cloud server also provides a bootstrap program for the system, enabling authentication to be performed smoothly. Before providing these services, they authenticate between the device and server to ensure legitimate access via wireless channels.
2.2. Elliptic Curve Cryptography
The security properties of ECC are mainly based on the intractable problem of discrete logarithms in elliptic curves. Given a prime field , the elliptic curve point is set on the finite field can be expressed as where , the prime number is the order of the finite field, and represents the infinity point. The Ellipse Curve Discrete Logarithm Problem (ECDLP) can be described as follows:
Definition 1. ECDLP: let denote the cyclic group generated by the base point and the operation rules of Abelian groups on the elliptic curve . For a given , if , where , cannot be solved in polynomial time, which is usually used as the private key.
Based on the ellipse curve and the ECDLP, the security if the ECC can be described as the Ellipse Curve Computation Diffie-Hellman Problem (ECCDHP), which is defined as follows.
Definition 2. ECCDHP: let be the cyclic group generated by the base point and the operation rules of Abelian groups on the elliptic curve . For , if and , where , we have that computing in polynomial time is a hard problem.
2.3. Random Oracle Model
Random oracle model (ROM) is proposed by Bellare and Rogaway [30], which made the provable security methodology that was purely theoretical research in the past make significant progress in practical applications. When applying the ROM, the necessary work is to establish a security model that treats different subjects as random oracles (RO). The RO has the following three characteristics: (1) consistency: for the same query, RO will always return the same output; (2) computability: for different queries, RO can obtain results and return them in polynomial time; and (3) uniform distribution: for different queries, the output of RO is evenly distributed in the value space without collision that the output obtained by different queries is always different.
To prove the security of the model, it is necessary to establish an attacker for the model and to provide the attacker with a simulated environment indistinguishable from the actual environment. For , the complexity and safety of the model boil down to mathematical computational difficulties (e.g., large factorization, ECDLP, and ECCDHP). In ROM, the convention judgement appears as (1)Formally define the security of the scheme, assuming that the attacker can destroy the security of the protocol with a nonnegligible probability in polynomial time(2)The attacker simulates the real environment by querying different random oracles(3)The way of attacking the attacker and the result boils down to solving a mathematical problem
Although the ROM methodology cannot be used as absolute proof that the actual solution is safe, it can still be a necessary basic safety test. Thus, this paper adopts it to validate the security of the proposed protocol.
3. Design of the Authentication Protocol
In this section, we introduce the proposed LAAP protocol including three phases, i.e., initialization phase, registration phase, and authentication phase. A summary of the notations used in this article is provided in Table 1.
3.1. Initialization Phase
Before authentication, the server needs to perform necessary parameter initialization operations. Initialization parameters are divided into public parameters and private parameters. The server selects an elliptic curve based on the finite prime field and selects the additive group of curve of the order . Then, the public key of the server can be calculated as , where is the private key and is the generator of the group . The server also needs to select a suitable one-way hash function , where the input is any length binary string and the output is a binary string of fixed length . The server generates a random key as a symmetric encryption key and selects an appropriate symmetric encryption algorithm as the basic algorithm for device identification update. The server publishes the parameters as public parameters and stores as private parameters.
3.2. Registration Phase
Before starting key negotiation, the device first needs to complete the registration. The LAAP protocol can ensure that the registration is completed by the public channel, and check whether the message responded by the server is legal. The registration process can be divided into three steps described as Figure 2. In the following, we will detail the three steps.
Step 1. The device first selects an unique , which is only known by the device. Then, the device generates a random number to randomize its and calculates and as and , respectively. Finally, the device sends the message to the server through the public channel.
Step 2. After receiving the registration information from , server uses the key to restore the data, where and are calculated according to , respectively. After restoring , is generated based on the device registration identity as , which is used to calculate the identity information for each authentication of the device. Otherwise, the server also generates a new identity for the device as the identity of the authentication stage. The server will save two IDs for each device, i.e., and , where is the new device ID and is the old ID of the previous session. Then, the hash value of is used as the initial value of the hash chain, which will be updated during each session key negotiation process.
Subsequently, the server uses the hash value of the key to encrypt and and stores the results in its database. After that, the server calculates the message of the response device as and . Finally, the server sends to the device through the public channel and stores as the registration information corresponding to the device.
Step 3. After receiving the message from the server, the device uses the initial value of the hash chain to restore and verify the data as . By splitting the data, the device verifies whether the decrypted is the same as the saved by itself. If they are the same, the device confirms that the message was sent by the server and stores as the registration information for subsequent identity authentication and key negotiation.
3.3. Authentication Phase
When the device wants to upload data or access the server, the device and server need to complete identity authentication and key negotiation. The authentication process can be divided into four steps described as Figure 3. In the following, we will introduce the four steps for details.
Step 1. Device first generates a random number and calculates , , and , where and are temporary values generated by the synchronization hash chain and the identity information in the registration phase. Then, the verification message is generated as . On the one hand, it can prevent message tampering, and on the other hand, it can verify whether the identity is legitimate. Finally, the device sends the message to the server for authentication.
Step 2. After receiving the message , restores the identity information based on the symmetric key . If the recovery is successful, can judge the recovery based on the matching information of the database; otherwise, terminate the session. When , the server updates the synchronization hash value as and reconstructs the authentication temporary value for this session as . Then, calculates the verification message as . If , it means that the message has been tampered with and the session is terminated. Otherwise, generates a random number and a new identity for as . Finally, calculates the verification messages as and sends them to
Step 3. After receiving the message , decrypts and verifies the new ID where . If , the message verification fails, and the session is terminated; otherwise, calculates the negotiated session key and the verification message as . Finally, the device sends the message to the server.
Step 4. After receiving the message , can calculate the negotiated session key and verify the message as and , respectively. If ,the server terminate the session, otherwise, the session key negotiation is successful.
4. Security Analysis
In this section, we provide the formal analysis and informal analysis to validate the security of the proposed protocol.
4.1. Formal Security Proof
For the formal analysis, we first adopts the widely accepted ROM [30] to verify the security of the proposed protocol.
4.1.1. Formal Security Proof with ROM
The extended RO is described as follows: is used to query the real identity information of the device, where and represent the identity after session key negotiation and the identity before session key negotiation, respectively. is used to query the secret information of the device and simulate the attack of the device being stolen.
There are two participants in this work, i.e., server and the embedded device . Each participant has multiple instances (i.e., ROs). Let and represent the -th instance of them, respectively; and represent the identity of and that are used to negotiate the session key, respectively; and indicate the updated ID and the preupdated ID of , respectively; and , respectively, represent the hash chain status of and ; represents the negotiated key for the -th time.
If the instance receives all the expected messages according to the predetermined steps, the instance enters the accepting state denoted as . In this protocol, the parties negotiating the secure session key should meet the following conditions: (1) both and enter the receiving state, i.e., ; (2) updates the identity, ; (3) the identities of and are not empty, i.e., ,
In the ROM, an attacker can simulate the attack by querying the RO. The included query is defined as follows:
Passive attack : the attacker can query the oracle to obtain the messages exchanged between and , giving the attacker the ability to eavesdrop on the channel.
Active attack : the attacker can interact with any participant by querying the oracle machine, and the oracle machine processes the message. If the message is valid, the oracle machine returns the processing result of message ; if the message is invalid, the oracle machine ignores the message.
: the attacker can obtain the session key of any participant by querying the oracle, and this query will only return the held key if the participant actually holds the session key. When an attacker queries the random oracle, the correct session key will be returned only if is accepted; otherwise, a random element in the state space will be returned.
: when , the hash chain value of is fed back during the query. If the hash chain value is invalid, the random element in the state space is returned. When , the query information is the registration information of . If the registration information is invalid, the random element in the state space is returned.
: the attacker can obtain the real identity of the device by querying the oracle. If the sent message is accepted, it will return the real identity of the device; otherwise, it will return a random element in the state space. This oracle is used to test the anonymity of the protocol.
: when the attacker queries the oracle, the RO throws an unbiased coin and the result is used to determine whether the query returns the correct result. If , it returns a random element in the state space; if , and the participant holds the session key, return the correct session key; otherwise return it. The oracle tests the security of the negotiated session key, where the query can only be executed once.
Semantic security for session keys. In the defined ROM, attacker can query the session key through or , and random elements in the state space will be returned during the query process; query through The real identity of the device. needs to distinguish between random elements and real information. The goal of is to guess the real information. At the end of the experiment, the attacker returns a guess bit . If , then wins the game event, which destroys the security of the protocol. denotes that wins the th experiment, and denotes the constructed LAAP protocol. More precisely, the advantage of overcoming the semantic security of the protocol is , if the experiment ends, the probability of obtaining attack success is negligible, indicating that the protocol is semantically secure.
Based on the above definitions, we have the following theorem which proves the security of the proposed protocol.
Theorem 3. Let denote the advantage of an adversary to break through the semantic security of the proposed protocol , and let denote the advantage of in cracking the ciphertext symmetric encrypted with the server key pair within a probability polynomial, and let denote the advantage of solving the problem of in any polynomial time where and are the elliptic curve group and the symmetric encryption algorithm, respectively, and , , and denote the times that attacker executes the queries , , and , respectively
Proof. Let denote the probability that wins in the -th experiment. The contribution of the -th experiment to the probability of winning can be expressed . The proof process can be described as the following five different experiments.
Experiment 1. This experiment corresponds to a real attack in the ROM. When implements a real attack on the protocol under the ROM model, we have
Experiment 2. This experiment is used to simulate an eavesdropping attack of an adversary . We know in the protocol, where is calculated by the embedded device through and random number , and is encrypted by the server with the secret key . Even if intercepting all parameters transmitted during the authentication phase, still cannot get it any information. Therefore implementing an eavesdropping attack cannot increase the probability of winning, and we can obtain
Experiment 3. This experiment is used to simulate all possible hash collisions in the authentication phase based on Experiment 2. tries to find hash collisions, and if the same output is produced for different inputs, the game ends. According to the birthday paradox (the number of collision tests for a hash table of bit length is not but only ), we have
where and represent the times that attacker queries and , respectively.
Experiment 4. Based on Experiment 3, attacker queries the device’s secret information and hash chain value by adding . If successfully obtains the information, the probability that wins the experiment is
where represents the times that the attacker queries .
Experiment 5. Based on Experiment 4, the experiment adds that can tamper with the authentication information and make legitimate participants believe the tampered message, i.e., can eavesdrop on the message and can make Hash collision. The following two cases will occur: (1) tampers with message , and (2) tampers with message .
Case 1. In this case, after tampering with , the adversary needs to solve how to correspond to the verification message . For this reason, the adversary needs to solve the ECDLP problem, and guess and , (i.e., ), so that it can guess . Besides, still needs to solve a symmetric key problem to generate legal , i.e., . Overall, we have
Case 2. In this case, tampers with to impersonate the server. Assuming that has obtained the synchronization value shared by the device and the server, still needs to solve the symmetric key decryption problem, i.e., . Similarly, if has decrypted the current symmetric key problem, still needs to solve the ECDLP problem to obtain the legal , i.e., . Thus, we have
In summary, the probability that the adversary wins in Experiment 5 is
All random predictions are simulated in the above four experiments. The results indicate that has no advantage in guessing the bit , and the only way to pass the test is to perform query guessing, i.e.,
Using the triangle inequality, we can obtain
Based on (3)–(8), we have
Submitting (12) into (11), we can obtain (2).
Remark 4. This result indicates that the adversary has no extra advantage to win the experiment and the proposed scheme is secure.
4.1.2. Formal Security Proof with AVISPA Tool
In this part, the AVISPA verification tool is used to verify the security of the LAAP protocol. The experimental environment is Oracle VM VirtualBox, SPAN-Ubuntu10.10-light. The HLPSL language description of the protocol is divided into the following five dimensions.
Role attributes: and are two agents, Hash and Mutli are two hash functions, Kab is a symmetric key, and Snd and RCV are the communication channels between the client and the outside world. The local variables defined are the same as the protocol description, as shown in Figure 4(a). The modeling of the server is similar to that of the client, as shown in Figure 4(b).
(a) Role attribute of
(b) Role attribute of
Role conversion process: the conversion process of in LAAP is divided into three stages: register1 means that starts to register and sends registration information to ; register2 means that receives the response from , conducts authentication calculation, and initiates an authentication request; authentication1 indicates that receives the response from and completes the final authentication process, as shown in Figure 5(a). Similarly, the conversion process of is also divided into three stages: register indicates that requests the registration information of ; authentication1 means that receives the authentication request of and performs verification and response; authentication2 means that receives the response of and completes the final authentication process, as shown in Figure 5(b).
(a) Role change process of D
(b) Role change process of S
(c) Session attributes
(d) Environmental attributes
Session attributes: the modeling of LAAP session attributes defines the rules that the communicating entities follow. The definition of basic attributes includes the role agents and , hash functions Hash and Multi, symmetric key Qi, and communication channels SND and RCV as shown in Figure 5(c).
Environmental attributes: the definition content of LAAP environment includes the communication channel of the communication entity, communication entity (including , , and ), security target constant, and session combination, as shown in Figure 5(d).
Safety goals: the security goal describes the secret information “secrecy_of” and the authentication quantity “authentication_o” of the communication entity defined in the protocol shown in Figure 6.
The OFMC simulation results are shown in Figure 6, and the ATSE simulation results are shown in Figure 6. From Figure 7, we can see that the LAAP realizes two-way authentication while resisting man-in-the-middle attacks and replay attacks, which proves the security of the protocol.
(a) OFMC backend simulation results
(b) ATSE backend simulation results
4.2. Informal Security Analysis
Informal security analysis mainly consists of two parts, i.e., basic function security and common attack defense. Basic functional security includes mutual authentication and device anonymity. Common attacks resistance mainly includes traceable attack defense, asynchronous attack defense, DoS attack defense, replay attack defense, and simulation attack defense.
Mutual authentication. In the LAAP protocol, server authenticates the legal identity of device based on the message and then restores the identity of the device with . This precess is performed through symmetric encryption. If gets a string of garbled characters after decrypting or cannot find matching information in the verification table, will discard the authentication message. After successfully decrypting and obtaining the device’s identity , verifies the authenticity of the device with . If , the verification is passed. In the response message , contains the new identity of the device, which is encrypted by the hash chain value synchronized by both parties, and contains the authentication information . Notice that only valid can calculate . Thus, if the calculated by the device is the same as the received , can confirm the legal identity of
Device anonymity. Device anonymity means that attacker cannot obtain any identifying information about the participants by listening to the messages in the channel. In the LAAP, the method of dynamic pseudonym and synchronous hash chain are used to solve the anonymity of the device. Notice that the identity identification is dynamically updated in the second phase of device authentication so that the identity identifications are different at different session stages. Under the Deolv-Yao attack model [31], is completely unable to distinguish the attribution of different sessions. Therefore, the proposed protocol satisfies the anonymity requirement of the device.
Traceable attack defense. Traceable attack means that attacker can identify the belonging of messages by listening to the information in the channel, so as to carry out specific analysis to undermine the security of the protocol. Recall that the LAAP protocol used the dynamic pseudonym. Thus, after each successful session key negotiation, the device identity is updated. That is, the sent in the -th session is completely different from the sent in the -th session. Therefore, cannot determine which communication entity the session message belongs to and also cannot track the session information of specific equipment.
Asynchronous attack defense. An asynchronous attack intercepts message transmission to make protocol participants lose synchronization. As a result, the protocol cannot be executed correctly, thus destroying the protocol. According to the LAAP, the messages transmitted on the public channel includes , , and . There are two messages related to synchronization information, i.e., the initial authentication message and the response message sent by and , respectively. For attacker , intercepting message has no effect on the synchronization of the protocol. Thus, we only consider the following two cases.
Case 1 ( intercepts the message). has updated the device ID as because has already processed the message . At this time, due to the information interception, the identity identifier of is the corresponding . When the timer of expires, will regenerate the random number to reauthenticate and send the message to . We can see that , and will determine that is out of synchronization, and the current hash value is directly used for authentication.
Case 2 ( intercepts the message ). The system status is that updated the device ID, and updated the device ID and hash chain value. After is intercepted, the hash chain value of the protocol participant is synchronously behind . When the timer of device expires, resends the authentication message , and . the hash chain value will be updated, and will be used in the update process. Therefore, and will resume synchronization.
DoS attacks defense. DoS attack means that attacker sends a large amount of invalid authentication information to the server, which consumes the computing resources of the server and makes the server unable to provide services normally. In the protocols in [11, 15], there is a way to find information about related devices by traversing the password check table or the local registry. Thus, their time complexity is . When there are enough registrations, even if most of the devices are offline, the server will go through all the devices during the authentication process. The proposed LAAP protocol combine the dynamic pseudonym with symmetric encryption, and the time complexity is reduced from to . So, the proposed protocol has a high authentication efficiency and can resist DoS attacks.
Replay attacks defense. Replay attack means that the attacker resends the message sent in the history negotiation stage to the server, thus achieving the purpose of spoofing. In LAAP, the messages transmitted by the public channel consist ,, and . Let the message sent by the device in the -th session be , the message sent by the server be , and the response message from the device be . Thus, there would be the following three cases.
Case 1 ( replays the message ). We will analyze it from two subcases. In subcase 1, the attacker launches a replay attack in the middle of the -th and -th key negotiation at the device side. Note that the device has not performed the -th key negotiation. Because the server will store the th device identity, the server will find in the authentication table and will consider that device is out of asynchrony. So in the next step of message verification, the server will calculate and classify the message as a replay attack and discard the session. In subcase 2, uses the device history negotiation information , where ): After receiving , the server uses key symmetric decryption to get the -th device identity based on . But the server cannot find the relevant information in the database, and it will discard the session.
Case 2 ( replay the message ). Similarly, we will analyze it from two subcases. Subcase 1 is similar to the above subcase. After receiving , the device will decrypt to obtain the new device identifier . At this time, the hash chain value at the device has been updated, and computed by the device is different from the received . So, the device will terminate the session. For subcase 2, after receiving the history information (where ), the device will decrypt to get the identity . However, because the hash chain value has been updated several times, obtained by decrypting is different from . Thus, the device will terminate the session.
Case 3 ( replay the historical message ). The server will use the new authentication information and message to calculate as follows:
We can find that is different from . Thus, the session key negotiation cannot be successful, and the server will discard the session.
Based on the analysis of the above three cases, we proof that the proposed protocol can resist the replay attacks.
Simulation attack defense. An emulation attack means that the attacker tampers authentication information to establish session keys on the simulated device or server. An attacker can tamper with or send historical authentication messages to spoof the device or the server based on the intercepted authentication messages.
For messages , has no access to the registration information and the synchronization hash value of the device, so it cannot obtain the legitimate to spoof . If replays the historical messages, see the above analysis for details. For messages , cannot know symmetric encryption key of and the authentication message generated in this session, so it cannot compute the legitimate and . If replays the historical message, the session is terminated due to authentication failure. For message , cannot know the authentication message of this session, so that it cannot compute . If replays the history message, the authentication will fail, and terminates the session. In summary, the proposed protocol can resist the simulation attacks.
We provide Table 2 to show the comparison of security performance between LAAP and the benchmarks. The dimension of comparison is based on the basic functional security and common attack resistance described in the above. In Table 2, where “Yes” (resp. “No”) indicate that the protocol can (cannot) support the security feature, and “—” indicates that the protocol does not involve this security feature. From Table 2, we can see that the proposed LAAP protocol can resist more security attacks.
5. Performance Evaluation
In this section, we provide the performance comparisons between the prosed LAAP protocol with several related protocols [9–11, 15] in terms of computational overhead, storage overhead, and communication overhead. For a fair comparison, all experiments use the http://golang.org/x/crypto/bn256 curve and the hash function SHA-.
5.1. Computational Cost Analysis
We first provide the comparison of a computational overhead between the proposed protocol and the benchmarks. The computational cost is divided into the time-consuming of the device in the registration phase and the authentication phase. The calculation overhead is shown in Table 3. From Table 3, we can see that in the registration stage, the proposed protocol increases the computational overhead of the device but reduces the overhead of the server. We also can observe that in the authentication stage, we reduce the computational overhead of both the device and server. Finally, the results of total overhead indicate that the proposed scheme outperforms the benchmarks.
In order to show the total computation cost under different numbers of devices, we plot Figure 8. We can observe that compared with the benchmarks, the proposed protocol can bring a lower computation cost. Furthermore, as the number of devices increases, the performance improvement of our protocol becomes more obvious. Therefore, the proposed protocol is more suitable for deployment in the IoT with a large number of devices.
5.2. Storage Cost Analysis
Here, we provide the comparison of the store overhead between the proposed protocol and the benchmarks. The store cost consists the space-consuming of the device in the registration phase and the authentication phase. In the analysis process, SHA- and bn are used as the hash function and elliptic curve, respectively.
According to Figure 2, the storage information at the device includes , , and . So the storage space required at the device side is bits in the registration phase. As Figure 3 shown, the storage space required by the server is bits in the authentication phase. The storage overhead of the benchmarks is calculated in the same way, and the detailed data is shown in Table 4. To show the comparison results more visually, we provide Figure 9. We can observe that the storage space required by the LAAP protocol at the device is consistent with the minimum storage required by the benchmarks, and the store overhead at the server only be higher than the protocol in [11]. Thus, our protocol requires higher storage overhead than the protocol in [11] but lower than other protocols in [9, 10, 15].
5.3. Communication Cost Analysis
Finally, we provide the comparison of the communication cost between the proposed protocol and the benchmarks. Similarly, the communication cost consists the consumption of the device in the registration phase and the authentication phase.
According to Figure 2, the information transmitted by the device includes , , , and . So the communication cost in the registration phase is bits. As Figure 3 shown for the proposed protocol, the communication overhead at the server is bits in the authentication phase. The communication overhead of the benchmarks is calculated in the same way and the detailed data is shown in Table 5..
We further provide Figure 10 to show the detailed comparison. We can see from Figure 10 that the communication overhead of the proposed protocol in the registration phase is slightly higher than the benchmarks. That is due to the fact that the proposed protocol takes necessary encryption measures to ensure public channel registration. However, the proposed protocol takes the lowest communication overhead. Considering that in practical applications, the number of registration stages is much less than the number of authentication stages, it is acceptable to increase the overhead of registration stage slightly. We can also find that the proposed protocol has the lowest total communication overhead and an average of reduction in terms of communication overhead compared to other protocols.
5.4. Performance Analysis under Different Number of Devices
To verify the performance of the proposed protocol under a large number of devices, the stress testing tool GO-WRK and custom scripts are used in this subsection to analyze the performance of the device registration module, server registration module, and identity authentication module of the system.
We first analyze the average response time for different numbers of the devices in the registration phase in Table 6. We can see that when the number of registered devices is less than , the server has a relatively fast response rate, and the average response time is ms. When the number of registered devices is greater than , the response time increases proportionally as the number of devices increases. It indicates that when the number of registrations is higher than , the system performance is saturated and all resources are fully utilized.
Then, we provide Table 7 to show the average cost under the different number of devices in the certificate phase. As shown in Table 7, under the LAAP protocol, the average time consumption of the devices is ms, and as the number of concurrent devices increases, the device time consumption is basically stable. When the server does not reach saturation, the server takes an average of ms. After the server reaches saturation, the response time of the server increases with the number of concurrent authentication devices. The saturation threshold of the server is devices. In the case of a single server, the server can quickly complete the authentication and key negotiation of devices.
6. Conclusion
In this work, we proposed a lightweight anonymous authentication protocol named LAAP against asynchronous attacks to realize the anonymous authentication between device and server in the IoT. Through informal security analysis and formal security analysis, we found that the proposed protocol has the following advantages: (1) it can solve the problem that the device identification is fixed and easy to be tracked by dynamically updating the identification; (2) the hashing chain value of communication devices can be adaptively synchronized to resist asynchronization attack; (3) the time complexity of finding the registration information of the device through the anonymous identity of the device is . Besides, extensive results were provided to indicate that the total overhead is lower than the benchmarks.
Note that this work only considers identity authentication within a single network domain. Therefore, the lightweight anonymous authentication of the IoT across network domains will be the future research direction. In addition, using the intelligent algorithms [32] to optimize our methods and solve the authentication of large-scale heterogeneous devices are also the future research.
Data Availability
The data used to support the findings of this study are included within the article.
Conflicts of Interest
The authors declare that there are no conflicts of interest.
Acknowledgments
This work was supported in part by the National Key R&D Program of China (Grant No. 2018YFE0207600), the National Natural Science Foundation of China (NSFC) under Grant 61972308, the Basic and Applied Basic Research Fund of Guangdong Province (Grant No. 2021A1515111017), and the Natural Science Basic Research Program of Shaanxi (Program No. 2019JC-17).