Abstract

RFID technology has become popular in many applications; however, most of the RFID products lack security related functionality due to the hardware limitation of the low-cost RFID tags. In this paper, we propose a lightweight mutual authentication protocol adopting error correction code for RFID. Besides, we also propose an advanced version of our protocol to provide key updating. Based on the secrecy of shared keys, the reader and the tag can establish a mutual authenticity relationship. Further analysis of the protocol showed that it also satisfies integrity, forward secrecy, anonymity, and untraceability. Compared with other lightweight protocols, the proposed protocol provides stronger resistance to tracing attacks, compromising attacks and replay attacks. We also compare our protocol with previous works in terms of performance.

1. Introduction

RFID (radio frequency identification) is a technique used for identifying objects via radio frequency. It has become very popular in many applications such as access control systems, supply chain management systems, transportation, ticketing systems, and animal identification. The global transaction of RFID system was US$2.65 billion in 2005 [1] and increased to US$5.56 billion in 2009 [2]. At present, RFID technology has become one of the fastest growing markets in radio communication industries.

The RFID systems are composed of three components: a set of tags, RFID readers, and one or more backend servers. A backend server is responsible for storing the related information of tags, calculating the computational processes when authenticates a tag; in addition, a backend server is usually with a more powerful computation ability than RFID reader and tags. An RFID reader (called a reader in this paper) can access the backend server via secure network channel and then acquire the information related to the tags. Generally, backend servers and readers are treated as a whole entity since they are usually connected with each other through a wired line. RFID tags are small electronic devices composed of antennas, microprocessors, and memory storages. A tag can communicate with a reader by using radio frequency signals transmitting from the reader. Normally, RFID tags can be classified into three types: active tag, semiactive tag, and passive tag. Active tags contain batteries that can actively communicate with the readers. Semiactive tags also have batteries, but they will remain silent until they receive query from a reader. Passive tags contain no battery, and their energies come from the reader’s radio signals through antennas. Regarding the cost of the tag, the active and semiactive tags are expensive and each costs about US$20, while the passive tags are usually considered as low-cost RFID tags which cost about US$0.05 each. Since RFID tags usually play the roles as tickets or ID cards, most of the RFID-tagged products are small and portable, and people carry them in their daily life. For example, the e-passports combine traditional paper passports and embedded RFID chips which contain personal biometric information. They are carried by travelers from over 60 countries in the world.

While RFID technology offers convenience, security and privacy issues are still the number one concern of most RFID applications today. Since an RFID tag can be continuously scanned within a 10 meter radius, the tag carrier’s location can be easily traced without awareness; thus privacy becomes an important issue in RFID applications. Moreover, RFID tags may contain sensitive information about the carrier in which the information should not be revealed to anyone, especially to an attacker. In other words, tags should first authenticate the reader’s validation before sending private data. Meanwhile, readers should also be able to authenticate tags to prevent counterfeit tags.

To address these problems, researchers have proposed many RFID protocols to achieve mutual authentication, untraceability, and other security requirements. However, with limited computational ability and insufficient memory storage on its embedded chip, low-cost RFID protocol design still remains a challenge. Previous studies showed that the number of logic gates available for security functionality on a low-cost RFID tag is 400 to 4000 [3], which is not enough to implement most public key or symmetric key cryptosystems. Therefore, an RFID protocol should be as computationally lightweight as possible.

In this paper, we propose a lightweight mutual authentication protocol based on error correction codes to provide a secure RFID mechanism. More specifically, our protocol provides mutual authenticity and untraceability to protect the security and privacy of tag carriers. We also present an evaluation on the security and performance level of our proposed protocol. Compared to other previous works, our protocol not only meets the fundamental security requirements but is also lightweight enough to be implemented on low-cost RFID tags.

The rest of this paper is organized as follows. Section 2 reviews the related works of RFID protocols. Section 3 describes a brief introduction of the error correction codes used in this paper. Our proposed RFID mutual authentication protocol is presented in Section 4. In Section 5, we analyze the security constraints of our protocol, followed by an evaluation of the performance of our protocol in Section 6. Finally, a conclusion is given.

With the rapid growth of network technology, security issues have been a matter of concern in various network environments [412] such as wireless sensor networks, social networks, and Internet of Things. In the RFID environment, security and privacy issues also receive increasing attention recently.

