# A Lightweight Privacy Protection User Authentication and Key Agreement Scheme Tailored for the Internet of Things Environment: LightPriAuth

Authors: Yuwen Chen; Lourdes López; José-Fernán Martínez; Pedro Castillejo
Journal: Journal of Sensors
 (2018)

---

## Abstract

Different data are collected by diverse sensors under an Internet of things scenario, such as health data, environmental data, and traffic flow data. People can access data remotely via the Internet easily. Considering the importance and confidentiality of these data, it is necessary to ensure the data security. In this study, we propose an authentication and key establishment scheme for an Internet of things scenario based on low-capability devices. This scheme achieves many security features: user anonymity, sensor anonymity, forward secrecy, resistance to the loss of synchronization problem, and so on We verified these security features using AVISPA and ProVerif; both results show that the scheme is safe enough to achieve the security requirements. Besides, the experiment results elucidate that this scheme gains an advantage in computation and communication costs. It is because of the sole usage of XOR operations and hash functions as well as a minimal amount of asymmetric encryptions to fulfil forward secrecy.


---

## Body

## 1. Introduction

As sensors are applied to different aspects of our daily life, too much different personal information has been collected by different kinds of sensors; the personal information includes but is not limited to health information, home temperature, and home humidity. The information is so personal that we do not want them to be leaked when we access them remotely via the network. Many lightweight authentication schemes have been proposed to guarantee the safety of remote data access. Figure1 depicts the structure of these schemes. There are three kinds of entities, the user who wants to read the data of sensors, sensors which are placed in the environment to collect data, and the gateway, which is introduced to authenticate users and sensors and helps the two to build a shared key. After negotiation of the shared key, the user and sensor can communicate with each other without the help of the gateway.Figure 1
The structure of the model.In this paper, we proposed an authentication and key establishment scheme with user anonymity; this scheme is an improved version of the previous scheme of ours [1] and the LifeWear project [2], which is also based on the ECC. To achieve user anonymity, the identity of the user is encrypted using XOR operation; the key for this encryption is generated by the gateway. When a user registers at the gateway, the gateway generates a random number for the user and a unique key based on this number and the gateway’s own secret key. This number could be seen as an indicator of the key; the key and this number are sent to the user. The user could encrypt his identity with this key.However, this is not enough to ensure perfect anonymity, because adversaries can track the user based on this unique number, even though the adversary does not know the real identity of this user. To prevent adversaries from tracking the users, in our scheme, once a user has been authenticated by the gateway, the gateway will assign a new number and a new key for this user. Thus, the adversary is unable to track the user based on the number, because the number has been updated to a new one. Many other schemes adopted this way of protecting the identity privacy of the users [3–10].Some schemes use an asymmetric encryption method to ensure the anonymity of the authentication scheme. The gateway has a public key that is known by all the members in the scheme; users can use this public key to encrypt their identities; thus, the scheme ensures user anonymity. Our scheme has an advantage compared to the asymmetric encryption method. This is because the asymmetric encryption method requires more computation time compared to our scheme. In our scheme, we encrypt the identity of the user by using the XOR method; the execution time of the XOR operation is minimal compared to an elliptic curve point multiplication [11]. This makes our scheme more suitable for the Internet of things scenario than the asymmetric encryption method.In the proposed scheme, to enable forward security, the shared key between the user and sensor is generated on an elliptic curve. However, elliptic curve computation needs more computation time compared to the symmetric method; to minimize the computation cost, the proposed scheme only uses four elliptic multiplication operations; as far as we know, this is the least amount needed to build a shared key with perfect forward security. The contribution of this paper is threefold:(1)
The proposed scheme uses the XOR operations, hash operations, and only four elliptic multiplications; the computation cost of the scheme is relatively low, and communication cost decreases at the same time.
(2)
The proposed scheme gains various security features: user anonymity, sensor anonymity, users being untraceable, sensors being untraceable, perfect forward secrecy, excellent resistance to the loss of synchronization problem, and so on. Most importantly, the password change phase has been modified to prevent an offline password-guessing attack.
(3)
We implement the scheme in HPSL language and test the security features; we analyze the scheme in ProVerif model, too.


## 2. Related Works

Turkanović et al. discussed the user authentication and key agreement problem for a wireless sensor network [12]. They analyzed the identity protection problem in this scenario; they used a fixed fake identity instead of the real identity to protect the identity of the user. Amin and Biswas proposed an improved scheme [13], which improved several security weaknesses of the protocol of Turkanović et al. They protected the identity privacy by encrypting the identity using a symmetric key that is shared by all the users.Wu et al. proposed a privacy-preserving and provable user authentication scheme for wireless sensor networks [14]. Every time a user asks access to a sensor’s data, the gateway atomically generates a new identity for the user. The identity privacy of the user has been well protected in the scheme, but this scheme faces a loss of synchronization problem. Imagine that the gateway generates a new identity for the user and sends this identity to the user via the Internet but the user does not receive this identity, because either this identity is lost due to poor quality of the network condition or this identity is blocked by an adversary. Thus, when the user logs in the next time using the old identity, he will not be treated as a legal user. Another potential defect of this scheme is that the users in this scheme may be tracked. Even though the adversary does not know the real identity of the user, the adversary can also track the user by the fixed informationMIi, which is used by the user.Different from [9, 10], Li et al. proposed a three-factor authentication scheme [3] with identity updating based on biometric information. Their scheme can successfully avoid the loss of synchronization problem. They did not update the identity of the users directly. Instead, in their scheme, every time the user logs in, the gateway generates a new key for the user and the user uses this new key to encrypt his identity. The adversary is unable to find out the real identity of the user. Li et al. proposed a similar scheme for wearable sensors in wireless body area networks [4]. In the scheme of Jiang et al., the keys to encrypt the identities of users are the same [6]. Schemes in [5–9] are similar; the key to encrypt the identity is updated when a user logs in. Das proposed a secure and robust temporal credential-based three-factor user authentication scheme for wireless sensor networks [10]. In this scheme, a temporary identity is generated for the user; every time the user asks for access, the temporary identity will be updated to a new one. However, in this case, the gateway has to store a table of the relationships between this temporary identity and the real identity of the user. This costs extra storage load on the server side.Asymmetric encryption is used in some authentication schemes to protect the identity privacy of the users. The gateway has a public key that is known by all the users in the system; when a user logs in, he can use the gateway’s public key to encrypt his identity. There are asymmetric encryption methods based on the Elliptic Curve Cryptography (ECC) [15], pairing-based cryptography [16] by Tsai and Lo, and the scheme in [17] by Odelu et al. Liu et al. used ECC [18] to protect the identity privacy of the users. All the real identities are encrypted by the public key of the server; only the server knows the real identities of the users. In the scheme of Wang et al. [19], they used the ECC public key encryption method to protect the identity privacy. Pairing-based cryptography is another popular asymmetric encryption method. The scheme of Li et al. [20], the scheme of Tsai and Lo [21], and the scheme of Shim [22] are all based on bilinear pairing-based cryptography.


