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

Authors: Yuwen Chen; José-Fernán Martínez; Pedro Castillejo; Lourdes López
Journal: Wireless Communications and Mobile Computing
 (2017)

---

## Abstract

In a wearable sensor-based deployment, sensors are placed over the patient to monitor their body health parameters. Continuous physiological information monitored by wearable sensors helps doctors have a better diagnostic and a suitable treatment. When doctors want to access the patient’s sensor data remotely via network, the patient will authenticate the identity of the doctor first, and then they will negotiate a key for further communication. Many lightweight schemes have been proposed to enable a mutual authentication and key establishment between the two parties with the help of a gateway node, but most of these schemes cannot enable identity confidentiality. Besides, the shared key is also known by the gateway, which means the patient’s sensor data could be leaked to the gateway. In PriAuth, identities are encrypted to guarantee confidentiality. Additionally, Elliptic Curve Diffie–Hellman (ECDH) key exchange protocol has been adopted to ensure the secrecy of the key, avoiding the gateway access to it. Besides, only hash and XOR computations are adopted because of the computability and power constraints of the wearable sensors. The proposed scheme has been validated by BAN logic and AVISPA, and the results show the scheme has been proven as secure.


---

## Body

## 1. Introduction

As sensors become widespread in their usage regarding health monitoring scenarios, a significant amount of personal sensitive data like blood pressure, pulse, or electrocardiogram readings will be monitored. These sensors could be interconnected to compose a Wireless Body Area Network (WBAN). With different sensors gathering patient’s data and continually sending these data to doctors or to a remote monitoring station for further analysis, it is necessary to make sure that these data are transferred confidentially. The usual way is to encrypt them first before they are sent. The proposal presented in this paper, named PriAuth, aims to help the patient and the doctor build a shared key for encrypting health parameters.Because only appointed doctors are allowed to access the patient’s data, the patient and the doctor have to authenticate each other first. A workable way is to introduce a gateway to help the patient authenticating the legitimacy of the doctor and vice versa. After authentication, the two parties will build a shared key for further communication.When a doctor wants to read patient’s data, he sends a request to the patient. The patient forwards this request together with his own identification information to the gateway. The gateway checks whether the patient and the doctor are legitimate, and if any of them is not regarded as such then the scheme is aborted. Only when they are all legitimate, the gateway sends the authentication result to the patient. Once the patient has become aware of the legitimacy of the doctor, he sends the authentication result to the doctor as well. Based on the authentication result, the patient and the doctor can build a shared key, which is used for encrypting confidential information sent between them.There are many research results focusing on the authentication and key agreement problems; while most of them could ensure the safety of the data, this is not enough, as there is also a need to protect privacy.In the authentication process, the patient and the doctor have to send their identities and some other related information to the gateway. It has to be ensured that the patient’s identity should not be leaked. Of course, a patient is usually unwilling to leak his identity information, because if the patient’s identity is leaked, the health history and status of the patient will be freely available for anyone in the system, regardless of the patient wishes.On the other hand, when a doctor sends his identity to the gateway for authentication, we have to make sure that the doctor’s identity is kept confidential, too (e.g., when an adversary eavesdrops the identity of the doctor and finds out the doctor’s major is dermatology according to the identity of the doctor, there is a great chance that the patient has a skin related problem). Therefore, it is also necessary to keep the doctor’s identity confidential in order to protect the privacy of the patient. In PriAuth, Elliptic Curve Cryptography (ECC) is adopted as the method used to protect the identities of the data transmission participants, which is similar to [15–21].After the gateway finishes the authentication process, the gateway will send the authentication result to the patient and the doctor. Based on the authentication result, the patient and the doctor could build a shared key. In some traditional schemes, the gateway could learn the key shared from the authentication information it gets from the patient and the doctor. This means the patient’s personal health data could be leaked to the gateway. It is necessary to prevent the gateway learning this key. In PriAuth, Elliptic Curve Diffie–Hellman (ECDH) key exchange protocol is adopted to ensure the shared key secrecy between the patient and doctor. Besides, only hash and XOR operations are adopted, which is suitable for the wearable sensors.PriAuth has been validated by BAN logic and AVISPA. BAN logic is one of the most prevalent methods that help determine whether the exchanged information is trustworthy, secure against eavesdropping. BAN logic is also adopted to prove the security of the schemes by [22–24]. AVISPA (Automated Validation of Internet Security Protocols and Applications) is a tool for the automated validation of Internet security-sensitive protocols and applications, which has been widely adopted by [24–26], and so forth.This paper is organized as follows: Section2 is related works; Section 3 is the preliminary knowledge. In Section 4, we introduce PriAuth; Section 5 provides the BAN logic validation. Section 6 includes AVISPA verification. Section 7 is the security analysis part. Section 8 provides a comparison with other schemes. Section 9 is the validation part. Section 10 concludes with a summary of the contributions.


## 2. Related Works

In several papers of the researched literature, the authors use different acronyms; user and sensor are the most commonly used, which equals to doctor and sensor in our scheme. Thus, from now on, we will use user and sensor instead of doctor and patient. D. Wang and P. Wang provide overviews of some of the schemes described in [27, 28]. Farash et al. use a single shared key between all the users or sensors to encrypt the identities [13]. All the sensors use the same key hXGWN∥1 to encrypt the sensor identity, using XOR method where SIDj is the sensor identity and T2 is a timestamp. (1)ESIDj=SIDj⊕hhXGWN∥1∥T2,wherehXGWN∥1 is a key that is shared by all the sensors, so malicious or curious sensors could learn the identity of sensor SIDj. As ESIDj, T2 are sent via a public channel. A malicious or curious sensor with identity SIDk can eavesdrop sensor SIDj to get ESIDj, T2. In order to get the sensor id SIDj, SIDk could decrypt ESIDj using the same key hXGWN∥1:(2)ESIDj⊕hhXGWN∥1∥T2=SIDj⊕hhXGWN∥1∥T2⊕hhXGWN∥1∥T2=SIDj.Lu et al. use a random identityTIDi to protect identity privacy [10]. But as the identity is a fixed value, a user could be tracked by an adversary. Schemes [29–32] use a similar method, but all these procedures are prone to suffer from tractability attack.In scheme proposed by Wu et al., every time the gateway gives a newPIDnewMU for the user [4]. But in this case, there is a potential loss of synchronization problem: if the adversary blocks the PIDnewMU from being sent to the user, then the two parties may lose their synchronization. Das et al. protect the identity of the user by generating a new masked identity every time in a similar way, but this scheme suffers from loss of synchronization problem, too [33].Jung et al. use the similar method with the scheme [13] of Farash et al. [6]. The key to encrypt the identity of a single user is the same for all the users. This scheme has the same problem that has been discussed. What a user sends to the gateway node is as follows: DIDi=hIDi∥R1, k=hDIDi∥v∗∥T1, Ai=EkDIDi∥R1∥T1, so other users could learn DIDi by decrypting Ai with the same key v∗. Besides, this scheme has the same inner side attacker problem, a detailed analysis is shown in Section 7.4.Rabin cryptosystem with quadratic residue problem is used to encrypt a message [11, 34]. Assume n=pq, where p and q are two large primes. If y=x2mod⁡n has a solution, that is, there exists a square root for y, then y is called a quadratic residue mod⁡n. The set of all quadratic residue numbers in [1,n-1] is denoted by QRn. The quadratic residue problem states that, for y∈QRn, it is hard to find x without the knowledge of p and q due to the difficulty of factoring n [35]; this is a kind of public-key encryption method.Chatterjee and Das provide a similar methodology of protecting the identity of the user. They use the ECC based public key methods [15]. Besides, they try to combine the authentication scheme with an attributed based access control scheme. He et al. use a similar method, while they use exponentiation operations instead [36].We summarize some of them in Table1. From the table, it can be inferred that privacy is a problem that has not drawn enough attention from the researchers. In some schemes, all the users share the same key to encrypt their identities, this means the encrypted identity could be decrypted by a malicious or curious user using the same key [5, 6, 10, 13]. Some of the schemes fail to enable the anonymity of the user or sensor, such as [37–39]. We adopt the ECC based method to enable the anonymity, which is similar to [15–21] because “ECC requires smaller keys compared to non-ECC cryptography (based on plain Galois fields) to provide equivalent security” [40]. The gateway has a public key that is known by every user; all the identities are encrypted by an XOR method with a new key which is generated from gateway’s public key before the identities are sent to the gateway. Thus, only the gateway could learn the identities.Table 1
Comparison of protection of privacy.
Schemes
Sensor anonymity
User anonymity
Shared key privacy
Choi et al. [1]
×
×
√
Shi and Gong [2]
×
×
√
Chang and Le [3, Scheme 1]
×
×
×
Chang and Le [3, Scheme 2]
×
×
√
Wu et al. [4]
√
×
√
Das et al. [5]
√
×
√
Jung et al. [6]
√
×
×
Fan et al. [7]
×
×
×
Amin and Biswas [8]
×
×
×
Nam et al. [9]
×
×
√
Lu et al. [10]
√
√
×
Zhao et al. [11]
√
×
×
Hou et al. [12]
×
×
×
Farash et al. [13]
×
×
×
Turkanović et al. [14]
×
×
×
PriAuth
√
√
√As for the shared key between user and sensor, in some schemes, the gateway knows the shared key in schemes [6–8, 11–14], while, in some others, the gateway does not know the key, they use Diffie–Hellman (DH) anonymous key agreement protocol to build the shared key [1, 2, 4, 5, 9, 30]. As we have discussed, the gateway is not allowed to know the shared key in order to prevent a curious gateway from eavesdropping the sensor data.


