Abstract
Various radio-frequency identification standards and products have been designed to meet various market needs. To satisfy various requirements and integrate important features of existent standards, EPCglobal (2013/11) announced the new Gen2 standard called EPC Class 2 Generation 2 version 2. Even though inheriting the name Gen2, Generation 2 version 2 goes far beyond the features and functions of Generation 2 version 1. Generation 2 version 2 is a super set of several existent radio-frequency identification standards. It opens up great opportunities of novel radio-frequency identification applications that could not be implemented using conventional radio-frequency identification standards and products. In this article, we introduce the new standards and propose one new mutual authentication scheme which protects tags’ identifications. This scheme is the first radio-frequency identification authentication that could protect tags from unauthorized tracing and unauthorized identification using coming standard-based products. The analysis shows that the proposed scheme owns better performance than their counterparts in the multi-tag setting.
Introduction
Even though radio-frequency identification (RFID) is quite convenient and potentially powerful for identifying objects wirelessly, it is quite difficult to meet all the requirements of potential applications using existent standards and products. Various standards and products have been designed to meet various market needs. Some of them focus on security, for example, Mifare DESfire 1 in payment. Generation 2 version 1 (Gen2v1)2,3 focuses on long reading distance and high reading volume, but neglects the possible security threats; Gen2v1 has been widely applied in the inventory management and the supply chain management. Both the academia and the industry have devoted the efforts on improving the security of Gen2v1,4–27 but no promising results are available if the standards are not modified.
In 2013 November, EPCglobal 28 announced the new Gen2 standard called Generation 2 version 2 (Gen2v2). Even though Gen2v2 inherits the name Gen2, its functions and security features go far beyond those of Gen2v1. Gen2v2 is a super set of several existent RFID standards and can simultaneously satisfy high security requirements, long reading distance, and high reading volume requirement. Gen2v2, which is compatible to Gen2v1, introduces a new and flexible file management and a new security framework. The new file management facilitates flexible file management functions like flexible file-attribute setting and flexible access-privilege setting. The new security framework consists of several security-related and privacy-related commands, and developers can use these commands to support further cryptographic mechanism designs like authentication and key agreement.
However, the new standards are so powerful, flexible, but complicated, that the academia and industry professionals still cannot master it; therefore, important cryptographic mechanisms like authentication and key agreement are seldom discussed and are still missing in the standards, even though the standard organizations plan to ratify the key agreement algorithms. This hinders and slows down the applications and promotion of the new standards.
Among the very few publications, Huang and Chien 29 discussed the implementations of typical RFID applications using Gen2v2 file commands and the user memory configuration. Engels et al. 30 proposed several Gen2v2-based mutual authentication schemes. Two of them are based on advanced encryption standard (AES)-cipher block chaining (CBC) and AES-output feedback (OFB) encryption modes, 31 respectively. AES is highly possible to be ratified as the encryption standard for Genv2. Engels et al. 30 also analyzed the resistance of the new standards against possible timing-based attacks like replay attacks and man-in-the-middle attacks (MITM). Their results show that the tight communication timings specified in the Gen2 protocol mitigate timing-based attacks; however, the loose timing implementations on commercial readers and the limited timing enforcement on tags lessen the effectiveness of the specified timing constraints. They highlighted that using the delayed response of the new Gen2 security functionality creates new vulnerabilities to timing-based attacks.30,32
Chien 33 reported that Engel et al.’s AES-CBC-based scheme and AES-OFB-based scheme are vulnerable to tag impersonation attacks, even if the schemes do not use the delayed responses. Chien also proposed two improved schemes to conquer the weaknesses. The improved schemes require a reader to issue two Authenticate commands and to use the delayed response, when it receives the first Authenticate command. This arrangement has two implications: one is that the tag has to use the delayed response which might increase the vulnerabilities to relay attacks and MITM, and the other is that the design did not leverage the potential of Gen2v2 commands to achieve high efficiency when we consider the multi-tag authentication scenarios. As some of the potential applications of Gen2v2 need high reading speed and high reading volume, it is desirable to further enhance the efficiency of Gen2v2 authentications.
RFID authentication with tag-identity protection is one of the important RFID cryptographic mechanisms, and there are many publications addressing this challenge. However, none of these publications could be successfully implemented using any conventional-standard-based RFID products. It is because all the conventional-standard-based products all transmit some kinds of identities (e.g. the electronic product code (EPC) and the tag identifier (TID) in the Gen2v1, the identification in the block 0 in Mifare card, 34 and the unique identification number (UID) in the ISO 15693 standard 34 ), despite how the upper-level authentication protocols work. These identities could be used by any readers (even unauthorized ones) to trace or identify a tag. Fortunately, the Gen2v2 security framework opens up great opportunities of implementing RFID authentication schemes that can protect tags’ identities from any unauthorized parties.
In this article, we introduce the new Gen2v2 standards, and then propose a new mutual authentication scheme which fully leverages Gen2v2 commands’ potential to achieve highly efficient authentication and protects tags’ identities. The rest of this article is organized as follows. Section “Preliminaries of Gen2v2 and the security framework” introduces Gen2v2. Section “New efficient authentication for Gen2v2 with tag-identity protection” proposes a new Gen2v2 authentication scheme with tag-identity protection. Section “Performance evaluation” evaluates its performance. Finally, section “Conclusion” draws our conclusions.
Preliminaries of Gen2v2 and the security framework
Even though Gen2v2 is literally a successor of Gen2v1, its positioning at the RFID ecology in terms of computing capacities and securities goes far beyond the scope of Gen2v1. AES or other encryption algorithms are deemed as desirable capacities of tags when manufactures implement the Gen2v2 security framework. In this section, we give some preliminaries on Gen2v2, its security framework.
Memory
Gen2 (both the version 1 and the version 2)2,3,28 is a passive tag standard. It communicates at an ultra-high frequency (UHF) band of 860–960 MHz. Its communication ranges from 2 to 10 m. A Gen2 tag supports a 16-bit pseudo-random number generator (PRNG), the 16-bit cyclic redundancy code (CRC), and the bitwise XOR. Moreover, it can optionally implement a 32-bit access password to prevent unauthorized data writing into tags and a 32-bit kill password to disable tags. The memory of a Gen2 tag is divided into four banks: the user memory (Bank11), the TID memory (Bank10), the EPC memory (Bank01), and the reserved memory (Bank00). A Gen2v2 tag has the same memory organization (Bank00, Bank01, Bank10, and Bank11) as that of Gen2v1, but Gen2v2 further enriches its memory banks’ fields and functions.
Figure 1 shows the memory banks of a Gen2v2 tag. Among many new features, we introduce some critical ones related to our discussion. The EPC bank contains a StoredCRC, a StoredPC, an EPC, and the optional first and second XPC words. The StoredCRC is a 16-bit cyclic redundancy check protecting the integrity of the EPC write operation and the update operation. The StoredPC consists of several flag bits of which the L flag defines the length of the EPC to be backscattered. The XI flag indicates whether the optional XPC_W1 is implemented. The EPC might be one of the GS1 EPC Tag Data Standard codes and the ISO/IEC 15962:2013 codes. 35 If the GS1 EPC is adopted, the code includes a company prefix, an item reference, and a serial number. The XPC_W1 word and the XPC_W2 word are optional. The U flag (the Untraceable indicator) in the XPC_W1 word indicates whether the tag implements the Untraceable command and whether the reader asserts the U flag. The TID bank contains one ISO/IEC 15963 class-identifier value and encodes the rest of this bank according to this class-identifier. The content of the encoding contains the information for readers to uniquely identify a tag and the features it supports.