## 3. The Proposed Scheme

The symbols used in the scheme are listed in Table1. At the beginning of the scheme, GWN generates the parameters for ECC encryption (p, a, b, G, n, and h) and publishes them to the whole system. GWN generates its secret key XGWN and keeps it as a secret.Table 1
Symbols used in the PriAuth.
Symbols
Meaning
GWN
Gateway
Ui, IDi
Theith user and his identity
Sj,SIDj
Thejth sensor node and its identity
||
Connects two strings together
⨁
XOR operation
XGWN
GWN’s secret key
G
The generator of ECC
SKij,SKij′
Shared key betweenUi and Sj
T1,T2
Timestamp
h
General hash function


### 3.1. Registration Phase of the User

UserUi chooses a random number ri and computes MPi=hriIDiPWi. Ui then sends the registration request message IDi,MPi to GWN via a private and secure channel.WhenGWN receives the user registration message IDi,MPi, it computes di=hIDiXGWN and fi=di⊕MPi. Then, GWN will choose a random number ki and computes ei=hkiXGWN; these random numbers ki and ei are used to encrypt the identity information at the login and authentication phase. Finally, GWN sends fi,li,ki to Ui in a private and secure channel.UserUi inserts the random nonce ri into the smart card and stores fi,li,ki,MPi,ri. Table 2 provides a depiction of the registration phase of the user.Table 2
Registration phase of the user.
User
Gateway
IDi,PWi
master keyXGWN
random numberri
MPi=hriIDiPWi
IDi,MPi
di=hIDiXGWN
fi=di⨁MPi
randomki,ei=hkiXGWN
li=ei⨁MPi
Storesfi,li,ki,MPi,ri
fi,li,ki


### 3.2. Registration Phase of the Sensor

The registration messages of the sensors in the registration phase are sent via a private and secure channel. SensorSj sends SIDj to GWN. After GWN receives the registration message from Sj, it computes xj=hSIDjXGWN and sends xj to sensor Sj. Sensor Sj keeps this private key in its memory.


### 3.3. Login and Authentication Phase

WhenUi wants to access a sensor’s data via network remotely, Ui has to log in first. A user inserts his smart card (SC) into a card reader and inputs his identity IDi′ and password PWi′. SC computes a temporary version MPi′=hriIDi′PWi′ using the user inputs PWi′ and IDi′ and the stored value ri. Then SC computes the information for login.
(1)
SC computes di=fi⨁MPi′ and ei=li⊕MPi′ using MPi′.
(2)
SC chooses a random number k1∈[1, n − 1] and gets A=k1·G.
(3)
SC gets the hash value M2=hAIDiSIDjdiT1.
(4)
SC encrypts IDi, SIDj, and M2 with ei to get M1=ei⨁IDiSIDjM2.
(5)
SC retrieves the stored ki, timestamp T1, and sends Message1=A,ki,M1,T1 to gateway via a public channel.When the gateway receivesMessage1=A,ki,M1,T1 from a user Ui, GWN first checks the freshness of the message by the timestamp, then GWN checks if this message is from a legal user or not. GWN will abandon this message if it is not from a legal user; otherwise, GWN will forward this request to the sensor SIDj. The process is depicted in the following:
(1)
GWN checks the freshness of T1; if T1 is not fresh, GWN abandons this message; otherwise, it goes to the next step.
(2)
GWN computes ei′=hkiXGWN using the received ki and its private key XGWN.
(3)
GWN decrypts M1 using ei′ and gets IDi′SIDj′M2′=M1⨁ei′.
(4)
GWN computes di′ by di′=hIDi′XGWN.
(5)
GWN computes xj′ by xj′=hSIDj′XGWN
(6)
GWN uses di′, A, IDi′, SIDj′, and T1 to check if M2=hAIDi′SIDj′di′T1. If they are equal, it goes to next step; otherwise, the protocol terminates here.
(7)
GWN gets timestamp T2 and computes M3=hASIDj′xj′T2.
(8)
GWN sends Message2=A,M3,T2 to sensor Sj.After sensorSj receives Message2=A,M3,T2, Sj first checks the legitimacy of this message; if it is from the gateway, then Sj replies to the message in the following way.
(1)
Sj checks the freshness of the T2; if T2 is not fresh, Sj abandons this message; otherwise, it goes to the next step.
(2)
Sj checks if M3=hASIDjxjT2; if they are equal, Sj learns that this information is from the gateway, and it goes to the next step; otherwise, the protocol terminates here.
(3)
Sj chooses a random number k2∈1,n−1 and gets B=k2·G.
(4)
Sj calculates the shared key SKij between Ui and Sj:SKij=hk2·A=hk1·k2·G.
(5)
Sj calculates the hash value M4=hBSKijA and M5=hAxjM3M4B.
(6)
Sj sends Message3=B,M4,M5 to GWN.AfterGWN receives Message3=B,M4,M5, first, GWN authenticates the source of the message, then GWN generates the new random number and the new key for the user; afterwards, GWN will send these encrypted information to the user.
(1)
GWN checks if M5=hAxjM3M4B; if they are equal, it goes to the next step; otherwise, it terminates here.
(2)
GWN chooses a random number k3 and computes einew=hk3XGWN.
(3)
GWN calculates M7=heinewk3di′T1M4.
(4)
GWN computes M6=einewk3M7⨁ei′.
(5)
GWN sends Message4=B,M6 to Ui.AfterUi receives Message4=B,M6, it authenticates if the message is from the gateway; if the message is from the gateway, then Ui updates the information received from the GWN. The whole process is depicted in Table 3.
(1)
Uigets einew′k3′M7′=M6⨁ei.
(2)
Uicomputes the shared key SKij′ between Ui and Sj: SKij′=hk1·B=hk1·k2·G.
(3)
Uigets the hashed value M4′=hBSKij′A and checks if M7=heinew′k3′diT1M4′. If they are equal, Ui accepts SKij′ as the shared key.
(4)
Ui updates the identity information li=MPi′⊕einew′,ki=k3′.Table 3
Login and authentication phase.
User
Gateway
Sensor
IDi,PWi
XGWN
SIDj,xj
inputIDi′andPWi′
MPi′=hriIDi′PWi′
di=fi⨁MPi′
ei=li⨁MPi′
randomk1, A=k1·G
getki, timestampT1
M2=hAIDiSIDjdiT1
M1=ei⨁IDiSIDjM2
A,ki,M1,T1
checks the freshness ofT1ei′=hkiXGWN
IDi′SIDj′M2′=M1⨁ei′
di′=hIDi′XGWN
M2′?=hAIDi′SIDj′di′T1
xj′=hSIDj′XGWN
timestampT2
M3=hASIDj′xj′T2
A,M3,T2
checks the freshness ofT2M3?=hASIDjxjT2
randomk2,B=k2·G
SKij=hk2·A
M4=hBSKijA
M5=hxjM3M4B
M5?=hxjM3M4Brandom numberk3
B,M4,M5
einew=hk3XGWN
M7=heinewk3di′T1M4
M6=einewk3M7⨁ei′
einew′k3′M7′=M6⨁eiSKij′=hk1·B
B,M6
M4′=hBSKij′A
M7′?=heinew′k3′diT1M4′
li=MPi′⨁einew′,ki=k3′


