There are many approaches for the privacy and security of the RFID systems. Sharma et al. [6] mentioned about the resource constrained in an RFID tag as a main challenge to provide privacy and security. The first approach towards the privacy and security of an RFID tag is to kill [7] the tag at the point of sale. Due to various reasons for which killing a tag is not expected because consumer may wish to reuse the tag. Weis et el. [8] proposed a hash-based access control (HAC) approach to protect a tag using a one-way hash function. To do it, the tag stores the hash of a random key as a metaID. Since the metaID is same for a tag all the times, it always transmits the same metaID, which can easily be tracked by an adversary [9]. Another problem in this system is that the information is transmitted in plain text which can easily be eavesdropped. Weis et al. [8] also suggested another approach that is extended from HAC called randomized access control [8]. It uses a random number to prevent location privacy. In each session, the tag produces a response with newly generated random number and its ID using a hash function. It cannot protect the system from replay attack and is not suitable in a real-life system where a large number of tags are used as it requires many expensive hash operations at the back-end database.
To protect location privacy several protocols use hash function of varied identifier or varied secret [9–13]. Chien and Chen [9] proposed a challenge-response-based authentication protocol to prevent replay attack. This protocol uses a database in the server which maintains new and old tag keys to protect DoS attack. To prevent traceability, authentication and access keys are updated. However, this scheme is still vulnerable to backward and forward traceability because if an active attacker compromise a tag this can identify the tag's past interactions from previous transactions and the fixed ID of the tag and can deduce the future transaction. Ohkubo et al. [10] proposed an RFID privacy scheme using a hash chain (HC) mechanism. This method uses two hash functions to protect the privacy and security. It is also not suitable in practical use because the back-end database requires a large number of HCs. Henrici et al. [11] proposed a scheme referred to the hash-based ID variation scheme (HIDV). It uses a one-way hash function to protect location privacy by changing the ID after each session. However, if any authentication session is unsuccessful it replies with the same hashed ID again for which it opens up the vulnerability for impersonation attack such as spoofing. Lee et al. [12] proposed a low-cost authentication protocol (LCAP) which simplifies and enhances HIDV scheme in both efficiency and security. It has the similar problem as in HIDV that a tag always replies with the same hashed ID before the next successful authentication which allows tag tracking. Dimitriou [13] proposed an RFID authentication scheme that preserves user privacy and also protects against tag cloning. This protocol uses the hash of its identifier as a response to a reader query to maintain scalability at the server, and the back-end server sends a message using the updated identifier to the tag after getting the tag response. This scheme also has a problem of tracking as between valid sessions the tag identifier remains the same.
Varying identifier may cause problem in ubiquitous computing environment. To solve the problem, static identifiers are used in many authentication protocols. Molnar et al. [14] proposed a private authentication scheme for library RFID systems. It uses a pseudorandom number and a shared secret key by the tag and the reader for efficient authentication. This scheme does not ensure forward security since the tag's identifier and the secret key are static and the random number forwarded is in plain text which can be captured by an adversary. Rhee et al. [15] proposed challenge response-based RFID authentication protocol (CRAP) which is designed to use in ubiquitous computing. However, this scheme requires (N/2+1) hash function computations in the database which is impractical for large number of tags in ubiquitous computing. Choi et al. [16] proposed a one-way hash-based LCAP (OHLCAP), which is suitable for ubiquitous environment. Ha et al. [17] claim that OHLCAP suffers from traceability and impersonation attack. The authors also proposed a solution of using hash function to protect from traceability attack. Tsudik [18] described an RFID identification protocol that provides a basic level of tag identification using time-stamps. Tsudik [18] also proposed two further schemes that provide tag authentication. The schemes use monotonically increasing time-stamps for tracking-resistant tag authentication, and employ a keyed hash function f.
Karthikeyan and Nesterenko [19] proposed RFID security protocol without computationally expensive cryptographic mechanisms and used simple matrix multiplication. However, this protocol is vulnerable to DoS attack and intruder can try a brute-force matrix and key guessing attack. Moreover, this scheme is not secure from replay and tracking attack. Song and Mitchell (SM) [20] proposed an RFID authentication protocol and ownership transfer protocol [21] to prevent all the attacks discussed so far. Although these protocols are efficient in terms of storage and computation requirements, but they are vulnerable to both tag impersonation attack and reader impersonation attack. Cai et al. [22] proposed a revised authentication protocol of SM [20] to eliminate the problems in it without violation of any other security properties. The storage and computation requirements are also comparable with the existing protocol.
In the next two sections, two prominent protocols LCAP [12] and OHLCAP [16] will be discussed in more detail as they are more related to the proposed work.
3.1 LCAP approach
LCAP scheme uses one-way hash function to protect the privacy and security of the tag. The notations and symbols used in LCAP operation are as follows [12]:
h: {0, 1} ∗ → {0, 1} l is a one-way hash function
ID: ID denotes identity of a tag and is a random value in {0, 1} l .
Data fields of a tag and a reader are initialized to the following values:
Tag: The data field of a tag is initialized to its own ID.
Reader: A reader picks uniformly a random number r in {0, 1} l .
The data fields of a back-end database are initialized to HaID, ID, TD and DATA.
HaID: HaID value is the hash value of ID used for identifying or addressing the tag.
TD: TD-entry is used to trace previous data information of a tag when loss of message occurs in the current session.
DATA: DATA stores the information about an accessible tag.
The back-end database maintains two rows; Prev for the previous session and Curr for the current session. Each row contains HaID, ID, TD, and DATA fields. In Prev, the back-end database records HaID and ID in the previous session. In Curr, it updates HaID and ID of Prev. TD-field of Curr has HaID value of Prev and TD-field of Prev contains HaID-value of Curr. The protocol is shown in Figure 2.
LCAP works as follows:
-
1.
A reader selects a random number r and sends a Query and r to the tag.
-
2.
The tag computes HaID = h(ID) and h(ID||r) using r and its ID and sends h
L
(ID||r) and HaID to the reader, where h
L
(ID||r) is the left half of h(ID||r).
-
3.
The reader sends h
L
(ID||r), r, and HaID to the back-end database.
-
4.
The back-end database then compares if the value of HaID in Prev is same as the value of HaID received from the reader. If successful, then the back-end database computes h
R
(ID||r) using r received from the reader and ID in Prev, where h
R
(ID||r) is the right half of h(ID||r). For the next session, the back-end database computes and stores HaID = h(ID ⊕ r) and ID = ID ⊕ r in Curr. TD-field of Prev is filled with current HaID = h(ID ⊕ r). Finally, the back-end database sends h
R
(ID||r) to the reader.
-
5.
The reader forwards h
R
(ID||r) to the tag.
-
6.
The tag checks h
R
(ID||r). If it matches, the tag updates its ID to ID ⊕ r.
In LCAP scheme, ID is changed in each authentication. So, it does not work in ubiquitous environment. Also mentioned earlier, it cannot overcome the traceability problem.
3.2 OHLCAP approach
OHLCAP uses a static identifier and secrets and is suitable for ubiquitous environment. It also uses a one-way hash function for privacy and security of the tag. OHLCAP requires an ID and a hash function h as in LCAP. Some additional fields are also required. GI is used as a group index. K is a common secret used in all tags and S is a tag secret. The protocol computes three messages: A1 = K ⊕ c, A2 = ID + (GI
i
⊕ r ⊕ c) mod (2l-1), and B = h(ID||(S ⊕ GI
i
)||(r ⊕ c)). B
L
and B
R
are the left and right half of B, respectively. c is used as a counter and initialized to an arbitrary value. It is increased every time a reader sends a query to the tag. The protocol is shown in Figure 3.
OHLCAP works as follows [16]:
Step 1: A reader selects a random value r and sends a query with r to a tag.
Step 2: The tag checks a random value r whether it is all zero value or not.
-
1.
If r value is all zero, the tag sends "stop" message to the reader and stop the protocol.
-
2.
Otherwise, the tag performs the following
-
The tag computes A 1 = K ⊕ c, A2 = ID + (GI
i
⊕ r ⊕ c) mod (2l-1),
B = h(ID||(S ⊕ GI
i
)||(r ⊕ c)) and sends A1, A2 and B
R
to the reader, where B
R
is a right half of B,
-
Then, the tag increases the counter c which should not exceed 2 l - 1.
If the counter c exceeds 2 l - 1, it is initialized by initial c.
Step 3. After receiving from the tag,
-
1.
The reader forwards A1, A2, B
R
and r to the back-end database.
-
2.
The back-end database computes c/= A1 ⊕ K and using all group indices GI
j
, j ∈ {1,...,n}
-
3.
The back-end database checks if one of computed is matching to one of the stored ID s in the back-end database. If this process succeeds, the back-end database check if the GI
j
used to compute the is equal to the group index GI
i
that contains the matching .
-
If this is successful, the database computes B=h(ID||(S ⊕ GI
i
)||(r ⊕ c)) using the matched ID.
-
Otherwise, the back-end database stops this process.
-
4.
Then, the back-end database authenticates the tag by matching the received value B
R
.
-
5.
The back-end database sends B
L
to the reader, where B
L
is a left half of B. The reader forwards B
L
to the tag.
Step 4. The tag authenticates the reader by comparing the received value B
L
.
OHLCAP is an efficient approach in ubiquitous environment that uses one-way hash function for privacy and security. However, Ha et al. [17] find its security weakness and proposes an enhanced OHLCAP (EOHLCAP) scheme. The authors showed that this protocol is vulnerable to traceability attack and impersonation attack because of its special property, namely, c
c
= c
p
+ 1 for two successive sessions. The adversary eavesdrops the messages transmitted between the tag and the reader and obtains the successive A1
p
and A1
c
where A1
p
= K ⊕ c
p
, A1
c
= K ⊕ c
c
. Afterwards, it computes A = A1
p
⊕ A1
c
= c
p
⊕ c
c
= c
p
⊕ (c
p
+ 1) and removes the secret key K in this equation. In this way, the adversary can trace the tag's holder. Similarly, the adversary can implement impersonation attack by selecting special random number r
c
= r
p
+ 1. If r
c
⊕ c
c
= r
p
⊕ c
p
then the value of B
p
is equal to B
c
since B = h(ID||(S ⊕ GI
i
)||(r ⊕ c)). To overcome the security weakness, Ha et al. [17] add a pseudorandom number generator to generate a random number and removes the counter in the tag to prevent traceability attack.