There are many RFID protocols using one-way hash functions (e.g., [13, 14]) to perform their authentication process by hashing random challenges, tag identity, and/or secret key into one message. However, hardware implementations of hash functions such as SHA-1 and MD5 are generally considered too expensive to be implemented on low-cost RFID tags. However, literatures [3, 15] describe some of these implementation issues in which some of them proposed their lightweight hash functions that can be implemented on low-cost RFID tags. These lightweight hash functions include Tav-128 proposed by Peris-Lopez et al. [16], low-cost SHA-1 proposed by O’Neill [17], and H-PRESENT-128 proposed by Bogdanov et al. [18].

The RFID authentication protocol can be classified into 4 classes. The first class refers to those protocols that apply conventional cryptographic functions, such as symmetric encryption or public key algorithm. The second class refers to those protocols that apply random number generator and one-way hash function. The third class refers to those protocols that apply random number generator and cyclic redundancy code (CRC) checksum. The last one refers to those protocols that apply simple bitwise operations (such as XOR, AND, OR, etc.). Generally, the third class is treated as lightweight level. Although our protocol has to adopt one hash function, we can simply apply the lightweight hash functions mentioned in the previous paragraph to achieve the goal of lightweight computation. Hence, by applying those lightweight hash functions, we propose our lightweight RFID protocol.

Lightweight authentication protocols aim to achieve mutual authentication through simple operations like bitwise XOR and binary addition. In 2005, Juels and Weis proposed a multiround lightweight authentication protocol called HB+ [19], which is an improvement of HumanAut, a human-to-computer authentication protocol designed by Hopper and Blum [20]. Nevertheless, Gilbert et al. proved that the HB+ protocol is vulnerable to a man-in-the-middle attack [21]. There are currently many improvements of the HB+ protocol, for example, the HB++ protocol proposed by Bringer et al. in 2006 [22], the HB-MP protocol proposed by Munilla and Peinado in 2007 [23], and the HB# protocol proposed by Gilbert et al. in 2008 [24].

The EPCglobal Class 1 Generation 2 UHF Air Interface Protocol Standard (generally known as Gen2 standard) [25] is a standard that defines the physical and logical requirements of RFID systems. In Gen2 standard, an RFID tag maintains the computational abilities to perform simple bitwise operations, 16-bit cyclic redundancy checks (CRC) and 16-bit pseudorandom number generator (PRNG) function. In 2009, Sun and Ting presented the protocol [26] for Gen2 standard. In this protocol, each tag stores a string called key pool, which is shared with a backend server. protocol is appropriate for Gen2 standard; however, Burmester et al. demonstrated an attack to break this protocol in 2009 [27].

3. Preliminary

In information theory and coding theory of computer science, error correction code (ECC) is a technique that enables the communication parties to correct the transmission errors which are incurred by the channel noise. This technique has been studied over 50 years, and substantial coding algorithms are proposed. In the following, we provide a brief introduction to one of the subclasses of ECC, called a linear block codes; in addition, if a linear block code fulfills some properties, it will form a special case of linear block codes, called perfect code. We will have a short description of perfect code in the end of this section as well.

3.1. Linear Block Codes

During the transmission, the information source, or sender, will encode a -bit message blocks into -bit codewords by using channel encoding algorithm, where . There are total distinct messages and corresponding distinct codewords. These fixed length codewords are called a set of block codes and is denoted by . A block code is called linear block code if it satisfies Definition 1.

Definition 1. A block code of codewords of each -bit in length is called a linear block code if and only if these codewords form a -dimension vector subspace over the Galois Field .

Because a linear block code is a -dimension vector subspace, it is possible to find linearly independent codewords in that every codeword in is a linear combination of these codewords. We write these codewords into row vectors and form a matrix as follows: where for . For a message , the corresponding codeword can be computed as follows:

To decode a codeword, we first construct a matrix , which is composed of linearly independent rows such that any linear combination of rows in is orthogonal to the rows of . This implies that any codeword in generated by must satisfy the following property.

Definition 2. A vector is a codeword in generated by if and only if .