### 3.4. Password Change Phase

To change a user’s password, the user first sends a password change request to theSC. After the SC verifies this user, the user can change his password.In order to prevent the offline password guess attack, in our scheme, the user is only allowed to change his passwordk times in a time period T. We use a variable counter to record the times a user inputs a wrong password. TWfirst means the first time a user inputs a wrong password. When a user inputs a wrong password more than k times in a time period T, he will not be allowed to input a password anymore in this time period. The whole process is depicted in Figure 2:
(1)
UserUi inserts his SC into a card reader and inputs his identity and password: IDi, PWi.
(2)
SC checks if the counter≥k; if counter≥k, go to step 3. If counter<k, go to step 4.
(3)
SC continues to check if ∣TWfirst−Tnow∣≤T; if ∣TWfirst−Tnow∣≤T, user is not allowed to change the password; otherwise, if set counter=0, go to step 4.
(4)
SC computes hriIDiPWi using IDi and PWi and the stored ri. SC compares hriIDiPWi with MPi stored in the smart card; if they are equal, SC acknowledges the legitimacy of Ui. If they are not equal, go to step 11.
(5)
Check ifcounter==0? If counter!=0, set counter=0.
(6)
SC computes di=fi⨁MPi using the stored fi and the user passwordMPi.
(7)
SC computes ei=li⊕MPi using the stored li and the user passwordMPi.
(8)
UserUi inputs the new password PWi′.
(9)
SC updates MPi to be MPi′=hriIDiPWi′.
(10)
SC uses this new PWi′ to update the stored version of fi and li to get fi′=di⨁MPi′ and li′=ei⨁MPi′. Now user has finished the password change phase.
(11)
Setcounter=counter+1; if counter==1, TWfirst is set to be now, go to the first step.Figure 2
The information flow for a user to change his password.


## 3.1. Registration Phase of the User

UserUi chooses a random number ri and computes MPi=hriIDiPWi. Ui then sends the registration request message IDi,MPi to GWN via a private and secure channel.WhenGWN receives the user registration message IDi,MPi, it computes di=hIDiXGWN and fi=di⊕MPi. Then, GWN will choose a random number ki and computes ei=hkiXGWN; these random numbers ki and ei are used to encrypt the identity information at the login and authentication phase. Finally, GWN sends fi,li,ki to Ui in a private and secure channel.UserUi inserts the random nonce ri into the smart card and stores fi,li,ki,MPi,ri. Table 2 provides a depiction of the registration phase of the user.Table 2
Registration phase of the user.
User
Gateway
IDi,PWi
master keyXGWN
random numberri
MPi=hriIDiPWi
IDi,MPi
di=hIDiXGWN
fi=di⨁MPi
randomki,ei=hkiXGWN
li=ei⨁MPi
Storesfi,li,ki,MPi,ri
fi,li,ki


## 3.2. Registration Phase of the Sensor

The registration messages of the sensors in the registration phase are sent via a private and secure channel. SensorSj sends SIDj to GWN. After GWN receives the registration message from Sj, it computes xj=hSIDjXGWN and sends xj to sensor Sj. Sensor Sj keeps this private key in its memory.


## 3.3. Login and Authentication Phase

WhenUi wants to access a sensor’s data via network remotely, Ui has to log in first. A user inserts his smart card (SC) into a card reader and inputs his identity IDi′ and password PWi′. SC computes a temporary version MPi′=hriIDi′PWi′ using the user inputs PWi′ and IDi′ and the stored value ri. Then SC computes the information for login.
(1)
SC computes di=fi⨁MPi′ and ei=li⊕MPi′ using MPi′.
(2)
SC chooses a random number k1∈[1, n − 1] and gets A=k1·G.
(3)
SC gets the hash value M2=hAIDiSIDjdiT1.
(4)
SC encrypts IDi, SIDj, and M2 with ei to get M1=ei⨁IDiSIDjM2.
(5)
SC retrieves the stored ki, timestamp T1, and sends Message1=A,ki,M1,T1 to gateway via a public channel.When the gateway receivesMessage1=A,ki,M1,T1 from a user Ui, GWN first checks the freshness of the message by the timestamp, then GWN checks if this message is from a legal user or not. GWN will abandon this message if it is not from a legal user; otherwise, GWN will forward this request to the sensor SIDj. The process is depicted in the following:
(1)
GWN checks the freshness of T1; if T1 is not fresh, GWN abandons this message; otherwise, it goes to the next step.
(2)
GWN computes ei′=hkiXGWN using the received ki and its private key XGWN.
(3)
GWN decrypts M1 using ei′ and gets IDi′SIDj′M2′=M1⨁ei′.
(4)
GWN computes di′ by di′=hIDi′XGWN.
(5)
GWN computes xj′ by xj′=hSIDj′XGWN
(6)
GWN uses di′, A, IDi′, SIDj′, and T1 to check if M2=hAIDi′SIDj′di′T1. If they are equal, it goes to next step; otherwise, the protocol terminates here.
(7)
GWN gets timestamp T2 and computes M3=hASIDj′xj′T2.
(8)
GWN sends Message2=A,M3,T2 to sensor Sj.After sensorSj receives Message2=A,M3,T2, Sj first checks the legitimacy of this message; if it is from the gateway, then Sj replies to the message in the following way.
(1)
Sj checks the freshness of the T2; if T2 is not fresh, Sj abandons this message; otherwise, it goes to the next step.
(2)
Sj checks if M3=hASIDjxjT2; if they are equal, Sj learns that this information is from the gateway, and it goes to the next step; otherwise, the protocol terminates here.
(3)
Sj chooses a random number k2∈1,n−1 and gets B=k2·G.
(4)
Sj calculates the shared key SKij between Ui and Sj:SKij=hk2·A=hk1·k2·G.
(5)
Sj calculates the hash value M4=hBSKijA and M5=hAxjM3M4B.
(6)
Sj sends Message3=B,M4,M5 to GWN.AfterGWN receives Message3=B,M4,M5, first, GWN authenticates the source of the message, then GWN generates the new random number and the new key for the user; afterwards, GWN will send these encrypted information to the user.
(1)
GWN checks if M5=hAxjM3M4B; if they are equal, it goes to the next step; otherwise, it terminates here.
(2)
GWN chooses a random number k3 and computes einew=hk3XGWN.
(3)
GWN calculates M7=heinewk3di′T1M4.
(4)
GWN computes M6=einewk3M7⨁ei′.
(5)
GWN sends Message4=B,M6 to Ui.AfterUi receives Message4=B,M6, it authenticates if the message is from the gateway; if the message is from the gateway, then Ui updates the information received from the GWN. The whole process is depicted in Table 3.
(1)
Uigets einew′k3′M7′=M6⨁ei.
(2)
Uicomputes the shared key SKij′ between Ui and Sj: SKij′=hk1·B=hk1·k2·G.
(3)
Uigets the hashed value M4′=hBSKij′A and checks if M7=heinew′k3′diT1M4′. If they are equal, Ui accepts SKij′ as the shared key.
(4)
Ui updates the identity information li=MPi′⊕einew′,ki=k3′.Table 3
Login and authentication phase.
User
Gateway
Sensor
IDi,PWi
XGWN
SIDj,xj
inputIDi′andPWi′
MPi′=hriIDi′PWi′
di=fi⨁MPi′
ei=li⨁MPi′
randomk1, A=k1·G
getki, timestampT1
M2=hAIDiSIDjdiT1
M1=ei⨁IDiSIDjM2
A,ki,M1,T1
checks the freshness ofT1ei′=hkiXGWN
IDi′SIDj′M2′=M1⨁ei′
di′=hIDi′XGWN
M2′?=hAIDi′SIDj′di′T1
xj′=hSIDj′XGWN
timestampT2
M3=hASIDj′xj′T2
A,M3,T2
checks the freshness ofT2M3?=hASIDjxjT2
randomk2,B=k2·G
SKij=hk2·A
M4=hBSKijA
M5=hxjM3M4B
M5?=hxjM3M4Brandom numberk3
B,M4,M5
einew=hk3XGWN
M7=heinewk3di′T1M4
M6=einewk3M7⨁ei′
einew′k3′M7′=M6⨁eiSKij′=hk1·B
B,M6
M4′=hBSKij′A
M7′?=heinew′k3′diT1M4′
li=MPi′⨁einew′,ki=k3′


