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.
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: 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 [13]. 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 [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 new for the user [4]. 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 [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: , , , 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 [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–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.
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:
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) [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.
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.
5.4. 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.
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.
7. 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.
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 to a sensor, an inner side legitimate sensor can intercept this message to generate its own 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 to the sensor. Afterwards, the sensor will be able to send 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 , so there is a potential risk. The message a gateway sends to the user is , where , in which and are public message, and is shared by all the legitimate users. This means any legitimate user could decrypt to get the shared key .
7.5. User Impersonation Attack
In scheme [1], when a user asks to access a sensor’s data, he could send his request to the sensor.
, , , and 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 , could easily generate a request the same as , and then will be treated as 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. is the time for HMAC with SHA-1 operation, according to [9] . The final result is in Table 14.
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.
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.
Appendix
A. The Proof of PriAuth Using BAN Logic
The proof starts at Message 2. From Message 2 onwards, we can prove that believes once said and believes once said .(1)According to Message 2, we get(2)According to (A.1) and “‘,’-elimination rule”(3)According to (A.2), A6, and “~ introduction rule”(4)According to (A.3), A10, and “~ introduction rule”(5)According to (A.4) and “‘,’-elimination rule”(6)According to (A.5) and “‘,’-elimination rule”(7)According to A1, (A.6), and “~ elimination rule”(8)According to A2, (A.7), and “~ elimination rule”
The following content is the analysis of Message 3. From it, we can prove that believes believes . Based on assumption A11, we can get that believes believes ; this process is shown at (A.10)~(A.17). Equations (A.18)~(A.20) prove the first goal of the scheme.(9)Based on Message 3,(10)According to (A.10) and “‘,’-elimination rule”(11)According to (A.11), A9, and “~ introduction rule”(12)According to (A.12) and “‘,’-elimination rule”(13)According to A3, (A.13), and “~ elimination rule”(14)According to A11, (A.8), (A.14), we get(15)According to A3, (A.15), and “~ elimination rule”(16)According to A13, (A.16), and “jurisdiction or control rule”(17)As is randomly created by , according to “#()-introduction”(18)According to (A.18), A3, A5, and “#-promotion rule”(19)According to (A.19), (A.17), and “ introduction rule”
The following is the analysis of Message 4, where it is proven that believes and believes , based on assumption A12, so we can infer that believes believes ; this procedure is shown at (A.21)~(A.28). Equations (A.29)~(A.31) prove the first goal of the scheme. Until now, the two goals of the scheme have been proved at (A.20) and (A.31), so it can be claimed that this protocol is feasible and safe.(20)Based on Message 4,(21)According to (A.21) and “‘,’-elimination rule”(22)According to (A.22), A7, and “~ introduction rule”(23)According to (A.23) and “‘,’-elimination rule”(24)According to A4, (A.23), and “~ elimination rule”(25)According to A12, (A.9), and (A.25), we get(26)According to A4, (A.26), and “~ elimination rule”(27)According to A14, (A.27), and “jurisdiction or control rule”(28)As is randomly created by , according to “#()-introduction”(29)According to (A.29), A4, A6, and “#()-promotion rule”(30)According to (A.30), (A.27), and “ introduction rule”
B. The HLPSL Code for PriAuth
The ECC public-key pair of the gateway is . At the beginning of this protocol usage, every user generates a random number and calculates , so we could treat , as the ECC key pair of this user, and we send to the gateway. Now the two parties could calculate a shared key . Thus, at the beginning of the scheme, we declare to be a symmetric key between the two.
For the role of the user, see Box 1. For the role of the sensor, see Box 2. For the role of the gateway, see Box 3. For the role of the session, see Box 4. For the role of the environment, see Box 5.
The role of the goal is divided into two parts. The first part is the “secrecy_of sc_sensor_id,sc_user_id”; this means we want to keep the identity of the user and sensor confidential between them and the gateway. The second part “authentication_on user_sensor_sk” means the authentication of the shared key between a user and a sensor (see Box 6).
Conflicts of Interest
The authors declare no conflicts of interest.
Authors’ Contributions
All the authors have contributed equally to this work.
Acknowledgments
The work presented in this paper has been supported by the LifeWear Project (funded by the Spanish Ministry of Industry, Energy and Tourism with Reference TSI-010400-2010-100). The work has also been supported by the Chinese Scholarship Council (CSC) with File no. 201507040027.