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

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.


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.

Wireless Communications and Mobile Computing
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][16][17][18][19][20][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][23][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][25][26], and so forth.
This paper is organized as follows: Section 2 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.

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 ℎ( GWN ‖ 1) to encrypt the sensor identity, using XOR method where SID  is the sensor identity and  2 is a timestamp.
where ℎ( GWN ‖ 1) is a key that is shared by all the sensors, so malicious or curious sensors could learn the identity of sensor SID  .As ESID  ,  2 are sent via a public channel.A malicious or curious sensor with identity SID  can eavesdrop sensor SID  to get ESID  ,  2 .In order to get the sensor id SID  , SID  could decrypt ESID  using the same key ℎ( GWN ‖ 1): Lu et al. use a random identity TID  to protect identity privacy [10].But as the identity is a fixed value, a user could be tracked by an adversary.Schemes [29][30][31][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 new PID newMU for the user [4].But in this case, there is a potential loss of synchronization problem: if the adversary blocks the PID newMU 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: DID  = ℎ(ID  ‖  1 ),  = ℎ(DID  ‖ V * ‖  1 ),   =   (DID  ‖  1 ‖  1 ), so other users could learn DID  by decrypting   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  = , where  and  are two large primes.If  =  2 mod  has a solution, that is, there exists a square root for , then  is called a quadratic residue mod.The set of all quadratic residue numbers in [1, −1] is denoted by QR  .The quadratic residue problem states that, for  ∈ QR  , it is hard to find  without the knowledge of  and  due to the difficulty of factoring  [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 Table 1.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][38][39].We adopt the ECC based method to enable the anonymity, which is similar to [15][16][17][18][19][20][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.
As for the shared key between user and sensor, in some schemes, the gateway knows the shared key in schemes [6][7][8][11][12][13][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.

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: In order to use ECC, all parties must agree on all the domain parameters of the elliptic curve {, , , , , ℎ}: (): the finite field over , where  is a prime and represents the size of the finite field Elliptic 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 (, , , , , ℎ) must be agreed upon.Also, each party must have a key pair suitable for elliptic curve cryptography, consisting of a private key  (a randomly selected integer in the interval [1, − 1]) and a public key  (where  = , that is, the result of adding  together  times).
Alice's private key and public key are (  ,   ); Bob's key pair is (  ,   ).Alice computes     while Bob computes     .So the shared key between them is     =     , because

Privacy Enhanced Scheme: PriAuth
The structure model of our scheme is depicted in Figure 1.
A gateway is introduced to help user and sensor authenticate each other.We suppose this gateway is trustworthy.

Symbols
Used in the PriAuth.Before the scheme begins, GWN (gateway node) generates the parameters for ECC encryption (, , , , , ℎ).After that, GWN generates its public-key pair (  ,   ); besides, GWN generates a secret key  GWN .The symbols are summarized in Table 2.  (1) It creates a random number   and gets the timestamp  1 .

User Gateway Sensor
(2) It covers its password with   ,   =   ⊕  GWN-  and generates a hash value After GWN receives   's registration message {SID  ,   ,   ,  1 }.GWN has to check the freshness of the message by  1 , if the message is not fresh, GWN abandons the message.Then GWN computes ).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 (2) GWN gets the timestamp  2 and gets the hash value After user   passes through the verification, then SC prepares for the authentication process.SC computes   =   ⊕    using    in login phase.SC chooses a random number  1 ∈ [1,  − 1] and gets the timestamp  1 .SC then computes the following data: Then SC sends Message 1 = {,  1 ,  2 ,  1 } to sensor   via a public channel.
(2)   calculates the shared key SK  between   and   :

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 Table 6, which is a summary of the steps: (1) A user   inserts his smart card SC into a card reader and inputs their identity and password: ID  , PW  .
(3) SC compares ℎ(  ‖ ID  ‖ PW  ) with the stored version of   in the smart card; if they are equal, SC acknowledges the legitimacy of user   .

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.The proof goals of PriAuth in BAN logic form are in the way described below.These goals could ensure   and   to agree on a shared key SK.

The Premise and
(5)

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 Table 9 (  = ℎ( 1 ‖  1 ⋅   )).At the same time, some assumptions have to be made, so (postulate B) and (postulate C) are included as assumptions A11 and A12.The assumptions are listed in Table 10.

The Proof of PriAuth.
The whole proof of the proposal is in Appendix A. 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.

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][25][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.

Security and Privacy Analysis
In this section, we conduct a security comparison of the schemes that has been depicted as Table 12.For the scheme in [3], we only consider the second situation.

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][30][31][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.

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 { 1 ,  2 ,  3 ,  1 } to a sensor, an inner side legitimate sensor can intercept this message to generate its own {  4 ,   5 , ESID   ,   2 } 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 {   6 ,   7 ,   8 ,   9 ,   3 } to the sensor.Afterwards, the sensor will be able to send {  6 ,   8 ,   10 ,   3 ,   4 } 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.

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   =   (DID  ‖ SID  ‖ SK ‖  1 ‖  4 ), where  = ℎ(DID  ‖ V * ‖  4 ), in which DID  and  4 are public message, and V * is shared by all the legitimate users.This means any legitimate user could decrypt   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  1 = {ID  , ID   , ,   , , } to the sensor.
ID  ,   , , and ID   are sent publicly;   is a random number generated by the user, whereas   is a timestamp.Only ℎ( ⊕ ) is regarded as secret information between the user and the gateway.ℎ( ⊕ ) is shared by all the users; other legitimate users, say a legitimate user with ID   , could easily generate a request the same as  1 , and then ID   will be treated as ID  by the gateway.

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][4][5][6][7][8][9][10][11][12][13][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. mac is the time for HMAC with SHA-1 operation, according to [9]  mac ≈   .The final result is in Table 14.

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.

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 realtime 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:

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.

Figure 1 :
Figure 1: The structure of the model.

Table 1 :
Comparison of protection of privacy.

Table 2 :
Symbols used in the PriAuth.
GWN GWN's secret value, master key  GWN-  Shared key between   and GWN (  ,   ) The private key and public key of GWN  The generator of ECC SK, SK  Shared key between user   and    1 ,  2 Timestamp ℎ Hash function 4.2.Registration Phase of the Sensor.The registration messages of the sensor in registration phase are sent via the public channel.Sensor   conducts the following steps for registration: first checks the freshness of  2 , then computes   =   ⊕ℎ(SID  ‖  GWN-  ), and checks if   = ℎ(  ‖  GWN-  ‖  2 ); if they are equal,   stores {  , , , , , , ℎ,   } in its memory.4.3.Registration Phase of the User.User   chooses a random number   and computes   = ℎ(  ‖ ID  ‖ PW  ).  then sends {ID  ,   } to GWN via a secure channel.After receiving the user registration message {ID  ,   }, GWN computes   = ℎ(ID  ‖  GWN ),   =   ⊕   .Finally, GWN sends {  , , , , , , ℎ,   } to   .After receiving {  , , , , , , ℎ,   },   inserts the previously selected random nonce   into it, now what in the smart card is {  ,   ,   , , , , , , ℎ,   }.The registration phase is described in Table 4. 4.4.Login and Authentication Phase.If user   wants to access a sensor's data,   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 ID   and password PW   .SC computes a temporary version    = ℎ(  ‖ ID   ‖ PW   ) using the inserted PW   , ID   and the stored value   .Then SC compares    with   in the smart card.If they are equal, SC acknowledges the legitimacy of   .

Table 3 :
Registration phase of the sensor.Sensor Gateway SID  ,  GWN-  master key  GWN for each sensor stores SID  ,  GWN-  random number   gets timestamp  1

Table 6 :
Password change phase of the user.SC computes   =   ⊕   using the stored values   and the user password   .

Table 7 :
Symbols of BAN logic.

Table 8 :
Some primary BAN logic postulates.

Table 13 :
Computation time of different operations.

Table 14 :
Computation cost of the login and authentication. MUL22.551