## 3. Preliminary

Elliptic Curve Cryptography (ECC) is a public-key cryptography approach based on the algebraic structure of elliptic curves over finite fields. For current cryptographic purposes, an elliptic curve is a plane curve over a finite field (rather than the real numbers) which consists of the points satisfying the following:(3)y2=x3+ax+b.In order to use ECC, all parties must agree on all the domain parameters of the elliptic curve{p,a,b,G,n,h}:F(p): the finite field over p, where p is a prime and represents the size of the finite field(a,b): the parameters of elliptic curves y2=x3+ax+b over F(p)G(xp,yp): generator point, but G≠0n: the order of the base point Gh: cofactor, an integer, h=F(p)/nElliptic Curve Diffie–Hellman (ECDH) is an anonymous key agreement protocol that allows two parties; each has an elliptic curve based public, private key pair, to establish a shared secret over an insecure channel. Suppose Alice wants to establish a shared key with Bob, but the channel available for them is not safe. Initially, the domain parameters(p,a,b,G,n,h) must be agreed upon. Also, each party must have a key pair suitable for elliptic curve cryptography, consisting of a private key d  (a randomly selected integer in the interval [1,n-1]) and a public key Q (where Q=dG, that is, the result of adding G together d times).Alice’s private key and public key are(dA,QA); Bob’s key pair is (dB,QB). Alice computes dAQB while Bob computes dBQA. So the shared key between them is dAQB=dBQA, because (4)dAQB=dAdBG=dBdAG=dBQA.


## 4. Privacy Enhanced Scheme: PriAuth

The structure model of our scheme is depicted in Figure1. A gateway is introduced to help user and sensor authenticate each other. We suppose this gateway is trustworthy.Figure 1
The structure of the model.


### 4.1. Symbols Used in the PriAuth

Before the scheme begins,GWN (gateway node) generates the parameters for ECC encryption (p,a,b,G,n,h). After that, GWN generates its public-key pair (dg,Qg); besides, GWN generates a secret key XGWN. The symbols are summarized in Table 2.Table 2
Symbols used in the PriAuth.
Symbols
Meaning
G
W
N
Gateway node
U
i
Theith user
S
j
Thejth sensor node
I
D
i
Theith user’s identity
S
I
D
j
Thejth sensor’s identity
∥
String connector, connect two strings together
⊕
XOR operation
X
G
W
N
G
W
N’s secret value, master key
X
G
W
N
-
S
j
Shared key betweenSj and GWN
(
d
g
,
Q
g
)
The private key and public key ofGWN
G
The generator of ECC
S
K, SK′
Shared key between userUi and Sj
T
1, T2
Timestamp
h
Hash function


### 4.2. Registration Phase of the Sensor

The registration messages of the sensor in registration phase are sent via the public channel. SensorSj conducts the following steps for registration:(1)
It creates a random numberrj and gets the timestamp T1.(2)
It covers its password withrj, MNj=rj⊕XGWN-Sj and generates a hash value MPj=hXGWN-Sj∥rj∥SIDj∥T1.(3)
It sends{SIDj,MPj,MNj,T1} to GWN via a public channel.AfterGWN receives Sj’s registration message {SIDj,MPj,MNj,T1}. GWN has to check the freshness of the message by T1, if the message is not fresh, GWN abandons the message. Then GWN computes rj′=MNj⊕XGWN-Sj. GWN checks if MPj equals hXGWN-Sj∥rj′∥SIDj∥T1. If they are not equal, GWN abandons the message. GWN continues the sensor registration phase in the following steps. The registration phase is described in Table 3.(1)
GWN computes xj=hSIDj∥XGWN,ej=xj⊕hSIDj∥XGWN-Sj.(2)
GWN gets the timestamp T2 and gets the hash value fj=hxj∥XGWN-Sj∥T2.(3)
GWN sends {ej,fj,T2,p,a,b,G,n,h,Qg} to sensor Sj.Table 3
Registration phase of the sensor.
Sensor
Gateway
S
I
D
j
,
X
G
W
N
-
S
j
master key
X
G
W
N  for each sensor storesSIDj,XGWN-Sj
random number
r
j
gets timestamp
T
1
MNj=rj⊕XGWN-Sj
MPj=hXGWN-Sj∥rj∥SIDj∥T1
→
S
I
D
j
,
M
P
j
,
M
N
j
,
T
1
checks if
T
1
is fresh  rj′=MNj⊕XGWN-Sj
M
P
j
=
?
h
X
G
W
N
-
S
j
∥
r
j
∥
S
I
D
j
∥
T
1
gets timestamp
T
2
x
j
=
h
S
I
D
j
∥
X
G
W
N
e
j
=
x
j
⊕
h
S
I
D
j
∥
X
G
W
N
-
S
j
f
j
=
h
x
j
∥
X
G
W
N
-
S
j
∥
T
2
checks if:
T
2
is fresh  xj=ej⊕hSIDj∥XGWN-Sj
←
e
j
,
f
j
,
T
2
,
p
,
a
,
b
,
G
,
n
,
h
,
Q
g
fj=?hxj∥XGWN-Sj∥T2
stores
{
x
j
,
p
,
a
,
b
,
G
,
n
,
h
,
Q
g
}After receiving the message,Sj first checks the freshness of T2, then computes xj=ej⊕hSIDj∥XGWN-Sj, and checks if fj=hxj∥XGWN-Sj∥T2; if they are equal, Sj stores {xj,p,a,b,G,n,h,Qg} in its memory.


### 4.3. Registration Phase of the User

UserUi chooses a random number ri and computes MPi=hri∥IDi∥PWi. Ui then sends {IDi,MPi} to GWN via a secure channel.After receiving the user registration message{IDi,MPi}, GWN computesdi=hIDi∥XGWN, fi=di⊕MPi. Finally, GWN sends {fi,p,a,b,G,n,h,Qg} to Ui.After receiving{fi,p,a,b,G,n,h,Qg}, Ui inserts the previously selected random nonce ri into it, now what in the smart card is {MPi,fi,ri,p,a,b,G,n,h,Qg}. The registration phase is described in Table 4.Table 4
Registration phase of the user.
User
Gateway
I
D
i
,
P
W
i
master key
X
G
W
N
random number
r
i
MPi=hri∥IDi∥PWi
→
I
D
i
,
M
P
i
d
i
=
h
I
D
i
∥
X
G
W
N  fi=di⊕MPi
inserts into the smart card  MPi,fi,ri,p,a,b,G,n,h,Qg
←
f
i
,
p
,
a
,
b
,
G
,
n
,
h
,
Q
g


