Cloud-based radio frequency identification authentication protocol with location privacy protection

Abstract

With the development of the Internet of things and cloud storage, a large number of objects access to the Internet through radio frequency identification technology, cloud-based radio frequency identification system attracts more attention because it can reduce the costs of system maintenance by renting the cloud storage service on demand. Especially, it is very suitable for the small- and medium-sized enterprises. However, the security and privacy issues of the cloud-based radio frequency identification system are more serious than traditional radio frequency identification systems. The link between the reader and the cloud is no longer secure, and the cloud service provider is not trusted. Both the location privacy of the reader and the data privacy of the radio frequency identification system are not able to be exposed to the cloud service provider. In this article, a cloud-based radio frequency identification authentication protocol is proposed. It considers not only the mutual authentication between the reader and the tag, but also the security of data transmission between the reader and the cloud database. In particular, in order to solve the reader’s location privacy problem, the proposed scheme introduces MIPv6 network framework without adding additional infrastructure. The experimental verification with AVISPA tool shows that the protocol satisfies the mutual authentication property. Compared with other cloud-based schemes, the proposed protocol has obvious advantages in deployment cost, scalability, real-time authentication, and the tag’s computational complexity.

Keywords

Radio frequency identification cloud database MIPv6 authentication protocol AVISPA tool

Introduction

Radio frequency identification (RFID) is one of the key technologies for Internet of Things (IoT),¹ which has the powerful capabilities in automatic identification, localization, and access control of the objects;² thus, RFID-based technologies have been widely used in various daily applications such as payment, access control, ticketing, and e-passport that require strong security and privacy mechanisms.³ The integration of RFID technology and wireless communication technology makes it superior to the bar code technology. However, the data privacy and the user’s information privacy problems are very serious.

A typical RFID system is composed of a back-end database, readers, and tags.⁴ The reader activates the tag by sending the RF signals, communicates with it in a noncontact way, and submits the relevant data to the back-end database.⁵ The primary function of the security protocols is identification and authentication which are related to the privacy and security of RFID systems.⁶ It is usually assumed that the channel between the back-end database and reader is secure.⁷ However, this assumption brings many problems. First, it limits the reader’s mobility, because the back-end server and the reader are wired connected. Second, the computing and storage capability of the back-end database have become a big bottleneck,⁸ because the RFID system needs to identify a growing number of objects. Cloud computing emerges as a new computing paradigm that aims to provide reliable, customized, and quality of service guaranteed computation environments for cloud users.⁹ With the development of the cloud computing and cloud storage, users can easily access the “virtual” resources stored in cloud server; RFID systems can benefit from cloud databases when thousands of tags are queried at the same time.¹⁰ Users can easily construct their application systems by renting the cloud database, which can also reduce the costs of deployment and maintenance of back-end database. In recent years, the combination of cloud server and RFID technology has become a research focus. C Dabas and JP Gupta¹¹ designed a cloud computing architecture framework for scalable RFID, Chen et al.¹⁰ proposed an RFID system with a cloud database as a back-end server, and Zhang et al.¹² proposed an efficient RFID search protocol based on clouds.

At present, there are several schemes about cloud-based RFID.^5,13–15 However, the cloud server providers are not trusted, and the tag’s data suffer from the privacy invasion.¹⁶ The cloud-based RFID system faces more serious security threats than the traditional one with a back-end database. Therefore, the traditional RFID authentication scheme is no longer suitable for the cloud environment.⁸ 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, W Xie et al.¹³ proposed a cloud-based RFID authentication protocol and introduced a virtual private network (VPN) agency to ensure the secure connection between the reader and cloud database. Lin et al.¹⁴ proposed a cloud-based authentication protocol for RFID supply chain systems; a trusted third party is introduced to solve the problems of data sharing among enterprises and authority transfer of tags. Dong et al.¹⁵ proposed a cloud-based RFID mutual authentication; 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. In all the above schemes, the computational complexity of the tag is high and most of them do not protect the reader’s location privacy.

In this article, a cloud-based lightweight RFID authentication protocol is proposed. The protocol is designed based on the hash function, and it considers not only the mutual authentication between the reader and the tag, but also the security of data transmission between the reader and the cloud database. In order to solve the reader’s location privacy problem, our scheme introduces MIPv6 network framework without adding additional infrastructure. AVISPA tool is used to analyze the security of the proposed protocol. Compared with other several cloud-based schemes, the proposed protocol has obvious advantages in deployment cost, scalability, real-time authentication, and the tag’s computational complexity.