## 3.4. Password Change Phase

To change a user’s password, the user first sends a password change request to theSC. After the SC verifies this user, the user can change his password.In order to prevent the offline password guess attack, in our scheme, the user is only allowed to change his passwordk times in a time period T. We use a variable counter to record the times a user inputs a wrong password. TWfirst means the first time a user inputs a wrong password. When a user inputs a wrong password more than k times in a time period T, he will not be allowed to input a password anymore in this time period. The whole process is depicted in Figure 2:
(1)
UserUi inserts his SC into a card reader and inputs his identity and password: IDi, PWi.
(2)
SC checks if the counter≥k; if counter≥k, go to step 3. If counter<k, go to step 4.
(3)
SC continues to check if ∣TWfirst−Tnow∣≤T; if ∣TWfirst−Tnow∣≤T, user is not allowed to change the password; otherwise, if set counter=0, go to step 4.
(4)
SC computes hriIDiPWi using IDi and PWi and the stored ri. SC compares hriIDiPWi with MPi stored in the smart card; if they are equal, SC acknowledges the legitimacy of Ui. If they are not equal, go to step 11.
(5)
Check ifcounter==0? If counter!=0, set counter=0.
(6)
SC computes di=fi⨁MPi using the stored fi and the user passwordMPi.
(7)
SC computes ei=li⊕MPi using the stored li and the user passwordMPi.
(8)
UserUi inputs the new password PWi′.
(9)
SC updates MPi to be MPi′=hriIDiPWi′.
(10)
SC uses this new PWi′ to update the stored version of fi and li to get fi′=di⨁MPi′ and li′=ei⨁MPi′. Now user has finished the password change phase.
(11)
Setcounter=counter+1; if counter==1, TWfirst is set to be now, go to the first step.Figure 2
The information flow for a user to change his password.


## 4. Formal Security Analysis Using ProVerif

ProVerif [23] is an automatic cryptographic protocol verifier, in the formal model (so-called Dolev-Yao model) [24]. It can handle many different cryptographic primitives; it also can handle an infinite number of sessions. We use this tool to prove the secrecy of the shared key and the secrecy of the identity; furthermore, we prove the authentication between the user and the gateway and between the sensor and the gateway. We use ProVerif version 1.98pl1; the simulation was conducted on Ubuntu 14.04 LTS (32-bit) with a memory 1 GB. We show the part of the code implemented in the ProVerif in Appendix A. For more detailed code, please refer to [25].


### 4.1. Test on the Identity Privacy

To prove that the identity of the user is not known to the attacker, we test the query “Query not attacker (idi).” The query result is “true,” which means the identity of the user is not derivable by the attacker. This proof shows that our scheme can protect the identity privacy of the user. For the protection of the sensor identity, the result is the same. The simulation results are in Box 1.Box 1
– Query not attacker(sidj[])……RESULT not attacker(sidj[]) is true.
– Query not attacker(idi[])……RESULT not attacker(idi[]) is true.


### 4.2. Test of the Authentication of the Scheme

In ProVerif, “Injective correspondence” is used to capture the authentication in case of a one-to-one relationship. The event “event acceptUser (bitstring)” is used by the user to record the belief that the user has accepted to run the protocol with the gateway and with the supplied symmetric key. The event “event termUser(bitstring)” means that the user believes he has terminated a protocol run using the data type “bitstring.” The other events have similar meanings. These queries ensure the authentication between the users and the gateway and between the sensors and the gateway (see Box 2).Box 2
RESULT inj-event(termGatewaywithSensor(x_71)) ==> inj-event(acceptSensor(x_71)) is true.
RESULT inj-event(termSensor(x_4088)) ==> inj-event(acceptUserbyGateway(x_4088)) is true.
RESULT inj-event(termUser(x_8075)) ==> inj-event(acceptUserbyGateway(x_8075)) is true.
RESULT inj-event(termGatewaywithUser(x_13373)) ==> inj-event(acceptSensor(x_13373)) is true.What is more, we prove the secrecy of the shared key by the queries “Query not attacker (skijs[])” and “Query not attacker(skiju[]).” The result is “true” as shown in the following. The user calculates the shared key between the user and sensor as “skijs;” the sensor calculates the shared key as “skiju” (see Box 3).Box 3
– Query not attacker(skijs[])……RESULT not attacker(skijs[]) is true.
– Query not attacker(skiju[])……RESULT not attacker(skiju[]) is true.


## 4.1. Test on the Identity Privacy

