Cloud-Based RFID Mutual Authentication Protocol without Leaking Location Privacy to the Cloud

Abstract

With the rapid developments of the IoT (Internet of Things) and the cloud computing, cloud-based RFID systems attract more attention. Users can reduce their cost of deploying and maintaining the RFID system by purchasing cloud services. However, the security threats of cloud-based RFID systems are more serious than those of traditional RFID systems. In cloud-based RFID systems, the connection between the reader and the cloud database is not secure and cloud service provider is not trusted. Therefore, the users have to encrypt their data stored in the cloud database to prevent the leakage of privacy. In addition, the reader's location privacy should be protected to avoid its leak to the cloud provider. In this paper, a cloud-based RFID mutual authentication protocol without leaking location privacy to the cloud is proposed. It provides real-time mutual authentication between the reader and the tag and protects the reader's location privacy by introducing the location privacy cloud. Compared with traditional backend-server-based schemes and serverless schemes, the proposed scheme has obvious advantages in deployment cost, scalability, real-time authentication, and the tag's computational complexity.

1. Introduction

RFID (radio frequency identification) is a key technology of the IoT for identifying the objects in a noncontact way. It is widely used in the fields of manufacture, retail, medical treatment, transportation, tracking, and location because the RFID tag is low in price, small in size, and easy to take. Besides, massive tags can be read simultaneously compared with bar codes. However, once the object is labeled a tag, the data privacy and the owner's location privacy would be threatened. So the owner's location privacy and security protection are the prerequisites for popularizing the RFID technology.

The traditional RFID system is composed of tags, readers, and a backend database, as seen in Figure 1. The reader activates the tag by sending the RF signals to communicate and exchange information with it in a noncontact way and submits the relevant data to the backend database. There are a lot of authentication schemes under this architecture [1–3]. These authentication schemes always assume that there is a secure backend server and the link between the reader and the backend server is reliable. For instance, Wei et al. [1] proposed a mutual authentication protocol based on hash function and Dong et al. [2] proposed a mutual authentication protocol based on SHA-3. In their schemes, the backend server needs to search the matching records by computing hash function; the computing ability of the backend server will be the bottleneck of the system. He et al. [3] proposed an ECC based authentication scheme in which the tag needs to compute scalar multiplication over the elliptic curve, so it does not satisfy the requirements of the lightweight tag. What is worse is that the backend-server-based architecture limits the mobility of the reader and the cost of deploying and maintaining the backend server is high.

Figure 1

The architecture of the backend-server-based schemes.

The serverless architecture consists of three kinds of entities: readers, tags, and a Certificate Authority (CA). Readers authenticate tags via the help of online CA, as seen in Figure 2. Each tag registers in the CA and each authorized reader downloads the Access List (AL) from the CA through a secure channel during the initialization process. For example, Lee et al. [4] proposed a serverless RFID authentication and search protocol. Hoque et al. [5] proposed enhancing privacy and security of RFID system with serverless authentication and search protocols in pervasive environments. Tan et al. [6] proposed a secure and serverless RFID authentication and search protocol. In the serverless system, the reader is able to move, but it only provides offline authentication and the computing ability of the reader is limited. What is worse is that if the reader is stolen, the AL stored in it could be used to forge tags.

Figure 2

The architecture of the serverless schemes.

With the development of the IoT, massive objects need to be identified by using RFID technology, thus forming big data of RFID applications. In the backend-server-based RFID systems, the computing ability of the backend server will be a bottleneck of the whole system when it receives massive authentication requests simultaneously. In the serverless RFID schemes, all the operations are conducted by the reader; the computing ability and storage capacity are more limited than those of the server-based RFID systems.

