Abstract
The ownership of RFID tag is often transferred from one owner to another in its life cycle. To address the privacy problem caused by tag ownership transfer, we propose a tag privacy model which captures the adversary’s abilities to get secret information inside readers, to corrupt tags, to authenticate tags, and to observe tag ownership transfer processes. This model gives formal definitions for tag forward privacy and backward privacy and can be used to measure the privacy property of tag ownership transfer scheme. We also present a tag ownership transfer scheme, which is privacy-preserving under the proposed model and satisfies the other common security requirements, in addition to achieving better performance.
1. Introduction
RFID (Radio-Frequency Identification) technology is widespread in commercial industry such as supply chain management, inventory management, and access control for people and vehicles. A RFID application system mainly consists of tags, readers/interrogators, and back-end server. A passive tag is basically a device embedded with a small chip and a coiled antenna, in which the chip has limited computation capability and small memory to store its secret key and identifier, and the antenna communicates with its reader via radio-frequency signal. A reader is used to interrogate tags and send the data received from tags to a back-end server for product identification or inventory tracking. The back-end server stores tag’s secret keys, identifiers, and the information of the items labeled by tags and executes product identification or inventory tracking.
However, the privacy issue (e.g., information leakage, location tracking, and profiling individuals) caused by RFID technology has raised grave concerns among the public. A recommendation on this issue was published by the Commission of the European Communities [1], which gave particular attention to the individual tracking and the access to personal data. Take the medicine supply chain for example, those tags attached to medicines are often transferred from one owner to another, however, the previous owner of a tag may infer the tag’s track from its future interactions with a new owner, and as a result, the new owner’s privacy may be infringed. Another serious scenario is that terrorists may exploit this technology to track their target who holds the RFID tags. Once those tags are distinguished at specific point (e.g., the checkpoint or toll station) by the terrorist’s surreptitious devices, particular devices such as a bomb may be triggered.
The privacy of RFID tag means anonymity and untraceability [2], namely, an adversary cannot distinguish or track a tag from other tags at the protocol level. It is observed that many studies [2–16] on tag privacy have focused on the privacy problems caused by tag authentication or tag identification, but little attention was paid to the tag ownership transfer which may leak out tag’s privacy.
Meanwhile, there are some other works [17–31] focusing on design and analysis for concrete tag ownership transfer schemes or protocols, but few of them use formal methods to analyze the privacy problem resulting from tag ownership transfer. As Munilla et al. [32] pointed out, strong privacy remains an open problem for lightweight RFID applications.
Actually, a malicious owner has access to the back-end server which stores all the information of readers and tags, and he has advantage to distinguish a tag after the tag ownership transfer or inferring the past activities of a tag when getting the tag’s ownership. This attack belongs to insider attack, which is serious in practice, but IND-CCA2 encryption can be employed to prevent such kind of attack [33].
Concentrating on tag ownership transfer, we propose a privacy model which introduces strong adversaries, who have abilities to obtain the full information of readers, to authenticate tags, to observe the whole transfer process, and to corrupt tags. With this model, we briefly analyze the scheme [17] which is based on public key encryption on tags. We also present a tag ownership transfer scheme, which is forward and backward privacy-preserving under our model.
The rest of this paper is organized as follows. In Section 2, we review the relevant work on tag ownership transfer, and then we describe the proposed model in Section 3. In Section 4, a recent tag ownership transfer scheme is briefly analyzed, and the proposed ownership transfer scheme is described and analyzed in Section 5. Section 6 concludes the paper.
2. Related Work
Soundness, correctness, and privacy are the required properties for RFID system. Briefly, soundness which is also called security in [2, 9] means that a fake tag cannot be accepted by the system except with negligible probability; correctness means a legitimate tag is always accepted by the system with an overwhelming probability. Canard et al. [6] gave the definitions of soundness and correctness.
In terms of tag ownership transfer scenario, tag forward privacy means an owner of a tag cannot distinguish from others if ’s ownership was transferred to another owner, and tag backward privacy means the current owner of cannot link to its previous interactions (e.g., the transcripts of authentication and ownership transfer process with its previous owner).
In Section 3, we will give the proposed privacy model, which defines tag forward privacy and backward privacy. Since our model concentrates on the privacy problem caused by tag ownership transfer, the properties of soundness and correctness will not be discussed further. However, their definitions can be combined compatibly with our model.
2.1. Tag Ownership
A tag is often attached to an item and authenticated to its back-end server, and it would be transferred from one owner to another in its lifetime. As for a tag ownership transfer, the current owner may launch authentication procedure to authenticate or identify the tag and then transfer the tag’s secret key or identifier to a new owner’s server. Upon getting these secret data, the new owner has ability to authenticate or identify the tag. In this sense, these secret data used for tag authentication/identification are called ownership. In order to prevent the previous owner from authenticating or identifying the tag, the new owner will launch update procedure to make the tag and the new server refresh these shared secret data.
2.2. Tag Ownership Transfer
Tag ownership transfer is more complicated than tag authentication to reader or their mutual authentication, because the current owner and the new owner are involved in the ownership transfer process. Moreover, tag ownership transfer is closely related to tag authentication to its reader.
Several tag ownership transfer schemes are derived from tag authentication protocols. Molnar et al. [22] proposed a scalable and delegatable pseudonym authentication protocol which enables tag ownership transfer; however, a trusted center is required. Lim and Kwon [21] proposed a robust authentication protocol enabling ownership transfer, whereas their scheme cannot achieve tag untraceability under the model in [34]. Song [25] suggested a tag ownership transfer scheme, which enables authorization recovery and protects the privacy of both current and previous owners, but this scheme is vulnerable to tag location tracking, tag forward traceability, and desynchronization attack [23]. Later, Song and Mitchell [26] proposed another RFID protocol and claimed it supports tag ownership transfer, tag delegation, and authorization recovery. Recently, Kardaş et al. [20] introduced an authentication protocol enabling tag ownership transfer with hash and XOR operation and claimed the protocol achieves tag untraceability against strong adversaries.
There are some ownership transfer schemes for the tags supporting public key encryption. Fu and Guo [27] designed a mutual authentication protocol supporting tag ownership transfer based on the SQUASH scheme [35], but the authors did not exhibit the tag ownership transfer process. Cheng et al. [17] presented an ownership transfer scheme, which employs elliptic curve cryptography (ECC) and will be briefly analyzed in Section 4.
There are some other ownership transfer schemes based on the public key encryption on readers. Elkhiyaoui et al. [18] designed a transfer scheme consisting of three subprotocols, but the scheme is vulnerable to the privacy track initiated by the tag’s previous owner [36], because their definitions neglected the ability of the previous owner who ever controls the secret key of the target tag, and some revisions in [29] were presented to correct this flaw. Xin et al. [28] proposed a privacy-preserving ownership transfer scheme and claimed it guarantees privacy and other security properties; however, this scheme employed a powerful Trusted Third Party.
Some researches on tag ownership transfer focus on mobile RFID environment, and the readers interested in this may refer to [30, 37, 38] for further investigation.
3. The Proposed Privacy Model
Most schemes introduced in Section 2.2 overlooked the fact that the owner may be malicious, and it lacks formal definitions to analyze the privacy property of tag ownership transfer scheme.
van Deursen and Radomirović [33] introduced the insider attack which is serious to the RFID system, because adversaries have the knowledge of readers and tags. In this section, we propose a privacy model for RFID tag ownership transfer. This model provides adversaries with abilities to get the reader’s secret information, to constantly eavesdrop on the communications between reader and its tags, to corrupt tags, and to transfer tag’s ownership to another owner. In the model, the goal of the adversary is to distinguish or infer the target tag from others.
3.1. Entities in the Proposed Model
For simplicity, we suppose the RFID system in the model consists of two owners denoted by with a reader and by with a reader . Because the reader and its back-end server are powerful devices and communicate via secure channel, we also suppose the back-end server is integrated with the reader. Moreover, we suppose the temporary information (e.g., the nonce generated by reader and tags) will be automatically erased when the authentication or ownership transfer process is completed. The notations used in the following sections are listed in Notations for readability.
3.2. Oracles Provided for Adversaries
In a realistic scenario, adversaries can exploit the following information to attack tag’s privacy: the secret information inside reader and tags, the authentication information between reader and tags, the results that adversaries launch authentication procedures with tags, and the ownership transfer information between reader and tags.
We give an adversary the following oracles to simulate his abilities to attack the privacy of a tag .(1): This oracle is provided for to make a reader launch authentication session with . If the adversary controls the secret information of and , it returns , the secret information such as key and identifier pairs , as well as the authentication result. Otherwise, it only returns the authentication result and the process transcripts; namely, it returns . This oracle simulates the adversary’s abilities to launch active attack and to get side channel information (e.g., the result whether or not a tag is accepted by its reader).(2): This oracle makes launch authentication session with the tag and returns the execution transcripts as well as the authentication result. The adversary can query this oracle to eavesdrop on the communication between the target tag and its reader.(3): This oracle is provided for the adversary to corrupt tags. It returns the secret key, the identifier, and the other information inside .(4): The adversary can query this oracle to get the information of the ownership transfer process. It transfers ’s ownership from a current owner who controls to a new owner who controls and returns a virtual identifier for the tag as well as the transcripts of the transfer process.(5): This oracle is provided for the adversary only once at any time. It accepts two tags and then selects a bit to transfer the ownership of to a new owner. This oracle returns the identifier of and the transcripts of the transfer process.
We denote the first four oracles by , , , and the number of times that the adversary queries them by , , , , respectively, and denote the set by . We say that an adversary is a -adversary, if the number of times that queries the above oracles is at most , where is polynomial in .
As for a tag ownership transfer process, a new owner will get the tag’s secret information (e.g., the key and identifier) from the current owner and then update some information inside the tag to prevent the current owner from successfully identifying or tracking the tag.
3.3. Definition of Forward Privacy
We denote a tag at time point just before its ownership is transferred by and denote it by after the transfer process is finished. The transfer scheme should guarantee the previous owner cannot infer the identity of from the identity of . Without loss of generality, we suppose the current reader of the tag is and the new reader is .
Definition 1. Provided with the information of any -adversary can query oracles in at most times, we denote the probability that selects two corrupted tags for querying and correctly guesses by , with permission to query . The tag is forward privacy if is negligible.
3.4. Definition of Backward Privacy
After the ownership of the tag has been successfully transferred to a new owner, the transfer scheme should guarantee the new owner cannot link the information of to the previous activities of the tag. With the same way to define tag forward privacy, we define tag backward privacy as follows.
Definition 2. Provided with all the information of any -adversary queries oracles in at most times, we denote the probability that chooses uncorrupted tags for querying Test and then correctly guesses by with being given the identifier of . We also denote the advantage that infers which of and is chosen by . The tag is backward privacy if is negligible.
4. Brief Analysis for an ECC-Based Tag Ownership Transfer Scheme
Some tag ownership transfer schemes such as [18, 20, 26] are not based on public key encryption on tags. To achieve forward privacy or backward privacy for tags, tag owner is required to run extra tag authentication sessions in an environment where adversaries cannot eavesdrop on the authentication sessions. Such requirements do not satisfy our model in which adversaries can always eavesdrop on the interactions between the tag and its reader, in addition to corrupting the tag after the ownership transfer.
To guarantee security and privacy, a few tag authentication protocols [27, 39–41] are based on tags that support public key encryption, and to the best of our knowledge, the authors of [17] presented a complete ownership transfer scheme based on tags supporting ECC. We briefly analyze this scheme as follows and demonstrate that it is not forward privacy under our definitions.
This ownership transfer scheme consists of four subprotocols: tag key change protocol (P1), tag key update protocol (P2), ownership transfer protocol (P3), and controlled delegation protocol (P4); however, the authentication protocol between reader and tags is not given. Before the current owner (e.g., ) transfers the tag to the new owner (e.g., ), first launches P1 to refresh the information inside and then runs P3 to transfer the ownership of to . Finally, launches P2 to update the information inside .
Under Definition 1, after querying the oracles in at most times, a -adversary chooses two corrupted tags for querying Test and then guesses a bit . However, since can corrupt to get its secret key , and is not updated throughout the whole ownership transfer process, can always correctly guess the value of.
Under Definition 2, after querying Test, the adversary will guess a bit , provided that the secret key is given. Yet it is unclear whether or not can link to the previous transcripts that authenticates to its reader, because the authentication protocol is not given in [17]. In other words, it is not ensured whether or not can infer from the previous authentication information.
5. The Proposed Tag Ownership Transfer Scheme
Motivated by the slightly higher performance tags like [42, 43] that support public key encryption, we propose a tag ownership transfer scheme in this section. This scheme consists of a mutual authentication protocol (AP) and an ownership transfer protocol (TP). We demonstrate it is both forward privacy and backward privacy under our model and give the security analysis in Appendix.
We suppose the database DB of the back-end server stores for each tag as well as the information of the products that are labeled by tags, and DB is integrated into the reader . stores its identifier and its reader’s public key . In the following sections, we first describe the mutual authentication protocol and then the tag ownership transfer protocol.
5.1. The Mutual Authentication Protocol
This protocol provides mutual authentication for the reader and tags; we give the details in Figure 1 and the interpretation as follows.(1) first sends a nonce and an access command query to .(2)Upon receiving and query, selects another nonce and responds with .(3)Upon receiving , decrypts it to get . If does not hold, interrupts this process. If holds, then retrieves in its DB. If both and hold, assigns another nonce to the variable . Otherwise, assigns the hash value to and updates with if equals . also updates with the value . Finally, sends back to .(4)Upon receiving , if holds, updates with the value ; namely, .
5.2. The Tag Ownership Transfer Protocol
This protocol transfers ’s ownership from the current owner of to the new owner of . Before the transfer process, and should authenticate to each other and setup a secure channel, and then sends , and the other information of to .
After finishing the ownership transfer process, ’s identifier is updated with a new value which is shared with , and the public key stored in is replaced with ’s public key; Figure 2 shows the details.(1) first sends its public key , a nonce , and the access command change to .(2)Once receiving , and change, selects another nonce and assigns the value to and then sends to .(3)Upon receiving , decrypts it to get and then forwards to .(4)Upon receiving , decrypts it to get , , and . If holds, interrupts this process. If both and hold, assigns a nonce to a variable ; otherwise, assigns the value of to and updates with if equals . also updates with . Finally, sends back to (5)If is equal to , replaces with and updates with to successfully finish the transfer process.
5.3. Forward Privacy of the Proposed Scheme
According to Definition 1 of the proposed model, an -adversary obtains all the information of and queries oracles in in the first stage. selects two corrupted tags in the second stage to query Test and guess a bit with permission to corrupt .
First, there is no link between the identifier and the knowledge that obtains in the first stage, because the scheme employs the hash value of a nonce to update the tag’s identifier in authentication and ownership transfer process. Hence, cannot benefit from this stage to enhance his advantage to infer from and , except to guess with probability of .
Second, Test will return the transcripts () in the second stage; therefore can take advantage of these transcripts to guess in the following ways.(1)Decrypting to get the nonce and compare the hash value , with , respectively, in order to determine the value of . However, since does not hold the secret key , the probability that he decrypts with a random secret key is . In other words, the advantage that correctly guesses is in this way.(2)Inverting the one-way hash function to get the nonce from and then calculating and to compare the results with . However, as we all know, it is hard to invert one-way hash function so far, and the adversary can only guess the value of . Hence, the probability correctly guesses is in this way.
Third, after querying Test, can corrupt to obtain its identifier which is the hash value of and then invert this value (namely, ) to get . However, it is difficult to invert the one-way hash function, and can only guess a value as the input of the hash function. As a result, the probability that correctly guesses is .
Finally, the adversary could keep on corrupting in the future interactions between the tag and its reader. However, this does not help link to , because the hash value of secret nonce is employed to update the tag’s identifier in our scheme.
To sum it up, according to the proposed model the advantage that a -adversary attacks the forward privacy of the scheme is negligible.
5.4. Backward Privacy of the Proposed Scheme
Under Definition 2, a -adversary receives all the information of and queries oracles in in the first stage. selects two uncorrupted tags in the second stage for querying Test and then guesses a bit , provided the identifier is given.
Except for guessing with probability , can guess by the following ways.
(1) Inferring from the relation between the interaction transcripts that authenticates and the identifier :
queries Authenticate or Observe to get the authentication transcripts , (or , ). However, cannot gain from because is a ciphertext by the public key ; he can only guess the secret key with probability to decrypt . also cannot gain from by inverting the one-way hash function , except to guess with probability . Hence, in this way the probability that correctly guesses is negligible.
(2) Inferring from the test transcripts () as well as the identifier : However, is not related to () and , which is a hash value of a nonce. Moreover, is the result of the encryption for , and is the ciphertext of , , and . Hence, this information cannot contribute to the adversary to infer which of and is selected. In other words, can only infer from with negligible probability in this way.
Furthermore, since is the hash value of and a nonce, the probability that directly links to is negligible.
In summary, the advantage of the adversary attacking the backward privacy of the scheme is negligible according to the proposed model.
5.5. Privacy Comparison with Some Related Work
Recently, some tag ownership transfer schemes have been proposed; we compare the privacy property between those schemes and ours in Table 1 under the proposed model.
From the table, it can be seen that our scheme enjoys privacy property. Although the schemes proposed in [17, 18, 20, 26] are forward privacy and backward privacy under their model or their specific processes, which need extra steps to protect tag’s privacy, those schemes cannot achieve forward privacy and backward privacy under our model, because in our model adversaries are permitted to corrupt tags after tag ownership transfer. Moreover, our model does not need extra processes to protect tag’s privacy, and our scheme uses evolving hash value of secret nonce to update tag’s identifier after each authentication or ownership transfer.
5.6. Performance Comparisons
Since RFID reader and server support enough complex cryptographic primitives, we only analyze the computation cost on tag side and the communication cost for messages that tag sends and directly receives from reader side, and we suppose our scheme is based on ECC.
For the sake of fair comparison, we suppose an elliptic curve is defined on finite field , which needs 40 bytes and 20 bytes to store an elliptic curve point and an element in the field, respectively. We employ the hash scheme H-PRESENT-128 [44] with 128 bits’ (16 bytes) output. We also suppose the bit length of a random number is 4 bytes and suppose the length of a tag’s identifier is 12 bytes in compliance with the EPC (Electronic Product Code) Class-1 Generation-2 standard. The length of an access command sent by reader is negligible.
Comparisons of Communication Cost. Table 2 shows the comparison results of communication cost for some recently proposed tag ownership transfer schemes.
The results listed in the table show our scheme achieves better performance on communication cost, and we explain the results as follows. The tag ownership transfer process in [18] uses ElGamal encryption scheme to encrypt tag’s identification information, so we suppose the length of a prime number in the scheme is 20 bytes. The scheme in [20] runs the authentication protocol three times to finish a tag’s ownership transfer, and the protocol (denoted by P2) proposed in [26] will be executed twice to complete the ownership transfer for a tag, while our scheme just runs the ownership transfer protocol only once. To finish a tag’s ownership transfer, a tag in the scheme [17] receives 8 elliptic curve points and sends 4 elliptic curve points; hence it sustains the heaviest communication cost.
Comparisons of Computation Cost. We denote the running time of a scalar multiplication operation over an elliptic curve by Ecm and a hash function operation by Ha; Table 3 shows the computation cost on tag side for some recent ownership transfer schemes and ours.
Because our ownership transfer protocol TP aims at those tags supporting ECC, thus the computation cost on tag side is higher than those tags not supporting ECC [18, 20, 26]; however, the computation cost of the TP is superior to the schemes in [17], which is also based on ECC on tags.
6. Conclusions
The privacy leakage caused by RFID tags is an important issue and has drawn wide attention. Some studies focused on the privacy problem caused by authentications between reader and tags, and a few researches paid attention to the privacy problem caused by tag ownership transfer. Yet few of them take the malicious owner into account or use formal methods to analyze the privacy leakage caused by tag ownership transfer.
In this paper, we propose a privacy model, which concentrates on the privacy problem caused by RFID tag ownership transfer. This model can be used to measure the privacy property of tag ownership transfer scheme, yet it cannot be directly applied to the authentications between reader and tags.
We also designed a tag ownership transfer scheme for the tags supporting public key encryption. According to the proposed model, we demonstrate our scheme enjoys both forward privacy and backward privacy. We also give the security analysis in Appendix. Upon comprehensive consideration on privacy protection, communication, and computation cost, our scheme is superior to those compared ones, and the implementation of this scheme would be our next work.
Appendix
Security of the Proposed Tag Ownership Transfer Scheme
We briefly analyze the security properties of the proposed scheme as follows.
Tag Impersonation Resistance. Note that almost all the RFID authentication protocols (including our scheme) keep tag’s identifiers as secrets in order to prevent malicious parties from tracking tags.
For the AP of our scheme, upon intercepting the first-round message of a reader querying a tag , an adversary should respond to the reader with the second-round message. However, cannot correctly compute the second-round message without knowing the identifier , unless he guesses an identifier, while the probability that correctly guess the value of is , which is negligible. Moreover, after each successful authentication process, a tag’s identifier will be updated with a hash value of a nonce concatenating the tag’s previous identifier.
We can use the same way to analyze tag impersonation resistance of the TP. Without knowing tag’s identity, the probability that adversaries correctly respond with the second-round message is , which is negligible.
Reader Impersonation Resistance. According to the specification of AP, a reader will first send a nonce along with a command to a tag to launch a new session. Once receiving the first-round message, the tag generates another secret nonce and responds to with ciphertext . It is obvious that an adversary cannot correctly decrypt this ciphertext without knowing the reader’s secret key sk in order to get . Hence, he cannot correctly respond to the tag with the last round message, which is a hash value directly related to . In other words, if an adversary tries to impersonate a reader, the verification for the last round message by tag will be failed.
The similar analysis can be applied to the reader impersonation resistance of our TP. To sum up, without knowing reader’s secret key, adversaries cannot correctly compute the last round message to pass the verification of the tag, except with negligible probability.
Replay Attack Resistance. The authentication sessions of the AP in our scheme are initiated by RFID reader, and our AP employs a secret nonce and an evolved identifier to compute the second-round message and the third-round message . For readability of analysis, we denote the nonce and tag’s identifier in the session and session by , and , , respectively, and denote the exchanged message in the session and session by , and , , respectively. We suppose the current session is , and an adversary has obtained the old message and .
Firstly, can replay to a reader . Upon receiving , decrypts it to get the nonce ; however, the verification for the value of by will be failed, because initiates the current session with other than .
Secondly, can replay to the tag . Once receiving , verifies whether it is equal to ; it is obvious that the verification will be failed because is the hash value of other than the hash value of .
For the TP of our scheme, adversaries also cannot replay old messages in order to pass the verification of the reader/tag. On one hand, if he replays an old message to a reader , after decrypting , gets and forward to a reader . However, once decrypts to get the value (which is not equal to the value that has sent to the tag in the current session), the verification for by will be failed. On the other hand, if an adversary replays an old message to a tag, the verification for will be failed because the current nonce that the tag generates is not .
Desynchronization Attack Resistance. In our scheme, the back-end database stores two identifiers for each tag. One is , which is the latest synchronization identifier between the reader and the tag. The other is , which is computed by the reader in the latest authentication process.
In a new session, if an adversary blocks the third-round message of the AP (or the fourth-round message of the TP) to desynchronize a reader with its tag, the reader can always recover synchronization with its tag in the next session using the old identifier .
Man-in-the-Middle Attack Resistance. For the AP, the second-round message sent by a tag is encrypted with its identifier, the nonces and . If an adversary intercepts this message and replaces it with another one to respond to a reader, the process that the reader identifies the tag will be failed with overwhelming probability. In other words, without knowing the secret identifier of a tag, an adversary cannot successfully launch the Man-in-the-Middle attack. Moreover, the third-round message that a reader sends to a tag is a ciphertext of a nonce and the tag’s identifier; without knowing the tag’s identifier, the adversary cannot generate a valid message to pass the verification of the tag.
For the TP of our scheme, the second-round message sent by a tag is also a ciphertext related to the secret identifier of the tag. Without knowing the tag’s identifier, adversaries cannot compute a valid message to pass the authentication of the reader.
In summary, both AP and TP resist to the Man-in-the-Middle attack because secret identifier is employed to generate the exchanged messages.
Notations
| , , : | The reader controlled by the owner , by owner and in a general sense, respectively. |
| , : | A tag with identifier id and at the time point . |
| , : | The secret key and public key of . |
| , : | The secret key and public key of . |
| sk, pk: | The secret key and public key of . |
| , , : | ’s secret key, identifier, and the identifier at time respectively, which are stored in . |
| , : | The set that consists of tags authenticated by and , respectively. |
| , , DB: | The database integrated in , and respectively. |
| , : | Secret key and identifier of the tag , which are stored in the database DB. |
| , : | The current identifier and the previous identifier of respectively, which are stored in DB. |
| τ: | Interactive information like the transcripts of authentication process or ownership transfer process between reader and tags. |
| −: | The unknown information. |
| result: | The result that a reader authenticates a tag, and 1 indicates the tag is accepted by the reader, or otherwise 0. |
| String concatenation. | |
| ←, →: | Assigning the right value to the left variable and returning the left value, respectively. |
| , : | The equal relationship and the operation that randomly selects an element from a finite set. |
| : | The security parameter which is the length of a secret key. |
| , : | The length of a tag’s identifier and the length of a nonce, respectively. |
| : | One-way hash function with input message . |
| : | An encryption function with input message and secret key sk. |
| : | A decryption function for a ciphertext with public key pk. |
Competing Interests
The authors declare that they have no competing interests.
Acknowledgments
This paper is partially supported by the China Postdoctoral Science Foundation (no. 2016M602675) and by the Nature Science Foundation of Sichuan Province Education Department (no. 13ZB0127).