Abstract

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

1. Introduction

As sensors are applied to different aspects of our daily life, too much different personal information has been collected by different kinds of sensors; the personal information includes but is not limited to health information, home temperature, and home humidity. The information is so personal that we do not want them to be leaked when we access them remotely via the network. Many lightweight authentication schemes have been proposed to guarantee the safety of remote data access. Figure 1 depicts the structure of these schemes. There are three kinds of entities, the user who wants to read the data of sensors, sensors which are placed in the environment to collect data, and the gateway, which is introduced to authenticate users and sensors and helps the two to build a shared key. After negotiation of the shared key, the user and sensor can communicate with each other without the help of the gateway.

In this paper, we proposed an authentication and key establishment scheme with user anonymity; this scheme is an improved version of the previous scheme of ours [1] and the LifeWear project [2], which is also based on the ECC. To achieve user anonymity, the identity of the user is encrypted using XOR operation; the key for this encryption is generated by the gateway. When a user registers at the gateway, the gateway generates a random number for the user and a unique key based on this number and the gateway’s own secret key. This number could be seen as an indicator of the key; the key and this number are sent to the user. The user could encrypt his identity with this key.

However, this is not enough to ensure perfect anonymity, because adversaries can track the user based on this unique number, even though the adversary does not know the real identity of this user. To prevent adversaries from tracking the users, in our scheme, once a user has been authenticated by the gateway, the gateway will assign a new number and a new key for this user. Thus, the adversary is unable to track the user based on the number, because the number has been updated to a new one. Many other schemes adopted this way of protecting the identity privacy of the users [310].

Some schemes use an asymmetric encryption method to ensure the anonymity of the authentication scheme. The gateway has a public key that is known by all the members in the scheme; users can use this public key to encrypt their identities; thus, the scheme ensures user anonymity. Our scheme has an advantage compared to the asymmetric encryption method. This is because the asymmetric encryption method requires more computation time compared to our scheme. In our scheme, we encrypt the identity of the user by using the XOR method; the execution time of the XOR operation is minimal compared to an elliptic curve point multiplication [11]. This makes our scheme more suitable for the Internet of things scenario than the asymmetric encryption method.

In the proposed scheme, to enable forward security, the shared key between the user and sensor is generated on an elliptic curve. However, elliptic curve computation needs more computation time compared to the symmetric method; to minimize the computation cost, the proposed scheme only uses four elliptic multiplication operations; as far as we know, this is the least amount needed to build a shared key with perfect forward security. The contribution of this paper is threefold: (1)The proposed scheme uses the XOR operations, hash operations, and only four elliptic multiplications; the computation cost of the scheme is relatively low, and communication cost decreases at the same time.(2)The proposed scheme gains various security features: user anonymity, sensor anonymity, users being untraceable, sensors being untraceable, perfect forward secrecy, excellent resistance to the loss of synchronization problem, and so on. Most importantly, the password change phase has been modified to prevent an offline password-guessing attack.(3)We implement the scheme in HPSL language and test the security features; we analyze the scheme in ProVerif model, too.

Turkanović et al. discussed the user authentication and key agreement problem for a wireless sensor network [12]. They analyzed the identity protection problem in this scenario; they used a fixed fake identity instead of the real identity to protect the identity of the user. Amin and Biswas proposed an improved scheme [13], which improved several security weaknesses of the protocol of Turkanović et al. They protected the identity privacy by encrypting the identity using a symmetric key that is shared by all the users.

Wu et al. proposed a privacy-preserving and provable user authentication scheme for wireless sensor networks [14]. Every time a user asks access to a sensor’s data, the gateway atomically generates a new identity for the user. The identity privacy of the user has been well protected in the scheme, but this scheme faces a loss of synchronization problem. Imagine that the gateway generates a new identity for the user and sends this identity to the user via the Internet but the user does not receive this identity, because either this identity is lost due to poor quality of the network condition or this identity is blocked by an adversary. Thus, when the user logs in the next time using the old identity, he will not be treated as a legal user. Another potential defect of this scheme is that the users in this scheme may be tracked. Even though the adversary does not know the real identity of the user, the adversary can also track the user by the fixed information, which is used by the user.

