Abstract
With the rapid development of mobile communication technology, the spatial information networks (SIN) have been used for various space tasks’ coverage in commercial, meteorology, emergency, and military scenarios. In SIN, one basic issue is to achieve mutual authentication and secret communication among the participants. Although many researches have designed authentication schemes for SIN, they have not considered the situation where the clock is not synchronized as the broad coverage space in wireless environment. In this paper, we disclose several flaws of Altaf et al.’s scheme (2020), in which the main weakness is that a malicious user can easily obtain the master key of the network control center after launching the offline password-guessing attack. Then, we design an authentication scheme against clock asynchronous for SIN by utilizing elliptic curve cryptosystem (ECC) and identity-based cryptography (IBC). Based on a brief introduction to the main design ideas of our scheme, the security protocol analysis tools of Scyther and AVISPA are used to prove that the scheme can resist various existing active and passive attacks. We further discuss our scheme that provides five essential requirements of security properties to design a robust scheme for SIN and is superior in terms of resistance to security functionality and computational performance by comparison with two other representative schemes. As a result, our scheme will be workable and efficient security for mobile users in the actual environment.
1. Introduction
As the pace of human exploration has spread across the entire Earth and even the deep universe, spatial information networks (SIN) have been proposed to meet the rapidly growing needs of mobile communications. SIN is a backbone communication network composed of multiple satellites in orbit and a satellite constellation, which is intrinsically a radio-based transmission medium in the wireless mobile environment [1]. It can provide communication and broadcasting services for various space tasks in professional, commercial, military, and emergency scenarios as it overcomes the shortcomings of geographic and environment limitations in traditional personal communication systems (e.g., LTE-A networks and Wi-Fi) [2]. Therefore, users will be more willing to access SIN to obtain network services, which has become a hot spot in global research today. In SIN, the typical model is the low-earth-orbit satellite communications () system [2, 3], which consists of the low Earth orbit satellites (), the ground station/gateway (), the network control center (), and mobile users (), as shown in Figure 1.
Recently, quite a lot of access authentication protocols have been designed for system [4–22], but many schemes in the literature only provide unilateral or ineffective properties. For detailed literature research introduction, we refer readers to [21]. In 2020, Altaf et al. [22] proposed a lightweight authentication scheme for system and claimed that it is protected against all possible security threats. However, we discover that their scheme is vulnerable to several drawbacks. Firstly, it has offline password-guessing attack because the smartcard records sensitive data during the registration phase. After lunching the above attack, a malicious user can easily get the secret number of the master control server, which is a crucial parameter to the entire system. Secondly, it is a common weakness that most protocols apply the freshness of timestamp to verify the validity of the message, which are not suitable for clock asynchronous environment as highly exposed links and extremely high propagation delay in SIN [23–25]. To overcome the shortcomings, we utilize elliptic curve cryptosystem (ECC) and identity-based cryptography (IBC) to design an efficient authentication scheme against clock asynchronous for SIN.
On the basis of analyzing the related scheme, we summarize several essential requirements of security and functionality which should be premeditated for designing a robust scheme in system:(1)Valid mutual authentication: All joined entities in a communication system should identify each other and communicational messages should be authenticated to come from the original sender. Compared with identity authentication, information authentication should be verified more carefully because it is usually overlooked and eavesdropped in a system.(2)Data confidentiality and integrity: It is well accepted to keep the data secrecy. Apart from that, the data integrity is also crucial. To protect the data integrity, an effective scheme should have the ability to detect the data manipulation including insertion, deletion, and substitution.(3)No sensitive data maintained by the and : In order to achieve mutual authentication between the and , a simple scheme should avoid sensitive data stored in both terminals, such as the verifier table in ’s terminal and the values stored in ’s mobile device.(4)Perfect session key secrecy: All session keys used to encrypt the exchange data between the and are kept in secret and the compromise of session keys does not divulge the forward/backward session keys.(5)User’s privacy: Any information of should be protected from outsiders and some vital information, such as password, should be even kept secret from .(6)Fast computation and few communication costs: On one hand, large storages and high calculations will be worthless in ’s lightweight equipment as its resource is constrained; on the other hand, due to the need for multiple forwarding and exposure to the wireless environment, the fewer communication costs each time, the better.
The rest of this paper is organized as follows. Section 2 provides necessary techniques used in this paper. In Section 3, we review Altaf et al.’s scheme and point out the security weaknesses in detail. The proposed scheme is introduced in Section 4. Results and discussion of our scheme are given in Section 5. Finally, we draw some concluding remarks of this paper in Section 6.
2. Technical Background
2.1. Elliptic Curve Cryptosystem (ECC)
ECC was firstly put forward by Miller [26] and Koblitz [27] to design public key cryptosystem. It gives more security with less bit size key and faster computation than traditional public key cryptography. For example, Hankerson et al. [28] pointed out that 160-bit ECC and 1024-bit RSA or DLP has the same security level in practice. Hence, it has been widely used in several cryptographic schemes to provide desired level of security and adequate computational efficiency [29–32].
In this section, we just give a simple description of the ECC defined over a prime field . A nonsingular or secure elliptic curve over is defined by an equation , ,and with the discriminant . Then, the set can form a cyclic additive elliptic curve group, where point is identity element of . Let be a base of with an order , since for the smallest integer . The point multiplication on group is defined as . Details of elliptic curve group properties are given in [28].
2.2. Computational Problem
(1)Discrete logarithm problem (DLP): Assume that is a generator of , where is a finite multiplicative cycle group and is a prime number. Given , find a number such that is difficult.(2)Elliptic curve discrete logarithm problem (ECDLP): Consider two points ; then find a number such that is impossible, where is cyclic additive elliptic curve group.(3)Computational Diffie-Hellman problem (CDHP) on ECC: Assume that there are three known points for , where all belong to group . Then, the computation of is also hard to .(4)Collision attack assumption 1 (k-CAA1) [30]: Assume that there exist a positive integer and some values , where , with ; then it is even difficult to explore the value .
2.3. Adversarial Model
In this section, we give the threat attack model, where the main reference is Dolev-Yao adversary threat model [33]. In 5.1, we will use this model to simulate the attack on our proposed scheme with the formalization tool Scyther. The result of the attack path is shown in Figure 2. The detailed descriptions of Dolev-Yao adversary threat model are as follows:(1)Adversary can eavesdrop and intercept all messages passing through the network.(2)Adversary can store and send the intercepted or self-constructed messages.(3)Adversary can participate in the operation of the protocol as a legal subject. In addition to this, since our scheme uses smart cards, we assume that the attacker has the following capability, which can be used to launch offline password-guessing attacks [34]. However, we will give the detailed description of how the proposed scheme can prevent this attack in the overall design idea of our scheme in Section 5.1.(4)The power analysis or side-channel attacks can help the attacker to extract the secret information stored in user’s smart card.
(a)
(b)
3. Altaf et al.’s Scheme and Its Weaknesses
This section reviews Altaf et al.’s scheme [22] and points out its flaws. As shown in Figure 1, there are mainly 3 types of participants in their scheme: a mobile (), network control center (), and the low-Earth-orbit satellites (). The notations used in this paper are defined in Table 1.
3.1. Altaf et al.’s Protocol
Altaf et al.’s protocol consists of registration phase and login and authentication phase, which are presented in Figure 3.
3.1.1. Registration Phase
When wanting to get the servers from , has to register to as in the following steps: Step 1: chooses his/her identity and password and generates a random number . Then, calculates . After that, sends the registration message to via a secure channel. Step 2: After receiving request message from , computes the following operations: , , and . Next, records the values into a smart card and delivers it to through a secure channel. Step 3: When getting , computes and writes the value into . Finally, stores the values
3.1.2. Login and Authentication Phase
When wishes to login to , the following steps are executed between and with the help of satellite: Step 1: inserts and enters his/her to compute , , , and . Then, verifies the condition . If , rejects this login of ; otherwise, randomly generates a number to calculate , , , and . Afterwards, sends to . Step 2: On receiving the login message from , forwards the message to . Step 3: When getting the message, checks the freshness of timestamp by verifying the condition . If is not permissible to the , this session is terminated; otherwise, computes , , , and and checks . If , thinks that is real and generates a random number . Next, it calculates , , and to send to finally. Step 4: Upon receiving response message, forwards to . Step 5: After receiving the message, checks the freshness of timestamp by verifying . If , authenticates and computes , , and . If , and achieve mutual authentication and negotiate a shared secret key.
Remark 1. There are two flows in this phase of Altaf et al.’s protocol. The first is the inconsistency operation between the flow chart display in Figure 4 of and the description in Step AP1 of . The second is that should append ’s identity information when sending this message to , instead of sending its own identity to , because only needs to have identity confirmation with in the system.
3.2. Security Analysis of Altaf et al.’s Scheme
In this section, we carefully make security analysis of Altaf et al.’s scheme [22]. Firstly, we review the adversarial model in their article, which supposed that has the following abilities when attacking the efficiency and security of their scheme:(1) can access the full public communication channel to modify, replay, amend, and intercept the confidential information.(2) can extract the secret information stored in user’s smart card with the help of power analysis.(3) can cheat the user by making the legitimate member of that system.
3.2.1. Offline Password-Guessing Attack
This section describes how a malicious attacker can obtain the private key of after launching the above attack in Altaf et al.’s protocol. The details are given in the following steps: Step 1: According to the adversarial model of (3), can register in network control center like a normal user. Firstly, computes with arbitrary selection of identity , password , and a random number . Then, records the values and sends to . Step 2: After receiving the login message from , calculates , , and . Then, it will issue a smart card recoding the values to . Step 3: Based on the adversarial model of (1), can extract the values and after getting . Next, computes and records the value . Step 4: Since , can launch the offline password-guessing attack by implementing Algorithm 1.
| ||||||||||||||||
Although this algorithm may take a long time to execute, will be willing to keep trying as network control center utilizes the private key for authenticating all the users, which is a crucial parameter to the whole system. Therefore, the protocol proposed by Altaf et al. is vulnerable to the above attack. The same attack can be also implemented in Sharif et al.’s scheme [21].
3.2.2. Inability to Deal with the Clock Asynchronous Situation
In Altaf et al.’s scheme, the validity of the message from is first verified by checking the condition , where is the timestamp transmitted from , is the current timestamp of , and is an estimated time delay by the system. As we all know, the propagation delay is usually large between the satellite and the ground. Even for low-Earth-orbit () satellites, there is a propagation delay of 10 to 40 milliseconds due to the transmission distance of 500 to 2,000 kilometers [2]. What is more, since the satellite only forwards the authentication message, the protocol at least needs two signal transmission delays between and (the uplink between mobile user and satellite and the downlink between satellite and ground station, regardless of transmission delay between gateway and , based on Figure 1), which will result in unacceptable access delay. Thus, it is very difficult for the entire system to estimate a uniform time delay, which may cause widespread denial of service for users.
Apart from that, users in some professional fields, such as scientists who perform north-south pole expeditions, may not be able to synchronize time with their mobile terminals due to the inability to communicate with synchronous satellites or other reasons in the actual environment. Obviously, Altaf et al.’s scheme is unable to deal with this clock asynchronous situation, while SIN covers all corners of the Earth and even deep space. Moreover, none of the existing schemes [19–21] take this situation into consideration.
4. Our Protocol
We introduce a novel authentication and key agreement protocol against clock asynchronous for SIN in this section. The proposed scheme mainly utilizes elliptic curve cryptosystem (ECC) and identity-based cryptography (IBC) to achieve sufficient security and authentication. There are 4 phases in our enhanced protocol: (1) initialization phase, (2) registration phase, (3) login and authentication phase, and (4) password-change phase. The detailed implementation of the middle two stages is shown in Figure 4.
4.1. Initialization Phase
Since our scheme is based on ECC, this phase is different from prerelevant schemes which can be divided into four steps as follows: Step 1: chooses a secure elliptic curve equation and a generator point of the cyclic additive elliptic curve group with order , where is an -bit prime number. Step 2: selects a random number as its private key and computes the corresponding public key . Step 3: picks a one-way key derivation function , which is mainly used to generate shared session password. Step 4: publishes as the system parameters and keeps its master key secret.
4.2. Registration Phase
If a mobile user wants to register to the system, this phase is performed only once as follows: Step 1: freely chooses a valid identity and password to enter into his/her mobile device, such as a smartphone. The identity can be combined by any one of ’s name, e-mail address, social security number, or other identity attributes as his/her public key for a unique signature. Next, the device collects ’s biometric to compute . Then, the device sends the message to through a secure channel. Step 2: After receiving the message, the server first calculates to check whether has been registered in the verifier table. If it has been registered, is asked to select a new identity. Otherwise, calculates the following operations: After that, inserts into the verifier table () and delivers the message to via the secure channel, where is a nonce. Step 3: On getting the response message, stores the values in his/her mobile device for later use in the login process.
Remark 2. The nonce is a unique value randomly generated by and is frequently used to avoid the replay attack. Here, we further apply it as a mechanism to combat the asynchronous clock scenario, which will be discussed at the end of Section 4.3.
Remark 3. There may be two approaches for to deliver the message to : One way is offline method where records into a smartcard and issues it to . The other way is online method where connects to through the Internet Key Exchange Protocol version 2 (IKEv2) [35] or Secure Socket Layer (SSL) Protocol [33]. The message will be encrypted for transmission.
4.3. Login and Authentication Phase
This part introduces the user login system process and the mutual authentication between and the . The detailed description is as follows: Step 1: When intends to communicate with others or get service from via the system, provides , , and to his/her mobile device. The device computes and it determines whether or not, where has been recorded in the device. If , the device randomly selects and calculates the operations as follows: Then, the device sends to . Step 2: After getting the message, forwards to . Step 3: When obtaining the message, calculates Next, uses to find the matching in the verifier table. If it is not found, refuses the request of ; otherwise, it computes and it checks . If , authenticates CS and generates a nonce to compute the operations Then, records nonce next to in the verifier table and sends to . Step 4: After getting the message, forwards to . Step 5: On receiving the reply message from , computes
Then, checks . If , confirms that are authentic and updates as in the mobile device. As a result, and realize mutual authentication and negotiate a shared secret key:
Remark 4. We briefly derive the consistency operations in this phase as follows:
Remark 5. In Step 3, records nonce next to rather than updating as . This means that keeps until receiving ’s next login message including the value . At this time, will produce a new nonce and then will update to and to . In a word, always keep two fresh numbers related to in the verifier table except the first login. The designed mechanism mainly fights against the denial of service attack due to the nonce between and being out of sync. We call this scenario “desynchronization challenge” as shown in Figure 5. “Successful authentication” means that has authenticated and updated to . Then, can apply the shared secret key to encrypt the next traffic with , namely, “Data Exchange Phase.” The failure indicates cannot authenticate because the message was tampered with by an attacker or interfered with the poor wireless environment. Then, “desynchronization challenge” is invoked. Since still holds the fresh number , can continue to send login request information with .
4.4. Password-Change Phase
Whenever wants to update his/her password to a new , this phase is activated without communication with . Firstly, provides , , and to his/her mobile device and asks for changing the password. Then, the device will automatically perform as follows: Step 1: The device computes , , and . It checks . If , it rejects ’s password change. Otherwise, the device prompts for a new password . Step 2: After enters , the device calculates , and . Finally, the device replaces the original with in the memory separately.
5. Results and Discussion
This section discusses security analysis of our protocol. Firstly, we give the overall design ideas of the proposed protocol. Then, the two security protocol analysis tools of Scyther and AVISPA simulate the implementation of our scheme. We further analyze how the proposed scheme can fulfill the five essential properties. Finally, the performance comparisons of our protocol with others are described briefly.
5.1. Overall Design Idea of Our Scheme
In our protocol, we utilize two symmetric keys between and . The first symmetric secret key is , which is established by calculating during the user registration process. In addition to the authentication of both parties, is also used to verify the integrity of the messages , , and and generate the shared secret key , which is used to encrypt information in the data exchange phase. If wants to obtain , it can only be obtained through brute-force calculation, because is protected by ’s real identity and ’s master key . However, according to 4th difficult calculation problem K-CAA1 in Section 2.3, it is impossible for to launch brute-force calculation to get this value, such as the offline password-guessing attack used in our attack on Altaf et al.’s scheme.
The second symmetric cipher is , which is secured by calculating ECDLP and CDHP on ECC. On the one hand, obtains by intercepting the message through the public channel. According to ECDLP, cannot obtain the value of by calculating , and it is also impossible to obtain the server’s master key by operating . On the other hand, if obtains and , it is also impossible to obtain , because, according to and to find , this is equivalent to calculating CDHP on ECC. The key is mainly used to protect ’s real identity and to realize the verification of the server signature by computing .
5.2. Simulation Analysis Using Scyther and AVISPA
This section presents simulation of the proposed protocol using widely accepted security protocol analysis tools of Scyther and AVISPA. During simulating the implementation of the scheme, Scyther can detect the reachability of the message among participants and discover the attack path initiated by a pretender. The AVISPA simulation tool sets up various attack models internally to test whether the protocol is SAFE or UNSAFE. The detailed instructions of Scyther can be found in [36, 37] and those of AVISPA can be found in [38, 39], and comparison of these analysis tools can be found in [40].
5.2.1. Simulation Code Description
This section introduces the use of Scyther formal language SPDL (Security Protocol Description Language) and AVISPA formal language HLPSL (High-Level Protocol Specification Language) to model our scheme.(1)Simulation code in Scyther SPDL: Figure 6 presents the simulation code of our protocol with the Scyther SPDL. Two hash functions and a simulated elliptic curve function (ECC) are defined at the beginning of SPDL simulation code. The ECC is modeled as public key encryption, where has a private key . Next, 3 roles in the scheme are defined: “role I″ simulates ; “role R” presents ; “role LEOS” indicates . Here, we take role as an example to introduce the SPDL code, which is mainly presented on the left of Figure 6. After defining the variables required for session protocol, user-side operations are mainly represented by the collection of events. The “send” and “recv” events mean that sends a message and receives one, respectively. Lines 16 to 19 indicate the event where receives the message from and checks during the login phase. Among them, the 16th line indicates that the symmetric secret key is modeled as ECC function with parameters of ’s private key and ’s identity ; line 17 presents that obtains by ; then, can receive and check , indicated on line 18 and line 19, respectively. Apart from that, the 28th line adds the matching of the verification , which ensures that the attacker cannot construct the message autonomously; the “claim” event in the 30th line is used to describe the authentication of roles and the confidentiality of variables.(2)Simulation code in AVISPA HLPSL: In the HLPSL modeling of our protocol, we first formalize the protocol in CAS+ specification language, as shown in Figure 7(a), and then use the SPAN (Security Protocol ANimator for AVISPA) to automatically convert the CAS+ file into the HLPSL format code in Figure 7(b). The following briefly describes the simulation CAS+ code of our scheme. After defining variables in Figure 7(a), the modeling is basically the same as the Scyther modeling, and the XOR and ECC operations are both expressed by approximate operations. Then, using the Alice-Bob message format, the protocol execution process is clear. Among them, “J”, “L,” and “S” present , , and , respectively; “=>” means encrypted channel, “-” means open channel, and “’” represents the inverse function; for example, “Ks’” is the private key of , while “ks” is the public key here. In lines 19 to 21, each line represents the parameters , , and known during the protocol execution process. The 28th line defines the knowledge of intruder when attacking the security of our scheme. After generating the HLPSL format file from the CAS+ file, we manually add the verification target “secret(KDF(ECC(inv(Ks).H(IDi)).N0.N1),sec1,J,S)” in both and roles and then generate the final HLPSL format code that simulates our protocol. Since the number of HDLS language lines after conversion is relatively large, here we only give role code in Figure 7(b).
(a)
(b)
(a)
(b)
5.2.2. Simulation Results
This section first presents the simulation results of our protocol using Scyther, which is shown in Figure 8. Figure 8(a) is the output report for verifying the reachability of messages among participants and Figure 8(b) presents the attack path search result of shared session secret key . All the analysis results prove that there is no problem in our formalization process, which means that and can securely convey the message and believe in the confidentiality of the negotiated shared session key in our scheme. Then, we verify whether there is an adversary attack on the protocol, that is, the vulnerability of the protocol message being obtained by the adversary. Figure 2 shows output path under the Dolev-Yao adversary threat model [41]. The analysis result indicates that, in the process of mutual authentication between and , the protocol has a impersonation attack because only forwards message and has not been authenticated in the scheme. However, due to the limitations of the nonce and the nonce and the verification message codes and , the attacker cannot construct the message independently and can only replay the message between and this time. Therefore, Scyther test results show that our proposed protocol does not have any threat under various active and passive attacks.
(a)
(b)
Next, we introduce the results of AVISPA analysis. The two back-end analysis results of OFMC and Atse provided by AVISPA are shown in Figure 9, which are both safe (SUMMARY SAFE). These demonstration results indicate that our protocol can achieve the expected security goals. Figure 10 shows the protocol flow chart under intruder simulation. The intruder can obtain the knowledge after the simulation attack is presented in Figure 11. From Figure 11, we can see that obtains values such as , , and by eavesdropping messages transmitted via open channel, but there is no effective attack path. Thus, AVISPA test results also prove that our scheme can resist the various existing active and passive attacks.
(a)
(b)
5.3. Security Properties Analysis
This section describes the essential security properties of our scheme, which we summarize above for designing a robust scheme for a system.
5.3.1. Valid Mutual Authentication
In our protocol, first verifies the authenticity of ’s identity by verifying and then verifies the validity of by checking . The conditions for and are all guaranteed by the symmetric keys and , where only real can calculate these two secret values as analyzed in the previous section. So, can effectively authenticate . Simultaneously, authenticates by verifying , which directly involves ’s real identity and the symmetric keys . and are only calculated by knowing ’s master key . Therefore, our scheme provides valid mutual authentication to avoid the impersonation attack.
5.3.2. Data Confidentiality and Integrity
The proposed scheme needs to protect three types of data: the random number selected by , the identity of , and the shared session key . is protected by ECDLP as discussed in 5.1; is encrypted and transmitted by the symmetric secret key through the operation ; is bound with and the symmetric key in one-way key derivation operation . For data integrity, it refers to the ability to quickly discover whether messages , , and are inserted, replaced, and deleted. stored in ’s mobile equipment is verified by the condition ; and are verified by checking and , respectively. Moreover, the values , , and are all bound to the symmetric key via hash function . Thus, the new scheme ensures the data confidentiality and integrity in all aspects.
5.3.3. No Sensitive Data Maintained by and
There are only in ’s verifier tables and stored in ’s device in our scheme. is just a nonce and is refreshed every session. As for , may obtain the user’s identity ID through offline password-guessing attacks after penetrating attack to the ’s inside. However, it is meaningless for the entire system as cannot acquire any clues about the ’s password and ’s master key. For data stored in ’s mobile device, and are only used in the beginning of ’s login phase and neither reveals the key parameters of the system. So, none of sensitive data are maintained by and in our scheme.
5.3.4. Perfect Session Key Secrecy
The shared session key is derived from , which is enclosed by the nonce and the nonce , which are refreshed every session. Therefore, even if th session key is leaked this time, it will not cause the previous or next session key to be compromised.
5.3.5. User’s Privacy
The scheme mainly involves three types of personal privacy of : identity , password , and biometric . At first, registers by submitting , where , in order to keep the secret password and biometric of from . Then, during the login and authentication phase, the pseudoidentity , which is derived from , is transmitted via public channel instead of the real . Therefore, any privacy information related to is enclosed in our scheme.
5.4. Performance Comparisons
In the following, we concretely compare our protocol with the other two protocols [21, 22] in terms of resistance to security functionality and computational performance. In 2019, Sharif et al. [21] compared their proposed protocol with 6 other related protocols in detail in terms of security features and computing performance and claimed that their protocol had obvious advantages in security features. Similarly, Altaf et al. [22] pointed out that their protocol had great advantages compared with the other 4 protocols in 2020. So, we simply give a comparison with these two representative articles. Moreover, Sharif et al.’s scheme is also designed using elliptic curve cryptography, and Altaf et al.’s scheme also uses public key and secret key algorithms, which is not specified in their article.
In Table 2, we list the 6 general security properties and 2 security attacks for designing a robust authentication protocol for SIN. In addition to the above 6 functions, the newly proposed protocol can resist other attacks, such as impersonation attack, DoS attack, man-in-the-middle attack, smart card loss attack, and replay attack. The results in Table 2 show the superiorities of our protocol in terms of resisting offline password-guessing attack and against clock asynchronous situation.
As we all know, always has no limitation with enough powerful servers. Although the most expensive operation is the point multiplication elliptic curve in the related protocol, it takes only 46 microseconds to execute the 160-bit elliptic curve point multiplication on the Intel Core-i7 processor [42]. Therefore, we only compare the efficiencies of different operations in ’s mobile device in Table 3, which refers to Table 11 in [21]. For the convenience of evaluating the computational cost, we assume that the public key and secret key algorithms in Altaf et al.’s scheme [22] are also elliptic curve cryptography, as mainly considering 160-bit ECC has the same security level as 1024-bit RSA or DLP in practice. In addition, it is generally accepted that XOR operation execution time can be ignored, as it consumes very little time.
Furthermore, we have considered communication cost in the last line of Table 4. We suppose that each length of parameter is roughly the same in [21]: the size of a random number/nonce to be 64 bits, a hash output to be 256 bits, an identifier/timestamp to be 32 bits, and an ECC point to be 384 bits for the communication cost as we also use this length in calculation time. In our scheme, the receives from ’s login request message and sends to at last. Thus, the total communication cost bits of and are 1440 bits. Table 4 demonstrates that our protocol is more efficient than the other two protocols as it uses the least times and far less communication cost bits.
6. Concluding Remarks
In this article, we deeply study the authentication schemes for SIN. We disclose that Altaf et al.’s protocol has fatal security drawbacks and point out that many protocols in the literature cannot handle the clock asynchronous situation. Because SIN mainly transmits information through wireless signals and covers a wide range of services, it often happens when users’ mobile devices cannot achieve clock asynchronous situation in the actual environment. To overcome these security challenges, we introduced a lightweight pseudonym identity-based authentication and key agreement scheme using ECC and IBC. To strengthen the security of our scheme, we first introduced the main ideas of the entire protocol design. Then, the security protocol analysis tools of AVISPA and Scyther are both utilized to simulate the proposed scheme and the analysis results prove that our scheme can resist the various existing attacks. We further discussed essential security properties of the proposed scheme, which meets the requirements to design a robust scheme for a system. Moreover, we concretely compare our protocol with the relatsed protocols in terms of security requirements, computational performance, and computational cost. All the results show that our protocol is superior to the other two representative protocols. Actually, our protocol will be well suited for mobile users in SIN.
Data Availability
The corresponding author shall keep the analysis and full simulation code set. If necessary, the data set can be requested from the corresponding author for reasonable requirements.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported by the National Key Research and Development project (no. 2019QY0501) and the National Natural Science Foundation of China (no. 2904020211).