Privacy in the Internet of ThingsView this Special Issue
Research Article | Open Access
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.
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: 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.
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 . All the sensors use the same key to encrypt the sensor identity, using XOR method where is the sensor identity and is a timestamp.
where is a key that is shared by all the sensors, so malicious or curious sensors could learn the identity of sensor . As , are sent via a public channel. A malicious or curious sensor with identity can eavesdrop sensor to get , . In order to get the sensor id , could decrypt using the same key :
Lu et al. use a random identity to protect identity privacy . 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 new for the user . But in this case, there is a potential loss of synchronization problem: if the adversary blocks the 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 .
Jung et al. use the similar method with the scheme  of Farash et al. . 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: , , , so other users could learn by decrypting with the same key . 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 has a solution, that is, there exists a square root for , then is called a quadratic residue . The set of all quadratic residue numbers in is denoted by . The quadratic residue problem states that, for , it is hard to find without the knowledge of and due to the difficulty of factoring ; 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 . 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 .
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–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” . 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–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.
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 : the parameters of elliptic curves over : generator point, but : the order of the base point : cofactor, an integer,
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 ) 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
4. 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.
4.1. Symbols Used in the PriAuth
Before the scheme begins, (gateway node) generates the parameters for ECC encryption . After that, generates its public-key pair ; besides, generates a secret key . The symbols are summarized in Table 2.
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:(1)It creates a random number and gets the timestamp .(2)It covers its password with , and generates a hash value .(3)It sends to via a public channel.
After receives ’s registration message . has to check the freshness of the message by , if the message is not fresh, abandons the message. Then computes . checks if equals . If they are not equal, abandons the message. continues the sensor registration phase in the following steps. The registration phase is described in Table 3.(1) computes .(2) gets the timestamp and gets the hash value .(3) sends to sensor .
After receiving the message, first checks the freshness of , then computes , and checks if ; if they are equal, stores in its memory.
4.3. Registration Phase of the User
User chooses a random number and computes . then sends to via a secure channel.
After receiving the user registration message , computes, . Finally, 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 . A user inserts his smart card into a card reader and inputs his identity and password . computes a temporary version using the inserted , and the stored value . Then compares with in the smart card. If they are equal, acknowledges the legitimacy of .
After user passes through the verification, then prepares for the authentication process. SC computes using in login phase. chooses a random number and gets the timestamp . then computes the following data:
Then sends Message 1 = to sensor via a public channel.
After receiving from , sensor first checks the freshness of and abandons the message if is not fresh and otherwise goes to the next step. chooses a random number and gets the timestamp . then computes the following data:
sends Message 2 = to via a public channel.
After receiving the message , first checks the freshness of and , if or is not fresh, abandons the message; otherwise completes the following steps:(1) computes .(2) gets and by .(3) computes by .(4) computes by .(5) uses and to check if . If they are equal, the procedure goes to next step; otherwise it terminates here.(6) uses and to check if . If they are equal, the procedure goes to next step; otherwise it terminates here.(7) calculates the following messages: (8) sends Message 3 = to sensor .
After receiving the message , sensor does the following calculations:(1) uses getting from user to checks if . If they are equal, the procedure goes to next step; otherwise it terminates here.(2) calculates the shared key between and : .(3) sends Message 4 = to user
After receives the message , goes to the following steps. The whole process is in Table 5.(1) uses getting from to check if ; if they are equal, the procedure goes to next step; otherwise it terminates here.(2) calculates the shared key between and : .
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 Table 6, which is a summary of the steps:(1)A user inserts his smart card into a card reader and inputs their identity and password: .(2) computes using password , , and the stored .(3) compares with the stored version of in the smart card; if they are equal, acknowledges the legitimacy of user .(4) computes using the stored values and the user password .(5)User inputs the new password .(6) uses this new to update the stored version of with .
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)  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.
5.2. The Premise and Proof Goals of PriAuth
, , and are used as the user, sensor, and the gateway. Suppose is trustworthy, if believes that has said message and believes that is fresh, would send to . If believes is fresh and believes once said , then believes said . This could be translated into BAN logic like . According to the “~ elimination rule,” could be simplified as . It is the same as the message that sensor sends to . If believes once said another message (the same notion is used for simplification), and believes is fresh, would send to . If believes is fresh and believes once said , then believes said . In the same way, we can get .
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 .
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 Table 9 . At the same time, some assumptions have to be made, so and are included as assumptions A11 and A12. The assumptions are listed in Table 10.