Efficient authentication scheme with tag-identity protection for EPC Class 2 Generation 2 version 2 standards

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.

Keywords

Security Internet of Things authentication radio-frequency identification anonymity EPCglobal

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¹ 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²⁸ 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²⁹ discussed the implementations of typical RFID applications using Gen2v2 file commands and the user memory configuration. Engels et al.³⁰ 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,³¹ respectively. AES is highly possible to be ratified as the encryption standard for Genv2. Engels et al.³⁰ 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³³ 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,³⁴ and the unique identification number (UID) in the ISO 15693 standard³⁴), 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.³⁵ 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.

Figure 1.

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).

Figure 2.

Reader/tag operations and tag states in Gen2v2.

Figure 3.

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.² and ISO/IEC 18000-6:2010³ 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.³⁰ 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 $RN 64_{R}$ in a Challenge command so that every selected tag in the communion range can immediately choose two random numbers $RN 64_{T}$ and $RN 64'_{T}$ , and starts to compute the response $AE S_{K} (RN 64_{R} | | RN 64_{T})$ and the temporary pseudonym $AE S_{K} (RN 64'_{T})$ . This arrangement has two important merits. One is that tags do not need to use any delayed replies when they are required to send their responses later, and this greatly increases the resistance to relay attacks and MITM attacks.³⁰ The other is that the system’s communication performance is greatly improved in the multi-tag environment.

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 tags^36,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 $Fla g_{unCom} | | RN 64'_{T} | | AE S_{K} (RN 64'_{T})$ each time a new request comes in; the content will be replaced later when an authenticated reader issues a SecureComm command. Fourth, upon receiving Ack commands, these tags only respond with the content of File_0 (either an updated pseudonyms (PN) or the value $Fla g_{unCom} | | RN 64'_{T} | | AE S_{K} (RN 64'_{T})$ . Those authorized readers can use the value to identify the tags and perform mutual authentication. The scheme consists of an initialization phase and an authentication phase as follows.

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.

Figure 4.

New efficient mutual authentication for Gen2v2 (Auth_Gen2v2_ID_Protect).

The reader then successively issues a Challenge[CSI, $RN 64_{R}$ ] command, a Query command, and several possible Query_Rep commands, where $RN 64_{R}$ in the Challenge command acts as a random challenge to the tags to generate their corresponding responses. CSI is the cryptographic indicator which indicates the specified cryptographic suite to be activated. Upon receiving the reader’s challenge $RN 64_{R}$ , the tag generates two 64-bit random numbers $RN 64_{T}$ and $RN 64'_{T}$ . This 64-bit $RN 64_{T}$ is organized as several parts: $RN 64_{T} \equiv RN 16 | | RN 64_{T, 17 - 48} | | handle$ , where $RN 16$ is a 16-bit random number, $RN 64_{T, 17 - 48}$ is a 32-bit random number consisting of bit 17 to 48 of $RN 64_{T}$ , and handle is a 16-bit random number. The tag starts to compute $C 128 \equiv C 128_{1 - 64} | | C 128_{65 - 128} = AE S_{K} (RN 64_{R} | | R 64_{T})$ and $AE S_{K} (R 64'_{T})$ , where $AE S_{K} ()$ denotes the AES encryption using the secret key K, $C 128_{1 - 64}$ denotes the 1–64 bits of $C 128$ , and $C 128_{65 - 128}$ denotes the 65–128 bits of $C 128$ . In the end of this inventory phase (Step 5, 6), the tag retrieves $RN 16$ from $RN 64_{T}$ and backscatters it to the reader, which responds with a ACK[ $RN 16$ ].