With the rapid development of cloud computing, cloud-based RFID systems attract more attention. There are several schemes which addressed the cloud-based RFID system [7–11]. Dabas and Gupta [7] proposed an architecture framework for the existing RFID systems melded with the cloud computing paradigm. Yuan and Li [8] built a cube model of RFID middleware data processing based on cloud computing. Chattopadhyay et al. [9] proposed a web based RFID asset management solution established on cloud services. Chu and Wu [10] designed a hybrid building fire evacuation system (HBFES) on a mobile phone using RFID techniques and cloud computing. However, most of them are focused on their functionalities rather than the security. Actually the security threats of cloud-based RFID systems are more serious than those of traditional RFID systems. In cloud-based RFID systems, the connection between the reader and the cloud database is not secure and cloud service provider is not trusted. To solve these problems, Xie et al. [12] proposed a cloud-based RFID authentication protocol in 2013. Abughazalah et al. [13] proposed a secure improved cloud-based RFID authentication protocol. Lin et al. [14] proposed a cloud-based authentication protocol for RFID supply chain systems. In all the above schemes, the computational complexity of the tag is high and they do not protect the reader's location privacy.

In this paper, a lightweight cloud-based RFID mutual authentication protocol without leaking location privacy to the cloud is proposed. A global encrypted hash table (EHT) corresponding to the encrypted RFID tags' information is stored in the cloud database. It provides real-time mutual authentication between the reader and the tag and protects the reader's location privacy by introducing the location privacy cloud which is not able to read the RFID data. Compared with traditional backend-server-based schemes and serverless schemes, the proposed scheme has obvious advantages in deployment cost, scalability, real-time authentication, and the tag's computational complexity.

The rest of the paper is organized as follows. Section 2 reviews the cloud-based RFID authentication schemes. The proposed authentication framework is given in Section 3. In Section 4, the proposed cloud-based RFID mutual authentication protocol is given. In Section 5, the security and the performance of the proposed protocol are analyzed. Section 6 concludes the paper.

2. Related Work

In this section, we will briefly review the cloud-based RFID authentication schemes and point out some disadvantages of them. Usually, the cloud-based RFID system is composed of a cloud server (cloud database), readers, and tags, where the reader is able to move and the RFID data is stored in the cloud database. There are several cloud-based RFID systems.

Xie et al. [12] proposed a cloud-based RFID authentication protocol. They used a Virtual Private Network (VPN) agency to guarantee the reliable connection between the reader and the cloud database. However, the cost of deploying and maintaining the VPN agency is high and this architecture is not suitable for SMEs (Small and Medium Enterprises). If the VPN agency is not maintained by the user, it is likely to expose the business information of the enterprise to the VPN agency. The protocol works as follows:

• (i)

The tag sends $H(R\parallel T\parallel S)$ and a request to the reader.

(ii)

The reader reads the cipher text $E(R\parallel T\parallel S)$ indexed by $H(R\parallel T\parallel S)$ from the cloud, decrypts it, and gets T and S. Then the reader generates a random number $Nr$ as a challenge to the tag.

(iii)

The tag calculates $H(R\parallel T\parallel Nr)$ as a response and a random nonce $Nt$ as its challenge to the reader.

(iv)

The reader verifies $H(R\parallel T\parallel Nr)$ , sends queries to the cloud, and checks answers, until finding the last valid record, assuming its SID is M. Then the reader computes $H(R\parallel T\parallel M^{\prime })$ and $E(R\parallel T\parallel M^{\prime })$ to notify the cloud to begin the update, where $M^{\prime }=M+1$ .

(v)

The cloud adds the new record into the EHT, computes $H(R\parallel T\parallel M^{\prime })\oplus H(E(R\parallel T\parallel M^{\prime }))$ , and sends it to the reader.

(vi)

The reader confirms the updating is successful and computes $H(R\parallel T\parallel Nt)\oplus M^{\prime }$ and $H(T\parallel R\parallel M^{\prime })$ to notify the tag to begin the update.

(vii)

The tag calculates $H\left(R\parallel T\parallel Nt\right)$ XOR with the received $H\left(R\parallel T\parallel Nt\right)\oplus M^{\prime }$ to obtain $M^{\prime }$ , and then it calculates and verifies $H(T\parallel R\parallel M^{\prime })$ .

The weakness of Wei's cloud-based RFID authentication protocol was pointed out by Abughazalah et al. [13]. The authors find that Wei's authentication protocol suffers from reader impersonate attack and tag's location tracking attack. And the authors proposed a secure improved cloud-based RFID authentication protocol. They assume that the communication channel between the reader and the cloud server is secure, but this assumption is not suitable for the mobile readers.