Different from [9, 10], Li et al. proposed a three-factor authentication scheme [3] with identity updating based on biometric information. Their scheme can successfully avoid the loss of synchronization problem. They did not update the identity of the users directly. Instead, in their scheme, every time the user logs in, the gateway generates a new key for the user and the user uses this new key to encrypt his identity. The adversary is unable to find out the real identity of the user. Li et al. proposed a similar scheme for wearable sensors in wireless body area networks [4]. In the scheme of Jiang et al., the keys to encrypt the identities of users are the same [6]. Schemes in [59] are similar; the key to encrypt the identity is updated when a user logs in. Das proposed a secure and robust temporal credential-based three-factor user authentication scheme for wireless sensor networks [10]. In this scheme, a temporary identity is generated for the user; every time the user asks for access, the temporary identity will be updated to a new one. However, in this case, the gateway has to store a table of the relationships between this temporary identity and the real identity of the user. This costs extra storage load on the server side.

Asymmetric encryption is used in some authentication schemes to protect the identity privacy of the users. The gateway has a public key that is known by all the users in the system; when a user logs in, he can use the gateway’s public key to encrypt his identity. There are asymmetric encryption methods based on the Elliptic Curve Cryptography (ECC) [15], pairing-based cryptography [16] by Tsai and Lo, and the scheme in [17] by Odelu et al. Liu et al. used ECC [18] to protect the identity privacy of the users. All the real identities are encrypted by the public key of the server; only the server knows the real identities of the users. In the scheme of Wang et al. [19], they used the ECC public key encryption method to protect the identity privacy. Pairing-based cryptography is another popular asymmetric encryption method. The scheme of Li et al. [20], the scheme of Tsai and Lo [21], and the scheme of Shim [22] are all based on bilinear pairing-based cryptography.

3. The Proposed Scheme

The symbols used in the scheme are listed in Table 1. At the beginning of the scheme, generates the parameters for ECC encryption (p, a, b, G, n, and h) and publishes them to the whole system. generates its secret key and keeps it as a secret.

3.1. Registration Phase of the User

User chooses a random number and computes . then sends the registration request message to via a private and secure channel.

When receives the user registration message , it computes and . Then, will choose a random number and computes ; these random numbers and are used to encrypt the identity information at the login and authentication phase. Finally, sends to in a private and secure channel.

User inserts the random nonce into the smart card and stores . Table 2 provides a depiction of the registration phase of the user.

3.2. Registration Phase of the Sensor

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

3.3. Login and Authentication Phase

When wants to access a sensor’s data via network remotely, has to log in first. A user inserts his smart card () into a card reader and inputs his identity and password . computes a temporary version using the user inputs and and the stored value . Then computes the information for login. (1) computes and using .(2) chooses a random number ∈[1, n − 1] and gets .(3) gets the hash value .(4) encrypts , , and with to get .(5) retrieves the stored , timestamp , and sends to gateway via a public channel.

When the gateway receives from a user , first checks the freshness of the message by the timestamp, then checks if this message is from a legal user or not. will abandon this message if it is not from a legal user; otherwise, will forward this request to the sensor . The process is depicted in the following: (1) checks the freshness of ; if is not fresh, abandons this message; otherwise, it goes to the next step.(2) computes using the received and its private key .(3) decrypts using and gets .(4) computes by .(5) computes by (6) uses , , , , and to check if . If they are equal, it goes to next step; otherwise, the protocol terminates here.(7) gets timestamp and computes .(8) sends to sensor .

After sensor receives , first checks the legitimacy of this message; if it is from the gateway, then replies to the message in the following way. (1) checks the freshness of the ; if is not fresh, abandons this message; otherwise, it goes to the next step.(2) checks if ; if they are equal, learns that this information is from the gateway, and it goes to the next step; otherwise, the protocol terminates here.(3) chooses a random number and gets .(4) calculates the shared key between and :.(5) calculates the hash value and .(6) sends to .

After receives , first, authenticates the source of the message, then generates the new random number and the new key for the user; afterwards, will send these encrypted information to the user. (1) checks if ; if they are equal, it goes to the next step; otherwise, it terminates here.(2) chooses a random number and computes .(3) calculates .(4) computes .(5) sends to .

After receives , it authenticates if the message is from the gateway; if the message is from the gateway, then updates the information received from the . The whole process is depicted in Table 3. (1)gets .(2)computes the shared key between and : .(3)gets the hashed value and checks if . If they are equal, accepts as the shared key.(4) updates the identity information .