To prove that the identity of the user is not known to the attacker, we test the query “Query not attacker (idi).” The query result is “true,” which means the identity of the user is not derivable by the attacker. This proof shows that our scheme can protect the identity privacy of the user. For the protection of the sensor identity, the result is the same. The simulation results are in Box 1.Box 1
– Query not attacker(sidj[])……RESULT not attacker(sidj[]) is true.
– Query not attacker(idi[])……RESULT not attacker(idi[]) is true.


## 4.2. Test of the Authentication of the Scheme

In ProVerif, “Injective correspondence” is used to capture the authentication in case of a one-to-one relationship. The event “event acceptUser (bitstring)” is used by the user to record the belief that the user has accepted to run the protocol with the gateway and with the supplied symmetric key. The event “event termUser(bitstring)” means that the user believes he has terminated a protocol run using the data type “bitstring.” The other events have similar meanings. These queries ensure the authentication between the users and the gateway and between the sensors and the gateway (see Box 2).Box 2
RESULT inj-event(termGatewaywithSensor(x_71)) ==> inj-event(acceptSensor(x_71)) is true.
RESULT inj-event(termSensor(x_4088)) ==> inj-event(acceptUserbyGateway(x_4088)) is true.
RESULT inj-event(termUser(x_8075)) ==> inj-event(acceptUserbyGateway(x_8075)) is true.
RESULT inj-event(termGatewaywithUser(x_13373)) ==> inj-event(acceptSensor(x_13373)) is true.What is more, we prove the secrecy of the shared key by the queries “Query not attacker (skijs[])” and “Query not attacker(skiju[]).” The result is “true” as shown in the following. The user calculates the shared key between the user and sensor as “skijs;” the sensor calculates the shared key as “skiju” (see Box 3).Box 3
– Query not attacker(skijs[])……RESULT not attacker(skijs[]) is true.
– Query not attacker(skiju[])……RESULT not attacker(skiju[]) is true.


## 5. AVISPA Verification

AVISPA (Automated Validation of Internet Security Protocols and Applications) is “a push-button tool for the automated validation of Internet security-sensitive protocols and applications” [26]. The AVISPA project aims at developing a push-button, industrial-strength technology for the analysis of large-scale Internet security-sensitive protocols and applications. We write the scheme in HLPSL, which is a role-based language designed explicitly for AVISPA. The code is in Appendix B; we have uploaded the code to [25].In the HLPSL, the confidentiality goals of the protocol are set to be “sc_sensor_id” and “sc_user_id,” which can ensure the confidentiality of the user identity and the sensor identity. The message authentication goal is set to be “shared_key,” which can enable the authentication of the shared key. This goal ensures that the users and sensors build a shared key with the help of the gateway.The running result of the protocol is shown in Table4. We run the security check based on the CL-based Model-Checker [27] and the On-the-Fly Model-Checker OFMC [28, 29]. The CL-based Model-Checker (CL-AtSe) translates protocol written as transition relation in the IF into a set of constraints which can be used efficiently to find attacks on protocols. While OFMC can be employed not only for efficient falsification of protocols but also for verification, without bounding the messages, an intruder can generate. Both of the two back-end verification tools show that our scheme is safe.Table 4
Simulation results.
CL-AtSe back end
OFMC
SUMMARY
% OFMC
SAFE
% Version of 2006/02/13
SUMMARY
DETAILS
SAFE
BOUNDED_NUMBER_OF_SESSIONS
DETAILS
TYPED_MODEL
BOUNDED_NUMBER_OF_SESSIONS
PROTOCOL
PROTOCOL
/home/yuwen/avispa/avispa-1.1/testsuite/results/usglight.if
/home/yuwen/avispa/avispa-1.1/testsuite/results/usglight.if
GOAL
GOAL
as_specified
As Specified
BACKEND
OFMC
BACKEND
COMMENTS
CL-AtSe
STATISTICS
parseTime: 0.00s
STATISTICS
searchTime: 0.02 s
Analysed: 5 states
visited Nodes: 4 nodes
Reachable: 0 states
depth: 2 plies
Translation: 0.02 seconds
Computation: 0.00 seconds


## 6. Comparison

In this section, we compared our scheme with the other three schemes [1, 9, 14]. We compared them in two folds: computation performance and communication performance.


### 6.1. Computation Performance