Gen2v2 memory.
The User Bank can be organized as zero, one, or more files. The file management allows users to define the types, the sizes, and the access rights of the files. The first file is called File_0 and it is always readable. The file management commands include FileOpen, FileList, FileSetup, and FilePrivilege.
Operation flow and commands
The operations of readers and Gen2v2 tags consist of three phases—the Select phase, the Inventory phase, and the Access phase. The phases, the corresponding commands, and the states are depicted in Figure 2, and a typical and simplified flow of singulation is depicted in Figure 3. The process of singulation starts from a reader issuing a Select command to a population of tags, where those matched tags enter into their Ready state. The matching is based on the parameters specified in the Select command, for example, the parameter MemBank specifies which memory bank of a tag to be matched with the parameter Mask. In the Select phase, a reader may issue optional Challenge commands to instruct multiple tags to simultaneously, yet independently, pre-compute and store a cryptographic value or values in their buffers, according to the specified Cryptographic Suite Indicator (CSI).

Reader/tag operations and tag states in Gen2v2.

Simplified diagram of singulation for Gen2v2.
In the Inventory phase, the reader issues a series of Query, QueryAdjust, QueryRep, ACK, and NAK commands to singulate each selected tag by identifying its identification—the EPC. The Inventory phase starts from the reader issuing a Query command and possible multiple QueryRep commands and/or QueryAdjust commands in Step 3. A selected tag randomly and independently chooses and replies a 16-bit number (called RN16) and the tag enters into the Reply state in Step 4. To uniquely respond to each tag’s reply, the reader issues an ACK command with the received RN16 in Step 5, and then the tag backscatters its EPC (or a truncated EPC) in Step 6.
At the end of the Inventory phase, the reader derives the EPC of each tag, and then the reader issues a Req_RN command to initiate a singulated tag into the Access phase. Upon receiving a Req_RN command, a tag would backscatter a new 16-bit random number (called Handle) and the reader will use this Handle in the Access phase. In the Access phase, the reader may issue a series of Req_RN, Read, Write, BlockRead, BlockWrite, Access, Lock, Access, Kill, Authenticate, ReadBuffer, AuthComm, SecureComm, Untraceable, and so on. These commands can be classified into several groups: the memory access group, the file access group, and the security-and-privacy group. Depending on the execution of the issued command, a tag may stay in one of its possible states (Figure 2).
The Gen2v2 protocol also defines the timing. T1 defines the timing between a reader’s command and the response from a tag, and T2 defines the timing between one tag’s response and the next command from a reader. Interested readers are referred to EPCglobal Inc. 2 and ISO/IEC 18000-6:2010 3 for details.
Security framework
Gen2v2 introduces a new security framework which provides several security-privacy-related commands and a new file management framework that supports flexile file management in the User memory bank. The new Gen2v2 security framework adds six optional commands that may be used with a cryptographic suite:28,30Challenge, Authenticate, ReadBuffer, SecureComm, AuthComm, and KeyUpdate. The goal of these commands is to provide further developments of cryptographic mechanisms and cryptographic suites. The KeyUpdate command allows for the explicit changing of cryptographic keys. Contrary to the defaulted T1 period, the new security framework allows a tag which takes an extended period of time (called delayed response) to complete its operations. Note that Engels et al.’s timing analysis shows that strict timing restriction would better resist timing-based attacks. 30 A tag requiring a significant amount of time to complete its operations will beacon a “busy signal” at least every 20 ms to indicate to the reader that it is still computing its result. A tag, instead of communicating its response directly to the reader, may write its result to a response buffer and, after doing so, indicates to the reader that it is finished. The reader can read the contents of this buffer through a ReadBuffer command. The Challenge command is a broadcast command that contains fields to specify which cryptographic suite to be used and contains a message that is to be interpreted according to the specified cryptographic suite. The Authenticate command is a singulated command that contains fields for the reader to specify which cryptographic suite to be used and contains a message that is to be interpreted according to the specified cryptographic suite. The SecureComm command is a singulated command that contains a secure message that is being communicated to the tag; this message will typically be a command that is encrypted and authenticated according to the cryptographic suite that is established during the authentication process. The AuthComm command is a singulated command that contains an authenticated message that is being communicated to the tag. The ReadBuffer command is a singulated command to retrieve the content of the response buffer within a tag.
The Untraceable command allows a reader with an asserted Untraceable privilege to instruct a tag to (a) alter the L and U flags in its EPC memory, (b) hide its memory from readers with a de-asserted Untraceable privilege, and/or (c) reduce its operating range for all readers. The U flag indicates whether the Untraceable flag is on or off, and the L flag indicates the length of the EPC that a tag backscatters in response to an ACK command.
New efficient authentication for Gen2v2 with tag-identity protection
To meet the high reading speed and high reading volume requirement of Gen2v2, a new design approach is adopted; here, we leverage the potential of Gen2v2 commands by letting readers broadcast their challenges as soon as possible. The main idea of improving the communication is that the reader broadcasts its challenge
Gen2v2 not only provides a security framework to implement mutual authentication schemes but also provides the opportunities of implementing authentication schemes with tag-identity protection using coming commercial Gen2v2-based products (as the Untraceable command and security-related commands are optional in the standards, the available Gen2v2-based tags36,37 do not implement the Untraceable command). Even though there are many publications addressing RFID anonymous authentication schemes, these designs could not be successfully implemented using the conventional-standard-based RFID products. It is because all the conventional-standard-based RFID products all transmit some kinds of fixed identities, despite how the upper-level authentication protocols work. Fortunately, the Gen2v2 security framework opens up great opportunities of implementing RFID authentication schemes with tag-identity protection, and we need to carefully design the schemes by leveraging the potentials of the Gen2v2 commands.
Here, we propose one such scheme which leverages the potential of the Select command, the Challenge command, the ReadBuffer command, the SecureComm command, and the Untraceable command. The scheme can even achieve better performance when we consider the multi-tag setting. The main idea of protecting tags’ identities consists of four parts. First, an asserted reader (an authenticated reader with proper privileges) writes a tag’s pseudonym (PN) in File_0 and issues Untraceable commands to instruct tags to limit their responses to Ack commands and Read commands. Second, only an authenticated reader can update the pseudonym in a tag’s File_0. Third, to deter attackers from tracing a tag using non-updated pseudonyms, we let each tag to update its File_0 with the new value
Initialization
A server (a reader) initializes a shared key K with a tag and assigns a pseudonym (called PN) to the tag. It writes PN in File_0 and sets up File_0 with the specified file type and privileges. File_0 is writeable only by asserted readers and the tag itself according to the specified cryptographic suite. The server keeps the vector (PN, EPC, and K) for each tag in its database. An asserted reader then issues Untraceable commands to set the L flag to limit the length of the backscattered EPC, to assert the U flag, and to hide the TID bank from any de-asserted readers.
Authentication
The authentication process is depicted in Figure 4. When the reader issues a Select command, the Select command specifies the parameters MemBank and Mask to specify the potential tags. One implementation is to let Membank = 01 and Mask = the manufacture code of the EPC: this will limit those tags with the targeted manufacture code to be selected.