Let be the received message, where is the codeword and is the error vector incurred by the channel noise. For a received message , the receiver first computes a -bit vector called syndrome, which can be calculated as . If there is no error, the syndrome will be zero and the receiver recognizes that is the correct codeword. Nonetheless, if is nonzero, the receiver has to determine the error vector from . The methods to find the error vector are different according to each coding algorithm, but we can always put every possible error pattern into the computation, get the corresponding syndromes, and construct a lookup table for the receiver in advance. Once the receiver obtained an error vector, it can recover the original codeword by computing .

Hamming weight of a binary vector is defined as the number of 1 in the vector. We further define Hamming weight function Hw to be a function that returns the Hamming weight from an input vector. Hamming distance is the number of positions that two vectors differ from each other, denoted as Dis. For instance, let and be two binary vectors; then since they differ in the first, second, and fourth positions.

The error correcting ability of a linear block code depends on the minimum Hamming distance (denoted as ) of every two codewords. We denote as an error correction code where its codeword length, message length, and minimum Hamming distance are , , and , respectively. A code is capable of correcting all the error vectors which have the Hamming weight less than or equal to .

3.2. Perfect Code

For a code, there are codewords each with a -bit length, and each codeword might have errors that occurred in positions at most. Therefore, there will have total messages that can be corrected to be a valid codeword in . Typically, this number is no greater than the number of totally possible messages. If satisfies , it is called a perfect code. That is, every possible message can be corrected to be a valid codeword.

4. The Proposed Protocols

In this section, we propose a lightweight RFID authentication protocol. Our main idea is to provide a mutual authentication between reader and tag. Our protocol is designed for low-cost RFID tags; therefore, the requirement for implementing our protocol will not overload the capabilities of the tags. Besides, we also propose an advanced version of our protocol to provide key updating.

Our protocol is suitable for large scale RFID systems, such as ticketing systems, transportation systems, and supply chain systems. These applications are generally composed of millions of RFID tags and readers. More importantly, the proposed protocol is appropriated for the reader to find out a specific tag from a large group of tags. For example, an airport employee desires to find a specific RFID tagged luggage from a loaded cargo truck. The proposed scheme checks whether the specific tag is in this area. In these large scale systems, readers are normally held by authorized persons or are used under supervision. They can easily connect to servers and synchronize their data. The tags in these systems are generally carried by humans or attached to goods and baggage. They are frequently scanned by the valid readers, and, in some situations, the tags can be brought back to a secure check (e.g., the RFID tagged tickets can be recycled). Before introducing the proposed protocol, the notations used are presented in the Notation section at the end of the paper.

4.1. Initialization

Initially, the administrator generates a pseudorandom number generator , a one-way hash function , and a error correction code, with the generator matrix and the parity check matrix . Each tag, denoted as , , has its unique identifier. We also denote their identifiers as just for simplicity. For each tag , the backend server randomly generates secret keys . Let be a -bit long binary vector which is a possible syndrome pattern induced by . Each tag is assigned with a syndrome pattern . Then, stores the tags’ identifiers, and corresponding and in its database. Finally, writes , , , , , , and into the storage memory of tag in a secure environment (e.g., at RFID tags manufacturer). For every authorized reader, also writes , , , , , , and into their storage memory.

4.2. Authentication Protocol: Basic Version

The main objective of this protocol (Algorithm 1) is to establish a mutual authentication relationship between a reader and a specific target tag in a group of tags. Since the reader may receive a substantial amount of tags’ responses for a single query, our protocol adds a filtering mechanism based on error correction codes to prevent the reader from having to examine every responding message.

(1)      :  Compute = + , where
        
        Generate a random challenge
(2)  :   ,
(3)     :Compute =
        IF satisfies any pattern in
         Generate a random challenge
         Compute = + , where
         
         
        ELSE
         Set = random value
         Set = random value
(4)  :  
(5)      :  Decode
         IF   can be decoded
        Verify to authenticate
         IF is correct
        
         ELSE
          Set = random value
         ELSE
        Set = random value
        Ignore
(6)  : 
(7)     : Verify to authenticate

At the beginning, selects its target tag, , and retrieves the corresponding and from database. In step 1, randomly generates a codeword in , denoted as . Then generates an error vector with Hamming weight less than or equal to , which is the maximum error correcting ability of . Finally, computes the masked codeword by adding with . The error vector generated in this step must be selected carefully so that the syndrome derived from will equal the preassigned pattern .