Lin et al. [14] proposed a cloud-based authentication protocol for RFID supply chain systems. In their scheme, the system is composed of tags, readers, a cloud server, and a trust party. The authentication protocol cannot resist old key compromise attack. Its key update used a simple XOR operation, ${\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}}=\mathrm{K}\mathrm{e}\mathrm{y}\oplus h(r_T)$ , where $h\left(\right)$ is a hash function and $r_T$ is a random number. When the adversaries obtained the old key, they can impersonate and track the key update. Therefore, this scheme does not achieve the forward security.

Furthermore, all the above schemes do not protect the reader's location privacy; the leakage of the reader's location privacy will expose the business information of the company.

3. Our Authentication Framework

In this section, we describe our authentication framework. It provides the location privacy protection for the reader to access the cloud database.

3.1. System Components

The framework is illustrated in Figure 3.

Figure 3

The authentication framework.

Tag. The tag is used to label the object. Its identity, ${\mathrm{i}\mathrm{d}}_T$ , and secret key, Key, are stored in the tag, and it is able to generate random numbers and conduct the bitwise XOR and hash operation.

Reader. The reader can move freely. In the reader, its identity $\mathrm{i}{\mathrm{d}}_R$ and the key $kRC$ shared by the reader and the cloud server are stored. The reader is able to generate random numbers and conduct the bitwise XOR, hash operation, and symmetric encryption and decryption.

Location Privacy Cloud. Location privacy cloud is an infrastructure of IoT. It is maintained by a trusted third party or an organization that provides privacy service like the public platform of IoT. It is composed of several public access points; one of them is called edge access point which connects to the cloud database directly, and the others are called general access points. The edge access point needs to support random numbers generation and symmetric encryption and decryption.

Cloud Server. The cloud server needs to provide service on demand. It stores the new EHT pairs and the old EHT pairs in the cloud database. The cloud server needs to support query and update of the RFID tag records and have the ability to calculate message authentication code (MAC).

3.2. The Location Privacy Mechanism of the Reader to the Cloud Database

In the following, we suppose the user $U_A$ is a small company and $U_A$ manages the sales of goods using RFID technology. In order to save maintenance costs, $U_A$ purchases cloud database service from the cloud service provider and applies for accessing the cloud database via the location privacy cloud in which there are some general access points that provide public access services for RFID readers. Generally, a company has one or more mobile readers to identify their tags with the help of the cloud database.

The mobile reader belongs to the user and its IP address is denoted by $\mathrm{I}{\mathrm{P}}_R$ . When the user purchases cloud database service, the cloud server shares a key $kRC$ with the reader. And the reader needs to store the IP address $\mathrm{I}{\mathrm{P}}_{\mathrm{C}\mathrm{l}\mathrm{o}\mathrm{u}\mathrm{d}A}$ of the cloud server. The cloud database which provides cloud service for the user $U_A$ is called CloudA, and the IP address is $\mathrm{I}{\mathrm{P}}_{\mathrm{C}\mathrm{l}\mathrm{o}\mathrm{u}\mathrm{d}A}$ .

In order to protect the location privacy of the reader, we design the following message transmission mechanism between the reader and the cloud database.

3.2.1. The Reader Sends Message $m_1$ to the Cloud Server

As shown in Figure 3, assume that the reader registers to the general access point AP₁ (its corresponding IP Address is IP₁); it will send the message $m_1$ to the cloud server by IP packets, where each IP packet is like the structure shown in Figure 4.

Figure 4

IP packet.

