# An Efficient ECC-Based Authentication Scheme against Clock Asynchronous for Spatial Information Network

Authors: Huihui Huang; Xuyang Miao; Zehui Wu; Qiang Wei
Journal: Mathematical Problems in Engineering
 (2021)

---

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


---

## Body

## 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 (LSC) system [2, 3], which consists of the low Earth orbit satellites (LEOS), the ground station/gateway (G), the network control center (NCC), and mobile users (U), as shown in Figure 1.Figure 1
A low Earth orbit satellite communications system.Recently, quite a lot of access authentication protocols have been designed forLSC 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 LSC 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 inLSC 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 aLSC 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 theNCC and U: In order to achieve mutual authentication between the NCC and U, a simple scheme should avoid sensitive data stored in both terminals, such as the verifier table in NCC’s terminal and the values stored in U’s mobile device.(4)
Perfect session key secrecy: All session keys used to encrypt the exchange data between theNCC and U are kept in secret and the compromise of session keys does not divulge the forward/backward session keys.(5)
User’s privacy: Any information ofU should be protected from outsiders and some vital information, such as password, should be even kept secret from NCC.(6)
Fast computation and few communication costs: On one hand, large storages and high calculations will be worthless inU’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. Section2 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 fieldFp . A nonsingular or secure elliptic curve Fpa,b over Fp is defined by an equation y2=x3+ax+bmodp, a,b∈Fp ,and with the discriminant Δ=4a3+27b2≠0modp. Then, the set Gp=x,y|x,y∈Fpandx,y∈Epa,b∪O can form a cyclic additive elliptic curve group, where point O is identity element of Gp . Let P be a base of Gp with an order n, since nP=O for the smallest integer n>0. The point multiplication on group Gp is defined as kP=P+P+⋯+Pktimes. Details of elliptic curve group properties are given in [28].


### 2.2. Computational Problem

(1)
Discrete logarithm problem (DLP): Assume thatg is a generator of Zp∗ , where Zp∗ is a finite multiplicative cycle group and p is a prime number. Given b,g∈Zp∗ , find a number a∈Zp∗ such that b=gamodp is difficult.(2)
Elliptic curve discrete logarithm problem (ECDLP): Consider two pointsQ,P∈Gp ; then find a number k∈1,n−1 such that Q=kP is impossible, where Gp is cyclic additive elliptic curve group.(3)
Computational Diffie-Hellman problem (CDHP) on ECC: Assume that there are three known pointsP,aP,bP for a,b∈1,n−1 , where all belong to group Gp . Then, the computation of abP is also hard to Gp.(4)
Collision attack assumption 1 (k-CAA1) [30]: Assume that there exist a positive integer k and some values P,xP,h0,h1,x+h1−1P,…,hk,x+hk−1P, where P∈Gp, x,h,∈Zn∗ with 0≤i≤k; then it is even difficult to explore the value h0+x−1P.


### 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.Figure 2
Attack path under the Dolev-Yao model using Scyther. (a) Path ofUi authenticating NCCs. (b) Path of NCCs authenticating Ui.
(a)(b)


## 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 fieldFp . A nonsingular or secure elliptic curve Fpa,b over Fp is defined by an equation y2=x3+ax+bmodp, a,b∈Fp ,and with the discriminant Δ=4a3+27b2≠0modp. Then, the set Gp=x,y|x,y∈Fpandx,y∈Epa,b∪O can form a cyclic additive elliptic curve group, where point O is identity element of Gp . Let P be a base of Gp with an order n, since nP=O for the smallest integer n>0. The point multiplication on group Gp is defined as kP=P+P+⋯+Pktimes. Details of elliptic curve group properties are given in [28].


## 2.2. Computational Problem

(1)
Discrete logarithm problem (DLP): Assume thatg is a generator of Zp∗ , where Zp∗ is a finite multiplicative cycle group and p is a prime number. Given b,g∈Zp∗ , find a number a∈Zp∗ such that b=gamodp is difficult.(2)
Elliptic curve discrete logarithm problem (ECDLP): Consider two pointsQ,P∈Gp ; then find a number k∈1,n−1 such that Q=kP is impossible, where Gp is cyclic additive elliptic curve group.(3)
Computational Diffie-Hellman problem (CDHP) on ECC: Assume that there are three known pointsP,aP,bP for a,b∈1,n−1 , where all belong to group Gp . Then, the computation of abP is also hard to Gp.(4)
Collision attack assumption 1 (k-CAA1) [30]: Assume that there exist a positive integer k and some values P,xP,h0,h1,x+h1−1P,…,hk,x+hk−1P, where P∈Gp, x,h,∈Zn∗ with 0≤i≤k; then it is even difficult to explore the value h0+x−1P.


## 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.Figure 2
Attack path under the Dolev-Yao model using Scyther. (a) Path ofUi authenticating NCCs. (b) Path of NCCs authenticating Ui.
(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 (Ui), network control center (NCCs), and the low-Earth-orbit satellites (LEOSq). The notations used in this paper are defined in Table 1.Table 1
Notations used in this paper.
SymbolDescriptionLSCLow-earth-orbit satellite communications systemUiMobile userNCCsNetwork control centerLEOSqLow-Earth-orbit satelliteAdvAttackerIDiIdentity ofUiIDleosIdentity ofLEOSqSCiSmart card issued to each specificUiPiPassword ofUini,biRandom numbers generated byUinsRandom numbers generated byNCCsmsk,mpkPrivate/public key ofNCCsSKShare session keyT1,T2TimestampPPoint multiplicationh·Hash function:0,1l⟶0,1n⊕Bitwise XOR operation∥Concatenate operation


### 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 Figure3.Figure 3
Implementation of Altaf et al.’s scheme.


#### 3.1.1. Registration Phase

When wanting to get the servers fromNCCs, Ui has to register to NCCs as in the following steps:Step 1:Ui chooses his/her identity IDi and password Pi and generates a random number ni. Then, Ui calculates P¯i=hIDiPini. After that, Ui sends the registration message IDi,P¯i to NCCs via a secure channel.Step 2: After receiving request message fromUi, NCCs computes the following operations: Xi=hIDi‖msk, Yi=Xi⊕P¯i, and Mi=hP¯iXiIDi . Next, NCCs records the values Yi,Mi,h· into a smart card SCi and delivers it to Ui through a secure channel.Step 3: When gettingSCi , Ui computes Ei=ni⊕hIDi‖Pi and writes the value Ei into SCi. Finally, SCi stores the values Yi,Mi,Ei,h·


#### 3.1.2. Login and Authentication Phase

WhenUi wishes to login to NCCs, the following steps are executed between Ui and NCCs with the help of LEO satellite:Step 1:Ui inserts SCi and enters his/her IDi∗,Pi∗ to compute ni∗=Ei⊕hIDi∗‖Pi∗, P¯i∗=hIDi∗Pi∗ni∗, Xi∗=Yi⊕P¯i∗, and Mi∗=hP¯i∗Xi∗IDi∗. Then, SCi verifies the condition Mi∗=?Mi. If Mi∗≠Mi, SCi rejects this login of Ui; otherwise, SCi randomly generates a number bi to calculate Qi=biP, Vi=bi.mpk, PIDi=Vi⊕IDi, and Authi=hIDi‖Bi‖PIDi‖T1. Afterwards, SCi sends PIDi,Authi,Qi,T1 to NCCs.Step 2: On receiving the login message fromUi, LEOSq forwards the message PIDi,Authi,Qi,T1,IDLEOSq to NCCs.Step 3: When getting the message,NCCs checks the freshness of timestamp by verifying the condition T1−Ts≤?ΔT. If ΔT is not permissible to the NCCs, this session is terminated; otherwise, NCCs computes Vi∗=msk.Qi , IDi=Vi∗⊕PIDi , Bi=hIDi‖msk, and Authi∗=hIDi‖Bi‖PIDi‖T1 and checks Authi∗=?Authi] . If Authi∗=Authi , NCCs thinks that Ui is real and generates a random number ns.    Next, it calculates Ws=ns⊕hIDi‖T2 , SK=hIDi‖Xi‖ns‖T2, and Auths=hIDi‖SK‖Xi‖ns‖Vi∗‖T2 to send Ws,Auths,T2,IDLEOSq to LEOSq finally.Step 4: Upon receiving response message,LEOSq forwards Ws,Auths,T2 to Ui.Step 5: After receiving the message,Ui checks the freshness of timestamp by verifying T2−Tr≤?ΔT . If T2−Tr≤ΔT , Ui authenticates NCCs and computes ns=Ws⊕hIDi‖T2 , SK∗=hIDi‖Xi‖ns‖T2, and Auths∗=hIDi‖SK∗‖Xi‖ns‖Vi‖T2 . If Auths∗=Auths , Ui and NCCs 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 Figure4 of P¯i∗=hPi∗‖IDi∗‖ni∗ and the description in Step AP1 of P¯i∗=hIDi∗‖Pi∗‖ni∗. The second is that NCCs should append LEOSq’s identity information when sending this message Ws,Auths,T2,IDLEOSq to LEOSq, instead of LEOSq sending its own identity to Ui, because LEOSq only needs to have identity confirmation with NCCs in the LSC system.Figure 4
Implementation of two stages in our scheme.


