attackers in the context of RFID tags. Moreover, it turns out to be mandatory for the attack of Juels and Weis to work. In contrary, we do not make this assumption and simply assume that the adversary interacts with all tags similarly. at is, our attack applies to a more constrained setting for the adversary by forcing a common tmax for all tags.

YA-TRAP was designed to speci cally output a random response even if the tag does not want to be validated by the reader, such that an adversary is unable to distinguish between that random response and a proper response. Yet, by observing the output of the reader-tag interaction, i.e. seeing if the tag passes the validation or not, still allows the distinguishing. In this sense, using the YA-TRAP approach of generating random responses by itself is not su cient to prevent tracing.

To reiterate, our attack can be prevented if the adversary is unable to observe the output of the reader-tag interaction, i.e. it does not know if the tag successfully passes the reader’s validation check. is inability in fact corresponds to the narrow adversary model de ned in Vaudenay’s privacy model [Vau ]. One example setting that ts this narrow model is the batch mode suggested for YA-TRAP. Nevertheless, the batch mode is not relevant for applications where immediate feedback is required and is only meaningful when tags are assumed to be honest since they are not authenticated on the spot but later. Clearly, this last assumption is hard to justify.

Cloning. First note that due to computational restrictions, it must be that tmax t0 is a polynomial function in the security parameter of the scheme. Hence, we can have an adversary enumerating all those timestamps and querying a particular tag with all of them. In the end, the adversary obtains a list of pairs of the form (tj; hj) that she can use to produce a clone to the earlier tag. e forged tag only needs to have that list and to answer to the hj that corresponds to the tj it receives. Clearly, this tag gets authenticated so the YA-TRAP protocol does not protect against cloning attacks.

. . YA-TRAP+

To address availability of all RFID tags, which is the main conceptual limit of YA-TRAP, Burmester et al. [LBdM ] proposed an extension to the latter protocol called YA-TRAP+. e di erence between the two version essentially lies in the absence of the max timestamp tmax. Moreover, the reader is assumed to have access to the tags’ secrets KID (instead of the outputs of a function of these secrets). For authentication, the reader issues a timestamp t and a random value rt, just like in YA-TRAP. e response from the tag then depends on the comparison of the received timestamp with the one he received during the session before. If the timestamp it receives is greater than the stored one then the tag answers with h1 = HKi (00jjtjjrt) and updates its internal timestamp tID to the received one. In the other case, the tag computes h1 = HKID (01jjrijjrt), for a randomly chosen ri, but does not update tID.

.

h1 = HKID (00jjtjjrt)_

h1 = HKID (01jjrIDjjrt)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Optional Part

h2 = HKID (10jjrIDjjt) ! h2 if (t > tID ^ h2 = HKID (10jjrIDjjt)) tID t

Figure 6.6: e YA-TRAP+ protocol.

To avoid distinguishing attacks by the number of values that the tag returns, it is set such that it sends ri and h1 in both cases, although it is useless in the rst one. Veri cation from the reader is straightforward since it has all the tags’ secrets.

To x the vulnerability to DoS attacks which a ects YA-TRAP, it was proposed to add an optional phase to YA-TRAP+ which implements reader authentication. In this variant, the reader issues a third message h2 = HKID (10jjrijjt). When a tag receives that message, it decides whether it matches with the answer it expects. In case of a match, the tag updates its tID to t, providing that t > tID. e whole protocol is shown in Figure . .

ItturnsoutthatthetracingattackagainstYA-TRAPissimplerwhenappliedtoYA-TRAP+ if its optional second pass is implemented. e attack runs as follows.

. Learning: An adversary rst issues Send queries to the tag T0 with some rt and a value t thatispredictablymuchlargerthanthetag’s tID. eadversarythenobtainstheresponse ri; h1 = HK (00jjtjjrt). A er that, she sends a random message h2 which, with very high probability will make T0 not authenticate its partner as the reader. Consequently, T0 does not update its internal time counter tID to t.

. Challenge: We let the adversary rst issue a Send query to the challenge tag Tb with the samert andt. Ifthechallengetagis T0,itwillreturntheresponseri′; h1 = HK (00jjtjjrt) forwhich h1 isthesame as theoneanswered inthe rstphase. Otherwise, theadversary knows Tb = T1. is allows to track the tag and win the privacy game.

Note that YA-TRAP+ was speci cally designed to resist the kind of tracing attack that we mounted on its predecessor YA-TRAP. Yet, this result shows that the optional second pass of

. - , - + -

Figure 6.7: e O-TRAP protocol.

YA-TRAP+, which was meant to provide additional security to resist denial of service attacks, makes the protocol vulnerable to tracing attacks.

. . O-TRAP

Beside proposing YA-TRAP+, Burmester et al. proposed another authentication protocol for RFID tags called O-TRAP. In its spirit, this protocol is similar to OSK [OSK ]. To authenticate itself, the tag computes a keyed function HKID of a challenge sent by reader rt and a self chosen nonce rID, i.e., it computes h = HKID (rt; rID), and sends both the output of H and its nonce to the reader. Having knowledge of the keys, the reader goes through all those keys to nd the one for which the output of H matches. e steps of O-TRAP are shown in Figure . .

. Learning: An adversary can issue a Send query to the tag T0 with random values rt repeatedly, causing the tag to update its rID each time such that it is way into the future compared to its synchronization with the reader.

. Challenge: e adversary observes the future interaction between a tag Tb 2 fT0; T1g and a reader via Execute queries to see if the reader accepts the tag as valid. If not, then the adversary knows this was the tag that it marked during the learning phase, i.e. Tb = T0. Else, Tb = T1.

Note that this kind of attack has been independently applied by Juels and Weis [JW ] to a couple of other older RFID protocols. Yet what is interesting, as has been demonstrated here, is that more recent provably secure protocols like YA-TRAP+ and O-TRAP still allow for tracing. In this particular case, the privacy leakage of the protocols come from the poor formulation of privacy in the LBdM model as it permits to prove that protocols that allow tracing attacks are private.

.

6.6RIPP-FS

RIPP-FS was proposed by Conti et al. [CPMS ] as an improvement to the YA-TRAP type protocols that features resilience to denial of service attacks and forward privacy. is last notion deals with the privacy of sessions that precedes the leakage of the tag’s secrets to an attacker. Albeit tag authentication works in a similar way to YA-TRAP, RIPP-FS includes an additional key that is shared between all the tags and the reader and is used to authenticate the latter. Concretely, that key is derived from a hash chain seeded by a value w and is de ned as follow.

{

Kℓ = w

Ki = H(Ki+1) = Hℓ 1(w); i = 0; : : : ; ℓ 1

To perform reader authentication, every tag is given K0. For time period i, it is the key Ki that will be sent by the reader as the rst message for authentication along with a period counter ti. Having the key of the last period, the tag checks that Ki 1 = H(Ki) (if one time period separates the current authentication from the last one. In general, the tag checks that Ki+ti tID = H(Ki) ). e rest of the protocol follows YA-TRAP: the tag updates its internal period counter tID to ti if the former value is greater than the later. e tag also updates Ki+ti tID to Ki and returns HMACKID (ti) to the reader which is able to recover KID and hence deducing the identity of the partner tag. As in the YA-TRAP protocol, when the received timestamp is smaller than the stored one, the tag does not perform any of the updates mentioned before and rather answers with PRNGID(i). e steps of RIPP-FS are given in Figure . .

. -