Under this structure, the reader's packet can be denoted by ${\mathrm{I}\mathrm{P}}_R\parallel \mathrm{I}{\mathrm{P}}_{\mathrm{C}\mathrm{l}\mathrm{o}\mathrm{u}\mathrm{d}A}\parallel \cdots \parallel m_1$ . When AP₁ receives the packet, it adds its IP address IP₁ to the loose source route field of the packets, namely, ${\mathrm{I}\mathrm{P}}_R\parallel \mathrm{I}{\mathrm{P}}_{\mathrm{C}\mathrm{l}\mathrm{o}\mathrm{u}\mathrm{d}A}\parallel {\mathrm{I}\mathrm{P}}_1\parallel \cdots \parallel m_1$ , and then AP₁ sends the packets to the cloud server by other general access points. When the packet routes to the edge access point AP₂, AP₂ adds its IP address IP₂ to the loose source route field of the packets, namely, ${\mathrm{I}\mathrm{P}}_R\parallel \mathrm{I}{\mathrm{P}}_{\mathrm{C}\mathrm{l}\mathrm{o}\mathrm{u}\mathrm{d}A}\parallel {\mathrm{I}\mathrm{P}}_{\mathrm{1}}\parallel {\mathrm{I}\mathrm{P}}_{\mathrm{2}}\parallel \cdots \parallel m_1$ . Then AP₂ generates a random number r and encrypts ${\mathrm{I}\mathrm{P}}_R$ and IP₁, respectively. Hence, the packet is $E\left(r\parallel {\mathrm{I}\mathrm{P}}_R\right)\parallel \mathrm{I}{\mathrm{P}}_{\mathrm{C}\mathrm{l}\mathrm{o}\mathrm{u}\mathrm{d}A}\parallel E\left(r\parallel {\mathrm{I}\mathrm{P}}_1\right)\parallel {\mathrm{I}\mathrm{P}}_2\parallel \cdots \parallel m_1$ . If the reader registers to the edge access point AP₂ directly, in order to protect the location privacy, AP₂ will construct the packets like $E\left(r\parallel {\mathrm{I}\mathrm{P}}_R\right)\parallel \mathrm{I}{\mathrm{P}}_{\mathrm{C}\mathrm{l}\mathrm{o}\mathrm{u}\mathrm{d}A}\parallel E\left(r\parallel {\mathrm{I}\mathrm{P}}_2\right)\parallel {\mathrm{I}\mathrm{P}}_2\parallel \cdots \parallel m_1$ . Finally, AP₂ sends packets to the CloudA.

3.2.2. The Cloud Server Sends Message $m_2$ to the Reader

Firstly, the cloud server sends the response packet $\mathrm{I}{\mathrm{P}}_{\mathrm{C}\mathrm{l}\mathrm{o}\mathrm{u}\mathrm{d}A}\parallel E\left(r\parallel {\mathrm{I}\mathrm{P}}_R\right)\parallel {\mathrm{I}\mathrm{P}}_{\mathrm{2}}\parallel E\left(r\parallel {\mathrm{I}\mathrm{P}}_1\right)\parallel \cdots \parallel m_2$ to AP₂, where $E\left(r\parallel {\mathrm{I}\mathrm{P}}_1\right)$ may be $E\left(r\parallel {\mathrm{I}\mathrm{P}}_2\right)$ if the reader registers to the edge access point AP₂ directly. AP₂ retrieves the loose source route field and destination ${\mathrm{I}\mathrm{P}}_R$ by decrypting $E\left(r\parallel {\mathrm{I}\mathrm{P}}_1\right)$ , $E\left(r\parallel {\mathrm{I}\mathrm{P}}_R\right)$ and then sends the packet to the mobile reader through the registered general access point AP₁.

Through the above process, the location privacy of the mobile reader is protected because the cloud server cannot obtain the information which the routing packet comes from. So it provides the location privacy protection transmission for the reader to access the cloud database.

4. The Proposed Cloud-Based RFID Mutual Authentication Protocol

The location privacy mechanism provides a privacy channel for the mobile reader to the cloud server. We propose an RFID mutual authentication protocol based on the above channel.

4.1. Notations

The notations are listed in the Notations.

4.2. Initial Phase

The tag stores its identity, $\mathrm{i}{\mathrm{d}}_T$ , and secret key, Key, and calculates $H(\mathrm{K}\mathrm{e}\mathrm{y}\parallel \mathrm{i}{\mathrm{d}}_T)$ . The cloud database stores the EHT $\{H_{\mathrm{o}\mathrm{l}\mathrm{d}}(\mathrm{i}{\mathrm{d}}_T\parallel \mathrm{K}\mathrm{e}\mathrm{y}),E_{\mathrm{o}\mathrm{l}\mathrm{d}}(\mathrm{i}{\mathrm{d}}_T\parallel \mathrm{K}\mathrm{e}\mathrm{y})\}$ , $\{H_{\mathrm{n}\mathrm{e}\mathrm{w}}(\mathrm{i}{\mathrm{d}}_T\parallel \mathrm{K}\mathrm{e}\mathrm{y}),E_{\mathrm{n}\mathrm{e}\mathrm{w}}(\mathrm{i}{\mathrm{d}}_T\parallel \mathrm{K}\mathrm{e}\mathrm{y})\}$ in the cloud database. And the old record and the new record are set to the same value. The reader shares the key $kRC$ with the cloud server.