The rest of the article is organized as follows: In section “Related work,” several available cloud-based RFID authentication schemes are briefly reviewed; in section “The authentication framework,” the authentication framework is described; In section “Cloud-based RFID mutual authentication protocol,” cloud-based RFID mutual authentication protocol is proposed; in section “Analysis of the proposed scheme,” the security of the proposed protocol is analyzed, and the security and performance are compared with other schemes; section “Conclusion” concludes the article.

Related work

The related schemes

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 are stored in the cloud database. Up to now, there are several authentication schemes of cloud-based RFID systems.

In 2013, W Xie et al.¹³ proposed the first cloud-based RFID authentication scheme. In their scheme, the RFID system is mainly composed of tag, reader, VPN agency, and cloud database; the VPN agency provides a secure link for the communication between the cloud server and the reader, which can protect the reader’s location privacy. The cloud database in the scheme stores an EHT (encrypted hash table) that is used to protect the tag’s identity secret value. But this scheme also has some problems, such as the deployment and maintenance costs of the VPN agency are high that is not suitable for small and medium-sized enterprises, if the VPN agency is maintained by a third party, it may leak reader’s location privacy; the session initiator is the tag, if there is a malicious tag sends authentication request persistently, that’s will cause the denial of service attack on the cloud database.

In 2014, Lin et al.¹⁴ proposed a cloud-based authentication protocol for RFID supply chain systems which is composed of tag, reader, trust party, cloud database. The scheme includes authentication phase, ownership transfer, authority recovery, and data sharing. The trust party is mainly to solve the problem of data sharing among enterprises and ownership transfer of the tag, the back-end database in the scheme stores the tag’s identity information encrypted with reader’s key, so as to ensure the security of data. However, the scheme neither provides mutual authentication between the tag and the reader, nor solves the reader’s location privacy issue. The key update only uses simple XOR operation: $Ke y_{T_{new}} = h (R_{T 2}) \oplus K_{T}$ , the key is easy to leak, and the scheme does not satisfy forward security. If an attacker (a malicious reader) sent $h (R_{R})$ and $R_{R} \oplus K_{R}$ to the tag over and over again, the scheme cannot resist the denial of service attacks.

In 2015, Dong et al.¹⁵ proposed an RFID mutual authentication protocol based on location privacy cloud; this system is composed of tags, readers and a cloud server and introduces a public access platform: location privacy cloud. The mutual information between the mobile reader and the cloud server is forwarded via location privacy cloud, the IP address of mobile reader is encrypted when sent to the cloud server, so the cloud server cannot ensure where the data packet comes from, thus the scheme protects the location privacy of the mobile reader. But the scheme needs the support of the public infrastructure, which is not very simple.

In 2017, Xiao et al.⁵ proposed a cloud-based RFID authentication protocol with insecure communication channels; the protocol protects the data transmission between the reader and the cloud server without any help from a third party and preserves tag privacy even when the tag does not update its identification. B Surekha et al.¹⁷ proposed a realistic lightweight authentication protocol for securing cloud-based RFID system. The location privacy of the reader in the two protocols is not protected.

In this article, the proposed scheme does not require any additional devices; the MIPv6 protocol is used to protect the location privacy of the mobile reader.

The attacker model

The attacker model in this article is described in the following two aspects:

A detailed discussion on the assumptions of each of the entities.

The cloud server can provide the right storage and query services; it is honest but curious. It cannot perform active attacks, but it can view users’ privacy data, so the cloud server can perform passive attacks. The structure of the cloud server is managed by cloud provider; in this article, it is regarded as a logical server.

The reader belongs to the user; it is trusted. For the symmetric encryption and hash function, it can provide enough computing support and does not have resource constraints. The reader trusts that the cloud server can provide the right storage and query services; the cloud server trusts that the reader can provide the right calculation.

The communication channel between the reader and the cloud server is not secure.

The communication channel between the reader and the tag is not secure.

A discussion of the capabilities of the adversary

The adversary can intercept any interaction information between the communication entities.

The adversary can receive messages from any other entity sent to the communication channel.

The adversary cannot obtain the shared authentication key between a reader and the cloud server by any means.

The attacker cannot calculate or guess the random number that the entity will use.

The authentication framework

In this section, we will give the authentication framework. This framework can protect the location privacy of the mobile reader.

System components