In step 2, broadcasts a query to tags, along with a random challenge and the masked codeword . In Step 3, the tags attempt to decode with the parity check matrix and compute a syndrome . If a tag finds that is equal to the pattern stored in its storage memory, it randomly generates a codeword in and a challenge . Then computes a verifier message and the masked codeword , where is a random error vector with . Since is shorter than , should be padded before XORing with . For the other tags that cannot find in its preassigned pattern, the verifier message and masked codeword are set to a random value.

Finally, no matter what their preassigned syndromes are, the tags respond , , and to the reader in step 4. Note that the masked codeword is further masked with the key to prevent possible tracing attack.

In Step 5, authenticates by examining the received messages. First, uses to unmask (XOR with ) the received messages and tries to decode every masked codeword . If finds a codeword that cannot be decoded with the decoding algorithm, simply ignores it and proceeds to the next masked codeword. Since the nontarget tags will always generate uncorrectable masked codewords, this method will filter out all the unnecessary messages sent by the nontarget tags, which reduces the computational loads of . If one of these masked codewords sent by can be decoded, uses the stored secret keys , , , and to verify if the corresponding is sent from . If is correct, computes another verifier message . Since is shorter than , should be padded before XORing with . At this step, has authenticated to be the target tag . If either cannot be decoded or is incorrect, will not recognize as its target, so assigns a random value. Whether is the target tag or not, always sends to (step 6).

In step 7, verifies the received to authenticate . Only the target tag that has the key can accept as the valid message and authenticate by using , , , and . At this step, both and have authenticated each other.

4.3. Error Vector Selecting

As we stated before, the error vector generated by the reader must be selected carefully so that can derive a syndrome that equals the preassigned syndrome pattern . It is straightforward since the syndromes are originally used by decoding algorithms to find corresponding error vectors. That is, can simply use the decoding algorithm to find the corresponding error vector of a specific syndrome. This error vector is exactly the error vector that should be used to mask the codeword generated by in the first step.

4.4. Session Key

Typically, the reader and the tag would exchange data after completing the authentication process. These data are sometimes considered private; for example, the tag used in a hospital would contain the records of its carrier. The threat of eavesdropping attacks makes the tag carriers feel insecure about transmitting sensitive data. To address this problem, we construct a mechanism to establish a session key and use it to encrypt the sensitive data. We suggest that the reader and the tag use the session key to encrypt the messages. Without the secret key , the adversary cannot decrypt the session to break the encrypted messages.

4.5. Secret Key Update

The secret key should not be used permanently. In fact, if the key is compromised, the messages encrypted with this key are also compromised. Hence, both the probability of messages compromised and the probability of financial loss will increase with the length of time in which a key is in use. We think that the secret keys stored in the readers and the tags should update regularly. Previous works use two approaches to perform this updating procedure. One possible approach is to have tags carriers bring their tags back to an authorized institution so that the new keys can be written into the tags in a secure environment. Another approach is to have the tags use the one-way hash functions stored in them to calculate new keys by hashing the older one.

The first approach could be combined with our authentication protocol in some RFID systems like ticketing systems and supply chain systems, since the tags are generally returned to the backend server. The second approach is also adequate for our protocol. Both the tag and the reader can hash their current secret key into the new one after a successful authentication process. More precisely, the tag will update its secret key after verifying at step 7, and the reader will update its key before sending to the tag (step 6). We suggest the entities update the key by computing , where denotes the string concatenation operation. The new secret key is then assigned to this hashing value. Note that the session key construction process should be performed prior to updating the secret key.

If the tag does not receive the verifier message , the keys between the reader and the tag might be desynchronized. This means that next time this tag’s verifier message will be rejected by the reader. To address this problem, the reader should store the previous key before updating. Once the reader discovers that can be decoded but is incorrect, it can attempt to verify the message by using the older key. This mechanism can help the system resist desynchronization attacks.

4.6. Advanced Protocol: With Secret Key Update

Now we present a modification of our protocol with the secret key updating mechanism in it. The steps of the modified protocol are depicted in Algorithm 2. The terms and represent the current secret key and the previous secret key for . Note that the value stored in the tag may be either or . After a successful authentication process, the reader constructs the session key by using either or , depending on which key is used to authenticate the tag. And the tag constructs the session key by using . Then, the reader updates its secret keys by setting and , while the tag updates the secret key by setting .