4.3. The Authentication Phase

The proposed RFID mutual authentication is illustrated in Figure 5. The authentication process is as follows.

Figure 5

The proposed RFID mutual authentication.

(1) R→T: $\mathrm{R}\mathrm{e}\mathrm{q}\mathrm{u}\mathrm{e}\mathrm{s}\mathrm{t}\parallel r_1$ .

The mobile reader generates a random number $r_1$ and sends $\mathrm{R}\mathrm{e}\mathrm{q}\mathrm{u}\mathrm{e}\mathrm{s}\mathrm{t}\parallel r_1$ to the tag.

(2) T→R: $r_2\parallel H^{\prime }(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)\parallel M_1$ .

The tag generates a random number $r_2$ , calculates $H^{\prime }(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)$ and $M_1=H(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T\parallel r_1)$ , and sends $r_2\parallel H^{\prime }(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)\parallel M_1$ to the reader.

(3) R→C: $U_A\parallel {\mathrm{i}\mathrm{d}}_R\parallel H^{\prime }(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)\parallel {\mathrm{M}\mathrm{A}\mathrm{C}}_{kRC}$ .

The reader stores $M_1$ and sends $U_A\parallel {\mathrm{i}\mathrm{d}}_R\parallel H^{\prime }\left(\mathrm{K}\mathrm{e}\mathrm{y}\parallel \mathrm{i}{\mathrm{d}}_T\right)\parallel {\mathrm{M}\mathrm{A}\mathrm{C}}_{kRC}$ to the cloud server.

$U_A$ denotes the identity of the user with which the cloud server only needs to search for the data belonging to the user, which is able to improve the efficiency of the searching operation. $\mathrm{M}\mathrm{A}{\mathrm{C}}_{kRC}$ denotes the message authentication code with the shared key $kRC$ .

(4) C→R: $E_k(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)\parallel {\mathrm{M}\mathrm{A}\mathrm{C}}_{kRC}$ .

If ${\mathrm{M}\mathrm{A}\mathrm{C}}_{kRC}$ is authenticated by the cloud with $kRC$ , the cloud server extracts $H^{\prime }(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)$ and searches the record stored in the cloud database. The results include three possible cases as follows.

Case 1. There is no matching record; the authentication is failed.

Case 2. If $H(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)$ equals $H^{\prime }(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)$ , it indicates that both the cloud server and the tag carried out the update normally last time. Then the cloud server sends $E_k(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)\parallel {\mathrm{M}\mathrm{A}\mathrm{C}}_{kRC}$ to the reader.

Case 3. If $H({\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{o}\mathrm{l}\mathrm{d}}\parallel {\mathrm{i}\mathrm{d}}_T)$ equals $H^{\prime }(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)$ , it indicates that the cloud server carried out the update normally, while the tag did not renew its key last time. Then the cloud server sends $E_k({\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{o}\mathrm{l}\mathrm{d}}\parallel {\mathrm{i}\mathrm{d}}_T)\parallel {\mathrm{M}\mathrm{A}\mathrm{C}}_{kRC}$ to the reader.

(5) R→C: $H({\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}}\parallel {\mathrm{i}\mathrm{d}}_T)\parallel E_k({\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}}\parallel {\mathrm{i}\mathrm{d}}_T)\parallel H(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)\parallel E_k(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)\parallel {\mathrm{M}\mathrm{A}\mathrm{C}}_{kRC}$ .