### 4.4. Login and Authentication Phase

If userUi wants to access a sensor’s data, Ui has to login first. This login process is completed by the smart card SC. 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′=hri∥IDi′∥PWi′ using the inserted PWi′, IDi′ and the stored value ri. Then SC compares MPi′ with MPi in the smart card. If they are equal, SC acknowledges the legitimacy of Ui.After userUi passes through the verification, then SC prepares for the authentication process. SC computes di=fi⊕MPi′ using MPi′ in login phase. SC chooses a random number k1∈[1,n-1] and gets the timestamp T1. SC then computes the following data:A=k1·GKug=hT1∥k1·QgM1=(IDi,SIDj)⊕KugM2=hA∥M1∥di∥T1ThenSC sends Message 1 = A,M1,M2,T1 to sensor Sj via a public channel.After receivingA,M1,M2,T1 from Ui, sensor Sj first checks the freshness of T1 and Sj abandons the message if T1 is not fresh and otherwise goes to the next step. Sj chooses a random number k2∈[1,n-1] and gets the timestamp T2. Sj then computes the following data:B=k2·GM3=hB∥M2∥xj∥T2S
j sends Message 2 = A,M1,M2,T1,B,M3,T2 to GWN via a public channel.After receiving the messageA,M1,M2,T1,B,M3,T2, GWN first checks the freshness of T1 and T2, if T1 or T2 is not fresh, GWN abandons the message; otherwise GWN completes the following steps:(1)
GWN computes Kug′=hT1∥dg·A.(2)
GWN gets IDi′ and SIDj′ by (IDi′,SIDj′)=M1⊕Kug′.(3)
GWN computes di′ by di′=hIDi′∥XGWN.(4)
GWN computes xj′ by xj′=hSIDj′∥XGWN.(5)
GWN uses di′,A,M1 and T1 to check if M2=hA∥M1∥di′∥T1. If they are equal, the procedure goes to next step; otherwise it terminates here.(6)
GWN uses xj′,B,M2 and T2 to check if M3=hB∥M2∥xj′∥T2. If they are equal, the procedure goes to next step; otherwise it terminates here.(7)
GWN calculates the following messages:M4=hA∥xj∥M3∥B∥T2M5=hB∥di∥M2∥A∥T1(8)
GWN sends Message 3 = M4,M5 to sensor Sj.After receiving the messageM4,M5, sensor Sj does the following calculations:(1)
Sj uses A getting from user to checks if M4=hA∥xj∥M3∥B∥T2. If they are equal, the procedure goes to next step; otherwise it terminates here.(2)
Sj calculates the shared key SK between Ui and Sj: SK=hk2·A=h(k1·k2·G).(3)
Sj sends Message 4 = B,M5 to user UiAfterUi receives the message B,M5, Ui goes to the following steps. The whole process is in Table 5.(1)
Ui uses B getting from Sj to check if M5=hB∥di∥M2∥A∥T1; if they are equal, the procedure goes to next step; otherwise it terminates here.(2)
Ui calculates the shared key SK′ between Ui and Sj: SK′=hk1·B=h(k1·k2·G).Table 5
Login and authentication phase.
User
Sensor
Gateway
I
D
i
,
P
W
i
,
d
i
S
I
D
j
,
x
j
d
g
,
Q
g
User: inserts
S
C
into terminal
User: input
I
D
i
′
and
P
W
i
′
SC:MPi′=hri∥IDi′∥PWi′
SC:di=fi⊕MPi′
SC:randomk1,A=k1⋅G
SC:gets timestampT1
SC:Kug=hT1∥k1⋅Qg
SC:M1=(IDi,SIDj)⊕Kug
SC:M2=hA∥M1∥di∥T1
checks the freshness of
T
1
→
{
A
,
M
1
,
M
2
,
T
1
}
random
k
2
,
B
=
k
2
⋅
G  gets timestampT2
M
3
=
h
B
∥
M
2
∥
x
j
∥
T
2
checks the freshness of
T
1
,
T
2
→
A
,
M
1
,
M
2
,
T
1
,
B
,
M
3
,
T
2
K
u
g
′
=
h
T
1
∥
d
g
⋅
A  (IDi′,SIDj′)=M1⊕Kug′
d
i
′
=
h
I
D
i
′
∥
X
G
W
N
x
j
′
=
h
S
I
D
j
′
∥
X
G
W
N
checks if:
M
2
=
h
A
∥
M
1
∥
d
i
′
∥
T
1
checks if:
M
3
=
h
B
∥
M
2
∥
x
j
′
∥
T
2
M
4
=
h
A
∥
x
j
∥
M
3
∥
B
∥
T
2
M
5
=
h
B
∥
d
i
∥
M
2
∥
A
∥
T
1
checks if:
M
4
=
h
A
∥
x
j
∥
M
3
∥
B
∥
T
2  SK=hk2⋅A=h(k1⋅k2⋅G)
←
M
4
,
M
5
Checks if:
M
5
=
h
B
∥
d
i
∥
M
2
∥
A
∥
T
1  SK′=hk1⋅B=hk1⋅k2⋅G
←
B
,
M
5


### 4.5. Password Change Phase

If a user wants to change his password, he has to be authenticated by the smart card first. We state the password change process in Table6, which is a summary of the steps:(1)
A userUi inserts his smart card SC into a card reader and inputs their identity and password: IDi,PWi.(2)
SC computes hri∥IDi∥PWi using password IDi, PWi, and the stored ri.(3)
SC compares hri∥IDi∥PWi with the stored version of MPi in the smart card; if they are equal, SC acknowledges the legitimacy of user Ui.(4)
SC computes di=fi⊕MPi using the stored values fi and the user password MPi.(5)
UserUi inputs the new password PWi′.(6)
SC uses this new PWi′ to update the stored version of fi with fi′=di⊕MPi′.Table 6
Password change phase of the user.
User
User: inserts
S
C
into terminal
User: inserts
I
D
i
and
P
W
i
SC:check ifMPi=?hri∥IDi∥PWi
SC:di=fi⊕MPi
User: inputs a new password
P
W
i
′
SC:MPi′=hri∥IDi∥PWi′
SC:fi′=di⊕MPi′
SC:changesfiwithfi′


## 4.1. Symbols Used in the PriAuth

Before the scheme begins,GWN (gateway node) generates the parameters for ECC encryption (p,a,b,G,n,h). After that, GWN generates its public-key pair (dg,Qg); besides, GWN generates a secret key XGWN. The symbols are summarized in Table 2.Table 2
Symbols used in the PriAuth.
Symbols
Meaning
G
W
N
Gateway node
U
i
Theith user
S
j
Thejth sensor node
I
D
i
Theith user’s identity
S
I
D
j
Thejth sensor’s identity
∥
String connector, connect two strings together
⊕
XOR operation
X
G
W
N
G
W
N’s secret value, master key
X
G
W
N
-
S
j
Shared key betweenSj and GWN
(
d
g
,
Q
g
)
The private key and public key ofGWN
G
The generator of ECC
S
K, SK′
Shared key between userUi and Sj
T
1, T2
Timestamp
h
Hash function


## 4.2. Registration Phase of the Sensor