(1)      :  Compute = + , where
        
        Generate a random challenge
(2)  :   ,
(3)     :  Compute =
        IF satisfies any pattern in
         Generate a random challenge
          = + , where
         
        ELSE
         Set = random value
         Set = random value
(4)    : 
(5)       : Compute
        Decode
         IF   can be decoded
        Verify by using
         IF is correct
        
        
         ELSE
         Verify by using
          IF is correct
          
          
         ELSE
         Set = random value and ignore
(6)  : 
(7)     : Verify to authenticate

Our protocol provides a convenient method for the tag and the reader to authenticate each other before exchanging data. Since the reader will receive many messages sent from other tags at the same time, our protocol uses the properties of error correction code to filter out the unnecessary messages. Therefore, the computational load of the reader is reduced. After mutual authentication, the relation between the reader and the tag is established. They will both update their secret keys to the new ones in order to defend against possible attacks. Furthermore, the two entities can also construct a session key to protect the message transmitted later.

5. Security Analysis

In this section, we show that our protocols fulfill the security requirements for RFID systems.

5.1. Mutual Authenticity

A reader can easily authenticate the tag’s identity since only the valid tag has the secret key needed to construct the correct verifier message. The random challenge sent by the reader prevents the attackers from pretending to be the target tag and thus it ensures reader-to-tag authenticity. Since the reader must authenticate itself to the server before retrieving any keying information from the server, the tag can trust the reader who has the correct secret key. In other words, tag-to-reader authenticity is achieved indirectly via server-to-reader authenticity.

5.2. Integrity

The integrity of the exchanged messages is guaranteed since the messages are encrypted by the session keys. The modification of these messages will produce meaningless plaintext, and both reader and tag can detect such modifications. During the authentication process, the adversary can also eavesdrop and modify the exchanged messages. Nevertheless, any modification on , , or will lead to an incorrect verifying result on either the reader or the tag. When an adversary attempts to modify the random challenge , the reader can still find the inconsistencies of and and thus reject the message. However, the modification of and cannot be discovered by the tags because these messages are independent. This modification causes the tags to produce incorrect responses. But since the modification on will change its underlying , all the verifier messages are invalid to the reader. These messages cannot be used to perform any further attacks on the RFID system. Although we cannot guarantee the integrity of and , the result of the modification on these messages is nothing but a denial-of-service attack.

5.3. Forward Secrecy

Our protocols maintain forward secrecy. Since the keys were updated by using one-way hash function in every session, the attacker cannot acquire the previous secret keys used in the prior sessions. Therefore, the previous session keys and the exchanged messages are secure.

5.4. Anonymity and Untraceability

Our protocols do not leak the tag’s identifier or any sensitive information. Therefore, our protocols fulfill the requirement of anonymity. During the authentication protocol, will send messages , , and to . The adversary is able to eavesdrop all the messages sent from its target tag. With the help of these collected messages, if the adversary is able to distinguish the target tag’s messages from the other tags’ messages, it is able to trace this tag. Obviously, the random challenge is indistinguishable from any other random number, so the adversary cannot use it to trace the tag. The verifier message is constructed by a PRNG with as its seed; thus it is also a random number.

Every tag stores the same generator matrix; therefore, all of them share the same probability of producing the same codeword. However, different tags will add different error vectors. As a result, the masked codewords produced by some tags can be decoded correctly while the others cannot. Once the parity check matrix is known by the adversary, this property may be used by the adversary to trace the tag. To defend against this, the tags further mask their messages with the secret keys. The adversary cannot apply decoding algorithm to the messages without first unmasking them. Hence, we can guard against tracing attacks as long as the target tag’s key is secure.

5.5. Confidentiality