The typical way to compute the execution time of the protocol is to calculate the protocol’s computational costs of different operations; the operations’ execution time is measured by simulation. In this study, the execution time of the XOR operation is minimal compared to an elliptic curve point multiplication or hash operation, and we neglect it when computing the time approximately [11]. In this section, we first compare different schemes using a benchmark from one previously published paper. Then, we simulate the computation time of these schemes in C++; the result is shown in Figure 3.Figure 3
The computation time of different schemes.The benchmark of MIRACL C/C++ Library used in this study can be found at [9]; we list the results in Table 5. Based on this benchmark, the computation costs of different schemes are calculated; the result is in Table 6. At the user side, our scheme only needs 2 ECC multiplications and 5 hash operations. At the sensor side, our scheme costs 2 ECC multiplications and 5 hash operations, and at the gateway side, our scheme costs 8 hash operations. Our scheme costs the least time at the user side and gateway side. And at the sensor side, our scheme costs the second least time. In all, our scheme costs the least computation time.Table 5
Computation time of different operations.
Operations
Time (ms)
TH: one-way hash function
0.0004
TE/D: AES encryption/decryption
0.1303
TMUL: ECC multiplications
7.3529Table 6
Computation cost of the login and authentication.
Schemes
User
Sensor
Gateway
Total
Total (ms)
Wu et al. [9]
11TH + 2TMUL + 1TE/D
4TH + 2TMUL + 1TE/D
11TH + 2TE/D
26TH + 4TMUL + 4TE/D
29.9432
Wu et al. [14]
13TH + 2TMUL
4TH + 2TMUL
14TH
31TH + 4TMUL
29.4240
Chang and Le [11]
7TH + 2TMUL
5TH + 2TMUL
9TH
21TH + 4TMUL
29.42
Chen et al. [1]
5TH + 3TMUL
3TH + 2TMUL
7TH + 1TMUL
15TH + 6TMUL
44.1234
LightPriAuth
5TH + 2TMUL
4TH + 2TMUL
8TH
17TH + 4TMUL
29.4184
In this table, the boldface ones are the ones with the least computation time.In the scheme [9], extra AES encryption/decryption is needed. User, sensor, and gateway need 1, 1, and 2 AES encryptions/decryptions separately. Their proposed scheme needs 6, 3, and 9 more hash operations than our scheme at the user side, gateway side, and in total, respectively.The scheme [11] needs 2, 1, 1, and 4 more hash operations than our scheme at the user side, sensor side, sensor side, gateway side, and in total, respectively. In PriAuth, the asymmetric encryption method is needed to encrypt the identity of the user. The user and gateway in this scheme both need one more ECC multiplication; in total, PriAuth needs two more ECC multiplications than our scheme. The scheme of Wu et al. [14] is the most similar one with the proposed scheme; however, compared to our scheme, their proposed scheme needs 8, 6, and 14 more hash operations than our scheme at the user side, gateway side, and in total, respectively.We implement these four different schemes in C++; the running codes are stored at a public repository inhttp://github.com [25]. We use the MIRACL C/C++ Library [30]. The experiment is conducted in Visual Studio C++ 2017 on a 64-bit Windows 7 operating system, 3.5 GHz processor, 8 GB memory. The hash function is SHA-256, the symmetric encryption/decryption function is AES in MR_PCFB1 form, and the 256-bit-long key for symmetric encryption/decryption function is generated by SHA-256 hash operation. We use the Curve P-192 provided by NIST Digital Signature Standard [31]. The parameters are listed in Appendix C.The code is compiled in x86 form, and the simulation does not take account of the transmission of the data. We run the login and authentication phase of different schemes 100, 250, 500, 750, and 1000 times. The result is shown in Figure3. In this figure, the horizontal axis indicates the times the experiment is run and the vertical axis indicates the milliseconds to accomplish the experiment. Our scheme is the second-best one, and the computation time of the PriAuth is the longest.We run the user registration phase of different schemes. The number of users in the registration phase is set to be 100, 250, 500, 750, and 1000. The result is shown in Figure4. In this figure, the horizontal axis indicates the number of users and the vertical axis indicates the milliseconds needed to accomplish the experiment. Under all experimental conditions, the running time of the PriAuth is the shortest. Our scheme is the second-best scheme, which is about 1.5 times that of the PriAuth. However, this ratio becomes much smaller when the user number increases. Why did this happen? The computation time is mainly composed of two parts: the hash operation time and the checking time. The numbers of hash operation are listed in Table 7. The checking is performed by the gateway to determine if the user has registered before. The gateway keeps a list of registered users’ identity; when the gateway receives a registration request, it has to search the list to check if this user has registered or not. The hash operation time and the checking time are close when the number of the user is smaller. However, the time difference becomes huge with the increasing user numbers.Figure 4
The user registration time of different schemes.Table 7
The cost of hash operations in the registration phase.
Phase
User registration
Sensor registration
Entity
User
Gateway
Total
Ratio
Sensor
Gateway
Total
Ratio
Wu et al. [9]
2
3
5
2.5
0
1
1
1/7
Wu et al. [14]
2
3
5
2.5
0
1
1
1/7
Chang and Le [11]
1
2
3
1.5
0
1
1
1/7
Chen et al. [1]
1
1
2
1
3
4
7
1
LightPriAuth
1
2
3
1.5
0
1
1
1/7The running time of the other two schemes is about 2.5 times that of PriAuth. The ratio of hash operations between them is roughly the same as that of the running time. In Table7, the ratio is computed using the formula Ratio=hi/H, where H means the number of hash operations needed by PriAuth. hi means the number of hash operations needed by the other schemes.We run the sensor registration phase of different schemes. The number of sensors in the registration phase is set to be 100, 250, 500, 750, and 1000. The result is shown in Figure5. In this figure, the horizontal axis indicates the number of sensors and the vertical axis indicates the milliseconds needed to accomplish the experiment. The running time of our scheme is close to the running time of Wu et al. [9, 14] and Chang and Le [11]; this is mainly because these three schemes need only 1 hash operation in the sensor registration phase. As PriAuth costs 7 hash operations in the sensor registration phase, the running time is close to 7 times that of the other three schemes. The computation time of the PriAuth is the longest. The running time of Wu et al. [9] is a little more than our scheme (Wu et al. [14] and Chang and Le [11]). This is because at the sensor registration phase, the input of the hash operation of our scheme, of Wu et al.’s scheme [14], and of Chang and Le’s scheme [11] is the sensor’s identity and the gateway’s private key, while the input of the hash operation of Wu et al. [9] is the sensor’s identity, gateway’s private key, and gateway’s identity; the hash operation’s input is longer.Figure 5
The sensor registration phase of different schemes.


### 6.2. Communication Performance

In this section, the communication performance is compared. The identity is set to 8 bytes long [32]. The size of the timestamp is set to 4 bytes [33]. Moreover, the byte length of a random number is set to be 20 bytes [9]. The result of SHA-256 is 256 bits, which is 32 bytes. The sizes of a point on the elliptic curve with a 192-bit elliptic curve is 384 bits, which is 48 bytes [9]. The sum of each type of variable length in bytes is calculated for comparison of the communication cost.Table8 shows the number of different types of data used in the scheme. It is not hard to find that the communication cost of our scheme is the least. The cost of our scheme, LightPriAuth, is 396 bytes; the costs of Wu et al.’s [9, 14], Chang and Le’s [11] and Chen et al.’s [1] schemes are 564, 624, 412, and 492 bytes, respectively; they are 168, 228, 16, and 96 bytes higher, respectively, than the proposed scheme. The main reason is that LightPriAuth transmits only 5 hash result data. While the other schemes of Wu et al. [9, 14], Chang and Le [11], and Chen et al. [1] have to transmit 10, 13, 9, and 9 hash result data, respectively. They are 5, 8, 4, and 4 more, respectively, than the proposed scheme.Table 8
Communication comparison.
Hash
ECC
Id
T
R
Total bytes
Com
Wu et al. [9]
10
4
4
0
1
564
+168
Wu et al. [14]
13
4
2
0
0
624
+228
Chang and Le [11]
9
2
1
5
0
412
+16
Chen et al. [1]
9
4
0
3
0
492
+96
LightPriAuth
5
4
2
2
1
396
0
Hash: means a general result data; ECC: means a random point on the elliptic curve, Id: means the identity of a sensor or a user; T: means a timestamp; R: means a general random number; Com: comparison between our scheme and the other schemes.


## 6.1. Computation Performance