The registration messages of the sensor in registration phase are sent via the public channel. SensorSj conducts the following steps for registration:(1)
It creates a random numberrj and gets the timestamp T1.(2)
It covers its password withrj, MNj=rj⊕XGWN-Sj and generates a hash value MPj=hXGWN-Sj∥rj∥SIDj∥T1.(3)
It sends{SIDj,MPj,MNj,T1} to GWN via a public channel.AfterGWN receives Sj’s registration message {SIDj,MPj,MNj,T1}. GWN has to check the freshness of the message by T1, if the message is not fresh, GWN abandons the message. Then GWN computes rj′=MNj⊕XGWN-Sj. GWN checks if MPj equals hXGWN-Sj∥rj′∥SIDj∥T1. If they are not equal, GWN abandons the message. GWN continues the sensor registration phase in the following steps. The registration phase is described in Table 3.(1)
GWN computes xj=hSIDj∥XGWN,ej=xj⊕hSIDj∥XGWN-Sj.(2)
GWN gets the timestamp T2 and gets the hash value fj=hxj∥XGWN-Sj∥T2.(3)
GWN sends {ej,fj,T2,p,a,b,G,n,h,Qg} to sensor Sj.Table 3
Registration phase of the sensor.
Sensor
Gateway
S
I
D
j
,
X
G
W
N
-
S
j
master key
X
G
W
N  for each sensor storesSIDj,XGWN-Sj
random number
r
j
gets timestamp
T
1
MNj=rj⊕XGWN-Sj
MPj=hXGWN-Sj∥rj∥SIDj∥T1
→
S
I
D
j
,
M
P
j
,
M
N
j
,
T
1
checks if
T
1
is fresh  rj′=MNj⊕XGWN-Sj
M
P
j
=
?
h
X
G
W
N
-
S
j
∥
r
j
∥
S
I
D
j
∥
T
1
gets timestamp
T
2
x
j
=
h
S
I
D
j
∥
X
G
W
N
e
j
=
x
j
⊕
h
S
I
D
j
∥
X
G
W
N
-
S
j
f
j
=
h
x
j
∥
X
G
W
N
-
S
j
∥
T
2
checks if:
T
2
is fresh  xj=ej⊕hSIDj∥XGWN-Sj
←
e
j
,
f
j
,
T
2
,
p
,
a
,
b
,
G
,
n
,
h
,
Q
g
fj=?hxj∥XGWN-Sj∥T2
stores
{
x
j
,
p
,
a
,
b
,
G
,
n
,
h
,
Q
g
}After receiving the message,Sj first checks the freshness of T2, then computes xj=ej⊕hSIDj∥XGWN-Sj, and checks if fj=hxj∥XGWN-Sj∥T2; if they are equal, Sj stores {xj,p,a,b,G,n,h,Qg} in its memory.


## 4.3. Registration Phase of the User

UserUi chooses a random number ri and computes MPi=hri∥IDi∥PWi. Ui then sends {IDi,MPi} to GWN via a secure channel.After receiving the user registration message{IDi,MPi}, GWN computesdi=hIDi∥XGWN, fi=di⊕MPi. Finally, GWN sends {fi,p,a,b,G,n,h,Qg} to Ui.After receiving{fi,p,a,b,G,n,h,Qg}, Ui inserts the previously selected random nonce ri into it, now what in the smart card is {MPi,fi,ri,p,a,b,G,n,h,Qg}. The registration phase is described in Table 4.Table 4
Registration phase of the user.
User
Gateway
I
D
i
,
P
W
i
master key
X
G
W
N
random number
r
i
MPi=hri∥IDi∥PWi
→
I
D
i
,
M
P
i
d
i
=
h
I
D
i
∥
X
G
W
N  fi=di⊕MPi
inserts into the smart card  MPi,fi,ri,p,a,b,G,n,h,Qg
←
f
i
,
p
,
a
,
b
,
G
,
n
,
h
,
Q
g


## 4.4. Login and Authentication Phase

If userUi wants to access a sensor’s data, Ui has to login first. This login process is completed by the smart card SC. 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′=hri∥IDi′∥PWi′ using the inserted PWi′, IDi′ and the stored value ri. Then SC compares MPi′ with MPi in the smart card. If they are equal, SC acknowledges the legitimacy of Ui.After userUi passes through the verification, then SC prepares for the authentication process. SC computes di=fi⊕MPi′ using MPi′ in login phase. SC chooses a random number k1∈[1,n-1] and gets the timestamp T1. SC then computes the following data:A=k1·GKug=hT1∥k1·QgM1=(IDi,SIDj)⊕KugM2=hA∥M1∥di∥T1ThenSC sends Message 1 = A,M1,M2,T1 to sensor Sj via a public channel.After receivingA,M1,M2,T1 from Ui, sensor Sj first checks the freshness of T1 and Sj abandons the message if T1 is not fresh and otherwise goes to the next step. Sj chooses a random number k2∈[1,n-1] and gets the timestamp T2. Sj then computes the following data:B=k2·GM3=hB∥M2∥xj∥T2S
j sends Message 2 = A,M1,M2,T1,B,M3,T2 to GWN via a public channel.After receiving the messageA,M1,M2,T1,B,M3,T2, GWN first checks the freshness of T1 and T2, if T1 or T2 is not fresh, GWN abandons the message; otherwise GWN completes the following steps:(1)
GWN computes Kug′=hT1∥dg·A.(2)
GWN gets IDi′ and SIDj′ by (IDi′,SIDj′)=M1⊕Kug′.(3)
GWN computes di′ by di′=hIDi′∥XGWN.(4)
GWN computes xj′ by xj′=hSIDj′∥XGWN.(5)
GWN uses di′,A,M1 and T1 to check if M2=hA∥M1∥di′∥T1. If they are equal, the procedure goes to next step; otherwise it terminates here.(6)
GWN uses xj′,B,M2 and T2 to check if M3=hB∥M2∥xj′∥T2. If they are equal, the procedure goes to next step; otherwise it terminates here.(7)
GWN calculates the following messages:M4=hA∥xj∥M3∥B∥T2M5=hB∥di∥M2∥A∥T1(8)
GWN sends Message 3 = M4,M5 to sensor Sj.After receiving the messageM4,M5, sensor Sj does the following calculations:(1)
Sj uses A getting from user to checks if M4=hA∥xj∥M3∥B∥T2. If they are equal, the procedure goes to next step; otherwise it terminates here.(2)
Sj calculates the shared key SK between Ui and Sj: SK=hk2·A=h(k1·k2·G).(3)
Sj sends Message 4 = B,M5 to user UiAfterUi receives the message B,M5, Ui goes to the following steps. The whole process is in Table 5.(1)
Ui uses B getting from Sj to check if M5=hB∥di∥M2∥A∥T1; if they are equal, the procedure goes to next step; otherwise it terminates here.(2)
Ui calculates the shared key SK′ between Ui and Sj: SK′=hk1·B=h(k1·k2·G).Table 5
Login and authentication phase.
User
Sensor
Gateway
I
D
i
,
P
W
i
,
d
i
S
I
D
j
,
x
j
d
g
,
Q
g
User: inserts
S
C
into terminal
User: input
I
D
i
′
and
P
W
i
′
SC:MPi′=hri∥IDi′∥PWi′
SC:di=fi⊕MPi′
SC:randomk1,A=k1⋅G
SC:gets timestampT1
SC:Kug=hT1∥k1⋅Qg
SC:M1=(IDi,SIDj)⊕Kug
SC:M2=hA∥M1∥di∥T1
checks the freshness of
T
1
→
{
A
,
M
1
,
M
2
,
T
1
}
random
k
2
,
B
=
k
2
⋅
G  gets timestampT2
M
3
=
h
B
∥
M
2
∥
x
j
∥
T
2
checks the freshness of
T
1
,
T
2
→
A
,
M
1
,
M
2
,
T
1
,
B
,
M
3
,
T
2
K
u
g
′
=
h
T
1
∥
d
g
⋅
A  (IDi′,SIDj′)=M1⊕Kug′
d
i
′
=
h
I
D
i
′
∥
X
G
W
N
x
j
′
=
h
S
I
D
j
′
∥
X
G
W
N
checks if:
M
2
=
h
A
∥
M
1
∥
d
i
′
∥
T
1
checks if:
M
3
=
h
B
∥
M
2
∥
x
j
′
∥
T
2
M
4
=
h
A
∥
x
j
∥
M
3
∥
B
∥
T
2
M
5
=
h
B
∥
d
i
∥
M
2
∥
A
∥
T
1
checks if:
M
4
=
h
A
∥
x
j
∥
M
3
∥
B
∥
T
2  SK=hk2⋅A=h(k1⋅k2⋅G)
←
M
4
,
M
5
Checks if:
M
5
=
h
B
∥
d
i
∥
M
2
∥
A
∥
T
1  SK′=hk1⋅B=hk1⋅k2⋅G
←
B
,
M
5