New efficient mutual authentication for Gen2v2 (Auth_Gen2v2_ID_Protect).
The reader then successively issues a Challenge[CSI,
In Step 6, the tag responds with (content of File_0,
The reader issues a ReqRN[
At this moment, the tag has enough time to complete the computation
The reader issues an Authenticate[handle,
In Step 13, the reader issues a SecureComm command which encapsulates a BlockWrite command with the parameter PN′ to update the content of File_0 of the tag. The tag verifies the SecureComm command and updates the content of File_0 if the verification succeeds.
Performance evaluation
Security analysis and computational performance
We first examine the security performance. In our scheme, a reader broadcasts its challenge
Corollary 1
The probability that an adversary successfully cheats in the authentication of the proposed scheme is
Proof
The security of our new scheme is based on the well-studied challenge-and-response technology. Both the reader and the tag need to compute
Regarding the protection of tags’ identities, we concern the privacy and the untraceability of a tag under the condition that adversaries could not successively capture a tag for its whole operational lifetime.
Corollary 2
An adversary could neither identify nor trace a tag in the proposed scheme.
Proof
Upon receiving Ack[RN16] in Step 5, a tag always responds with the content of its File_0. The content is either an updated PN or the value
Computational performance
Table 1 summarizes the security performance and the computational performance. In summary, our scheme does not require any delay replies and has better resistance to relay attacks and MITM attacks.
Comparison of Gen2v2-based key agreement schemes.
Communication performance
Next, we analyze the communication performance. We follow Engels et al.’s setting (which is described in the following two paragraphs and in Table 2) of analyzing the communication performance. In the setting, we neglect the possible Query_Rep commands and the possible QueryAdjust commands in the singulation process, and we assume that both readers and tags use the fastest available communication rate in the following figures. This setting would result in the estimated times being slightly smaller than the actual implementations; however, it will not downgrade the effectiveness of the following communication performance comparison.
Communication times (µs) for Gen2v2 commands.
The reader-to-tag communication rate ranges from 26.7 to 128 kbps. The tag-to-reader communication rate ranges from 5 to 640 kbps. A Preamble before a Query command requires 51.625–337.5 µs, and a Framesync before all other commands requires 34.375–112.5 µs. T1 is dependent on the communication rate used by tags and has values ranging from 15.625 to 250 µs. A typical UHF passive RFID tag has a 2 Mhz clock, and it would take 160 clock (80 µs) to complete one 128-bit AES encryption. 38
Based on the fastest rate, we list the estimated time for each command in Table 2 (which is an extension from Engels et al.’s 30 estimations). In the calculation in Table 2, we assume that a Preamble precedes a Query command, a Framesync precedes all other commands, a 6-bit TRPreamble precedes tags’ replies, and a 41-bit header is used in the delayed reply. Note that some of the figures in Table 2 are slightly different from the corresponding figures in Engels et al.’s tables because we differentiate the Authenticate commands with distinct message lengths, and different header lengths are adopted according to the newly published standards. 28 The slight differences do not change the effectiveness of the comparison.
We now estimate the communication times in a single-tag setting, where a reader selects a single tag in the process. Based on the figures in Table 2, Engels et al.’s AES-CBC-based scheme takes 4182.439 µs, Engels et al.’s AES-OFB-based scheme requires 4102.439 µs, and our scheme requires 4462.234 µs. We can see that the differences are insignificant.
We now examine the performance in a multi-tag setting, where a reader selects, invents, and authenticates multiple tags. Let n denote the number of tags in that process. In the calculation, we note that the Select command, the Challenge command, and the Query command are broadcast commands and they are broadcasted only once in the process. Then, the communication time is 385.9375+223.5+n*3573.001 µs for Engels et al.’s AES-CBC-based scheme, 385.9375+223.5+n*3493.001 µs for Engels et al.’s AES-OFB-based scheme, and 1295.313+223.5+n*2943.421 µs for our scheme. Table 3 lists the communication times for varying values of n in a multi-tag setting, and Figure 5 depicts the result.
Communication times (µs) in a multi-tag setting.

Communication times in a multi-tag setting.
According to the result, we can see that the differences of the communication times of these schemes are insignificant in a single-tag setting, but our scheme apparently out-performs Engels et al.’s schemes in the multi-tag setting. The improvements mainly result from the arrangement that a reader’s challenge
Conclusion
Previous publications on untraceable RFID authentication protocols only concern the security within the context of the proposed protocols and neglect the facts that the protocols could not be supported by existent standards; this results in that those proposed schemes have no way of being implemented using existent standards. This results in the fact that those proposed schemes have no way of being implemented using conventional standards. On the contrary, this study proposes a feasible, untraceable RFID authentication protocol that leverages the functions and the commands of the Gen2v2 standards to achieve its functions. The evaluation shows that the proposed scheme not only improves the securities but also improves the communication performance in the multi-tag setting. This pioneering work sheds a light on the study of untraceable RFID protocols that aim at achieving the security functions using existent standards and coming commercial standard-based products.
Footnotes
Academic Editor: Feng Hong
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 project was partially supported by the Ministry of Science and Technology, Taiwan, R.O.C., under grant no. MOST 105-2221-E-260-014.