Now we analyze the probability that an attacker will successfully guess one secret key of a tag with different advantages provided. First, if the adversary knows no additional information, the success probability is surely . If the adversary acquires generator matrix by compromising a tag or a reader, it will have some advantages in constructing the codewords. Now the adversary attempts to guess the to derive from the message sent in step 4 of the proposed protocol. The number of all valid codewords is . With the error vector added in which , the number of all possible is . Therefore, the success probability of guessing the correct and is . Notice that the adversary is able to verify whether the guess is correct or not by rapidly substituting the keys into the verifier messages , sending it to , and validating the response . ISO standard 14443 specifies the data exchange rate between the reader and the tag, which is 106 kbit to 848 kbit [28]. Based on this data, we can calculate the relationship between the different codes, the amount of messages the tag transmitted, and the response time, where the response time is the time required for a tag to respond to reader’s query. The result is depicted in Table 1.

Assume the adversary tries to launch the guessing attack by rapidly querying the tag before the tag’s stored key can be updated by the valid reader. Generally, in real-world applications, the adversary is unable to rapidly query a specific tag for a long time because of the mobility of the tag’s carrier. Therefore, attacks that require more than one hour may be regarded as useless. Nonetheless, the adversary may steal a tag from the system to avoid side effects caused by carriers. Nevertheless, in some existing RFID systems, tags will be recycled regularly. For example, in the public transportation systems, the RFID tagged tickets will be recycled and calculated every day. The system manager can find that if a tag has been stolen and remove that tag from the system. As a result, the stolen tag will be unusable hereafter, and the attacker can no longer threaten the system with the tag. In other words, if the required time of an attack is higher than one day, the system can be considered secure. In Table 2, we estimate the success probability of key guessing attack if the attacker performs the attack by rapidly querying the tag either within one hour or within one day. Based on the above arguments and analysis, we choose , , , , and as the candidates for implementing our protocol since they provide better security. In some systems with intensive surveillance, can also be taken into consideration.

5.6. Comparison

In the following, we show the comparisons between our protocol and other related protocols in terms of the security requirements. We take Chien’s SASI protocol [29] and Chien-Laih’s ECC-based protocol [30], Juels-Weis’ HB+ protocol [19], and Sun-Ting’s protocol [26] into comparison. These lightweight protocols are similar to our protocol in basic assumptions. The comparison results of security requirements are shown in Table 3.

SASI protocol was proposed in 2007. This ultralightweight authentication protocol requires only PRNG and simple bitwise operations which are supported by EPC Gen2 tags. However, studies [31, 32] showed that SASI is vulnerable to desynchronizing and tracing attacks. Chien-Laih’s ECC-based lightweight authentication protocol was proposed in 2009. However, this protocol cannot defend against the tracing attacks [33]. Juels-Weis’s HB+ protocol is a multiround lightweight mutual authentication protocol. It requires the tags and the readers to share the same secret to perform its authentication protocol. Studies have proved that HB+ protocol is vulnerable to a man-in-the-middle attack [21]. In this attack, the attacker can retrieve the entire secret and impersonate the valid tag. Therefore, HB+ cannot satisfy authenticity. And, without a secret key update scheme, this protocol also cannot maintain forward secrecy. Sun-Ting’s Gen2+ protocol is another lightweight mutual authentication protocol suitable for Gen2 standard. In [27], the authors proved that the attacker can calculate a fake message to pass the authentication process by replaying the previous messages. As a result, Gen2+ is unable to fulfill authenticity requirement.

5.7. Summary

We had analyzed the security of our protocol and showed that our protocol provides high security against the common security threats of the RFID systems. We also analyzed the adversary’s success probability of recovering the secret key. With careful parameter selection, the attacker will need a long time to break the protocol. Therefore, in most application scenarios, our protocol provides a good solution for securing the RFID system.

6. Evaluation

In this section, we will first describe the hardware constraints on selecting parameters for our lightweight protocol. Then we will have a discussion on the computational loads of the reader and the tag. Finally, based on the analysis, we will compare our protocol with previous works in terms of performance.

6.1. Parameter Selection

We analyze the memory storage and computational capability on the low-cost RFID tags in this section. Based on the analysis, we will select parameters that provide enough security to our protocol and show that the protocol is lightweight enough to be implemented on the tags.

Since our protocol requires tag to store the generator matrix and the parity check matrix , the size of the matrices should not exceed the size of the tag’s storage memory. Fortunately, most passive RFID tags have 1 Kbytes–8 Kbytes of storage; some may even have up to 64 Kbytes of storage [15]. This is sufficient for storing our matrices, which only require about 1 Kbytes-2 Kbytes. With the secret keys and other information added, the requirement is still within the tag’s capability.