Tag: the tag needs to store its identity $i d_{T}$ and secret value $key$ ; it also needs to support the generation of random numbers and the operations of hash function.

Reader: the reader needs to store its identity $i d_{R}$ , symmetric key $k$ for encrypting and decrypting the data stored in the cloud database, authentication key $kRC$ shared by the reader and the cloud server. It also needs to support the generation of random numbers, the operations of hash function and symmetric encryption and decryption, the update operations and has the ability to calculate the message authentication code (MAC). The reader can move arbitrarily.

When the user purchases the cloud service from the cloud service provider, he registers related information, such as the users’ normal identity information, the binding information of the user and the reader. To ensure the security of the protocol, readers need to update the key k regularly and then the user updates all encrypted data with the new key k and notifies the cloud server to update the relevant values. The cloud server can know the user of the reader by users’ registered information.

3. Cloud server: the cloud server needs to provide the service of on-demand computing and storing, stores $(h (i d_{R}), KRC)$ , ${h (key | | i d_{T} | | h (i d_{R})), E_{k} (key | | i d_{T})}$ , ${h (ke y_{old} | | i d_{T} | | h (i d_{R})), E_{k} (ke y_{old} | | i d_{T})}$ . It also needs to support the query and update operations, the generation of random numbers, the operations of hash function and has the ability to calculate the MAC.

4. MIPv6: this system is based on the MIPv6 protocol, a basic wireless network protocol standard,¹⁸ which has excellent mobility support. In MIPv6 network, mobile node (MN, such as mobile reader) has a permanent home address (HoA) and a temporary care-of address (CoA) in foreign link, correspondent node (CN, such as cloud server) is a node which can communicate with MN, and home agent (HA) is a router located in home network. Access router is responsible for the external communication of IPv6 nodes in the access network. A MN can use a stateful or stateless address auto-configuration protocol to obtain a CoA. We assume that the network transmission between mobile readers and the cloud database is based on MIPv6 protocol.

The authentication framework is illustrated in Figure 1.

Figure 1.

The authentication framework.

The location privacy protection mechanism

Once a user has purchased the cloud service, the cloud server will authorize each of his mobile readers and negotiate an authentication key $kRC$ ; the authentication key shared between each reader and the cloud server is different. All the mobile readers share a secret key that is used to encrypt the data in the cloud database; the mobile readers store the IP address IP_C of the cloud server.

In MIPv6 protocol, MN and CN have two communication modes, bi-directional tunnel mode and routing optimization mode, in order to protect the location privacy of the mobile reader; in this article, we use the first one. In this mode, the CN does not need to support MIPv6; the packet from CN is routed to the HA and sent to the MN though the tunnel. The packet from MN is sent to the HA and then routed to the CN. The tunnel is implemented using the IPv6 package.

The RFID system works in the MIPv6 network environment. The mobile reader communicates with the cloud server with the help of the HA and the tunnel. In the following, we will describe the process of the tunnel establishment and the message transmission:

When the mobile reader receives a route announcement sent from foreign network, it can determine whether it has been moved to foreign network. If does, the mobile reader gets a CoA in the foreign network.

The mobile reader sends a binding update message to the HA to register the new CoA.

After the HA receives the bind and update message, it binds the reader’s CoA with its HoA and registers the CoA, then returns a binding confirmation message, then it finishes the home registration process. Thus, a tunnel between the HA and the reader is established.

It should be noted that MIPv6 provides “dynamic HA address discovery” mechanism, allows mobile reader to dynamically discover the existing IP address of the home link, thus ensures it to register its CoA.

The message transmission between the reader and the cloud server

The message transmission between the mobile reader and the cloud server is shown as follows:

The reader sends packet to the cloud server

The packet from reader to HA includes the following contents: (The structure of the packet is shown in Figure 2.)

The outer IPv6 header: in the outer IPv6 header, the source address is the CoA of mobile reader; the destination address is IP address of the HA IP_H.

The inner IPv6 header: in the inner IPv6 header, the source address is the HoA of mobile reader; the destination address is IP_C.

The upper layer of protocol data unit (PDU): PDU contains application layer data sent from mobile reader to cloud server.

Figure 2.

IP packet 1.

After the HA receives the packet from mobile reader, it forwards the packet to cloud server. The packet includes: (The structure of the packet is shown in Figure 3.)

IPv6 basic header: in the IPv6 basic header, the source address is the HoA of mobile reader; the destination address is IP_C.

The upper layer of PDU: PDU contains application layer data sent from mobile reader to cloud server.