In Step 6, the tag responds with (content of File_0, $RN 64_{T, 17 - 48}$ ) to the reader. The content of File_0 could be either PN if the previous authentication is completed or the value $Fla g_{unCom} | | RN 64'_{T} | | AE S_{K} (RN 64'_{T})$ , where the flag $Fla g_{uncom}$ indicates that the previous authentication was not completed. If the previous session is completed, then the reader can use the updated PN to directly identify the tag; otherwise, the reader, based on the flag $Fla g_{uncom}$ , knows that the previous authentication is not completed and it has to try all possible tags to find a match with the value $RN 64'_{T} | | AE S_{K} (RN 64'_{T})$ .

The reader issues a ReqRN[ $RN 16$ ] command, and the tag responds its handle. Upon this moment, the reader concatenates $RN 16 | | RN 64_{T, 17 - 48} | | handle$ as $RN 64_{T}$ and computes $C 128 \equiv C 128_{1 - 64} | | C 128_{65 - 128} = AE S_{K} (RN 64_{R} | | RN 64_{T})$ .

At this moment, the tag has enough time to complete the computation $C 128 \equiv C 128_{1 - 64} | | C 128_{65 - 128} = AE S_{K} (RN 64_{R} | | RN 64_{T})$ which started when the tag received the challenge at Step 2. It stores $C 128_{1 - 64}$ in its buffer. The reader issues ReadBuffer[handle] and the tags respond with (handle, $C 128_{1 - 64}$ ). The reader verifies the received $C 128_{1 - 64}$ with its local one. If the verification succeeds, it authenticates the tag and computes the session key $K_{sess} = kdf (K, EPC | | RN 64_{T} | | RN 64_{R})$ , where kdf() is a key derivation function and it could be implemented using AES() or any secure hash functions. The reader also chooses a new pseudonym PN′ for the tag, and updates PN = PN′ in its database.

The reader issues an Authenticate[handle, $C 128_{65 - 128}$ ], and the tag verifies the received $C 128_{65 - 128}$ using its local one. If the verification succeeds, the tag completes the authentication of the reader and computes the session key $K_{sess} = kdf (K, EPC | | RN 64_{T} | | RN 64_{R})$ . It responds with either OK or Fail, depending on the result of the authentication.

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 $RN 64_{R}$ in its Challenge command so that every selected tag can immediately choose its random numbers and starts to compute the response. So, when the reader later issues a ReadBuffer command to read a tag’s buffer, the tag does not need to use the delayed reply. This arrangement can greatly improve the resistance to possible relay attacks and possible MITM attacks. However, Engels et al.’s schemes and Chien’s³³ scheme 1 require every selected tag to use the delayed reply because these tags start to compute their responses (AES encryptions) when they receive the reader’s first Authenticate command. According to the implementations,³⁸ the AES encryption would require four times larger than the minimum T1 window;³⁰ therefore, Engels et al.’s schemes and Chien’s³³ schemes need the delayed reply for replying the Authenticate command. Even though Engels et al.³⁰ claimed that a tag in their AES-OFB-based scheme might choose its random number $RN 64_{T}$ and start to compute the value $O_{1} = {Enc}_{K} (RN 64_{T})$ when a tag powers up, we find this claim does not hold because the first Authenticate command in their schemes is the earliest command that might use the CSI to activate the specified cryptographic suites, according to the recently published standards,²⁸ that is, when a tag is powered up by a Select command, it does not has the CSI to activate the cryptographic suite. It has the implication that our new schemes have better resistance to relay attacks and MITM attacks.

Corollary 1