3.4. Password Change Phase

To change a user’s password, the user first sends a password change request to the . After the verifies this user, the user can change his password.

In order to prevent the offline password guess attack, in our scheme, the user is only allowed to change his password times in a time period . We use a variable to record the times a user inputs a wrong password. means the first time a user inputs a wrong password. When a user inputs a wrong password more than times in a time period , he will not be allowed to input a password anymore in this time period. The whole process is depicted in Figure 2: (1)User inserts his into a card reader and inputs his identity and password: , .(2) checks if the ; if , go to step 3. If , go to step 4.(3) continues to check if ; if , user is not allowed to change the password; otherwise, if set , go to step 4.(4) computes using and and the stored . compares with stored in the smart card; if they are equal, acknowledges the legitimacy of . If they are not equal, go to step 11.(5)Check if ? If , set .(6) computes using the stored and the user password.(7) computes using the stored and the user password.(8)User inputs the new password .(9) updates to be .(10) uses this new to update the stored version of and to get and . Now user has finished the password change phase.(11)Set ; if , is set to be , go to the first step.

4. Formal Security Analysis Using ProVerif

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

4.1. Test on the Identity Privacy

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

4.2. Test of the Authentication of the Scheme

In ProVerif, “Injective correspondence” is used to capture the authentication in case of a one-to-one relationship. The event “event acceptUser (bitstring)” is used by the user to record the belief that the user has accepted to run the protocol with the gateway and with the supplied symmetric key. The event “event termUser(bitstring)” means that the user believes he has terminated a protocol run using the data type “bitstring.” The other events have similar meanings. These queries ensure the authentication between the users and the gateway and between the sensors and the gateway (see Box 2).

What is more, we prove the secrecy of the shared key by the queries “Query not attacker (skijs[])” and “Query not attacker(skiju[]).” The result is “true” as shown in the following. The user calculates the shared key between the user and sensor as “skijs;” the sensor calculates the shared key as “skiju” (see Box 3).

5. AVISPA Verification

AVISPA (Automated Validation of Internet Security Protocols and Applications) is “a push-button tool for the automated validation of Internet security-sensitive protocols and applications” [26]. The AVISPA project aims at developing a push-button, industrial-strength technology for the analysis of large-scale Internet security-sensitive protocols and applications. We write the scheme in HLPSL, which is a role-based language designed explicitly for AVISPA. The code is in Appendix B; we have uploaded the code to [25].

In the HLPSL, the confidentiality goals of the protocol are set to be “sc_sensor_id” and “sc_user_id,” which can ensure the confidentiality of the user identity and the sensor identity. The message authentication goal is set to be “shared_key,” which can enable the authentication of the shared key. This goal ensures that the users and sensors build a shared key with the help of the gateway.

The running result of the protocol is shown in Table 4. We run the security check based on the CL-based Model-Checker [27] and the On-the-Fly Model-Checker OFMC [28, 29]. The CL-based Model-Checker (CL-AtSe) translates protocol written as transition relation in the IF into a set of constraints which can be used efficiently to find attacks on protocols. While OFMC can be employed not only for efficient falsification of protocols but also for verification, without bounding the messages, an intruder can generate. Both of the two back-end verification tools show that our scheme is safe.

6. Comparison

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

6.1. Computation Performance

The typical way to compute the execution time of the protocol is to calculate the protocol’s computational costs of different operations; the operations’ execution time is measured by simulation. In this study, the execution time of the XOR operation is minimal compared to an elliptic curve point multiplication or hash operation, and we neglect it when computing the time approximately [11]. In this section, we first compare different schemes using a benchmark from one previously published paper. Then, we simulate the computation time of these schemes in C++; the result is shown in Figure 3.

The benchmark of MIRACL C/C++ Library used in this study can be found at [9]; we list the results in Table 5. Based on this benchmark, the computation costs of different schemes are calculated; the result is in Table 6. At the user side, our scheme only needs 2 ECC multiplications and 5 hash operations. At the sensor side, our scheme costs 2 ECC multiplications and 5 hash operations, and at the gateway side, our scheme costs 8 hash operations. Our scheme costs the least time at the user side and gateway side. And at the sensor side, our scheme costs the second least time. In all, our scheme costs the least computation time.