2. The cloud server sends packet to the reader.

The packet includes the following contents: (The structure of the packet is shown in Figure 3.)

IPv6 basic header: in the IPv6 basic header, the source address is IP_C; the destination address is the HoA of mobile reader.

The upper layer of PDU: PDU contains application layer data sent from cloud server to mobile reader.

Figure 3.

IP packet 2.

The HA intercepts the packet sent to the HoA of the mobile reader by the neighbor discovery mechanism, then finds the binding cache according to the IP destination address, and acquires the CoA registered by mobile reader, then sends the packet to the CoA of mobile reader though the tunnel. The packet includes: (The structure of the packet is shown in Figure 2.)

The outer IPv6 header: in the outer IPv6 header, the source address is IP_H; the destination address is the CoA of the mobile reader.

The inner IPv6 header: in the inner IPv6 header, the source address is IP_C; the destination address is the HoA of mobile reader.

The upper layer of PDU: PDU contains application layer data sent from cloud server to mobile reader.

Through the above process, the cloud server cannot know the CoA of the reader; thus, the location privacy of the mobile reader is protected that is invisible to the following authentication protocol.

Cloud-based RFID mutual authentication protocol

The MIPv6 network framework can protect the reader’s location privacy in the cloud environment. In the section, we propose an RFID mutual authentication protocol based on this framework.

Notations

The notations used in this article are defined in Table 1.

Table1.

Notations definition.

Notations definition	Description
T	The tag
R	The mobile reader
Cloud	The cloud server
$i d_{T}$	The identity of the tag
$i d_{R}$	The identity of the reader
$key$	A secret key of the tag
$kRC$	An authentication key shared by the reader and the cloud server
$k$	Symmetric encryption and decryption key for encrypting the data stored in cloud
$r_{i}$	A random number
$MAC$	Message authentication code
$h ()$	Hash function
$E ()$	Symmetric encryption algorithm
\|\|	The concatenation of two strings

Initialization

The tags store their own identity $i d_{T}$ and secret value $key$ .

The cloud server stores $(h (i d_{R}), KRC)$ , ${h (key | | i d_{T} | | h (i d_{R})), E_{k} (key | | i d_{T})}$ , ${h (ke y_{old} | | i d_{T} | | h (i d_{R})), E_{k} (ke y_{old} | | i d_{T})}$ , and sets $h (key | | i d_{T} | | h (i d_{R})) = h (ke y_{old} | | i d_{T} | | h (i d_{R}))$ , $E_{k} (key | | i d_{T}) = E_{k} (ke y_{old} | | i d_{T})$ .

The reader stores its identity $i d_{R}$ , key k and precomputes $h (i d_{R})$ , shares authentication key $kRC$ with the cloud server.

The authentication protocol

The proposed protocol is not a traditional three-party protocol, in the authentication phase, the cloud server is only responsible for storing and searching the RFID data, the authentication is between tag and reader.

As shown in Figure 4, the cloud-based RFID mutual authentication protocol is as follows:

R → T: $h (i d_{R}) | | r_{1}$ .

The mobile reader generates a random number $r_{1}$ and sends $h (i d_{R}) | | r_{1}$ to the tag.

2. T → R: $r_{2} | | h (key | | i d_{T} | | h (i d_{R})) | | h (r_{1} | | key | | i d_{T})$ .

After receiving $h (i d_{R}) | | r_{1}$ , the tag generates a random number $r_{2}$ , uses the hash function to compute $X = h (key | | i d_{T} | | h (i d_{R}))$ , $M_{1} = h (r_{1} | | key | | i d_{T})$ , and sends $r_{2} | | X | | M_{1}$ to the reader as a response.

3. R → C: $r_{1} | | h (i d_{R}) | | X | | MA C_{kRC} {r_{1} | | h (i d_{R}) | | X}$ .

The reader stores the messages $M_{1} = h (r_{1} | | key | | i d_{T})$ and $r_{2}$ sent from the tag, sends $r_{1} | | h (i d_{R}) | | X | | MA C_{kRC} {r_{1} | | h (i d_{R}) | | X}$ to the cloud server. $MA C_{kRC} {r_{1} | | h (i d_{R}) | | X}$ denotes the MAC.

4. C → R: $r_{1} | | r_{3} | | E_{k} (key | | i d_{T}) | | MA C_{KRC} {r_{1} | | r_{3} | | E_{k} (key | | i d_{T})}$ .