## 4.5. Password Change Phase

If a user wants to change his password, he has to be authenticated by the smart card first. We state the password change process in Table6, which is a summary of the steps:(1)
A userUi inserts his smart card SC into a card reader and inputs their identity and password: IDi,PWi.(2)
SC computes hri∥IDi∥PWi using password IDi, PWi, and the stored ri.(3)
SC compares hri∥IDi∥PWi with the stored version of MPi in the smart card; if they are equal, SC acknowledges the legitimacy of user Ui.(4)
SC computes di=fi⊕MPi using the stored values fi and the user password MPi.(5)
UserUi inputs the new password PWi′.(6)
SC uses this new PWi′ to update the stored version of fi with fi′=di⊕MPi′.Table 6
Password change phase of the user.
User
User: inserts
S
C
into terminal
User: inserts
I
D
i
and
P
W
i
SC:check ifMPi=?hri∥IDi∥PWi
SC:di=fi⊕MPi
User: inputs a new password
P
W
i
′
SC:MPi′=hri∥IDi∥PWi′
SC:fi′=di⊕MPi′
SC:changesfiwithfi′


## 5. Security Analysis Using BAN Logic

### 5.1. Some Basic Knowledge of BAN Logic

A security analysis of PriAuth using Burrows-Abadi-Needham logic (BAN logic) [41] is conducted in this part. With the help of BAN logic, we can determine whether the exchanged information is trustworthy and secure against eavesdropping. First, some symbols and primary postulates used in BAN logic are described in Tables 7 and 8.Table 7
Symbols of BAN logic.
Symbol
Meaning
P
≡
X
P believes X
P
⊲
X
P sees/receives X
P
~
X
P once said X (or P sent X)
P
⇒
X
P controls X
#(X)
X is fresh
P
↔
k
Q
P and Q communicate using shared key K
→
k
Q
K is the public key of Q
{
X
}
k
MessageX is encrypted by K
{
X
}
k
-
1
MessageX is encrypted by private key KTable 8
Some primary BAN logic postulates.
Rule
BAN Logic form
⊲ rule
P
≡
→
k
P
,
P
⊲
{
X
}
k
P
⊲
X, P≡P↔kQ,P⊲{X}kP⊲X, P≡→kQ,P⊲{X}k-1P⊲X
| ~ introduction rule
P
≡
→
k
Q
,
P
⊲
{
X
}
k
-
1
P
≡
Q
~
X, P≡P↔kQ,P⊲{X}kP≡Q~X
| ~ elimination rule
P
≡
#
X
,
P
≡
Q
~
X
P
≡
Q
≡
X
#
(
)-introduction
P
c
r
e
a
t
e
s
X
P
≡
#
X
Jurisdiction or control rule
P
≡
Q
⤇
X
,
P
≡
Q
≡
X
P
≡
X
↔
k introduction rule
P
≡
#
(
k
)
,
P
≡
Q
≡
X
P
≡
P
↔
k
Q
Freshness rule
P
≡
#
X
P
≡
#
X
,
Y
Elimination of multipart messages rule
P
≡
Q
~
X
,
Y
P
≡
Q
~
X, P≡Q≡X,YP≡Q≡X, P≡X,YP≡X, P⊲X,YP⊲X, P≡#X,YP≡#X


### 5.2. The Premise and Proof Goals of PriAuth

U
i, Sj, and GWN are used as the user, sensor, and the gateway. Suppose GWN is trustworthy, if GWN believes that Ui has said message X and GWN believes that X is fresh, GWN would send X to Sj. If Sj believes X is fresh and Sj believes GWN once said X, then Sj believes Ui said X. This could be translated into BAN logic like postulateA.  According to the “|~ elimination rule,” postulateA could be simplified as postulateB.  It is the same as the message that sensor Sj sends to GWN. If GWN believes Sj once said another message X (the same notion is used for simplification), and GWN believes X is fresh, GWN would send X to Ui. If Ui believes X is fresh and Ui believes GWN once said X, then Ui believes Sj said X. In the same way, we can get postulateC. postulateAGWN≡#X,GWN≡Ui~X,Sj≡#X,Sj≡GWN~XSj≡Ui~XpostulateBGWN≡Ui≡X,Sj≡GWN≡XSj≡Ui~XpostulateCGWN≡Sj≡X,Ui≡GWN≡XUi≡Sj~XThe proof goals of PriAuth in BAN logic form are in the way described below. These goals could ensureUi and Sj to agree on a shared key SK.(5)1Ui≡Ui↔SKSj2Sj≡Ui↔SKSj.


### 5.3. Preparation for Proof

Before the proof begins, messages have to be transformed into an idealized form, the messages of PriAuth in idealized form in BAN logic are given in Table9  Kug=hT1∥k1·Qg. At the same time, some assumptions have to be made, so postulateB and postulateC are included as assumptions A11 and A12. The assumptions are listed in Table 10.Table 9
The idealization form of the message.
Message
Flow
Idealized form
1
U
i
⟶
S
j
A
,
I
D
i
,
S
I
D
j
K
u
g
,
A
,
I
D
i
,
S
I
D
j
K
u
g
,
T
1
d
i
,
T
1
2
S
j
⟶
G
W
N
A
,
I
D
i
,
S
I
D
j
K
u
g
,
A
,
I
D
i
,
S
I
D
j
K
u
g
,
T
1
d
i
,
T
1
,
B
,
B
,
M
2
,
T
2
x
j
,
T
2
3
G
W
N
⟶
S
j
A
,
M
3
,
B
,
T
2
x
j
,
B
,
M
2
,
A
,
T
1
d
i
4
S
j
⟶
U
i
B
,
B
,
M
2
,
A
,
T
1
d
iTable 10
Some assumptions.
Number
Assumptions
A1
G
W
N
≡
#
A
A2
G
W
N
≡
#
B
A3
S
j
≡
#
A
A4
U
i
≡
#
B
A5
U
i
≡
G
W
N
↔
d
i
U
i
A6
G
W
N
≡
G
W
N
↔
d
i
U
i
A7
U
i
≡
G
W
N
↔
K
u
g
U
i
A8
G
W
N
≡
G
W
N
↔
K
u
g
U
i
A9
S
j
≡
G
W
N
↔
x
j
S
j
A10
G
W
N
≡
G
W
N
↔
x
j
S
j
A11
G
W
N
≡
U
i
≡
X
,
S
j
≡
G
W
N
≡
X
S
j
≡
U
i
~
X
A12
G
W
N
≡
S
j
≡
X
,
U
i
≡
G
W
N
≡
X
U
i
≡
S
j
~
X
A13
S
j
≡
U
i
⤇
A
A14
U
i
≡
S
j
⤇
B


### 5.4. The Proof of PriAuth

The whole proof of the proposal is in AppendixA. It has been divided into 3 parts related to Message 2, Message 3, and Message 4 separately. The two goals of the scheme are proved at the Message 3 and Message 4. The proof results show that PriAuth is secured under BAN logic.


## 5.1. Some Basic Knowledge of BAN Logic