In the scheme [9], extra AES encryption/decryption is needed. User, sensor, and gateway need 1, 1, and 2 AES encryptions/decryptions separately. Their proposed scheme needs 6, 3, and 9 more hash operations than our scheme at the user side, gateway side, and in total, respectively.

The scheme [11] needs 2, 1, 1, and 4 more hash operations than our scheme at the user side, sensor side, sensor side, gateway side, and in total, respectively. In PriAuth, the asymmetric encryption method is needed to encrypt the identity of the user. The user and gateway in this scheme both need one more ECC multiplication; in total, PriAuth needs two more ECC multiplications than our scheme. The scheme of Wu et al. [14] is the most similar one with the proposed scheme; however, compared to our scheme, their proposed scheme needs 8, 6, and 14 more hash operations than our scheme at the user side, gateway side, and in total, respectively.

We implement these four different schemes in C++; the running codes are stored at a public repository in http://github.com [25]. We use the MIRACL C/C++ Library [30]. The experiment is conducted in Visual Studio C++ 2017 on a 64-bit Windows 7 operating system, 3.5 GHz processor, 8 GB memory. The hash function is SHA-256, the symmetric encryption/decryption function is AES in MR_PCFB1 form, and the 256-bit-long key for symmetric encryption/decryption function is generated by SHA-256 hash operation. We use the Curve P-192 provided by NIST Digital Signature Standard [31]. The parameters are listed in Appendix C.

The code is compiled in x86 form, and the simulation does not take account of the transmission of the data. We run the login and authentication phase of different schemes 100, 250, 500, 750, and 1000 times. The result is shown in Figure 3. In this figure, the horizontal axis indicates the times the experiment is run and the vertical axis indicates the milliseconds to accomplish the experiment. Our scheme is the second-best one, and the computation time of the PriAuth is the longest.

We run the user registration phase of different schemes. The number of users in the registration phase is set to be 100, 250, 500, 750, and 1000. The result is shown in Figure 4. In this figure, the horizontal axis indicates the number of users and the vertical axis indicates the milliseconds needed to accomplish the experiment. Under all experimental conditions, the running time of the PriAuth is the shortest. Our scheme is the second-best scheme, which is about 1.5 times that of the PriAuth. However, this ratio becomes much smaller when the user number increases. Why did this happen? The computation time is mainly composed of two parts: the hash operation time and the checking time. The numbers of hash operation are listed in Table 7. The checking is performed by the gateway to determine if the user has registered before. The gateway keeps a list of registered users’ identity; when the gateway receives a registration request, it has to search the list to check if this user has registered or not. The hash operation time and the checking time are close when the number of the user is smaller. However, the time difference becomes huge with the increasing user numbers.

The running time of the other two schemes is about 2.5 times that of PriAuth. The ratio of hash operations between them is roughly the same as that of the running time. In Table 7, the ratio is computed using the formula , where means the number of hash operations needed by PriAuth. means the number of hash operations needed by the other schemes.

We run the sensor registration phase of different schemes. The number of sensors in the registration phase is set to be 100, 250, 500, 750, and 1000. The result is shown in Figure 5. In this figure, the horizontal axis indicates the number of sensors and the vertical axis indicates the milliseconds needed to accomplish the experiment. The running time of our scheme is close to the running time of Wu et al. [9, 14] and Chang and Le [11]; this is mainly because these three schemes need only 1 hash operation in the sensor registration phase. As PriAuth costs 7 hash operations in the sensor registration phase, the running time is close to 7 times that of the other three schemes. The computation time of the PriAuth is the longest. The running time of Wu et al. [9] is a little more than our scheme (Wu et al. [14] and Chang and Le [11]). This is because at the sensor registration phase, the input of the hash operation of our scheme, of Wu et al.’s scheme [14], and of Chang and Le’s scheme [11] is the sensor’s identity and the gateway’s private key, while the input of the hash operation of Wu et al. [9] is the sensor’s identity, gateway’s private key, and gateway’s identity; the hash operation’s input is longer.

6.2. Communication Performance

In this section, the communication performance is compared. The identity is set to 8 bytes long [32]. The size of the timestamp is set to 4 bytes [33]. Moreover, the byte length of a random number is set to be 20 bytes [9]. The result of SHA-256 is 256 bits, which is 32 bytes. The sizes of a point on the elliptic curve with a 192-bit elliptic curve is 384 bits, which is 48 bytes [9]. The sum of each type of variable length in bytes is calculated for comparison of the communication cost.