The probability that an adversary successfully cheats in the authentication of the proposed scheme is $1 / 2^{k}$ , where k is the bit length of the required response.

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 $C 128 \equiv C 128_{1 - 64} | | C 128_{65 - 128} = AE S_{K} (RN 64_{R} | | RN 64_{T})$ , where $RN 64_{R}$ and $RN 64_{T}$ are, respectively, the challenges from the reader and the tag. The reader sends the last 64 bits of the computation to convince its partner of its authenticity while the tag sends the first 64 bits to convince its partner. The k is 64 in this setting. If the AES function is modeled as a random oracle, then the probability of cheating a partner is $1 / 2^{64}$ . The strength of the security could be easily enhanced to being compatible with the 128-bit AES, for example, let the reader compute and respond with $C 128 \equiv AE S_{K} (RN 64_{R} | | RN 64_{T})$ , and let the tag compute and respond with $\tilde{C} 128 \equiv AE S_{K} (RN 64_{T} | | RN 64_{R})$ . The k is 128 in this setting.

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 $Fla g_{unCom} | | RN 64'_{T} | | AE S_{K} (RN 64'_{T})$ . Since only an authenticated reader can update the PN and only the tag itself can update the value $Fla g_{unCom} | | RN 64'_{T} | | AE S_{K} (RN 64'_{T})$ , the value is random and fresh in each session, and attackers have no clue to identify or trace the tag.

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.

Table 1.

Comparison of Gen2v2-based key agreement schemes.

	AES-CBC-based scheme³⁰	AES-OFB-based scheme³⁰	Chien’s³³ scheme 1	Chien’s³³ scheme 2	proposed scheme
Tag anonymity to outsiders	No	No	No	No	Yes
Vulnerability to tag impersonation attack	Yes	Yes	No	No	No
Delayed replies required and possible vulnerability to relay attacks	Yes	Yes	Yes	No	No
Number of encryptions on tag	2	2	2	1	2

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.

Table 2.

Communication times (µs) for Gen2v2 commands.

Command	Command time (128 kbps)	Response time (640 kbps)
Select (Framesync+45 bits)	385.9375	No response
Query (Preamble+22 bits)	223.5	34.375
Ack (Framesync+18 bits)	175.000	259.375
Req_RN (Framesync+40 bits)	346.875	62.5 (handle+RN16)
Challenge (RT Framesync+48 bits)	909.375 (64-bit message)	No response
Authenticate (RT Framesync+64 bits)	534.375 (64-bit message)	73.438 (41-bit header) (41-bit header+192-bit message)
ReadBuffer (RT Framesync+64 bits)	534.375	160.983 (TR Preamble+33-bit header+64-bit message)
SecureComm (64-bit header+66-bit BlockWrite header+16-bit PN)	262.5

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.³⁸

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³⁰ 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.²⁸ 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.

Table 3.

Communication times (µs) in a multi-tag setting.

	n = 1	n = 100	n = 200	n = 300	n = 400	n = 500	n = 600	n = 700	n = 800	n = 900	n = 1000
Auth_Gen2v2_ID_Protect	4462.234	295,860.9	590,203	884,545.1	1,178,887	1,473,229	1,767,571	2,061,914	2,356,256	2,650,598	2,944,940
Engels AES-CBC	4182.4385	357,909.5	715,209.6	1,072,510	1,429,810	1,787,110	2,144,410	2,501,710	2,859,010	3,216,310	3,573,610
Engels AES-OFB	4102.4385	349,909.5	699,209.6	1,048,510	1,397,810	1,747,110	2,096,410	2,445,710	2,795,010	3,144,310	3,493,610

Figure 5.

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 $RN 64_{R}$ is sent via a Challenge command, which is a broadcast command.

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.

References

NXP Semiconductors. Smart solutions to smart services, http://www.nxp.com/documents/line_card/75016728.pdf (accessed 25 May 2015).

EPCglobal Inc. EPC™ radio-frequency identity protocols class-1 generation-2 UHF RFID protocol for communications at 860 MHz–960 MHz, version 1.2.0, October 2008, http://www.gs1.org/sites/default/files/docs/epc/uhfc1g2_1_2_0-standard-20080511.pdf

ISO/IEC 18000-6:2010. Information technology—radio frequency identification for item management–part 6: parameters for air interface communications at 860 MHz to 960 MHz (International Organization for Standardization, April 2011).

Aigner

Plos

Feldhofer

. Report on first part of the security WP: anti-cloning tag (D4.3.1). EU bridge project, 2008, http://www.bridge-project.eu/data/File/BRIDGE_WP04_tag_security.pdf