The typical way to compute the execution time of the protocol is to calculate the protocol’s computational costs of different operations; the operations’ execution time is measured by simulation. In this study, the execution time of the XOR operation is minimal compared to an elliptic curve point multiplication or hash operation, and we neglect it when computing the time approximately [11]. In this section, we first compare different schemes using a benchmark from one previously published paper. Then, we simulate the computation time of these schemes in C++; the result is shown in Figure 3.Figure 3
The computation time of different schemes.The benchmark of MIRACL C/C++ Library used in this study can be found at [9]; we list the results in Table 5. Based on this benchmark, the computation costs of different schemes are calculated; the result is in Table 6. At the user side, our scheme only needs 2 ECC multiplications and 5 hash operations. At the sensor side, our scheme costs 2 ECC multiplications and 5 hash operations, and at the gateway side, our scheme costs 8 hash operations. Our scheme costs the least time at the user side and gateway side. And at the sensor side, our scheme costs the second least time. In all, our scheme costs the least computation time.Table 5
Computation time of different operations.
Operations
Time (ms)
TH: one-way hash function
0.0004
TE/D: AES encryption/decryption
0.1303
TMUL: ECC multiplications
7.3529Table 6
Computation cost of the login and authentication.
Schemes
User
Sensor
Gateway
Total
Total (ms)
Wu et al. [9]
11TH + 2TMUL + 1TE/D
4TH + 2TMUL + 1TE/D
11TH + 2TE/D
26TH + 4TMUL + 4TE/D
29.9432
Wu et al. [14]
13TH + 2TMUL
4TH + 2TMUL
14TH
31TH + 4TMUL
29.4240
Chang and Le [11]
7TH + 2TMUL
5TH + 2TMUL
9TH
21TH + 4TMUL
29.42
Chen et al. [1]
5TH + 3TMUL
3TH + 2TMUL
7TH + 1TMUL
15TH + 6TMUL
44.1234
LightPriAuth
5TH + 2TMUL
4TH + 2TMUL
8TH
17TH + 4TMUL
29.4184
In this table, the boldface ones are the ones with the least computation time.In the scheme [9], extra AES encryption/decryption is needed. User, sensor, and gateway need 1, 1, and 2 AES encryptions/decryptions separately. Their proposed scheme needs 6, 3, and 9 more hash operations than our scheme at the user side, gateway side, and in total, respectively.The scheme [11] needs 2, 1, 1, and 4 more hash operations than our scheme at the user side, sensor side, sensor side, gateway side, and in total, respectively. In PriAuth, the asymmetric encryption method is needed to encrypt the identity of the user. The user and gateway in this scheme both need one more ECC multiplication; in total, PriAuth needs two more ECC multiplications than our scheme. The scheme of Wu et al. [14] is the most similar one with the proposed scheme; however, compared to our scheme, their proposed scheme needs 8, 6, and 14 more hash operations than our scheme at the user side, gateway side, and in total, respectively.We implement these four different schemes in C++; the running codes are stored at a public repository inhttp://github.com [25]. We use the MIRACL C/C++ Library [30]. The experiment is conducted in Visual Studio C++ 2017 on a 64-bit Windows 7 operating system, 3.5 GHz processor, 8 GB memory. The hash function is SHA-256, the symmetric encryption/decryption function is AES in MR_PCFB1 form, and the 256-bit-long key for symmetric encryption/decryption function is generated by SHA-256 hash operation. We use the Curve P-192 provided by NIST Digital Signature Standard [31]. The parameters are listed in Appendix C.The code is compiled in x86 form, and the simulation does not take account of the transmission of the data. We run the login and authentication phase of different schemes 100, 250, 500, 750, and 1000 times. The result is shown in Figure3. In this figure, the horizontal axis indicates the times the experiment is run and the vertical axis indicates the milliseconds to accomplish the experiment. Our scheme is the second-best one, and the computation time of the PriAuth is the longest.We run the user registration phase of different schemes. The number of users in the registration phase is set to be 100, 250, 500, 750, and 1000. The result is shown in Figure4. In this figure, the horizontal axis indicates the number of users and the vertical axis indicates the milliseconds needed to accomplish the experiment. Under all experimental conditions, the running time of the PriAuth is the shortest. Our scheme is the second-best scheme, which is about 1.5 times that of the PriAuth. However, this ratio becomes much smaller when the user number increases. Why did this happen? The computation time is mainly composed of two parts: the hash operation time and the checking time. The numbers of hash operation are listed in Table 7. The checking is performed by the gateway to determine if the user has registered before. The gateway keeps a list of registered users’ identity; when the gateway receives a registration request, it has to search the list to check if this user has registered or not. The hash operation time and the checking time are close when the number of the user is smaller. However, the time difference becomes huge with the increasing user numbers.Figure 4
The user registration time of different schemes.Table 7
The cost of hash operations in the registration phase.
Phase
User registration
Sensor registration
Entity
User
Gateway
Total
Ratio
Sensor
Gateway
Total
Ratio
Wu et al. [9]
2
3
5
2.5
0
1
1
1/7
Wu et al. [14]
2
3
5
2.5
0
1
1
1/7
Chang and Le [11]
1
2
3
1.5
0
1
1
1/7
Chen et al. [1]
1
1
2
1
3
4
7
1
LightPriAuth
1
2
3
1.5
0
1
1
1/7The running time of the other two schemes is about 2.5 times that of PriAuth. The ratio of hash operations between them is roughly the same as that of the running time. In Table7, the ratio is computed using the formula Ratio=hi/H, where H means the number of hash operations needed by PriAuth. hi means the number of hash operations needed by the other schemes.We run the sensor registration phase of different schemes. The number of sensors in the registration phase is set to be 100, 250, 500, 750, and 1000. The result is shown in Figure5. In this figure, the horizontal axis indicates the number of sensors and the vertical axis indicates the milliseconds needed to accomplish the experiment. The running time of our scheme is close to the running time of Wu et al. [9, 14] and Chang and Le [11]; this is mainly because these three schemes need only 1 hash operation in the sensor registration phase. As PriAuth costs 7 hash operations in the sensor registration phase, the running time is close to 7 times that of the other three schemes. The computation time of the PriAuth is the longest. The running time of Wu et al. [9] is a little more than our scheme (Wu et al. [14] and Chang and Le [11]). This is because at the sensor registration phase, the input of the hash operation of our scheme, of Wu et al.’s scheme [14], and of Chang and Le’s scheme [11] is the sensor’s identity and the gateway’s private key, while the input of the hash operation of Wu et al. [9] is the sensor’s identity, gateway’s private key, and gateway’s identity; the hash operation’s input is longer.Figure 5
The sensor registration phase of different schemes.


## 6.2. Communication Performance

In this section, the communication performance is compared. The identity is set to 8 bytes long [32]. The size of the timestamp is set to 4 bytes [33]. Moreover, the byte length of a random number is set to be 20 bytes [9]. The result of SHA-256 is 256 bits, which is 32 bytes. The sizes of a point on the elliptic curve with a 192-bit elliptic curve is 384 bits, which is 48 bytes [9]. The sum of each type of variable length in bytes is calculated for comparison of the communication cost.Table8 shows the number of different types of data used in the scheme. It is not hard to find that the communication cost of our scheme is the least. The cost of our scheme, LightPriAuth, is 396 bytes; the costs of Wu et al.’s [9, 14], Chang and Le’s [11] and Chen et al.’s [1] schemes are 564, 624, 412, and 492 bytes, respectively; they are 168, 228, 16, and 96 bytes higher, respectively, than the proposed scheme. The main reason is that LightPriAuth transmits only 5 hash result data. While the other schemes of Wu et al. [9, 14], Chang and Le [11], and Chen et al. [1] have to transmit 10, 13, 9, and 9 hash result data, respectively. They are 5, 8, 4, and 4 more, respectively, than the proposed scheme.Table 8
Communication comparison.
Hash
ECC
Id
T
R
Total bytes
Com
Wu et al. [9]
10
4
4
0
1
564
+168
Wu et al. [14]
13
4
2
0
0
624
+228
Chang and Le [11]
9
2
1
5
0
412
+16
Chen et al. [1]
9
4
0
3
0
492
+96
LightPriAuth
5
4
2
2
1
396
0
Hash: means a general result data; ECC: means a random point on the elliptic curve, Id: means the identity of a sensor or a user; T: means a timestamp; R: means a general random number; Com: comparison between our scheme and the other schemes.