The reader decrypts $E_k(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)$ to get Key and ${\mathrm{i}\mathrm{d}}_T$ , and it checks whether $H(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T\parallel r_1)$ equals $M_1$ . If it succeeds, the tag is authenticated by the reader. Then it calculates ${\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}}=H(\mathrm{K}\mathrm{e}\mathrm{y}\parallel r_1\parallel r_2)$ , $H({\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}}\parallel {\mathrm{i}\mathrm{d}}_T)$ , and $E_k({\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}}\parallel {\mathrm{i}\mathrm{d}}_T)$ . And it sends $H({\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}}\parallel {\mathrm{i}\mathrm{d}}_T)\parallel E_k({\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}}\parallel {\mathrm{i}\mathrm{d}}_T)\parallel H(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)\parallel E_k(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)\parallel {\mathrm{M}\mathrm{A}\mathrm{C}}_{kRC}$ to the cloud server.

(6) C→R: ACK message.

The cloud server checks ${\mathrm{M}\mathrm{A}\mathrm{C}}_{kRC}$ and updates the corresponding records. Then it sends the ACK message to the reader.

(7) R→T: $H({\mathrm{i}\mathrm{d}}_T\parallel {\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}})\parallel H(\mathrm{K}\mathrm{e}\mathrm{y}\parallel r_2)\oplus {\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}}$ .

When the reader receives the ACK message, it calculates $H({\mathrm{i}\mathrm{d}}_T\parallel {\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}})$ and $H(\mathrm{K}\mathrm{e}\mathrm{y}\parallel r_2)\oplus {\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}}$ to the tag.

(8) The tag extracts ${\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}}$ and verifies $H({\mathrm{i}\mathrm{d}}_T\parallel {\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}})$ . If it holds, the reader is authenticated by the tag. Then the tag updates $\mathrm{K}\mathrm{e}\mathrm{y}={\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}}$ and stores $H({\mathrm{i}\mathrm{d}}_T\parallel {\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}})$ for the next run.

5. Analysis of the Proposed Scheme

In this section, we will analyze the security and performance of the proposed protocol. We use AVISPA tool to verify the security and compare the security and performance of the proposed protocol with those of the other two cloud-based authentication protocols.

5.1. Analysis of the Security Goals

Our protocol provides mutual authentication between the tag and the reader, which achieves the following security goals.

Tag Tracking. In each time of the authentication, the tag and reader generate random numbers $r_2$ and $r_1$ , respectively. The tag's responses are changed in each session using the updated tag's secret and fresh random numbers. After receiving the request, $\mathrm{R}\mathrm{e}\mathrm{q}\mathrm{u}\mathrm{e}\mathrm{s}\mathrm{t}\parallel r_{\mathrm{1}}$ , the tag computes $M_1=H(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T\parallel r_1)$ , $H(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)$ and sends $r_2,M_1,H(\mathrm{K}\mathrm{e}\mathrm{y}\parallel {\mathrm{i}\mathrm{d}}_T)$ to the reader; thus the attacker obtains new different responses every time when he/she eavesdrops on a session. So he/she cannot track the tag.

Mutual Authentication. Mutual authentication means that the tag and the reader could authenticate each other in the execution of the authentication. In the proposed scheme, the reader authenticates the tag by checking the correctness of $M_1$ and the tag authenticates the reader by checking the correctness of $H({\mathrm{i}\mathrm{d}}_T\parallel {\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{n}\mathrm{e}\mathrm{w}})$ .

Forward Security. Forward security means that an adversary cannot obtain previous key by an entity even if he/she compromises it. In the proposed protocol, the Key begins the update by computing hash function of the random numbers and ${\mathrm{K}\mathrm{e}\mathrm{y}}_{\mathrm{o}\mathrm{l}\mathrm{d}}$ , and the adversary cannot impersonate the process of the update. So the adversary cannot figure out the previous Key even if he/she intercepts a lot of messages.

Location Privacy of the Reader. In our scheme, we introduce a location privacy cloud which can protect the reader's location information from leaking to the cloud server and the adversary.

Replay Attack. Having intercepted previous communication, the attacker can replay the same message of the receiver or the sender to pass the verification of the system. However, the random numbers and the secret key are different in each session and there is no regular pattern to follow for the adversary. The replay attack will fail in the proposed protocol.