The cloud server searches $h (i d_{R})$ , if finds it, the cloud server can find the corresponding $kRC$ , then uses $kRC$ to verify $MA C_{kRC} {r_{1} | | h (i d_{R}) | | X}$ to determine whether the information from the reader is tampered or not. If the verification passes, the cloud server searches $X$ in its own records. The searching results include three cases as follows:

There is no matching hash value, the authentication is failed, and then the protocol stops.

If the cloud server finds $h (key | | i d_{T} | | h (i d_{R}))$ that is equal to $X$ , it indicates that both the cloud server and the tag carried out the update normally in the last authentication. The cloud server generates a random number $r_{3}$ , sends $r_{1} | | r_{3} | | E_{k} (key | | i d_{T}) | | MA C_{KRC} {r_{1} | | r_{3} | | E_{k} (key | | i d_{T})}$ to the reader.

If the cloud server finds $h (ke y_{old} | | i d_{T} | | h (i d_{R}))$ that is equal to $X$ , it indicates that the cloud server carried out the update normally, while the tag did not renew its key in the last authentication. The cloud server generates a random number $r_{3}$ , sends $r_{1} | | r_{3} | | E_{k} (ke y_{old} | | i d_{T}) | | MA C_{KRC} {r_{1} | | r_{3} | | E_{k} (ke y_{old} | | i d_{T})}$ to the reader.

5. R → C: $r_{3} | | h (ke y_{new} | | i d_{T} | | h (i d_{R})) | | E_{k} (ke y_{new} | | i d_{T}) | | MA C_{kRC} {r_{3} | | h (ke y_{new} | | i d_{T} | | h (i d_{R})) | | E_{k} (ke y_{new} | | i d_{T})}$

The reader uses $k$ to decrypt $E_{k} (key | | i d_{T})$ to get $key$ and $i d_{T}$ , and it checks whether $h (r_{1} | | key | | i d_{T})$ is equal to $M_{1}$ , if it succeeds, the tag is authenticated by the reader.

The reader computes $ke y_{new} = h (r_{1} | | r_{2} | | key)$ , $h (ke y_{new} | | i d_{T} | | h (i d_{R}))$ , $E_{k} (ke y_{new} | | i d_{T})$ , sends $r_{3} | | h (ke y_{new} | | i d_{T} | | h (i d_{R})) | | E_{k} (ke y_{new} | | i d_{T}) | | MA C_{kRC} {r_{3} | | h (ke y_{new} | | i d_{T} | | h (i d_{R})) | | E_{k} (ke y_{new} | | i d_{T})}$ to the cloud server to remind the cloud server to carry out the update.

6. C → R: $r_{3} | | ACK | | MA C_{KRC} {r_{3} | | ACK}$ .

The cloud server checks $MA C_{kRC} {r_{3} | | h (ke y_{new} | | i d_{T} | | h (i d_{R})) | | E_{k} (ke y_{new} | | i d_{T})}$ and updates the corresponding records, sets: $h (ke y_{old} | | i d_{T} | | h (i d_{R})) = h (key | | i d_{T} | | h (i d_{R}))$ , $E_{k} (ke y_{old} | | i d_{T}) = E_{k} (key | | i d_{T})$ , $h (key | | i d_{T} | | h (i d_{R})) = h (ke y_{new} | | i d_{T} | | h (i d_{R}))$ , $E_{k} (key | | i d_{T}) = E_{k} (ke y_{new} | | i d_{T})$ . Then it sends $r_{3} | | ACK | | MA C_{kRC} {r_{3} | | ACK}$ to the reader.

7. R → T: $M_{2}$

When the reader receives the $r_{3} | | ACK | | MA C_{kRC} {r_{3} | | ACK}$ , it computes $M_{2} = h (r_{2} | | ke y_{new})$ and sends $M_{2}$ to the tag.

8. The tag computes $ke y_{new} = h (r_{1} | | r_{2} | | key)$ , verifies that whether $h (r_{2} | | ke y_{new})$ is equal to $M_{2}$ or not; if it succeeds, the reader is authenticated by the tag. Then the tag updates $key = ke y_{new}$ .

Figure 4.

Cloud-based RFID mutual authentication protocol.

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 several other cloud-based authentication protocols.

Analysis of the security goals

The proposed RFID authentication scheme not only achieves mutual authentication between the reader and the tag, but also meets the following security goals:

Tag tracking