### 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 Adv has the following abilities when attacking the efficiency and security of their scheme:(1)
Adv can access the full public communication channel to modify, replay, amend, and intercept the confidential information.(2)
Adv can extract the secret information stored in user’s smart card with the help of power analysis.(3)
Adv 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 keymsk of NCCs 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), Adv can register in network control center like a normal user. Firstly, Adv computes P¯Adv=hIDAdv‖PAdv‖nAdv with arbitrary selection of identity IDAdv , password PAdv, and a random number nAdv . Then, Adv records the values P¯Adv,IDAdv and sends IDAdv,P¯Adv to NCCs.Step 2: After receiving the login message fromAdv , NCCs calculates XAdv=hIDAdv‖msk, YAdv=XAdv⊕P¯Adv, and MAdv=hP¯Adv‖XAdv‖IDAdv. Then, it will issue a smart card SCAdv recoding the values YAdv,MAdv,h· to Adv.Step 3: Based on the adversarial model of (1), Adv can extract the values YAdv and h· after getting SCAdv. Next, Adv computes XAdv=YAdv⊕P¯Adv and records the value XAdv.Step 4: SinceXAdv=hIDAdv‖msk, Adv can launch the offline password-guessing attack by implementing Algorithm 1.Algorithm 1: Offline password-guessing attack.
Input: XAdv, IDAdv and h·.Output: msk , which is the private key only known to NCCs.(1)
Adv generates a random number and takes it as key msktmp(2)
AdvComputes Xtmp=hIDAdv‖msktmp(3)
IfXtmp==XAdvthenReturn (msktmp)elseGo to 1 until correct key is obtainedAlthough this algorithm may take a long time to execute,Adv will be willing to keep trying as network control center NCCs 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 messagePIDi,Authi,Qi,T1,IDLEOSq from Ui is first verified by checking the condition T1−Ts≤?ΔT, where T1 is the timestamp transmitted from Ui , Ts is the current timestamp of CNNs, and ΔT 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 (LEO) 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 Ui and CNNs (the uplink between mobile user and satellite and the downlink between satellite and ground station, regardless of transmission delay between gateway and NCCi, 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.


## 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 Figure3.Figure 3
Implementation of Altaf et al.’s scheme.


### 3.1.1. Registration Phase

When wanting to get the servers fromNCCs, Ui has to register to NCCs as in the following steps:Step 1:Ui chooses his/her identity IDi and password Pi and generates a random number ni. Then, Ui calculates P¯i=hIDiPini. After that, Ui sends the registration message IDi,P¯i to NCCs via a secure channel.Step 2: After receiving request message fromUi, NCCs computes the following operations: Xi=hIDi‖msk, Yi=Xi⊕P¯i, and Mi=hP¯iXiIDi . Next, NCCs records the values Yi,Mi,h· into a smart card SCi and delivers it to Ui through a secure channel.Step 3: When gettingSCi , Ui computes Ei=ni⊕hIDi‖Pi and writes the value Ei into SCi. Finally, SCi stores the values Yi,Mi,Ei,h·


### 3.1.2. Login and Authentication Phase

WhenUi wishes to login to NCCs, the following steps are executed between Ui and NCCs with the help of LEO satellite:Step 1:Ui inserts SCi and enters his/her IDi∗,Pi∗ to compute ni∗=Ei⊕hIDi∗‖Pi∗, P¯i∗=hIDi∗Pi∗ni∗, Xi∗=Yi⊕P¯i∗, and Mi∗=hP¯i∗Xi∗IDi∗. Then, SCi verifies the condition Mi∗=?Mi. If Mi∗≠Mi, SCi rejects this login of Ui; otherwise, SCi randomly generates a number bi to calculate Qi=biP, Vi=bi.mpk, PIDi=Vi⊕IDi, and Authi=hIDi‖Bi‖PIDi‖T1. Afterwards, SCi sends PIDi,Authi,Qi,T1 to NCCs.Step 2: On receiving the login message fromUi, LEOSq forwards the message PIDi,Authi,Qi,T1,IDLEOSq to NCCs.Step 3: When getting the message,NCCs checks the freshness of timestamp by verifying the condition T1−Ts≤?ΔT. If ΔT is not permissible to the NCCs, this session is terminated; otherwise, NCCs computes Vi∗=msk.Qi , IDi=Vi∗⊕PIDi , Bi=hIDi‖msk, and Authi∗=hIDi‖Bi‖PIDi‖T1 and checks Authi∗=?Authi] . If Authi∗=Authi , NCCs thinks that Ui is real and generates a random number ns.    Next, it calculates Ws=ns⊕hIDi‖T2 , SK=hIDi‖Xi‖ns‖T2, and Auths=hIDi‖SK‖Xi‖ns‖Vi∗‖T2 to send Ws,Auths,T2,IDLEOSq to LEOSq finally.Step 4: Upon receiving response message,LEOSq forwards Ws,Auths,T2 to Ui.Step 5: After receiving the message,Ui checks the freshness of timestamp by verifying T2−Tr≤?ΔT . If T2−Tr≤ΔT , Ui authenticates NCCs and computes ns=Ws⊕hIDi‖T2 , SK∗=hIDi‖Xi‖ns‖T2, and Auths∗=hIDi‖SK∗‖Xi‖ns‖Vi‖T2 . If Auths∗=Auths , Ui and NCCs 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 Figure4 of P¯i∗=hPi∗‖IDi∗‖ni∗ and the description in Step AP1 of P¯i∗=hIDi∗‖Pi∗‖ni∗. The second is that NCCs should append LEOSq’s identity information when sending this message Ws,Auths,T2,IDLEOSq to LEOSq, instead of LEOSq sending its own identity to Ui, because LEOSq only needs to have identity confirmation with NCCs in the LSC system.Figure 4
Implementation of two stages in our scheme.