Desynchronization Attack. During a successful tag query, both the reader and the tag are in synchronization. In fact, the adversary can hamper the communication between the reader and the tag so that the keys stored in the database and the tag will be out of sync. In the proposed protocol, the cloud database stores $\{H_{\mathrm{o}\mathrm{l}\mathrm{d}}({\mathrm{i}\mathrm{d}}_T\parallel \mathrm{K}\mathrm{e}\mathrm{y}),E_{\mathrm{o}\mathrm{l}\mathrm{d}}({\mathrm{i}\mathrm{d}}_T\parallel \mathrm{K}\mathrm{e}\mathrm{y})\},\{H_{\mathrm{n}\mathrm{e}\mathrm{w}}({\mathrm{i}\mathrm{d}}_T\parallel \mathrm{K}\mathrm{e}\mathrm{y}),E_{\mathrm{n}\mathrm{e}\mathrm{w}}({\mathrm{i}\mathrm{d}}_T\parallel \mathrm{K}\mathrm{e}\mathrm{y})\}$ pairs. So when the adversary interrupts the update process of the session, it will recover to synchronization in the next run.

5.2. The Formal Security Verification under the AVISPA Tool

In our analysis, we have used a formal verification tool called AVISPA (Automated Validation of Internet Security Protocols and Applications) [15]. It is considered the best suitable one for verifying security properties [16]. It provides a modular and expressive formal language for specifying protocols and their security properties and integrates different backends that implement a variety of automatic protocol analysis techniques. AVISPA requires the protocol specification to be written in HLPSL (High Level Protocol Specification Language), which is then provided as an input to the tool. User establishes a secure analysis model by inputting participant identification, operating environment, attacker's ability, and goals of the protocol.

We describe the interactive process of the proposed protocol in HLPSL and define the ability of the adversary. The specification of the proposed protocol contains three basic roles: the tag, the reader, and the cloud database. Each role contains a list of global and local variables and it defines transitions that usually describe the receipt of a message and the sending of a reply. Once roles are defined, we have added the protocol session, the environment section, and the list of declarations goals for security properties. The adversary can obtain the hash function and all the random numbers in our definition.

We verify the security of the proposed protocol and the result shows that it is safe. The HLPSL code and the result are shown in the appendix.

5.3. Security Comparisons

Security comparisons between the proposed protocol and the other schemes are listed in Table 1.

Table 1

Security comparisons.

	[12]	[13]	[14]	The proposed protocol
Tag tracking	No	Yes	Yes	Yes
Mutual authentication	Yes	Yes	Yes	Yes
Forward security	Yes	Yes	No	Yes
Location privacy of the reader	No	No	No	Yes
Replay attack	Yes	Yes	Yes	Yes
Desynchronization attack	Yes	Yes	Yes	Yes

5.4. Performance and Cost Comparisons

We analyze the performance of our method in terms of tag's computation cost, tag's storage spaces, tag's communication message, the efficiency of the cloud database, and so forth. Performance comparisons between the proposed protocol and the other existing schemes are listed in Table 2.

Table 2

Performance comparisons.

	[12]	[13]	[14]	The proposed protocol
Tag's computation cost	$$4h+1r+1\text{xor}$$	$$5h+1r+2\text{xor}$$	$$4h+2r+7\text{xor}$$	$$3h+1r+1\text{xor}$$
Tag's storage spaces	$$3L$$	$$2L$$	$$4L$$	$$2L$$
Tag's communication message	3l	3l	3l	3l
Efficiency of the cloud database	Low	Low	Medium	High
Deployment cost	High	Medium	Medium	Low

h: the computing cost of a hash function; r: the computing cost of generating a random number; L: the length of the tag's identity and secret; l: the length of the hash output; xor: the computing cost of a bitwise XOR operation.

By analyzing and comparing these schemes in security and performance, our method not only meets the security requirements, but also has advantages in deployment cost, tag's computation cost, and the efficiency of the cloud database.

6. Conclusion

In this paper, we proposed an RFID mutual authentication protocol based on location privacy cloud. Our scheme not only protects the reader's location privacy, but also has advantages in security and performance. Compared with the existing cloud-based RFID systems, our proposed scheme is more efficient in terms of communication overhead and memory requirement while offering higher level of security. We proved that our proposed scheme is secure against the relevant attacks and also ensures a higher security level and good performance compared with the existing similar schemes. In the future work, we will expand the location privacy cloud to an RFID public access platform to provide more services.