A security analysis of PriAuth using Burrows-Abadi-Needham logic (BAN logic) [41] is conducted in this part. With the help of BAN logic, we can determine whether the exchanged information is trustworthy and secure against eavesdropping. First, some symbols and primary postulates used in BAN logic are described in Tables 7 and 8.Table 7
Symbols of BAN logic.
Symbol
Meaning
P
≡
X
P believes X
P
⊲
X
P sees/receives X
P
~
X
P once said X (or P sent X)
P
⇒
X
P controls X
#(X)
X is fresh
P
↔
k
Q
P and Q communicate using shared key K
→
k
Q
K is the public key of Q
{
X
}
k
MessageX is encrypted by K
{
X
}
k
-
1
MessageX is encrypted by private key KTable 8
Some primary BAN logic postulates.
Rule
BAN Logic form
⊲ rule
P
≡
→
k
P
,
P
⊲
{
X
}
k
P
⊲
X, P≡P↔kQ,P⊲{X}kP⊲X, P≡→kQ,P⊲{X}k-1P⊲X
| ~ introduction rule
P
≡
→
k
Q
,
P
⊲
{
X
}
k
-
1
P
≡
Q
~
X, P≡P↔kQ,P⊲{X}kP≡Q~X
| ~ elimination rule
P
≡
#
X
,
P
≡
Q
~
X
P
≡
Q
≡
X
#
(
)-introduction
P
c
r
e
a
t
e
s
X
P
≡
#
X
Jurisdiction or control rule
P
≡
Q
⤇
X
,
P
≡
Q
≡
X
P
≡
X
↔
k introduction rule
P
≡
#
(
k
)
,
P
≡
Q
≡
X
P
≡
P
↔
k
Q
Freshness rule
P
≡
#
X
P
≡
#
X
,
Y
Elimination of multipart messages rule
P
≡
Q
~
X
,
Y
P
≡
Q
~
X, P≡Q≡X,YP≡Q≡X, P≡X,YP≡X, P⊲X,YP⊲X, P≡#X,YP≡#X


## 5.2. The Premise and Proof Goals of PriAuth

U
i, Sj, and GWN are used as the user, sensor, and the gateway. Suppose GWN is trustworthy, if GWN believes that Ui has said message X and GWN believes that X is fresh, GWN would send X to Sj. If Sj believes X is fresh and Sj believes GWN once said X, then Sj believes Ui said X. This could be translated into BAN logic like postulateA.  According to the “|~ elimination rule,” postulateA could be simplified as postulateB.  It is the same as the message that sensor Sj sends to GWN. If GWN believes Sj once said another message X (the same notion is used for simplification), and GWN believes X is fresh, GWN would send X to Ui. If Ui believes X is fresh and Ui believes GWN once said X, then Ui believes Sj said X. In the same way, we can get postulateC. postulateAGWN≡#X,GWN≡Ui~X,Sj≡#X,Sj≡GWN~XSj≡Ui~XpostulateBGWN≡Ui≡X,Sj≡GWN≡XSj≡Ui~XpostulateCGWN≡Sj≡X,Ui≡GWN≡XUi≡Sj~XThe proof goals of PriAuth in BAN logic form are in the way described below. These goals could ensureUi and Sj to agree on a shared key SK.(5)1Ui≡Ui↔SKSj2Sj≡Ui↔SKSj.


## 5.3. Preparation for Proof

Before the proof begins, messages have to be transformed into an idealized form, the messages of PriAuth in idealized form in BAN logic are given in Table9  Kug=hT1∥k1·Qg. At the same time, some assumptions have to be made, so postulateB and postulateC are included as assumptions A11 and A12. The assumptions are listed in Table 10.Table 9
The idealization form of the message.
Message
Flow
Idealized form
1
U
i
⟶
S
j
A
,
I
D
i
,
S
I
D
j
K
u
g
,
A
,
I
D
i
,
S
I
D
j
K
u
g
,
T
1
d
i
,
T
1
2
S
j
⟶
G
W
N
A
,
I
D
i
,
S
I
D
j
K
u
g
,
A
,
I
D
i
,
S
I
D
j
K
u
g
,
T
1
d
i
,
T
1
,
B
,
B
,
M
2
,
T
2
x
j
,
T
2
3
G
W
N
⟶
S
j
A
,
M
3
,
B
,
T
2
x
j
,
B
,
M
2
,
A
,
T
1
d
i
4
S
j
⟶
U
i
B
,
B
,
M
2
,
A
,
T
1
d
iTable 10
Some assumptions.
Number
Assumptions
A1
G
W
N
≡
#
A
A2
G
W
N
≡
#
B
A3
S
j
≡
#
A
A4
U
i
≡
#
B
A5
U
i
≡
G
W
N
↔
d
i
U
i
A6
G
W
N
≡
G
W
N
↔
d
i
U
i
A7
U
i
≡
G
W
N
↔
K
u
g
U
i
A8
G
W
N
≡
G
W
N
↔
K
u
g
U
i
A9
S
j
≡
G
W
N
↔
x
j
S
j
A10
G
W
N
≡
G
W
N
↔
x
j
S
j
A11
G
W
N
≡
U
i
≡
X
,
S
j
≡
G
W
N
≡
X
S
j
≡
U
i
~
X
A12
G
W
N
≡
S
j
≡
X
,
U
i
≡
G
W
N
≡
X
U
i
≡
S
j
~
X
A13
S
j
≡
U
i
⤇
A
A14
U
i
≡
S
j
⤇
B


## 5.4. The Proof of PriAuth

The whole proof of the proposal is in AppendixA. It has been divided into 3 parts related to Message 2, Message 3, and Message 4 separately. The two goals of the scheme are proved at the Message 3 and Message 4. The proof results show that PriAuth is secured under BAN logic.


## 6. 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”[42]. Recently, many papers have used this method as a way to authenticate their protocols, like [24–26]. HLPSL (High Level Protocols Specification Language) is a role-based language that is used to describe security protocols and specifying their intended security properties, as well as a set of tools to formally validate them. We write the protocol in HLPSL and test the protocol. The code is in Appendix B. The goal of PriAuth is to create a key that is shared by a user and a sensor. The validation result of the protocol is in Table 11. Considering all these testing activities, it could be concluded that our protocol is safe. PriAuth can protect the privacy of the user identity, sensor identity, and the key between the user and sensor.Table 11
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/iotdev/avispa/avispa-1.1/testsuite/results/usg.if
/home/iotdev/avispa/avispa-1.1/testsuite/results/usg.if
GOAL
GOAL
as_specified
As Specified
BACKEND
OFMC
BACKEND
COMMENTS
CL-AtSe
STATISTICS
parseTime: 0.00 s
STATISTICS
searchTime: 0.05 s
Analysed: 14 states
visitedNodes: 24 nodes
Reachable: 4 states
depth: 4 plies
Translation: 0.00 seconds
Computation: 0.00 seconds


## 7. Security and Privacy Analysis

In this section, we conduct a security comparison of the schemes that has been depicted as Table12. For the scheme in [3], we only consider the second situation.Table 12
Security feature comparison.
Security feature
[1]
[3, Scheme 2]
[7]
[9]
PriAuth
User anonymity
×
×
√
√
√
Sensor anonymity
×
×
×
×
√
Shared key privacy
√
√
√
√
√
Traceability of user
×
×
√
√
√
Traceability of sensor
×
×
×
×
√
Loss of synchronization
√
√
×
√
√
Malicious sensor attack
√
√
√
√
√
User impersonation attack
×
√
√
√
√
Sensor impersonation attack
√
√
√
√
√
Replay attack
√
√
×
√
√
Inside user attack
√
√
√
√
√


### 7.1. Traceability Protection

Traceability means the adversary can track a user or a sensor according to their identities or masked identities like in the scheme [5, 10, 29–32]. Once some fixed information about the identities is used in a scheme, then this scheme could probably be tracked by an adversary. One possible solution is to update their masked identity every time like in the schemes shown in [4, 7]. But these kinds of solutions are vulnerable to loss of synchronization attack.