Next we turn our attention to the tag’s computational power. As estimated in [15], the cost of an RFID tag should range from US$0.05 to US$0.10, and the area of a silicon chip is limited to approximately 0.25 mm2–0.5 mm2. Under these constraints, the number of logical gates that can be mounted on the chip is limited. Researchers from Auto-ID Labs have estimated that only 400–4000 gate equivalents (GE) can be used for the security related functionality [3].

When running our protocol, the tag has to perform vector-matrix multiplication for decoding and encoding. According to [34], this multiplication can actually be performed by broadcasting columns of the matrix and multiplying them with the corresponding row elements of the vector. Therefore, the operation is simply to rapidly read a column of the matrix from the memory, XOR it with the vector, and accumulate them into a buffer until all the columns are multiplied. The only operation required in the vector-matrix multiplication is a bitwise XOR, which is not an obstacle for the RFID tags. However, during the operation, the elements need to be loaded into the registers. This implies that our protocol requires at least bits of registers for buffer implementation. We also need bitwise XOR logical gates for the multiplication. The other operations, like adding error vector, can also be performed by using these buffers and XOR gates. One bit register takes 6 GE to implement, and a XOR logical gate costs 2.67 GE. Besides, in our protocol, a one-way hash function is required to compute the verifier messages. Implementation of a lightweight hash function costs about 2500 GE [16]. Based on the above analysis, we now estimate the number of required GE for each parameter set we suggested in Section 5.5. The result is listed in Table 4. Most of these do not exceed the limitation of 4000 GE.

6.2. Performance

It is difficult to implement our protocol on the current low-cost RFID tags, since most of the RFID modules are not user-programmable. They run merely the processes that set in manufacturer phase. Therefore, we cannot evaluate the time consuming on the real tags. Hence, we calculated the average amount of transmitted messages in our protocol to estimate the average time of communicating.

Assume that a reader is going to authenticate a tag from tags. We denote as the length of the secret key. In our protocol, the secret key length is equal to the length of the message, . For each tag, it will send , , and to respond to the reader’s single query. All of them are bits in length. For the reader, it will broadcast and to tags (2 bits). After receiving one response message from a tag, the reader will try to decode it. Whatever the decoding result is, the reader always sends a -bit message to the tag. Since the reader will receive at most   responses from the tags, it will broadcast at most bits of messages. As a result, the total amount of transmitted messages of the reader and the tags during the authentication process is and , respectively.

Now we can estimate the running time of our protocol. First note that all tags compute and transmit their messages in parallel; therefore, we should use the amount of total message of a single tag ( bits) for our calculation. Also, based on the fact that the data rate specified in ISO 14443 standard is 106 Kbits to 848 Kbits, we can compute the required data transmitting time of our protocol. The result is shown in Table 5. Even in the worst case scenario, the longest transmitting time is still about 0.13 seconds, which is negligible for most users.

In order to minimize its computational load, the reader will attempt to filter out the unnecessary verifier messages . At step 3, when the tag discovers the syndrome it computed is not matching with the syndrome pattern its stored, the tag will assign a random value to the masked codeword. Even though the probability is small, this random value may be recognized as a valid codeword by the reader. If a random number is recognized as the codeword, the reader has to verify an extra verifier message, thus adding its load. The probability can be computed by dividing the number of all possible by the number of all possible random values; that is, . In Table 6, we show the probability that the random number is recognized as a valid codeword between different codes. Note that and are perfect codes. Therefore, their probability of mistake is 1 since every random message can be corrected to a valid codeword.

Because the number of possible syndrome patterns is limited, a pattern might be shared by many tags. In other words, tags might store the same syndrome pattern. If the reader wants to authenticate one of these tags, each of them will respond with a valid codeword and verifier message. If that is the case, the reader will have to verify unnecessary verifier messages. The number of tags that share the same syndrome pattern is , if the syndrome patterns are randomly distributed to the tags. Taking the mistaking probability shown in Table 6 and the number of unnecessary responses into consideration, we estimate the average number of verifier messages in which a reader has to verify in an authentication process. The result is shown in Table 7. The greater the number, the heavier the reader’s computational load. Notice that the target tag might not be the one of these tags in real-world applications; therefore, we have to remove the target tag from the experiment in order to get a fair result. Depending on the above evaluation, , , and provide good balance for the reader in both security and performance.