Table 8 shows the number of different types of data used in the scheme. It is not hard to find that the communication cost of our scheme is the least. The cost of our scheme, LightPriAuth, is 396 bytes; the costs of Wu et al.’s [9, 14], Chang and Le’s [11] and Chen et al.’s [1] schemes are 564, 624, 412, and 492 bytes, respectively; they are 168, 228, 16, and 96 bytes higher, respectively, than the proposed scheme. The main reason is that LightPriAuth transmits only 5 hash result data. While the other schemes of Wu et al. [9, 14], Chang and Le [11], and Chen et al. [1] have to transmit 10, 13, 9, and 9 hash result data, respectively. They are 5, 8, 4, and 4 more, respectively, than the proposed scheme.

7. Other Security Feature Analyses

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

7.1. User Anonymity/Sensor Anonymity

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

7.2. User Anonymity to Sensor

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

7.3. Loss of Synchronization Problem

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

7.4. Offline Dictionary Attack

For most of the schemes, an adversary is unable to launch an offline dictionary attack in the login and authentication phase. However, an adversary is able to launch an offline dictionary attack in the password-changing phase.

In the password change phase of [19], if the adversary types in a random identity and a random password , he will get a reply from the . Based on the replied message, the adversary can judge if the identity and password are correct or not. If the adversary guesses a correct key pair by accident, then he could set a new password. Thus, the adversary is able to launch an offline dictionary attack.

In the proposed scheme, we set a limitation on the user, if the user inputs a wrong identity and password pair more than times in a time period , he is not allowed to log in in this period of time. Thus, our scheme can avoid the offline dictionary attack in the password change phase.

7.5. Security Feature Comparison

Finally, we get in Table 9 the comparison of security features; we can find that compared to other schemes, the proposed scheme has more security features. Besides, the computation cost and the communication cost of the proposed scheme are lower.

8. Conclusions

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

Appendix

A. Appendix

Algorithm 1 describes the role of the user.

( Role of the user)
let processUser(idi: bitstring, sidj: bitstring, pwi: bitstring) =
 ( registration phase of the user )
  new ri:bitstring;
 let mpi = hash(con(ri,con(idi,pwi))) in
 out(scUser,(idi,mpi));
 in(scUser,(fi:bitstring,li:bitstring,ki:bitstring));
 let (ei:bitstring) = xor(li, mpi) in
  let (di:bitstring) = xor(fi, mpi) in
  ( Real start of the role )
   ( Message 1)
   new k1:exponent;
   let A = exp(g,k1) in
   new T1:bitstring;
   let m2 = hash(con(g2 h(A),con(idi,(con(sidj,con(di,T1)))))) in
   let m1 = xor(ei,con(idi,con(sidj,m2))) in
   out(cug, (A, ki, m1, T1));
   ( Message 4 )
   in(cug, (B:G, M6:bitstring));
   let (tem:bitstring) = xor(M6, ei) in
   let (einew’:bitstring, tem1: bitstring) = Split(tem) in
   let (k3’:bitstring, m7’:bitstring) = Split(tem1) in
   let skiju = hash(g2h(exp (B, k1))) in
   let m4’ = hash(con(g2h(B),con(skiju,g2h(A)))) in
   if (m7’) = hash(con(einew’,con(k3’,con(di,con(T1,m4’))))) then
       event acceptUser(di);
    let li = xor(mpi,einew’) in
    let ki = k3’ in
       event termUser(di).

Algorithm 2 describes the role of the sensor.

( Role of the Sensor)
let processSensor(sidj: bitstring) =
  ( registration phase of the sensor )
  out(scSensor,sidj);
 in (scSensor,xj: bitstring);
  ( Real start of the role )
 ( Message 2)
 in(csg,(A:G,m3:bitstring,T2:bitstring));
 ( Message 3)
 if (m3) = hash(con(g2h(A),con(sidj,con(xj,T2)))) then
  event acceptSensor(xj);
 new k2:exponent;
 let B = exp (g, k2) in
 let skijs = hash(g2h(exp (A, k2))) in
 let m4 = hash(con(g2h(B),con(skijs,g2h(A)))) in
 let m5 = hash(con(xj,con(m3,con(m4,g2h(B))))) in
 out(csg,(B,m4,m5));
  event termSensor(xj).