Alomair

Clark

Cuellar

. Securing low-cost RFID systems: an unconditionally secure approach. In: Proceedings of the workshop on RFID security (RFIDsec’10 Asia), Singapore, 22–23 February 2010. New York: ACM.

Chen

Lee

Zhao

. Enhancement of the RFID security method with ownership transfer. In: Proceedings of the international conference on ubiquitous information management and communication, Suwon, Korea, 15–16 January 2009, pp.251–254. New York: ACM.

Chien

Chen

CH.

Mutual authentication protocol for RFID conforming to EPC Class 1 Generation 2 standards. Comput Stand Inter 2007; 29: 254–259.

Chien

HY.

SASI: a new ultralightweight RFID authentication protocol providing strong authentication and strong integrity. IEEE T Depend Secure 2007; 4(4): 337–340.

Avoine

Dysli

Oechslin

Reducing time complexity in RFID systems. In: Proceedings of the 12th annual workshop on selected areas in cryptography (SAC), Kingston, ON, Canada, 11–12 August 2005. Berlin: Springer.

10.

Choi

Lee

Lim

JI.

Anti-cloning protocol suitable to EPCglobal Class-1 Generation-2 RFID systems. Comput Stand Inter 2009; 31(6): 1124–1130.

11.

Duc

Park

Lee

. Enhancing security of EPCglobal Gen-2 RFID tag against traceability and cloning. In: Proceedings of the symposium on cryptography and information security, Hiroshima, Japan, 17–20 January 2006, pp.17–20. Berlin: Springer.

12.

Yang

MH.

Secure multiple group ownership transfer protocol for mobile RFID. Electron Commer R A 2012; 11(4): 361–373.

13.

Henrici

Müller

. Hash-based enhancement of location privacy for radio-frequency identification devices using varying identifiers. In: Proceedings of the 2nd IEEE annual conference on pervasive computing and communications, workshops (PerCom2004), Orlando, FL, 14–17 March 2004, pp.149–153. New York: IEEE.

14.

Kim

Choi

Lee

. Secure EPCglobal Class-1 Gen-2 RFID system against security and privacy problems. In: Proceedings of the OTM 2006 workshops, vol. 4277 (Lecture notes in computer science), Montpellier, 29 October–3 November 2006, pp.362–371. Berlin: Springer.

15.

Juels

Strengthening EPC tag against cloning. In: Proceedings of the ACM workshop on wireless security (WiSe), Cologne, 2 September 2005, pp.67–76. New York: ACM.

16.

Lee

Asano

Kim

. RFID mutual authentication scheme based on synchronized secret information. In: Proceedings of the symposium on cryptography information security, Hiroshima, Japan, 17–20 January 2006. Berlin: Springer.

17.

Lin

Chang

. Cryptanalysis of an EPC Class-1 Generation-2 RFID authentication. In: Proceedings of the information security conference 2007, Chiayi, Taiwan, 07–08 June. Chinese Cryptology and Information Security Association.

18.

Melia-Segui

Garcia-Alfaro

Herrera-Joancomarti

. Analysis and improvement of a pseudorandom number generator for EPC Gen2 tags. In: Sion

Curtmola

Dietrich

. (eds) Financial cryptography and data security, vol. 6054 (Lecture notes in computer science). Berlin: Springer, 2010, pp.34–46.

19.

Molnar

Wagner

Privacy and security in library RFID: issues, practices, and architectures. In: Proceedings of the 11th ACM conference on computer and communications security (CCS ’04), Washington, DC, 25–29 October 2004, pp.210–219. New York: ACM Press.

20.

Ohkubo

Suzuki

Kinoshita

. Cryptographic approach to “privacy-friendly” tags. In: Presented at the RFID privacy workshop, MIT, Cambridge, MA, 15 November 2003.

21.

Park

Kim