### 7.2. Synchronization Loss Attack

In order to protect the identity of the user, the gateway will generate a new identity for them when it is requested [4]. But if an adversary prevents this new identity from being received by the user, the user could not update his old identity while the gateway has updated its stored version of the user’s identity. When the user logs in for the next time, this legitimate user will not be treated as a legal one anymore. A similar problem exists in the scheme [7].


### 7.3. Malicious Sensor Attack

Like in scheme [13], the gateway only checks the legitimacy of a sensor. If the sensor is a legitimate one, the gateway will reply some key information to the sensor, but the gateway does not check if the sensor is the one that the user wants to talk to. So a legitimate but malicious sensor could launch an attack.When a user sends a request message{M1,M2,M3,T1} to a sensor, an inner side legitimate sensor can intercept this message to generate its own {M4′,M5′,ESIDj′,T2′} and send this message to the gateway, as the gateway only checks the legitimacy of the sensor. Therefore, this inner side sensor will definitely be treated as a legal sensor. The gateway will send {M6′,M7′,M8′,M9′,T3′} to the sensor. Afterwards, the sensor will be able to send {M6′,M8′,M10′,T3′,T4′} to the user, and it will be treated as a legal sensor by the user, but the user will not check if this is the sensor he wants to talk to. In this way, the sensor could send false data to the user.


### 7.4. Inside User Attack

In scheme [6], all the users share a key v∗, so there is a potential risk. The message a gateway sends to the user is Di=EkDIDi∥SIDn∥SK∥R1∥T4, where k=hDIDi∥v∗∥T4, in which DIDi and T4 are public message, and v∗ is shared by all the legitimate users. This means any legitimate user could decrypt Di to get the shared key SK.


### 7.5. User Impersonation Attack

In scheme [1], when a user asks to access a sensor’s data, he could send his request M1={IDu,IDSn,X,Tu,α,ω} to the sensor.(6)X′=ru×P,X=ru×Ku,ω=hIDu∥hIDSn∥hX⊕Y∥Tu,α=hIDu∥IDSn∥X∥X′∥Tu∥ω.I
D
u, Ku, P, and IDSn are sent publicly; ru is a random number generated by the user, whereas Tu is a timestamp. Only h(X⊕Y) is regarded as secret information between the user and the gateway. h(X⊕Y) is shared by all the users; other legitimate users, say a legitimate user with IDu′, could easily generate a request the same as M1, and then IDu′ will be treated as IDu by the gateway.


## 7.1. Traceability Protection

Traceability means the adversary can track a user or a sensor according to their identities or masked identities like in the scheme [5, 10, 29–32]. Once some fixed information about the identities is used in a scheme, then this scheme could probably be tracked by an adversary. One possible solution is to update their masked identity every time like in the schemes shown in [4, 7]. But these kinds of solutions are vulnerable to loss of synchronization attack.


## 7.2. Synchronization Loss Attack

In order to protect the identity of the user, the gateway will generate a new identity for them when it is requested [4]. But if an adversary prevents this new identity from being received by the user, the user could not update his old identity while the gateway has updated its stored version of the user’s identity. When the user logs in for the next time, this legitimate user will not be treated as a legal one anymore. A similar problem exists in the scheme [7].


## 7.3. Malicious Sensor Attack

Like in scheme [13], the gateway only checks the legitimacy of a sensor. If the sensor is a legitimate one, the gateway will reply some key information to the sensor, but the gateway does not check if the sensor is the one that the user wants to talk to. So a legitimate but malicious sensor could launch an attack.When a user sends a request message{M1,M2,M3,T1} to a sensor, an inner side legitimate sensor can intercept this message to generate its own {M4′,M5′,ESIDj′,T2′} and send this message to the gateway, as the gateway only checks the legitimacy of the sensor. Therefore, this inner side sensor will definitely be treated as a legal sensor. The gateway will send {M6′,M7′,M8′,M9′,T3′} to the sensor. Afterwards, the sensor will be able to send {M6′,M8′,M10′,T3′,T4′} to the user, and it will be treated as a legal sensor by the user, but the user will not check if this is the sensor he wants to talk to. In this way, the sensor could send false data to the user.


## 7.4. Inside User Attack

In scheme [6], all the users share a key v∗, so there is a potential risk. The message a gateway sends to the user is Di=EkDIDi∥SIDn∥SK∥R1∥T4, where k=hDIDi∥v∗∥T4, in which DIDi and T4 are public message, and v∗ is shared by all the legitimate users. This means any legitimate user could decrypt Di to get the shared key SK.


## 7.5. User Impersonation Attack

In scheme [1], when a user asks to access a sensor’s data, he could send his request M1={IDu,IDSn,X,Tu,α,ω} to the sensor.(6)X′=ru×P,X=ru×Ku,ω=hIDu∥hIDSn∥hX⊕Y∥Tu,α=hIDu∥IDSn∥X∥X′∥Tu∥ω.I
D
u, Ku, P, and IDSn are sent publicly; ru is a random number generated by the user, whereas Tu is a timestamp. Only h(X⊕Y) is regarded as secret information between the user and the gateway. h(X⊕Y) is shared by all the users; other legitimate users, say a legitimate user with IDu′, could easily generate a request the same as M1, and then IDu′ will be treated as IDu by the gateway.


## 8. Comparison

### 8.1. Computational Performance

The normal way to compute the execution time of the protocol is to calculate protocol’s computational costs of different operations, and the operations’ execution time is measured by simulation [3–14]. The execution time of XOR operation is very small compared to an elliptic curve point multiplication or hash operation; we neglect it when computing the time approximately [3]. We use the famous MIRACL++ Library [43] (example code can be found at [44]). The experiment is conducted in Visual C++ 2017 on a 64-bit Windows 7 operating system, 3.5 GHz processor, 8 GB memory. The hash function is the SHA-1; the symmetric encryption/decryption function is AES with a 128-bit long key of the MR_PCFB1 form (using one string to encrypt another string, the same hash function is called to get the hashed form of the key string). The elliptic curve encryption scheme is ECC-160. The results are shown in Table 13. Tmac is the time for HMAC with SHA-1 operation, according to [9] Tmac≈TH. The final result is in Table 14.Table 13
Computation time of different operations.
Operations
Time
Experiment times
T
H
: one way hash function
0.0394 ms
1000000
T
E/D
: symmetric encryption/decryption
0.5728 ms
100000
T
M
U
L
: scalar multiplication in ECC-160
3.66 ms
2733Table 14
Computation cost of the login and authentication.
Schemes
User
Sensor
Gateway
Total
Total (ms)
Choi et al. [1]
7
T
H
+
3
T
M
U
L
4
T
H
+
2
T
M
U
L
4
T
H
+
1
T
M
U
L
1
5
T
H
+
6
T
M
U
L
22.551
Chang and Le  [3, Scheme 2]
7
T
H
+
2
T
M
U
L
5
T
H
+
2
T
M
U
L
9
T
H
2
1
T
H
+
4
T
M
U
L
15.4674
Fan et al. [7]
1
3
T
H
+
2
T
M
U
L
4
T
H
+
2
T
M
U
L
1
4
T
H
3
1
T
H
+
4
T
M
U
L
15.8614
Nam et al. [9]
3
T
H
+
1
T
E
/
D
+
1
T
m
a
c
+
3
T
M
U
L
1
T
H
+
2
T
m
a
c
+
2
T
M
U
L
2
T
H
+
2
T
E
/
D
+
3
T
m
a
c
+
1
T
M
U
L
6
T
H
+
3
T
E
/
D
+
6
T
m
a
c
+
6
T
M
U
L
24.1512
PriAuth
5
T
H
+
3
T
M
U
L
3
T
H
+
2
T
M
U
L
7
T
H
+
1
T
M
U
L
1
5
T
H
+
6
T
M
U
L
22.551