Algorithm 3 describes the role of the gateway.

(gateway )
let processGateway(xgwn: bitstring) =
 ( Message 2)
 in(cug,(A:G, ki:bitstring, M1:bitstring, T1:bitstring));
 let ei’ = hash(con(ki,xgwn)) in
 let (tem:bitstring) = xor(M1, ei’) in
 let (idi’:bitstring, tem1: bitstring) = Split(tem) in
 let di’= hash(con(idi’,xgwn)) in
 let (sidj’: bitstring, m2’: bitstring) = Split(tem1) in
 if (m2’) = hash(con(g2h(A),con(sidj’,hash(con(idi’,xgwn))))) then
  event acceptUserbyGateway(di’);
 new T2: bitstring;
 let xj’=hash(con(sidj’,xgwn)) in
 let m3 = hash(con(g2h(A),con(sidj’,con(xj’,T2)))) in
 out(csg,(A,m3,T2));
 ( Message 4)
 in(csg,(B:G, m4:bitstring, m5:bitstring));
 if (m5) = hash(con(xj’,con(m3,con(m4,g2h(B))))) then
 new k3:bitstring;
 let einew = hash(con(k3,xgwn)) in
 let m7 = hash(con(einew,con(k3,con(di’,con(T1,m4))))) in
  event acceptSensorbyGateway(xj’);
  event termGatewaywithSensor(xj’);
 let m6 = xor(con(einew,con(k3,m7)),ei’) in
 out(cug,(B,m6));
  event termGatewaywithUser(di’).
( User registration )
let processUserRegistration(xgwn: bitstring) =
   in(scUser, (idi: bitstring, mpi:bitstring));
 let di = hash(con(idi,xgwn)) in
 let fi = xor(di,mpi) in
 new ki:bitstring;
  let ei= hash(con(idi,xgwn)) in
  let li= xor(ei,mpi) in
 out(scUser,(fi,li,ki)).
( Sensor registration )
let processSensorRegistration(xgwn: bitstring) =
 in(scSensor, sidj:bitstring);
 let xj = hash(con(sidj,xgwn)) in
 out(scSensor,xj).

B. Appendix

Note that we write our scheme in HLPSL from the authentication phase; supposing that the users and sensors have registered at the gateway secretly, and successfully get the registered information, the role of the user is described in Algorithm 4.

role user (Ui, Sj, GW: agent,
    Kdi,Kei: symmetric_key,
    H: hash_func
    P: text,
    SND_US,RCV_US: channel (dy))
played_by Ui
def=
 local State: nat,
 T1,K1,A,M1,M2,Ki,B,K3,K2,IDi,SIDj,M4,M6,M7,SK,Keinew: text
 const shared_key,sc_user_id,sc_sensor_id:protocol_id
 init State:= 0
 transition
   1. State = 0   RCV_US(start)=|>
   State’: = 2   ⋀ T1’:= new()
         ⋀ K1’:= new()
         ⋀ A’:= exp(P,K1’)
         ⋀ M2’:= H(A’.IDi.SIDj.Kdi.T1’)
         ⋀ M1’:= xor(Kei,(IDi.SIDj. H(A’.IDi.SIDj.Kdi.T1’)))
         ⋀ SND_UG(A’.M1’.Ki.T1’)
   2. State = 7  ⋀ RCV_UG(B
              .xor((Keinew’.K3’.H(Kei.K3’.Kdi.T1.M4’)),Kei)
              )=|>
   State’:= 8  ⋀ Kei’:= Keinew’
         ⋀ Ki’:= K3’
         ⋀ SK’:= H(exp(B,K1))
         ⋀ witness(Ui,Sj,user_sensor_sk,SK’)
         ⋀ request(Ui,Sj,user_sensor_sk,SK’)
  end role

The role of the sensor is described in Algorithm 5.

role sensor (Ui, Sj, GW: agent,
     Kxj: symmetric_key,
     H: hash_func,
     P: text,
     SND_SG,RCV_SG: channel(dy))