In each time of the authentication, the reader and tag generate random numbers $r_{1}$ and $r_{2}$ , respectively. The tag’s responses are changed in each session using the updated tag’s secret and fresh random numbers. After receiving $h (i d_{R}) | | r_{1}$ , the tag computes $X = h (key | | i d_{T} | | h (i d_{R}))$ , $M_{1} = h (r_{1} | | key | | i d_{T})$ , and sends $r_{2} | | X | | M_{1}$ to the reader; thus, the attacker obtains new different responses every time when he or she eavesdrops on a session. Therefore, he or she cannot track the tag.¹⁵

Mutual authentication

Mutual authentication means that the reader and the tag 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}$ ; the tag authenticates the reader by checking the correctness of $M_{2}$ .

Forward security

Forward security means that even if the adversary can decrypt the key in the current session, he cannot calculate the messages of the previous session according to the key. In the proposed protocol, since the use of random number $r_{1}$ , $r_{2}$ and one-time hash function, it ensures that each interactive messages are different, the update rule of the tag’s secret key $key$ is $ke y_{new} = h (r_{1} | | r_{2} | | key)$ , and the hash function is a one-way function; thus, the adversary cannot recover the past session messages according to the current key. Therefore, the protocol satisfies the forward security.

Location privacy of the reader

The proposed scheme introduces the MIPv6 network framework; the communication messages between the reader and the cloud server all need to be forwarded via the HA; the cloud server cannot know the real direction of the message; thus, the location privacy of the reader is protected.

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. In the proposed protocol, both the tag and the reader generate random numbers; in each session, the random numbers and the tag’s secret key are different, and there is no regular pattern to follow for the attacker, so the replay attack will fail.

The desynchronization attack

The desynchronization attack means that the attacker uses some methods, such as interdicting the last message, to make the back-end server and the valid tags share the different secrets.¹⁹ In the proposed protocol, the cloud server updates the secret key earlier than the tag. If the attacker hampers the message sent from the reader to the tag, then the cloud server finishes the update but the tag does not. However, since the cloud server stores $h (key | | i d_{T} | | h (i d_{R}))$ , $E_{k} (key | | i d_{T})$ and $h (ke y_{old} | | i d_{T} | | h (i d_{R}))$ , $E_{k} (ke y_{old} | | i d_{T})$ , so the next authentication still can be carried out normally based on old key, then the synchronization is established again. Therefore, the proposed protocol can resist the desynchronization attack.

Denial of service attack

The malicious adversary continues to send request, which consumes the resources of link and server, to achieve the purpose of the denial of service. In the proposed protocol, the initiator of the protocol is the reader, and the reader shares authentication key $kRC$ with the cloud server, so the adversary cannot impersonate the tag or the reader to send continuous authentication request to consume the resources of link and server.

The formal security verification with the AVISPA tool

In this section, we use a formal verification tool called AVISPA to analyze the proposed protocol. It provides a modular and expressive formal language for specifying protocols and their security properties and integrates different back-ends that implement a variety of state-of-the-art automatic analysis techniques. To the best of our knowledge, no other tool exhibits the same level of scope and robustness while enjoying the same performance and scalability.²⁰ AVISPA uses HLPSL (High-Level Protocol Specification Language), the user establishes a secure analysis model by inputting participant identification, operating environment, attacker’s ability, and goals of the protocol.

In this article, we use HLPSL to describe the interactive process of the proposed protocol and define the attacker’s abilities. The participants of the protocol contain three basic roles: the tag, the reader, and the cloud database; each role contains some definitions of variables and functions. The attacker can obtain hash functions and random numbers of the whole process. The HLPSL language description of the protocol is shown in Figure 5. The interactive process of the protocol is shown in Figure 6.

Figure 5.

The HLPSL language description of the protocol.

Figure 6.

The interactive process of the protocol.

The operation result of the AVISPA is shown in Figure 7, which indicates that the proposed protocol is secure. The complete HLPSL codes are shown in Appendix 1.

Figure 7.

The operation result of the AVISPA.

Security comparisons

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

Table 2.

Security comparisons.

	Wei	Lin	Dong	Proposed protocol
Tag tracking	No	Yes	Yes	Yes
Mutual authentication	Yes	Yes	Yes	Yes
Forward security	Yes	No	Yes	Yes
Location privacy of reader	No	No	Yes	Yes
Repay attack	Yes	Yes	Yes	Yes
Desynchronization attack	Yes	Yes	Yes	Yes
Denial of service attack	No	Yes	Yes	Yes