## 7. Other Security Feature Analyses

In this section, we analyze the security features of different schemes. At the end of this section, we conclude the results into a table.


### 7.1. User Anonymity/Sensor Anonymity

Regarding user anonymity, we find that all the schemes could enable user anonymity, as the identities of the users are encrypted. For sensor anonymity, the identity of the sensor is transmitted transparently in the scheme [11, 14]; adversaries could get the identity easily.


### 7.2. User Anonymity to Sensor

In the scheme of [9], the identity of the user is sent to the sensors directly; once a user accesses a sensor’s data, this user’s identity is known by the sensor; the sensor can learn the identity of the user. Apparently, this is not good for the identity privacy of the user. In the proposed scheme, LightPriAuth, the identity of the user need not be sent to the sensor; thus, this could avoid the potential identity leaking problem. We describe this “user anonymity to sensor.”


### 7.3. Loss of Synchronization Problem

Similar to the scheme [3], when a user logs in, the gateway will generate a new identity for the user and the old identity will not be used anymore. However, if adversaries block this identity from being sent to the user, the user cannot receive this identity, when he logs in the next time using the old identity, he will not be treated as a legal user anymore. The scheme in [14] has this problem.


### 7.4. Offline Dictionary Attack

For most of the schemes, an adversary is unable to launch an offline dictionary attack in the login and authentication phase. However, an adversary is able to launch an offline dictionary attack in the password-changing phase.In the password change phase of [19], if the adversary types in a random identity IDi′ and a random password PWi′, he will get a reply from the SC. Based on the replied message, the adversary can judge if the identity and password are correct or not. If the adversary guesses a correct key pair by accident, then he could set a new password. Thus, the adversary is able to launch an offline dictionary attack.In the proposed scheme, we set a limitation on the user, if the user inputs a wrong identity and password pair more thank times in a time period T, he is not allowed to log in in this period of time. Thus, our scheme can avoid the offline dictionary attack in the password change phase.


### 7.5. Security Feature Comparison

Finally, we get in Table9 the comparison of security features; we can find that compared to other schemes, the proposed scheme has more security features. Besides, the computation cost and the communication cost of the proposed scheme are lower.Table 9
Security feature comparison.
Security feature
Wu et al. [9]
Wu et al. [14]
Chang and Le [11]
Chen et al. [1]
LightPriAuth
User anonymity
✓
✓
✓
✓
✓
User being tracked
✓
X
X
✓
✓
Sensor anonymity
✓
X
X
✓
✓
User anonymity to sensor
X
✓
✓
✓
✓
Loss of synchronization
✓
X
✓
✓
✓
With timestamp
X
X
✓
✓
✓
Offline dictionary attack
X
X
X
X
✓
Computation cost (ms)
29.9432
29.424
29.42
44.1234
29.4184
Communication cost (bytes)
564
624
412
492
396


## 7.1. User Anonymity/Sensor Anonymity

Regarding user anonymity, we find that all the schemes could enable user anonymity, as the identities of the users are encrypted. For sensor anonymity, the identity of the sensor is transmitted transparently in the scheme [11, 14]; adversaries could get the identity easily.


## 7.2. User Anonymity to Sensor

In the scheme of [9], the identity of the user is sent to the sensors directly; once a user accesses a sensor’s data, this user’s identity is known by the sensor; the sensor can learn the identity of the user. Apparently, this is not good for the identity privacy of the user. In the proposed scheme, LightPriAuth, the identity of the user need not be sent to the sensor; thus, this could avoid the potential identity leaking problem. We describe this “user anonymity to sensor.”


## 7.3. Loss of Synchronization Problem

Similar to the scheme [3], when a user logs in, the gateway will generate a new identity for the user and the old identity will not be used anymore. However, if adversaries block this identity from being sent to the user, the user cannot receive this identity, when he logs in the next time using the old identity, he will not be treated as a legal user anymore. The scheme in [14] has this problem.


## 7.4. Offline Dictionary Attack

For most of the schemes, an adversary is unable to launch an offline dictionary attack in the login and authentication phase. However, an adversary is able to launch an offline dictionary attack in the password-changing phase.In the password change phase of [19], if the adversary types in a random identity IDi′ and a random password PWi′, he will get a reply from the SC. Based on the replied message, the adversary can judge if the identity and password are correct or not. If the adversary guesses a correct key pair by accident, then he could set a new password. Thus, the adversary is able to launch an offline dictionary attack.In the proposed scheme, we set a limitation on the user, if the user inputs a wrong identity and password pair more thank times in a time period T, he is not allowed to log in in this period of time. Thus, our scheme can avoid the offline dictionary attack in the password change phase.


## 7.5. Security Feature Comparison

Finally, we get in Table9 the comparison of security features; we can find that compared to other schemes, the proposed scheme has more security features. Besides, the computation cost and the communication cost of the proposed scheme are lower.Table 9
Security feature comparison.
Security feature
Wu et al. [9]
Wu et al. [14]
Chang and Le [11]
Chen et al. [1]
LightPriAuth
User anonymity
✓
✓
✓
✓
✓
User being tracked
✓
X
X
✓
✓
Sensor anonymity
✓
X
X
✓
✓
User anonymity to sensor
X
✓
✓
✓
✓
Loss of synchronization
✓
X
✓
✓
✓
With timestamp
X
X
✓
✓
✓
Offline dictionary attack
X
X
X
X
✓
Computation cost (ms)
29.9432
29.424
29.42
44.1234
29.4184
Communication cost (bytes)
564
624
412
492
396


## 8. Conclusions

With different sensors collecting different data around us, it is vital not only to ensure the safety of these data but also to protect the privacy of the data. In this paper, we propose an authentication and key establishment scheme between users and sensors. We analyzed the security features using ProVerif and AVISPA; the formal verifications show that the proposed scheme has achieved all the desired security features. Through comparison, we find that the proposed scheme is comparable to the related works regarding the computation cost and more efficient in communication cost. Our work is part of the LifeWear project, in which we focus on the safety of data transmission and identity privacy problem.



---

*Source: 7574238-2018-09-18.xml*