. A practical approach for enhancing security of EPCglobal RFID Gen2 tag. In: Proceedings of the future generation communication and networking, Jeju-Island, Korea, 6–8 December 2007, pp.436–441. New York: IEEE.

22.

Song

Mitchell

. RFID authentication protocol for low-cost tags. In: Proceedings of the 1st ACM conference on wireless network security, Alexandria, VA, 31 March–2 April 2008, pp.140–147. New York: ACM.

23.

Tsudik

YA-TRAP: yet another trivial RFID authentication protocol. In: Proceedings of the 4th annual IEEE international conference on pervasive computing and communications workshops, Pisa, 13–17 March 2006, pp.640–643. New York: IEEE.

24.

Yamamoto

Suzuki

Hada

. A tamper detection method for RFID tag data. In: Proceedings of the IEEE international conference on RFID, Las Vegas, NV, 16–17 April 2008, pp.51–57. New York: IEEE.

25.

Yang

Park

Lee

. Mutual authentication protocol for low-cost RFID. In: Proceedings of the handout of the encrypt workshop on RFID and lightweight crypto, Graz, 2005. Austria: Graz University of Technology.

26.

Lee

C-F

Chien

H-Y

Laih

C-S

. On the security of several Gen2-based protocols without modifying the standards. J Chin Inst Eng 2012; 35(4): 391–399.

27.

Jin

Y-M

Sun

H-P

Xin

. Lightweight RFID mutual authentication protocol against feasible problems. In: Proceedings of the 13th international conference (ICICS 2011), Beijing, China, 23–26 November 2011, pp.69–77. Berlin: Springer.

28.

EPCglobal Inc. EPC™ radio-frequency identity protocols generation-2 UHF RFID specification for RFID air interface protocol for communications at 860 MHz–960 MHz (version 2.0.0 ratified), November 2013.

29.

Huang

T-Y

Chien

H-Y.

Gen2v2-security-and-privacy-features-leveraged application designs. In: Proceedings of the 2014 9th Asia joint conference on information security (Asia JCIS), Wuhan, China, 3–5 September 2014. New York: IEEE.

30.

Engels

Kang

Wang

J-Y

. On security with the new Gen2 RFID security framework. In: Proceedings of the IEEE international conference on RFID, Orlando, FL, 30 April–2 May 2013. New York: IEEE.

31.

National Institute of Standards and Technology (NIST). Advanced encryption standard (AES): federal information (Processing standards publication 197, 26 November), 2001, http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

32.

Hancke

Kuhn

MG.

An RFID distance bounding protocol. In: Proceedings of the IEEE 1st international conference on security and privacy for emerging areas in communications networks, 2005 (SecureComm 2005), Athens, 5–9 September 2005, pp.67–73. New York: IEEE.

33.

Chien

H-Y.

New Gen2v2-based mutual authentication schemes. In: Proceedings of the 8th international conference on software security and reliability (SERE2014), San Francisco, CA, 30 June–2 July 2014. New York: IEEE.

34.

ISO/IEC FCD 15693-3:2009. Identification cards—contactless integrated circuit(s) cards—vicinity cards—part 3: anti-collision and transmission protocol.

35.

ISO/IEC 15962:2013. Information technology—radio frequency identification (RFID) for item management—data protocol: data encoding rules and logical memory functions.

36.

NXP. SL3S1204: UCODE^® 7, http://cache.nxp.com/documents/data_sheet/SL3S1204.pdf?fsrch=1&sr=6&pageNum=12017/02/24access

37.

NXP. UCODE DNA: a breakthrough in UHF security, http://www.themobileknowledge.com/sites/default/files/UCODE%20DNA%20-%20a%20breakthrough%20in%20UHF%20security_1.pdf

38.

Hamalainen

Alho

Hannikainen

. Design and implementation of low-area and low-power AES encryption hardware core. In: Proceedings of the 9th Euromicro conference on digital system design: architectures, methods and tools (DSD 2006), Dubrovnik, 30 August–1 September 2006, pp.577–583. New York: IEEE.