Performance comparisons

Performance comparison between the proposed protocol and several other schemes is listed in Table 3.

Table 3.

Performance comparisons.

	Wei	Lin	Dong	Proposed protocol
Tag’s computation cost	$4 h + 1 r + 1 xor$	$4 h + 2 r + 7 xor$	$4 h + 1 r + 1 xor$	$4 h + 1 r$
Tag’s storage spaces	3L	4L	2L	2L
Tag’s communication message	3l	3l	3l	3l
Number of messages	10	5	7	7
Efficiency of cloud database	Low	Medium	High	High
Public infrastructure	No	No	Yes	No
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.

The security and performance comparisons show that the proposed protocol satisfies the security requirements and has advantages in tag’s computation cost and deployment cost.

Conclusion

In this article, we proposed an cloud-based RFID mutual authentication protocol, the protocol introduces MIPv6 network framework without adding additional infrastructure, it not only protects the location privacy of the mobile reader, but also realizes the mutual authentication between the tag and the reader, meanwhile, meets the security features of untraceability, forward security, and so on. We also used the AVISPA tool to verify the security of the protocol. Finally, compared with several cloud-based RFID protocols, this protocol has higher security and better performance. In future work, we will continue to improve the performance of cloud-based RFID authentication protocol.

Footnotes

Appendix 1

role role_Aa(Aa:agent,Bb:agent,R2:text,H:function,Key:text,SND,RCV:channel(dy))

played_by Aa

def=

local

State:nat,R1:text,Keynew:text

init

State := 0

transition

1. State=0 /\ RCV(H(Bb).R1’) =|>State’:=1/\SND(R2.H(Key.Aa. H(Bb)).H(R1’.Key.Aa))

7. State=1/\ RCV(H(R2.Keynew’)) =|> State’:=2/\ witness(Aa,Bb,auth_2,Aa)

end role

role role_Bb(Bb:agent,Cc:agent,R1:text,H:function,K:symmetric_key,KRC:symmetric_key,SND,RCV:channel(dy))

played_by Bb

def=

local

State:nat,MAC:text,Keynew:text,Aa:agent,R2:text,R3:text,Key:text,ACK:text

init

State := 0

transition

1. State=0 /\ RCV(start) =|> State’:=1 /\ SND(H(Bb).R1)

2. State=1 /\ RCV(R2’.H(Key’.Aa’.H(Bb)).H(R1.Key’.Aa’)) =|> State’:=2 /\ MAC’:=new() /\ SND(R1.H(Bb).H(Key’.Aa’.H(Bb)).{MAC’}_KRC)

4. State=2 /\ RCV(R1.R3’.{Key.Aa}_K.{MAC}_KRC) =|> State’:=3/\ witness(Bb,Aa,auth_1,Key’) /\ Keynew’:=new() /\ SND(R3’.H(Keynew’.Aa.H(Bb)).{Keynew’.Aa}_K.{MAC}_KRC)

6. State=3 /\ RCV(R3.ACK’.{MAC}_KRC) =|>State’:=4 /\ SND(H(R2.Keynew))

end role

role

role_Cc(Cc:agent,Bb:agent, R3:text, KRC:symmetric_key,K:symmetric_key,H:function,SND,

RCV:channel(dy))

played_by Cc

def=

local

State:nat,MAC:text,R1:text,R2:text,Aa:agent,Keynew:text,Key:text,ACK:text

init

State := 0

transition

3. State=0 /\ RCV(R1’.H(Bb).H(Key’.Aa’.H(Bb)).{MAC’}_KRC) =|> State’:=1 /\ SND(R1’.R3.{Key.Aa’}_K.{MAC’}_KRC)

5. State=1/\ RCV(R3.H(Keynew’.Aa.H(Bb)).{Keynew’.Aa}_K.{MAC}_KRC) =|> State’:=2/\ Keynew’:=new()/\ SND(R3.ACK’.{MAC}_KRC)

end role

role session1(R1:text,Aa:agent,R2:text, Key:text,R3:text, Cc:agent,Bb:agent,KRC:symmetric_key,

K:symmetric_key,H:function)

def=

local

SND3,RCV3,SND2,RCV2,SND1,RCV1:channel(dy)

composition

role_Cc(Cc,Bb,R3,KRC,K,H,SND3,RCV3)/\role_Bb(Bb,Cc,R1,H,K,KRC,SND2,RCV2) /\ role_Aa(Aa,Bb,R2,H,Key,SND1,RCV1)