played_by Sj
def=
 local State: nat,
 T2,K2,A,B,SK,M3,M4,M5,SIDj :text
 const shared_key:protocol_id
 init State:= 4
 transition
  1. State = 4  ⋀ RCV_SG(A’
              .H(A’.SIDj’.Kxj.T2’)
              .T2’
              )=|>
   State’:= 3   ⋀ K2’:= new()
           ⋀ B:= exp(P,K2’)
           ⋀ SK’:= H(exp(A’,K2))
           ⋀ M4’:= H(B.SK.A’)
           ⋀ M5’:= H(Kxj.H(A’.SIDj’.Kxj.T2’).M4’.B)
           ⋀ SND_SG(B.M4’.M5’)
           ⋀ witness(Ui,Sj,shared_key,SK’)
           ⋀ request(Ui,Sj,shared_key,SK’)
 end role

The role of the gateway is described in Algorithm 6.

role gateway (Ui, Sj, GW: agent,
      Kdi,Kei, Kxj, Xgwn: symmetric_key,
      H: hash_func,
      SND_UG,RCV_UG,SND_SG,RCV_SG: channel(dy))
played_by GW
def=
 local State: nat,
 T1,T2,A,B,IDi,SIDj,M2,M3,M4,M6,M7,Ki,Keinew,K3: text
 const sc_user_id,sc_sensor_id:protocol_id
 init State: = 2
 transition
 1. State = 2  ⋀ RCV_UG(A’.
            xor(H(Ki’.Xgwn),(IDi’.SIDj’.H(A’.IDi’.SIDj’.Kdi.T1’))).
            Ki’.
            T1’
            )=|>
 State’:= 3  ⋀ T2’: = new()
         ⋀ M3’:= H(A’.SIDj’.Kxj.T2’)
         ⋀ SND_SG(A’.M3’.T2’)
         ⋀ secret(IDi,sc_user_id,{Ui,GW})
         ⋀ secret(SIDj,sc_sensor_id,{Ui,GW})
 2. State = 5  ⋀ RCV_SG(B
             .M4’
             .H(Kxj.M3.M4’.B)
             )=|>
 State’:=6  ⋀ K3’:= new()
             ⋀ Keinew’:= H(K3’.Xgwn)
             ⋀ M7’:= H(Kei.K3’.Kdi.T1.M4’)
             ⋀ M6’:= xor((Keinew’.K3’.M7’),Kei)
             ⋀ SND_UG(B.M6’)
end role

The role of the session is described in Algorithm 7.

role session(Ui, Sj, GW: agent,
     Kdi,Kei, Kxj,Xgwn: symmetric_key,
     H: hash_func,
     P: text
     )
def=
 local  SSG,RSG,
     SUG,RUG:channel(dy)
 composition
  user(Ui,Sj,GW, Kdi,Kei,     H,P, SUG,RUG)
⋀ sensor(Ui,Sj,GW, Kxj,       H,P, SSG,RSG)
⋀ gateway(Ui,Sj,GW, Kdi,Kei,Kxj,Xgwn, H, SUG,RUG,SSG,RSG)
end role

The role of the environment is described in Algorithm 8.

role environment()
def=
 const ui, sj, gw: agent,
   kdi,kei, kxj,xgwn, kig,keig: symmetric_key,
   shared_key, sc_user_id,
   sk_sensor_gwn, sc_sensor_id: protocol_id,
   h,expp: hash_func,
   p: text
intruder_knowledge={ui, sj, gw, kig, h, p}
composition
   session(ui,sj,gw, kdi,kei,kxj,xgwn, h,p)
  ⋀ session(ui, i,gw, kdi,kei,kig,xgwn, h,p)
  ⋀ session( i,sj,gw, kig,keig,kxj,xgwn, h,p)
end role

The role of the goal is divided into two parts. The first part is the “secrecy_of sc_sensor_id” and “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 (Algorithm 9).

% Confidentiality (G12)
 secrecy_of sc_sensor_id,sc_user_id
% Message authentication (G2)
 authentication_on shared_key

C. Appendix

The parameters of the Curve P-192 by NIST is described in Algorithm 10.

A = -3
B = 64210519E59C80E70FA7E9AB72243049FEB8DEECC146B9B1
P = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFFFFFFFFFFFF
= 188DA80EB03090F67CBF20EB43A18800F4FF0AFD82FF1012
= 07192B95FFC8DA78631011ED6B24CDD573F977A11E794811

Data Availability

The experimental data used to support the findings of this study are included within the article.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

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.