## 3.1.1. Registration Phase

When wanting to get the servers fromNCCs, Ui has to register to NCCs as in the following steps:Step 1:Ui chooses his/her identity IDi and password Pi and generates a random number ni. Then, Ui calculates P¯i=hIDiPini. After that, Ui sends the registration message IDi,P¯i to NCCs via a secure channel.Step 2: After receiving request message fromUi, NCCs computes the following operations: Xi=hIDi‖msk, Yi=Xi⊕P¯i, and Mi=hP¯iXiIDi . Next, NCCs records the values Yi,Mi,h· into a smart card SCi and delivers it to Ui through a secure channel.Step 3: When gettingSCi , Ui computes Ei=ni⊕hIDi‖Pi and writes the value Ei into SCi. Finally, SCi stores the values Yi,Mi,Ei,h·


## 3.1.2. Login and Authentication Phase

WhenUi wishes to login to NCCs, the following steps are executed between Ui and NCCs with the help of LEO satellite:Step 1:Ui inserts SCi and enters his/her IDi∗,Pi∗ to compute ni∗=Ei⊕hIDi∗‖Pi∗, P¯i∗=hIDi∗Pi∗ni∗, Xi∗=Yi⊕P¯i∗, and Mi∗=hP¯i∗Xi∗IDi∗. Then, SCi verifies the condition Mi∗=?Mi. If Mi∗≠Mi, SCi rejects this login of Ui; otherwise, SCi randomly generates a number bi to calculate Qi=biP, Vi=bi.mpk, PIDi=Vi⊕IDi, and Authi=hIDi‖Bi‖PIDi‖T1. Afterwards, SCi sends PIDi,Authi,Qi,T1 to NCCs.Step 2: On receiving the login message fromUi, LEOSq forwards the message PIDi,Authi,Qi,T1,IDLEOSq to NCCs.Step 3: When getting the message,NCCs checks the freshness of timestamp by verifying the condition T1−Ts≤?ΔT. If ΔT is not permissible to the NCCs, this session is terminated; otherwise, NCCs computes Vi∗=msk.Qi , IDi=Vi∗⊕PIDi , Bi=hIDi‖msk, and Authi∗=hIDi‖Bi‖PIDi‖T1 and checks Authi∗=?Authi] . If Authi∗=Authi , NCCs thinks that Ui is real and generates a random number ns.    Next, it calculates Ws=ns⊕hIDi‖T2 , SK=hIDi‖Xi‖ns‖T2, and Auths=hIDi‖SK‖Xi‖ns‖Vi∗‖T2 to send Ws,Auths,T2,IDLEOSq to LEOSq finally.Step 4: Upon receiving response message,LEOSq forwards Ws,Auths,T2 to Ui.Step 5: After receiving the message,Ui checks the freshness of timestamp by verifying T2−Tr≤?ΔT . If T2−Tr≤ΔT , Ui authenticates NCCs and computes ns=Ws⊕hIDi‖T2 , SK∗=hIDi‖Xi‖ns‖T2, and Auths∗=hIDi‖SK∗‖Xi‖ns‖Vi‖T2 . If Auths∗=Auths , Ui and NCCs 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 Figure4 of P¯i∗=hPi∗‖IDi∗‖ni∗ and the description in Step AP1 of P¯i∗=hIDi∗‖Pi∗‖ni∗. The second is that NCCs should append LEOSq’s identity information when sending this message Ws,Auths,T2,IDLEOSq to LEOSq, instead of LEOSq sending its own identity to Ui, because LEOSq only needs to have identity confirmation with NCCs in the LSC system.Figure 4
Implementation of two stages in our scheme.