end role

role environment()

def=

const

hash_0:function,k:symmetric_key,reader:agent,key:text,tag:agent,r1:text,r2:text,r3:text,cloudDatabase:agent,kRC:symmetric_key,h:function,auth_1:protocol_id,auth_2:protocol_id

intruder_knowledge = {h,r1,r2, r3}

composition

session1(r1,tag,r2,key,r3,cloudDatabase,reader,kRC,k,h)

end role

goal

authentication_on auth_1

authentication_on auth_2

end goal

environment()

Handling Editor: Antonio Lazaro

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work is supported by the National Natural Science Foundation of China (nos 61373172, 61303216).

References

Fan

et al . ESLRAS: a lightweight RFID authentication scheme with high efficiency and strong security for internet of things. In: Proceedings of the international conference on intelligent networking and collaborative systems, Bucharest, 19–21 September 2012, pp.323–328. New York: IEEE.

Dass

. A secure authentication scheme for RFID systems. Procedia Comput Sci 2016; 78: 100–106.

Kardas

Celik

Bingol

et al . A new security and privacy framework for RFID in cloud computing. In: Proceedings of the IEEE international conference on cloud computing technology and science, Bristol, 2–5 December 2013, pp.171–176. New York: IEEE.

Morshed

Atkins

. Secure ubiquitous authentication protocols for RFID systems. EURASIP J Wirel Comm 2012; 1: 1–8.

Xiao

Alshehri

Christianson

. A cloud-based RFID authentication protocol with insecure communication channels. In: Proceedings of the Trustcom/BigDataSE/ISPA, Tianjin, China, 23–26 August 2017, pp.332–339. New York: IEEE.

Srivastava

Awasthi

Kaul

et al . A hash based mutual RFID tag authentication protocol in telecare medicine information system. J Med Syst 2015; 39(1): 153.

Kim

et al . Efficient RFID secure protocol with forward secrecy. J I Webcasting Internet Telecommun 2011; 12(6): 139–147.

Tong

Dong

Huo

. Cloud-based low-cost RFID authentication protocol. J Cryptogr 2015; 2(4): 333–341.

Wei

Zhu

Cao

et al . Security and privacy for storage and computation in cloud computing. Inform Sci 2014; 258(3): 371–386.

10.

Chen

Sun

et al . CRFID: an RFID system with a cloud database as a back-end server. Future Gener Comp Sy 2014; 30(1): 155–161.

11.

Dabas

Gupta

. A cloud computing architecture framework for scalable RFID. Lect Notes Eng Comp 2010; 2180(1): 441–444.

12.

Zhang

Qian

Wan

et al . An efficient RFID search protocol based on clouds. Mobile Netw Appl 2015; 20(3): 356–362.

13.

Xie

Zhang

et al . Cloud-based RFID authentication. In: Proceedings of the IEEE international conference on RFID, Penang, Malaysia, 30 April–2 May 2013, pp.168–175. New York: IEEE.

14.

Lin

Hsu

Cheng

. A cloud-based authentication protocol for RFID supply chain systems. J Netw Syst Manag 2015; 23(4): 1–20.

15.

Dong

Tong

Chen

. Cloud-based RFID mutual authentication protocol without leaking location privacy to the cloud. Int J Distrib Sens N 2015; 11: 1–9.

16.

Abughazalah

Markantonakis

Mayes

. Secure improved cloud-based RFID authentication protocol. In: Garcia-Alfaro

Herrera-Joancomartí

Lupu

et al . (eds) Data privacy management, autonomous spontaneous security, and security assurance. Berlin: Springer, 2015, pp.147–164.

17.

Surekha

Narayana

Jayaprakash

et al . A realistic lightweight authentication protocol for securing cloud based RFID system. In: Proceedings of the IEEE international conference on cloud computing in emerging markets, Bangalore, India, 19–21 October 2017, pp.54–60. New York: IEEE.

18.

Johnson

Perkins

Arkko

. RFC 3775: mobility support in IPv6. Fremont, CA: IETF, 2004, pp.10–30.

19.

Zhou

Zhang

Luo

et al . A lightweight anti-desynchronization RFID authentication protocol. Inform Syst Front 2010; 12(5): 521–528.

20.

Armando

Basin

Boichut

et al . The AVISPA tool for the automated validation of internet security protocols and applications. Lect Notes Comput Sc 2005; 3576(6): 135–165.