6.3. Comparisons

We compare the amount of transmitted messages between different authentication protocols as follows. Still taking Chien’s SASI protocol [29] and Chien-Laih’s ECC-based protocol [30], Juels-Weis’s HB+ protocol [19], and Sun-Ting’s protocol [26] into comparison, assume that the reader needs to authenticate a specific tag from a group of tags. The amounts of messages sent between different number of tags and protocols are presented in Table 8.

In SASI protocol, the tags first send pseudonyms s to the reader, and the reader replies with the messages , , and to the target tag. Finally, the tag responds with message to the reader. Each message is Kbits in length. In this protocol, the reader is able to find its target tag from the tags’ responding s. Therefore, the reader does not need to transmit any unnecessary message to the nontarget tags. In Chien-Laih’s ECC-based protocol, the exchanged messages including a random number , the message sets and . and are Kbits in length. On the other hand, , , , and are generated by a PRNG. We denote their length in bits as . When the reader wants to find a tag from a group of tags, it has to authenticate every tag until it finds its target tag. In HB+ protocol, the reader and the tag exchange two random numbers and one bit message in a single round. But the reader is still required to authenticate each tag to find its target tag. In Gen2+ protocol, the tag transmits 16-bit message set to the reader, and the reader responds with 16-bit to the tag in a single round. After running rounds, the tag eventually responds with a 96- bit EPC to the reader. In this protocol, the reader has to authenticate each tag until it finds its target tag.

Compared with these protocols, the total amount of messages our protocol sent is no greater than most of the existing protocols. Although SASI protocol provides a very efficient identification mechanism based on tags’ pseudonyms, the fixed pseudonyms make the tags vulnerable to tracing attack before they can be updated again.

7. Conclusion

Security and privacy issues on RFID have been studied in recent years due to the rapid growth of RFID systems. Many researchers worry about the disadvantages of RFID technology, such as keeping their location privacy and confidentiality of private information. On the other hand, manufacturers do not provide security functionality on their products because of the native limitation of RFID tags. As a result, researchers have proposed substantial lightweight authentication protocols for securing low-cost RFID tags.

Some real-world RFID application scenarios require a reader to find out and authenticate a tag from a group of tags. In previous works, the reader has to authenticate each tag individually until the reader found the target one, thus greatly increasing the communication and computation time. To address this problem, our protocol provides an error correction codes based mechanism to minimize the computational load of reader. When receiving query, the tags respond with verifier messages along with different codewords in which some of them cannot be decoded. The reader can filter out the unnecessary verifier messages by examining these codewords, therefore improving its performance.

In this paper, we presented a single-round lightweight mutual authentication protocol. The protocol is designed with decoding and encoding operations on error correction codes, pseudorandom number generating, and a hash function. These operations are proved lightweight enough to be implemented on low-cost RFID tags or can be realized by using simple bitwise operations. Based on the secrecy of shared keys, the reader and the tag can establish a mutual authenticity relationship. Further analysis of the protocol showed that it also satisfies integrity, forward secrecy, anonymity, and untraceability. Compared with other lightweight protocols, the proposed protocol provides stronger resistance to tracing attacks, compromising attacks, and replay attacks.

Notation

RFID backend server
:RFID reader
:A RFID tag
:Syndrome pattern
:A syndrome pattern of
:A secret key of
:Pseudorandom number generator
:One-way hash function
:Generator matrix
:Parity check matrix
, :ECC codeword from and , respectively
, :ECC error vector from and , respectively
, :Verifier message from and , respectively
, :Random nonce from and , respectively
:Hamming weight.

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

Acknowledgment

The work of Chien-Ming Chen was supported in part by the Project HIT.NSRIF.2014098 supported by Natural Scientific Research Innovation Foundation in Harbin Institute of Technology, in part by Shenzhen Peacock Project, China, under Contract KQC201109020055A, and in part by Shenzhen Strategic Emerging Industries Program under Grant ZDSY20120613125016389. The work of H.-M. Sun was supported in part by the National Science Council, Taiwan, under Grant NSC 100–2628-E-007-018-MY3.