### 8.2. Communication Performance

The sum of each variable length in bytes which a sensor node and a gateway node need while performing authentication process is calculated for comparison of the communication cost. The identity or password is 8-byte long [13]. The sizes of the general hash function’s output and timestamp are 20 bytes and 4 bytes, respectively [45]. The random point of ECC-160 is 20 bytes. The result is shown in Table 15. The byte length of the AES encryption result is treated as byte length of the original data for approximation.Table 15
Communication comparison.
Schemes
M1
M2
M3
M4
Total bytes
C
o
m
p
a
r
e
d
∗
Choi et al. [1]
80
124
44
68
316
+64
Chang and Le [3, Scheme 2]
64
84
64
44
256
+4
Fan et al. [7]
128
68
60
100
356
+104
Nam et al. [9]
52
104
40
56
252
0
PriAuth
64
108
40
40
252
0
C
o
m
p
a
r
e
d
∗ means compared with our scheme; M1, M2, M3, and M4 mean Messages 1, 2, 3, and 4.


## 8.1. Computational Performance

The normal way to compute the execution time of the protocol is to calculate protocol’s computational costs of different operations, and the operations’ execution time is measured by simulation [3–14]. The execution time of XOR operation is very small compared to an elliptic curve point multiplication or hash operation; we neglect it when computing the time approximately [3]. We use the famous MIRACL++ Library [43] (example code can be found at [44]). The experiment is conducted in Visual C++ 2017 on a 64-bit Windows 7 operating system, 3.5 GHz processor, 8 GB memory. The hash function is the SHA-1; the symmetric encryption/decryption function is AES with a 128-bit long key of the MR_PCFB1 form (using one string to encrypt another string, the same hash function is called to get the hashed form of the key string). The elliptic curve encryption scheme is ECC-160. The results are shown in Table 13. Tmac is the time for HMAC with SHA-1 operation, according to [9] Tmac≈TH. The final result is in Table 14.Table 13
Computation time of different operations.
Operations
Time
Experiment times
T
H
: one way hash function
0.0394 ms
1000000
T
E/D
: symmetric encryption/decryption
0.5728 ms
100000
T
M
U
L
: scalar multiplication in ECC-160
3.66 ms
2733Table 14
Computation cost of the login and authentication.
Schemes
User
Sensor
Gateway
Total
Total (ms)
Choi et al. [1]
7
T
H
+
3
T
M
U
L
4
T
H
+
2
T
M
U
L
4
T
H
+
1
T
M
U
L
1
5
T
H
+
6
T
M
U
L
22.551
Chang and Le  [3, Scheme 2]
7
T
H
+
2
T
M
U
L
5
T
H
+
2
T
M
U
L
9
T
H
2
1
T
H
+
4
T
M
U
L
15.4674
Fan et al. [7]
1
3
T
H
+
2
T
M
U
L
4
T
H
+
2
T
M
U
L
1
4
T
H
3
1
T
H
+
4
T
M
U
L
15.8614
Nam et al. [9]
3
T
H
+
1
T
E
/
D
+
1
T
m
a
c
+
3
T
M
U
L
1
T
H
+
2
T
m
a
c
+
2
T
M
U
L
2
T
H
+
2
T
E
/
D
+
3
T
m
a
c
+
1
T
M
U
L
6
T
H
+
3
T
E
/
D
+
6
T
m
a
c
+
6
T
M
U
L
24.1512
PriAuth
5
T
H
+
3
T
M
U
L
3
T
H
+
2
T
M
U
L
7
T
H
+
1
T
M
U
L
1
5
T
H
+
6
T
M
U
L
22.551


## 8.2. Communication Performance

The sum of each variable length in bytes which a sensor node and a gateway node need while performing authentication process is calculated for comparison of the communication cost. The identity or password is 8-byte long [13]. The sizes of the general hash function’s output and timestamp are 20 bytes and 4 bytes, respectively [45]. The random point of ECC-160 is 20 bytes. The result is shown in Table 15. The byte length of the AES encryption result is treated as byte length of the original data for approximation.Table 15
Communication comparison.
Schemes
M1
M2
M3
M4
Total bytes
C
o
m
p
a
r
e
d
∗
Choi et al. [1]
80
124
44
68
316
+64
Chang and Le [3, Scheme 2]
64
84
64
44
256
+4
Fan et al. [7]
128
68
60
100
356
+104
Nam et al. [9]
52
104
40
56
252
0
PriAuth
64
108
40
40
252
0
C
o
m
p
a
r
e
d
∗ means compared with our scheme; M1, M2, M3, and M4 mean Messages 1, 2, 3, and 4.


## 9. Validation

LifeWear project intends to improve the quality of human life by using wearable equipment and applications for everyday use [46]. The main objective of LifeWear is the development of modern physiological monitoring to inspect human health parameters, like blood pressure, pulse, or the electrocardiogram of a patient in different environments. With real-time data of these health parameters, medical staffs can take actions instantly, which can greatly improve the quality of a treatment.Since medical parameters are sent from patients to medical staffs, data security and patient’s privacy are a must. In order to ensure the data confidentiality, all the data must be encrypted before they are sent. The proposed scheme helps the patients and medical staff building a shared key. This key will be used to encrypt the health parameters of the patient. In order to protect the privacy of the patient, all the identities are encrypted before they are sent as well. Since wearable sensors have only limited computability, we introduce a gateway to provide the patients and medical staff the shared key to be used in the system.LifeWear project also makes use of a middleware solution able to hide heterogeneity and interoperability problem. This middleware is composed of four abstraction layers related to the functionalities covered in each of them, namely, hardware abstraction layer, low and high services, cross-layer services, and service composition platform.The hardware abstraction layer includes the IoT hardware platform, the operating system, and the networking stack. It offers an easy way to port the solution to other hardware platforms. The low and high service layers define the software components needed to abstract the underlying network heterogeneity, thus providing an integrated, distributed environment to simplify programming tasks by means of a set of generic services, along with an access point to the management functions of the sensor network services. The upper layer is the service composition platform, designed to build applications using services offered by the lower layers. The cross-layer services are offered to both high and low level services in order to provide inner service composition. The proposal presented in this paper (PriAuth) has been deployed as a service inside this layer. The security service can be used by the upper layer (service composition) to compose newly secured services, based on the services presented in the lower layers.The architecture has been deployed over a commercial IoT node solution called SunSPOT platform, manufactured by Oracle. Main characteristics of SunSPOT hardware platform are as follows:(a)
Processor: ARM 920T CPU (400 MHz, 32 bits)(b)
Memory: 1 Mb RAM, 8 Mb Flash memory(c)
Network: Chipcon 2420 radio with integrated antenna (IEEE 802.15.4 at 2.4 GHz)(d)
Data: USB interface, mini-USB connector(e)
Power supply: 3.6 V rechargeable 750 mAh Li-Ion battery


## 10. Conclusions

Privacy will be a big concern as more and more IoT equipment is applied into the medical scenarios. In this paper, we propose an authentication and key agreement scheme tailored for Wireless Sensor Networks. We focus on the privacy problems during the authentication process. Our scheme not only ensures the security of the data but also protects the identity privacy of the users and sensors. The shared key between the user and sensor is built by means of the Elliptic Curve Diffie–Hellman method, which could ensure forward privacy. The proposed scheme has been verified with BAN logic and AVISPA, which are the two most commonly used tools to validate the security of the communication scheme. Simulation results show that our scheme is feasible and secure. Furthermore, experiment results show that our scheme is comparable with the related works in terms of computation cost and more efficient in communication cost.As part of our work in the LifeWear project, we focus on privacy problems during the authentication and key establishment processes. In future, we will pay more attention to authentication scheme without the help of the gateway.



---

*Source: 5290579-2017-12-24.xml*