## 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 Adv has the following abilities when attacking the efficiency and security of their scheme:(1)
Adv can access the full public communication channel to modify, replay, amend, and intercept the confidential information.(2)
Adv can extract the secret information stored in user’s smart card with the help of power analysis.(3)
Adv 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 keymsk of NCCs 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), Adv can register in network control center like a normal user. Firstly, Adv computes P¯Adv=hIDAdv‖PAdv‖nAdv with arbitrary selection of identity IDAdv , password PAdv, and a random number nAdv . Then, Adv records the values P¯Adv,IDAdv and sends IDAdv,P¯Adv to NCCs.Step 2: After receiving the login message fromAdv , NCCs calculates XAdv=hIDAdv‖msk, YAdv=XAdv⊕P¯Adv, and MAdv=hP¯Adv‖XAdv‖IDAdv. Then, it will issue a smart card SCAdv recoding the values YAdv,MAdv,h· to Adv.Step 3: Based on the adversarial model of (1), Adv can extract the values YAdv and h· after getting SCAdv. Next, Adv computes XAdv=YAdv⊕P¯Adv and records the value XAdv.Step 4: SinceXAdv=hIDAdv‖msk, Adv can launch the offline password-guessing attack by implementing Algorithm 1.Algorithm 1: Offline password-guessing attack.
Input: XAdv, IDAdv and h·.Output: msk , which is the private key only known to NCCs.(1)
Adv generates a random number and takes it as key msktmp(2)
AdvComputes Xtmp=hIDAdv‖msktmp(3)
IfXtmp==XAdvthenReturn (msktmp)elseGo to 1 until correct key is obtainedAlthough this algorithm may take a long time to execute,Adv will be willing to keep trying as network control center NCCs 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 messagePIDi,Authi,Qi,T1,IDLEOSq from Ui is first verified by checking the condition T1−Ts≤?ΔT, where T1 is the timestamp transmitted from Ui , Ts is the current timestamp of CNNs, and ΔT 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 (LEO) 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 Ui and CNNs (the uplink between mobile user and satellite and the downlink between satellite and ground station, regardless of transmission delay between gateway and NCCi, 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.


## 3.2.1. Offline Password-Guessing Attack

This section describes how a malicious attacker can obtain the private keymsk of NCCs 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), Adv can register in network control center like a normal user. Firstly, Adv computes P¯Adv=hIDAdv‖PAdv‖nAdv with arbitrary selection of identity IDAdv , password PAdv, and a random number nAdv . Then, Adv records the values P¯Adv,IDAdv and sends IDAdv,P¯Adv to NCCs.Step 2: After receiving the login message fromAdv , NCCs calculates XAdv=hIDAdv‖msk, YAdv=XAdv⊕P¯Adv, and MAdv=hP¯Adv‖XAdv‖IDAdv. Then, it will issue a smart card SCAdv recoding the values YAdv,MAdv,h· to Adv.Step 3: Based on the adversarial model of (1), Adv can extract the values YAdv and h· after getting SCAdv. Next, Adv computes XAdv=YAdv⊕P¯Adv and records the value XAdv.Step 4: SinceXAdv=hIDAdv‖msk, Adv can launch the offline password-guessing attack by implementing Algorithm 1.Algorithm 1: Offline password-guessing attack.
Input: XAdv, IDAdv and h·.Output: msk , which is the private key only known to NCCs.(1)
Adv generates a random number and takes it as key msktmp(2)
AdvComputes Xtmp=hIDAdv‖msktmp(3)
IfXtmp==XAdvthenReturn (msktmp)elseGo to 1 until correct key is obtainedAlthough this algorithm may take a long time to execute,Adv will be willing to keep trying as network control center NCCs 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 messagePIDi,Authi,Qi,T1,IDLEOSq from Ui is first verified by checking the condition T1−Ts≤?ΔT, where T1 is the timestamp transmitted from Ui , Ts is the current timestamp of CNNs, and ΔT 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 (LEO) 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 Ui and CNNs (the uplink between mobile user and satellite and the downlink between satellite and ground station, regardless of transmission delay between gateway and NCCi, 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 Figure4.


### 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:NCCs chooses a secure elliptic curve equation Epa,b and a generator point P of the cyclic additive elliptic curve group Gp with order n , where p is an x-bit prime number.Step 2:NCCs selects a random number k∈1,n−1 as its private key and computes the corresponding public key K=kP.Step 3:NCCs picks a one-way key derivation function kdf:0,1j⟶0,1m, which is mainly used to generate shared session password.Step 4:NCCs publishes Epa,b,n,P,K,h·,kdf as the system parameters and keeps its master key k secret.


### 4.2. Registration Phase

If a mobile userUi wants to register to the system, this phase is performed only once as follows:Step 1:Ui freely chooses a valid identity IDi and password Pi to enter into his/her mobile device, such as a smartphone. The identity IDi can be combined by any one of Ui’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 Ui’s biometric Bi to compute vi=hIDi‖Pi‖Bi . Then, the device sends the message IDi,vi to NCCs through a secure channel.Step 2: After receiving the message, the server first calculateshIDi to check whether IDi has been registered in the verifier table. If it has been registered, Ui is asked to select a new identity. Otherwise, NCCs calculates the following operations:(1)Si=k+hIDi−1,P=xs,ys,li=xs⊕vi,mi=hvixsIDi.After that,NCCs inserts N0,hIDi into the verifier table (VT) and delivers the message M0=N0,li,mi to Ui via the secure channel, where N0 is a nonce.Step 3: On getting the response message,Ui stores the values N0,li,mi in his/her mobile device for later use in the login process.Remark 2.
The nonceN0 is a unique value randomly generated by NCCs 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 forNCCs to deliver the message M0 to Ui: One way is offline method where NCCs records M0 into a smartcard and issues it to Ui. The other way is online method where NCCs connects to Ui 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 betweenUi and the NCCs. The detailed description is as follows:Step 1: WhenUi intends to communicate with others or get service from NCCs via the LSC system, Ui provides IDi∗, Pi∗, and Bi∗ to his/her mobile device. The device computes(2)vi∗=hIDi∗Pi∗Bi∗,xs∗=li⊕vi∗,mi∗=hvi∗xs∗IDi∗,and it determines whethermi∗=?mi or not, where mi has been recorded in the device. If mi∗=mi, the device randomly selects bi∈1,n−1 and calculates the operations as follows:(3)Qi=biP=xq,yq,Vi=biK=xv,yv,PIDi=xv⊕IDiαi=hIDixsPIDiN0.Then, the device sendsM1=PIDi,αi,Qi,N0 to LEOSq.Step 2: After getting the message,LEOSq forwards PIDi,αi,Qi,N0,IDLEOSq to NCCs.Step 3: When obtaining the message,NCCs calculates(4)Vi∗=kQi=xv∗,yv∗,IDi∗=xv∗⊕PIDi.Next,NCCs uses N0 to find the matching hIDi in the verifier table. If it is not found, NCCs refuses the request of Ui; otherwise, it computes(5)Si∗=k+hIDi∗−1,P=xs∗,ys∗,αi∗=hIDixs∗PIDiN0,and it checksαi∗=?αi. If αi∗=?αi, NCCs authenticates CS and generates a nonce N1 to compute the operations(6)SKs=kdfIDixsN0N1,βs=hIDiSKsxsN1.Then,NCCs records nonce N1 next to N0 in the verifier table and sends βs,N1,IDLEOSq to LEOSq.Step 4: After getting the message,LEOSq forwards M2=βs,N1 to Ui.Step 5: On receiving the reply message fromLEOSq, Ui computes(7)SKi∗=kdfIDixsN0N1,βs∗=hIDiSKi∗xsN1.Then,Ui checks βs∗=?βs. If βs∗=βs, Ui confirms that NCCs are authentic and updates N0 as N1 in the mobile device. As a result, Ui and NCCs realize mutual authentication and negotiate a shared secret key:(8)SK=kdfIDixsN0N1.Remark 4.
We briefly derive the consistency operations in this phase as follows:(9)Vi∗=kQi=kbiP=bikP=biK=Vi.Remark 5.
In Step 3,NCCs records nonce N1 next to N0 rather than updating N1 as N0. This means that NCCs keeps N0 until receiving Ui’s next login message including the value N1. At this time, NCCs will produce a new nonce N2 and then will update N1 to N0 and N2 to N1. In a word, NCCs always keep two fresh numbers related to Ui in the verifier table except the first login. The designed mechanism mainly fights against the denial of service attack due to the nonce between Ui and NCCs being out of sync. We call this scenario “desynchronization challenge” as shown in Figure 5. “Successful authentication” means that Ui has authenticated NCCs and updated N0 to N1. Then, Ui can apply the shared secret key SK to encrypt the next traffic with NCCs, namely, “Data Exchange Phase.” The failure indicates Ui cannot authenticate NCCs because the message M3 was tampered with by an attacker or interfered with the poor wireless environment. Then, “desynchronization challenge” is invoked. Since NCCs still holds the fresh number N0, Ui can continue to send login request information with N0.Figure 5
Flow diagram of the new protocol.


### 4.4. Password-Change Phase

WheneverUi wants to update his/her password Pi to a new Pinew, this phase is activated without communication with NCCs. Firstly, Ui provides IDi∗, Pi∗, and Bi∗ to his/her mobile device and asks for changing the password. Then, the device will automatically perform as follows:Step 1: The device computesvi∗=hIDi∗‖Pi∗‖Bi∗, xs∗=li⊕vi∗, and mi∗=hvi∗‖xi∗‖IDi∗. It checks mi∗=?mi. If mi∗≠mi, it rejects Ui’s password change. Otherwise, the device prompts Ui for a new password Pinew.Step 2: AfterUi enters Pinew, the device calculates vinew=hIDi∗‖Pinew‖Bi∗, linew=xs⊕vinew and minew=hvinew‖xs∗‖IDi∗. Finally, the device replaces the original li,mi with linew,minew in the memory separately.


## 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:NCCs chooses a secure elliptic curve equation Epa,b and a generator point P of the cyclic additive elliptic curve group Gp with order n , where p is an x-bit prime number.Step 2:NCCs selects a random number k∈1,n−1 as its private key and computes the corresponding public key K=kP.Step 3:NCCs picks a one-way key derivation function kdf:0,1j⟶0,1m, which is mainly used to generate shared session password.Step 4:NCCs publishes Epa,b,n,P,K,h·,kdf as the system parameters and keeps its master key k secret.


## 4.2. Registration Phase

If a mobile userUi wants to register to the system, this phase is performed only once as follows:Step 1:Ui freely chooses a valid identity IDi and password Pi to enter into his/her mobile device, such as a smartphone. The identity IDi can be combined by any one of Ui’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 Ui’s biometric Bi to compute vi=hIDi‖Pi‖Bi . Then, the device sends the message IDi,vi to NCCs through a secure channel.Step 2: After receiving the message, the server first calculateshIDi to check whether IDi has been registered in the verifier table. If it has been registered, Ui is asked to select a new identity. Otherwise, NCCs calculates the following operations:(1)Si=k+hIDi−1,P=xs,ys,li=xs⊕vi,mi=hvixsIDi.After that,NCCs inserts N0,hIDi into the verifier table (VT) and delivers the message M0=N0,li,mi to Ui via the secure channel, where N0 is a nonce.Step 3: On getting the response message,Ui stores the values N0,li,mi in his/her mobile device for later use in the login process.Remark 2.
The nonceN0 is a unique value randomly generated by NCCs 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 forNCCs to deliver the message M0 to Ui: One way is offline method where NCCs records M0 into a smartcard and issues it to Ui. The other way is online method where NCCs connects to Ui 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 betweenUi and the NCCs. The detailed description is as follows:Step 1: WhenUi intends to communicate with others or get service from NCCs via the LSC system, Ui provides IDi∗, Pi∗, and Bi∗ to his/her mobile device. The device computes(2)vi∗=hIDi∗Pi∗Bi∗,xs∗=li⊕vi∗,mi∗=hvi∗xs∗IDi∗,and it determines whethermi∗=?mi or not, where mi has been recorded in the device. If mi∗=mi, the device randomly selects bi∈1,n−1 and calculates the operations as follows:(3)Qi=biP=xq,yq,Vi=biK=xv,yv,PIDi=xv⊕IDiαi=hIDixsPIDiN0.Then, the device sendsM1=PIDi,αi,Qi,N0 to LEOSq.Step 2: After getting the message,LEOSq forwards PIDi,αi,Qi,N0,IDLEOSq to NCCs.Step 3: When obtaining the message,NCCs calculates(4)Vi∗=kQi=xv∗,yv∗,IDi∗=xv∗⊕PIDi.Next,NCCs uses N0 to find the matching hIDi in the verifier table. If it is not found, NCCs refuses the request of Ui; otherwise, it computes(5)Si∗=k+hIDi∗−1,P=xs∗,ys∗,αi∗=hIDixs∗PIDiN0,and it checksαi∗=?αi. If αi∗=?αi, NCCs authenticates CS and generates a nonce N1 to compute the operations(6)SKs=kdfIDixsN0N1,βs=hIDiSKsxsN1.Then,NCCs records nonce N1 next to N0 in the verifier table and sends βs,N1,IDLEOSq to LEOSq.Step 4: After getting the message,LEOSq forwards M2=βs,N1 to Ui.Step 5: On receiving the reply message fromLEOSq, Ui computes(7)SKi∗=kdfIDixsN0N1,βs∗=hIDiSKi∗xsN1.Then,Ui checks βs∗=?βs. If βs∗=βs, Ui confirms that NCCs are authentic and updates N0 as N1 in the mobile device. As a result, Ui and NCCs realize mutual authentication and negotiate a shared secret key:(8)SK=kdfIDixsN0N1.Remark 4.
We briefly derive the consistency operations in this phase as follows:(9)Vi∗=kQi=kbiP=bikP=biK=Vi.Remark 5.
In Step 3,NCCs records nonce N1 next to N0 rather than updating N1 as N0. This means that NCCs keeps N0 until receiving Ui’s next login message including the value N1. At this time, NCCs will produce a new nonce N2 and then will update N1 to N0 and N2 to N1. In a word, NCCs always keep two fresh numbers related to Ui in the verifier table except the first login. The designed mechanism mainly fights against the denial of service attack due to the nonce between Ui and NCCs being out of sync. We call this scenario “desynchronization challenge” as shown in Figure 5. “Successful authentication” means that Ui has authenticated NCCs and updated N0 to N1. Then, Ui can apply the shared secret key SK to encrypt the next traffic with NCCs, namely, “Data Exchange Phase.” The failure indicates Ui cannot authenticate NCCs because the message M3 was tampered with by an attacker or interfered with the poor wireless environment. Then, “desynchronization challenge” is invoked. Since NCCs still holds the fresh number N0, Ui can continue to send login request information with N0.Figure 5
Flow diagram of the new protocol.


## 4.4. Password-Change Phase

WheneverUi wants to update his/her password Pi to a new Pinew, this phase is activated without communication with NCCs. Firstly, Ui provides IDi∗, Pi∗, and Bi∗ to his/her mobile device and asks for changing the password. Then, the device will automatically perform as follows:Step 1: The device computesvi∗=hIDi∗‖Pi∗‖Bi∗, xs∗=li⊕vi∗, and mi∗=hvi∗‖xi∗‖IDi∗. It checks mi∗=?mi. If mi∗≠mi, it rejects Ui’s password change. Otherwise, the device prompts Ui for a new password Pinew.Step 2: AfterUi enters Pinew, the device calculates vinew=hIDi∗‖Pinew‖Bi∗, linew=xs⊕vinew and minew=hvinew‖xs∗‖IDi∗. Finally, the device replaces the original li,mi with linew,minew 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 betweenUi and NCCs. The first symmetric secret key is xs, which is established by calculating Si=k+hIDi−1P=xs,ys during the user registration process. In addition to the authentication of both parties, xs is also used to verify the integrity of the messages M0, M1, and M2 and generate the shared secret key SK, which is used to encrypt information in the data exchange phase. If Adv wants to obtain xs, it can only be obtained through brute-force calculation, because xs is protected by Ui’s real identity IDi and NCCs’s master key k. However, according to 4th difficult calculation problem K-CAA1 in Section 2.3, it is impossible for Adv 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 isxv, which is secured by calculating ECDLP and CDHP on ECC. On the one hand, Adv obtains Qi by intercepting the message M1 through the public channel. According to ECDLP, Adv cannot obtain the value of bi by calculating Qi=biP, and it is also impossible to obtain the server’s master key k by operating K=kP. On the other hand, if Adv obtains Qi and K, it is also impossible to obtain Vi, because, according to Qi=biP and K=kP to find Qi=bikP, this is equivalent to calculating CDHP on ECC. The key xv is mainly used to protect Ui’s real identity IDi and to realize the verification of the server signature by computing Vi∗=kQi.


### 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: Figure6 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 NCCs has a private key k. Next, 3 roles in the scheme are defined: “role I″ simulates Ui; “role R” presents NCCs; “role LEOS” indicates LEOS. Here, we take Ui 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 Ui sends a message and receives one, respectively. Lines 16 to 19 indicate the event where Ui receives the message M0 from NCCs and checks mi∗=?mi during the login phase. Among them, the 16th line indicates that the symmetric secret key xs is modeled as ECC function with parameters of NCCs’s private key k and Ui’s identity IDi; line 17 presents that Ui obtains xs by li; then, Ui can receive M0 and check mi∗=?mi, indicated on line 18 and line 19, respectively. Apart from that, the 28th line adds the matching of the verification βs, 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 Figure7(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 Ui, LEOS, and NCCs, respectively; “=>” means encrypted channel, “->” means open channel, and “’” represents the inverse function; for example, “Ks’” is the private key of NCCs, while “ks” is the public key here. In lines 19 to 21, each line represents the parameters Ui, LEOS, and NCCs 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 Ui and NCCs 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 Ui role code in Figure 7(b).Figure 6
Simulation code in Scyther SPDL.
(a)(b)Figure 7
Simulation code of our protocol using AVISPA. (a) Simulation code in CAS+. (b) Part simulation code in HDLS.
(a)(b)


#### 5.2.2. Simulation Results

This section first presents the simulation results of our protocol using Scyther, which is shown in Figure8. 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 SK. All the analysis results prove that there is no problem in our formalization process, which means that Ui and NCCs can securely convey the message and believe in the confidentiality of the negotiated shared session key SK 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 Ui and NCCs, the protocol has a LEOS impersonation attack because LEOS only forwards message and has not been authenticated in the scheme. However, due to the limitations of the nonce N0 and the nonce N1 and the verification message codes αi and βs, the attacker cannot construct the message independently and can only replay the message between Ui and NCCs this time. Therefore, Scyther test results show that our proposed protocol does not have any threat under various active and passive attacks.Figure 8
Simulation results of the Scyther tool. (a) Message reachability analysis report of our protocol. (b) SK confidentiality analysis report of our protocol.
(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 Figure9, 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 Adv obtains values such as N0, N1, and IDLEOSq 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.Figure 9
The results of OFMC and CL-Atse using AVISPA. (a) OFMC output. (b) CL-Atse output.
(a)(b)Figure 10
Flow chart under intruder simulation with AVISPA.Figure 11
Intruder knowledge after simulation attack with AVISPA.


### 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 aLSC system.


#### 5.3.1. Valid Mutual Authentication

In our protocol,NCCs first verifies the authenticity of IDi’s identityIDi by verifying hIDi=?hIDi∗ and then verifies the validity of Ui by checking αi∗=?αi. The conditions for hIDi=hIDi∗ and αi∗=αi are all guaranteed by the symmetric keys xv and xs, where only real Ui can calculate these two secret values as analyzed in the previous section. So, NCCs can effectively authenticate Ui. Simultaneously, Ui authenticates NCCs by verifying βs∗=?βs, which directly involves Ui’s real identity IDi and the symmetric keys xs. IDi and xs are only calculated by knowing NCCs’s master key k. 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 numberbi selected by Ui, the identity IDi of Ui, and the shared session key SK. bi is protected by ECDLP as discussed in 5.1; IDi is encrypted and transmitted by the symmetric secret key xv through the operation PIDi=xv⊕IDi; SK is bound with IDi and the symmetric key xs in one-way key derivation operation SK=kdfIDi‖xS‖N0‖N1. For data integrity, it refers to the ability to quickly discover whether messages M0, M1, and M2 are inserted, replaced, and deleted. M0 stored in Ui’s mobile equipment is verified by the condition mi∗=?mi; M1 and M2 are verified by checking αi∗=?αi and βs∗=?βs, respectively. Moreover, the values mi, αi, and βs are all bound to the symmetric key xs via hash function h·. Thus, the new scheme ensures the data confidentiality and integrity in all aspects.


#### 5.3.3. No Sensitive Data Maintained byNCCs and Ui

There are onlyN0,hIDi in NCCs’s verifier tables and N0,li,mi stored in Ui’s device in our scheme. N0 is just a nonce and is refreshed every session. As for hIDi, Adv may obtain the user’s identity ID through offline password-guessing attacks after penetrating attack to the NCCs’s inside. However, it is meaningless for the entire system as Adv cannot acquire any clues about the Ui’s password and NCCs’s master key. For data stored in Ui’s mobile device, li and mi are only used in the beginning of Ui’s login phase and neither reveals the key parameters of the system. So, none of sensitive data are maintained by NCCs and Ui in our scheme.


#### 5.3.4. Perfect Session Key Secrecy

The shared session key is derived fromSKi=kdfIDi‖xS‖N0‖N1, which is enclosed by the nonce N0 and the nonce N1, which are refreshed every session. Therefore, even if jth session key SKij is leaked this time, it will not cause the previous SKij−1 or next session key SKij+1 to be compromised.


#### 5.3.5. User’s Privacy

The scheme mainly involves three types of personal privacy ofUi: identity IDi, password Pi, and biometric Bi. At first, Ui registers by submitting IDi,vi, where vi=hIDi‖Pi‖Bi, in order to keep the secret password Pi and biometric Bi of Ui from NCCs. Then, during the login and authentication phase, the pseudoidentity PIDi, which is derived from PIDi=xv⊕IDi, is transmitted via public channel instead of the real IDi. Therefore, any privacy information related to Ui 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 Table2, 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.Table 2
Security functionality comparisons.
Security functionalityProposed[22][21]Valid mutual authenticationYesYesYesData confidentiality and integrityYesYesYesNo sensitive tables kept by NCC and userYesYesYesPerfect session key secrecyYesYesYesUser’s privacyYesYesYesProtection of the biometricYesNoYesResist offline password-guessing attackYesNoNoAgainst clock asynchronous situationYesNoNoAs we all know,NCCs 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 Ui’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.Table 3
Running time of cryptographic elements using OpenSSL library [21].
ElementTimeDescriptionTh0.121µs256-bit hash function (16 size blocks)Tx<0.001 µsThe bitwise XOR operationTp2199µs384-bit nistp384 ECC point multiplicationFurthermore, we have considered communication cost in the last line of Table4. 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 LEOS receives M1=PIDi,αi,Qi,N0 from Ui’s login request message and sends M2=βs,N1 to Ui at last. Thus, the total communication cost bits of M1=32,256,384,384,64 and M2=256,64 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.Table 4
Operations and communication cost comparison among related schemes.
OursAltaf et al. [22]Sharif et al. [21]Registration phase1Th2Th + 1Tx2Th + 2TxLogin and authentication phase5Th + 2Tx + 2Tp7Th + 4Tx + 2Tp7Th + 5Tx + 3TpTotal execution time4198.726µs4399.089µs6598.089µsCommunication cost bits144014402112


## 5.1. Overall Design Idea of Our Scheme

In our protocol, we utilize two symmetric keys betweenUi and NCCs. The first symmetric secret key is xs, which is established by calculating Si=k+hIDi−1P=xs,ys during the user registration process. In addition to the authentication of both parties, xs is also used to verify the integrity of the messages M0, M1, and M2 and generate the shared secret key SK, which is used to encrypt information in the data exchange phase. If Adv wants to obtain xs, it can only be obtained through brute-force calculation, because xs is protected by Ui’s real identity IDi and NCCs’s master key k. However, according to 4th difficult calculation problem K-CAA1 in Section 2.3, it is impossible for Adv 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 isxv, which is secured by calculating ECDLP and CDHP on ECC. On the one hand, Adv obtains Qi by intercepting the message M1 through the public channel. According to ECDLP, Adv cannot obtain the value of bi by calculating Qi=biP, and it is also impossible to obtain the server’s master key k by operating K=kP. On the other hand, if Adv obtains Qi and K, it is also impossible to obtain Vi, because, according to Qi=biP and K=kP to find Qi=bikP, this is equivalent to calculating CDHP on ECC. The key xv is mainly used to protect Ui’s real identity IDi and to realize the verification of the server signature by computing Vi∗=kQi.


## 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: Figure6 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 NCCs has a private key k. Next, 3 roles in the scheme are defined: “role I″ simulates Ui; “role R” presents NCCs; “role LEOS” indicates LEOS. Here, we take Ui 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 Ui sends a message and receives one, respectively. Lines 16 to 19 indicate the event where Ui receives the message M0 from NCCs and checks mi∗=?mi during the login phase. Among them, the 16th line indicates that the symmetric secret key xs is modeled as ECC function with parameters of NCCs’s private key k and Ui’s identity IDi; line 17 presents that Ui obtains xs by li; then, Ui can receive M0 and check mi∗=?mi, indicated on line 18 and line 19, respectively. Apart from that, the 28th line adds the matching of the verification βs, 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 Figure7(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 Ui, LEOS, and NCCs, respectively; “=>” means encrypted channel, “->” means open channel, and “’” represents the inverse function; for example, “Ks’” is the private key of NCCs, while “ks” is the public key here. In lines 19 to 21, each line represents the parameters Ui, LEOS, and NCCs 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 Ui and NCCs 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 Ui role code in Figure 7(b).Figure 6
Simulation code in Scyther SPDL.
(a)(b)Figure 7
Simulation code of our protocol using AVISPA. (a) Simulation code in CAS+. (b) Part simulation code in HDLS.
(a)(b)


### 5.2.2. Simulation Results

This section first presents the simulation results of our protocol using Scyther, which is shown in Figure8. 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 SK. All the analysis results prove that there is no problem in our formalization process, which means that Ui and NCCs can securely convey the message and believe in the confidentiality of the negotiated shared session key SK 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 Ui and NCCs, the protocol has a LEOS impersonation attack because LEOS only forwards message and has not been authenticated in the scheme. However, due to the limitations of the nonce N0 and the nonce N1 and the verification message codes αi and βs, the attacker cannot construct the message independently and can only replay the message between Ui and NCCs this time. Therefore, Scyther test results show that our proposed protocol does not have any threat under various active and passive attacks.Figure 8
Simulation results of the Scyther tool. (a) Message reachability analysis report of our protocol. (b) SK confidentiality analysis report of our protocol.
(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 Figure9, 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 Adv obtains values such as N0, N1, and IDLEOSq 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.Figure 9
The results of OFMC and CL-Atse using AVISPA. (a) OFMC output. (b) CL-Atse output.
(a)(b)Figure 10
Flow chart under intruder simulation with AVISPA.Figure 11
Intruder knowledge after simulation attack with AVISPA.


## 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: Figure6 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 NCCs has a private key k. Next, 3 roles in the scheme are defined: “role I″ simulates Ui; “role R” presents NCCs; “role LEOS” indicates LEOS. Here, we take Ui 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 Ui sends a message and receives one, respectively. Lines 16 to 19 indicate the event where Ui receives the message M0 from NCCs and checks mi∗=?mi during the login phase. Among them, the 16th line indicates that the symmetric secret key xs is modeled as ECC function with parameters of NCCs’s private key k and Ui’s identity IDi; line 17 presents that Ui obtains xs by li; then, Ui can receive M0 and check mi∗=?mi, indicated on line 18 and line 19, respectively. Apart from that, the 28th line adds the matching of the verification βs, 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 Figure7(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 Ui, LEOS, and NCCs, respectively; “=>” means encrypted channel, “->” means open channel, and “’” represents the inverse function; for example, “Ks’” is the private key of NCCs, while “ks” is the public key here. In lines 19 to 21, each line represents the parameters Ui, LEOS, and NCCs 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 Ui and NCCs 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 Ui role code in Figure 7(b).Figure 6
Simulation code in Scyther SPDL.
(a)(b)Figure 7
Simulation code of our protocol using AVISPA. (a) Simulation code in CAS+. (b) Part simulation code in HDLS.
(a)(b)


## 5.2.2. Simulation Results

This section first presents the simulation results of our protocol using Scyther, which is shown in Figure8. 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 SK. All the analysis results prove that there is no problem in our formalization process, which means that Ui and NCCs can securely convey the message and believe in the confidentiality of the negotiated shared session key SK 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 Ui and NCCs, the protocol has a LEOS impersonation attack because LEOS only forwards message and has not been authenticated in the scheme. However, due to the limitations of the nonce N0 and the nonce N1 and the verification message codes αi and βs, the attacker cannot construct the message independently and can only replay the message between Ui and NCCs this time. Therefore, Scyther test results show that our proposed protocol does not have any threat under various active and passive attacks.Figure 8
Simulation results of the Scyther tool. (a) Message reachability analysis report of our protocol. (b) SK confidentiality analysis report of our protocol.
(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 Figure9, 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 Adv obtains values such as N0, N1, and IDLEOSq 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.Figure 9
The results of OFMC and CL-Atse using AVISPA. (a) OFMC output. (b) CL-Atse output.
(a)(b)Figure 10
Flow chart under intruder simulation with AVISPA.Figure 11
Intruder knowledge after simulation attack with AVISPA.


## 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 aLSC system.


### 5.3.1. Valid Mutual Authentication

In our protocol,NCCs first verifies the authenticity of IDi’s identityIDi by verifying hIDi=?hIDi∗ and then verifies the validity of Ui by checking αi∗=?αi. The conditions for hIDi=hIDi∗ and αi∗=αi are all guaranteed by the symmetric keys xv and xs, where only real Ui can calculate these two secret values as analyzed in the previous section. So, NCCs can effectively authenticate Ui. Simultaneously, Ui authenticates NCCs by verifying βs∗=?βs, which directly involves Ui’s real identity IDi and the symmetric keys xs. IDi and xs are only calculated by knowing NCCs’s master key k. 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 numberbi selected by Ui, the identity IDi of Ui, and the shared session key SK. bi is protected by ECDLP as discussed in 5.1; IDi is encrypted and transmitted by the symmetric secret key xv through the operation PIDi=xv⊕IDi; SK is bound with IDi and the symmetric key xs in one-way key derivation operation SK=kdfIDi‖xS‖N0‖N1. For data integrity, it refers to the ability to quickly discover whether messages M0, M1, and M2 are inserted, replaced, and deleted. M0 stored in Ui’s mobile equipment is verified by the condition mi∗=?mi; M1 and M2 are verified by checking αi∗=?αi and βs∗=?βs, respectively. Moreover, the values mi, αi, and βs are all bound to the symmetric key xs via hash function h·. Thus, the new scheme ensures the data confidentiality and integrity in all aspects.


### 5.3.3. No Sensitive Data Maintained byNCCs and Ui

There are onlyN0,hIDi in NCCs’s verifier tables and N0,li,mi stored in Ui’s device in our scheme. N0 is just a nonce and is refreshed every session. As for hIDi, Adv may obtain the user’s identity ID through offline password-guessing attacks after penetrating attack to the NCCs’s inside. However, it is meaningless for the entire system as Adv cannot acquire any clues about the Ui’s password and NCCs’s master key. For data stored in Ui’s mobile device, li and mi are only used in the beginning of Ui’s login phase and neither reveals the key parameters of the system. So, none of sensitive data are maintained by NCCs and Ui in our scheme.


### 5.3.4. Perfect Session Key Secrecy

The shared session key is derived fromSKi=kdfIDi‖xS‖N0‖N1, which is enclosed by the nonce N0 and the nonce N1, which are refreshed every session. Therefore, even if jth session key SKij is leaked this time, it will not cause the previous SKij−1 or next session key SKij+1 to be compromised.


### 5.3.5. User’s Privacy

The scheme mainly involves three types of personal privacy ofUi: identity IDi, password Pi, and biometric Bi. At first, Ui registers by submitting IDi,vi, where vi=hIDi‖Pi‖Bi, in order to keep the secret password Pi and biometric Bi of Ui from NCCs. Then, during the login and authentication phase, the pseudoidentity PIDi, which is derived from PIDi=xv⊕IDi, is transmitted via public channel instead of the real IDi. Therefore, any privacy information related to Ui is enclosed in our scheme.


## 5.3.1. Valid Mutual Authentication

In our protocol,NCCs first verifies the authenticity of IDi’s identityIDi by verifying hIDi=?hIDi∗ and then verifies the validity of Ui by checking αi∗=?αi. The conditions for hIDi=hIDi∗ and αi∗=αi are all guaranteed by the symmetric keys xv and xs, where only real Ui can calculate these two secret values as analyzed in the previous section. So, NCCs can effectively authenticate Ui. Simultaneously, Ui authenticates NCCs by verifying βs∗=?βs, which directly involves Ui’s real identity IDi and the symmetric keys xs. IDi and xs are only calculated by knowing NCCs’s master key k. 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 numberbi selected by Ui, the identity IDi of Ui, and the shared session key SK. bi is protected by ECDLP as discussed in 5.1; IDi is encrypted and transmitted by the symmetric secret key xv through the operation PIDi=xv⊕IDi; SK is bound with IDi and the symmetric key xs in one-way key derivation operation SK=kdfIDi‖xS‖N0‖N1. For data integrity, it refers to the ability to quickly discover whether messages M0, M1, and M2 are inserted, replaced, and deleted. M0 stored in Ui’s mobile equipment is verified by the condition mi∗=?mi; M1 and M2 are verified by checking αi∗=?αi and βs∗=?βs, respectively. Moreover, the values mi, αi, and βs are all bound to the symmetric key xs via hash function h·. Thus, the new scheme ensures the data confidentiality and integrity in all aspects.


## 5.3.3. No Sensitive Data Maintained byNCCs and Ui

There are onlyN0,hIDi in NCCs’s verifier tables and N0,li,mi stored in Ui’s device in our scheme. N0 is just a nonce and is refreshed every session. As for hIDi, Adv may obtain the user’s identity ID through offline password-guessing attacks after penetrating attack to the NCCs’s inside. However, it is meaningless for the entire system as Adv cannot acquire any clues about the Ui’s password and NCCs’s master key. For data stored in Ui’s mobile device, li and mi are only used in the beginning of Ui’s login phase and neither reveals the key parameters of the system. So, none of sensitive data are maintained by NCCs and Ui in our scheme.


## 5.3.4. Perfect Session Key Secrecy

The shared session key is derived fromSKi=kdfIDi‖xS‖N0‖N1, which is enclosed by the nonce N0 and the nonce N1, which are refreshed every session. Therefore, even if jth session key SKij is leaked this time, it will not cause the previous SKij−1 or next session key SKij+1 to be compromised.


## 5.3.5. User’s Privacy

The scheme mainly involves three types of personal privacy ofUi: identity IDi, password Pi, and biometric Bi. At first, Ui registers by submitting IDi,vi, where vi=hIDi‖Pi‖Bi, in order to keep the secret password Pi and biometric Bi of Ui from NCCs. Then, during the login and authentication phase, the pseudoidentity PIDi, which is derived from PIDi=xv⊕IDi, is transmitted via public channel instead of the real IDi. Therefore, any privacy information related to Ui 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 Table2, 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.Table 2
Security functionality comparisons.
Security functionalityProposed[22][21]Valid mutual authenticationYesYesYesData confidentiality and integrityYesYesYesNo sensitive tables kept by NCC and userYesYesYesPerfect session key secrecyYesYesYesUser’s privacyYesYesYesProtection of the biometricYesNoYesResist offline password-guessing attackYesNoNoAgainst clock asynchronous situationYesNoNoAs we all know,NCCs 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 Ui’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.Table 3
Running time of cryptographic elements using OpenSSL library [21].
ElementTimeDescriptionTh0.121µs256-bit hash function (16 size blocks)Tx<0.001 µsThe bitwise XOR operationTp2199µs384-bit nistp384 ECC point multiplicationFurthermore, we have considered communication cost in the last line of Table4. 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 LEOS receives M1=PIDi,αi,Qi,N0 from Ui’s login request message and sends M2=βs,N1 to Ui at last. Thus, the total communication cost bits of M1=32,256,384,384,64 and M2=256,64 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.Table 4
Operations and communication cost comparison among related schemes.
OursAltaf et al. [22]Sharif et al. [21]Registration phase1Th2Th + 1Tx2Th + 2TxLogin and authentication phase5Th + 2Tx + 2Tp7Th + 4Tx + 2Tp7Th + 5Tx + 3TpTotal execution time4198.726µs4399.089µs6598.089µsCommunication cost bits144014402112


## 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 aLSC 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.



---

*Source: 8811970-2021-02-02.xml*