Attacks on RFID Protocols Ton van Deursen

(1)

Attacks on RFID Protocols

Ton van Deursen

ton.vandeursen@uni.lu

Saˇsa Radomirovi´c

sasa.radomirovic@uni.lu

August 6, 2009

Version 1.1

Abstract

This document consists of a description of attack methodologies and a collection of detailed attacks upon RFID protocols. It is meant to serve as a quick and easy reference and it will be updated as new attacks are found. Currently the only attacks on protocols shown in full detail are the authors’ original attacks with references to similar attacks on other protocols.

The main security properties considered are authentication, untraceability, and desynchronization resistance.

Keywords: RFID, identification protocols, attacks.

Parts of this document have appeared in [DR08a,DR08b,DR09].

Preliminaries

Terminology

In this document, reader refers to the actual RFID reader as well as a potential database or server communicating with the reader, since in all protocols considered this communication takes place over a secure channel. An agent can be a tag or a reader, while a role refers to the protocol steps a tag or reader is expected to carry out. A run is the execution of a role by an agent. A nonce is a random number or a random string.

For convenience and intuition, we will refer to certain attacks on protocols as quality-time attacks. These are attacks in which the adversary interacts with a tag in absence of an honest or trusted RFID reader. The attacks can be carried out on tags that happen to be in the vicinity of an adversary for a short period of time or on tags the attacker is able to isolate from their environment for an extended period of time.

When we refer to the untraceability property of a protocol, we mean the tag’s untraceability.

Notation

The exclusive or (xor ) operator is a commutative, associative operator, denoted by ⊕. The xor operator has the property that equal terms cancel each other out, i.e. (a ⊕ b) ⊕ a = b for any a and b.

We use message sequence charts, such as in Figure 1, for the description of protocols as well as attacks on protocols¹.We add textual explanations only when the message sequence chart is ambiguous or insufficient in some form.

Every message sequence chart shows the role names, framed, near the top of the chart. Above the role names, the terms known to the role are shown.

Actions, such as nonce generation, computation, verification of terms, and as- signments are shown in boxes. Messages to be sent and expected to be received are specified above arrows connecting the roles. It is assumed that an agent continues the execution of its run only if it receives a message conforming to its role. Other conditions that need to be satisfied are shown in diamond boxes.

Such conditions will include security claims made by the protocol’s authors,

1Note that attacks can be viewed as protocols in which the intruder’s role has been specified.

(5)

such as untraceability or authentication claims, which will appear typically at the bottom of the chart. There are two types of condition boxes that represent security claims. The first type is a crossed-out diamond box, representing a security claim we invalidate. Such an invalidated claim will be accompanied by an explicit attack on the security claim. The second type is a normal diamond box, representing a security claim we have not invalidated nor proven.

For example, in Figure1, the role names are R and T , both know the secret term k, only T knows T Slast. The picture represents the following execution flow. R generates the timestamp T S before sending the first message. After reception of the first message, T verifies the condition T S > T Slast before continuing its run. T generates a nonce r and sends the second message to R.

The reader hashes the key k and the second part of the message (r) and verifies that the hash is equal to the first part of the message (h(k, r)). If not, the reader stops its execution, else it continues by hashing r and k and sending the third message to T . The tag verifies that the received value matches h(r, k) and if so it sets T Slast to T S. The protocol has been claimed to satisfy untraceability of the tag role and authentication of the tag role towards the reader role but the latter claim can be shown to be false.

k R

k, T Slast

T timestampT S

T S

T S > T Slast

noncer h(k, r), r

h(r, k)

T Slast:= T S

auth(T ) untrac

Figure 1: Example protocol

We simplify the presented protocols whenever possible by leaving out irrelevant steps, communications, and terms. The description given suffices to reconstruct the attacks on the original protocols. Furthermore, for the reader’s convenience, when describing a protocol, we consistently use the notation shown in Table1. Whenever additional functions and variables are needed we use the notation that was originally chosen by the authors of the protocol. When several runs of a protocol are shown, the terms used in the second run are primed, the terms in the third run are double primed, etc. Similarly, in protocols where

(6)

Table 1: Notation

Symbol Meaning

A, B, R, T agent names

h cryptographic hash function

, concatenation

⊕ exclusive or operator

ID, k, k0, k1, . . . shared secret between reader and tag r, r0, r1, r2. . . random numbers

reader or tag update stored variables, the variables whose values are being updated are shown with a prime after the update.

Convention

To simplify references, we name the presented protocols with the citation key which consists of the first letters of the last names of the protocol’s authors and the year of publication appended. Thus for instance, the Diffie-Hellman key exchange protocol would be named [DH76].

Security Properties

In terms of Lowe’s authentication hierarchy [Low97], we consider recent aliveness to be the most appropriate authentication requirement for RFID protocols.

Recent aliveness captures the fact that the tag needs to have generated a message as a consequence of a reader’s query. More formally, a protocol guarantees to an agent a in role A that any corresponding agent b in role B has been re- cently alive, iff whenever a completes a run, there has been an event of b during that run. What recent aliveness does not capture, is the requirement that the tag needs to be in the vicinity of the reader at the time of the communication.

We do not consider this issue in the present paper.

We consider the notion of untraceability as defined in [DMR08] which captures the intuitive notion that a tag is untraceable if an adversary cannot tell whether he has seen the same tag twice or two different tags.

The third security property we investigate is desynchronization resistance as defined in [DMRV09]. It ensures that the system in which the protocol runs will never evolve into a state where there is nobody who can successfully execute the protocol with a tag. In this paper, we restrict ourselves to the three aforementioned properties.

Other properties which are relevant to the RFID setting are distance bounding and scalability. A distance-bounding protocol ensures that the tag is in close proximity to the reader when communicating. In particular, distance-bounding protocols prevent man-in-the-middle attacks on the protocols. Scalability ensures that the reader can efficiently authenticate any tag and is is therefore only tangentially related to the security of an RFID protocol.

(7)

Intruder Model

We perform our security analyses in the Dolev–Yao intruder model [DY83]. In this model, the adversary may eavesdrop on any message exchanged between tag and reader, modify or block any message sent from tag to reader or vice versa, and may inject his own messages making them look like they were sent by tag or reader. We additionally assume that the adversary can observe whether an agent successfully completed its run. This is in line with adversary mod- els designed for RFID protocol analysis, such as Avoine [Avo05], Juels and Weis [JW07], Vaudenay [Vau07], Damg˚ard and Pedersen [DP08], and Paise and Vaudenay [PV08].

Attacking RFID Protocols

From the general description of the adversary’s capabilities we derive three types of attack strategies for the adversary which are meant to enhance the intuition for the attacks and simplify their description.

The simplest strategy is to eavesdrop on messages transmitted between tag and reader. The adversary may then deduce information and combine messages to later impersonate or trace a tag.

The second strategy is to spend some “quality time” with a tag. In these attacks, to which we refer as quality-time attacks, the adversary interacts with a tag in absence of an honest or trusted RFID reader. The point of such an attack is to send carefully designed challenges to the tag in order to obtain information which can later be used to impersonate a reader or the tag, trace the tag, or attack any other security requirement of a protocol.

Quality-time attacks are facilitated by the mobile and wireless nature of RFID tags. The attacks can be carried out on tags that happen to be in the vicinity of an adversary for a short period of time or on tags the attacker is able to isolate from their environment for an extended period of time. In case tags and readers share secret keys, a quality time attack might be mounted on the reader as well.

The third strategy involves modifying messages transmitted between a reader and a tag. This attack works best when the adversary has simultaneous access to a legitimate reader and a tag which is not in the reader’s vicinity. The adversary may modify transmitted messages and then observe the evolution of the communication session.

For each of the three strategies, the feasibility of an attack depends on many factors. In general, it is obvious that the fewer interactions an adversary needs to engage in, eavesdrop on, or modify, the more feasible the attack becomes.

By applying these strategies to several proposed RFID protocols we have identified three types of attacks, which we discuss in subsequent sections. These types of attacks are what we call algebraic replay attacks targeting the challenge- response mechanism in authentication protocols, attribute acquisition attacks on untraceability of tags, and cryptanalytic attacks on secrecy of keys and tag

(8)

identities.

Algebraic Replay Attacks

A common way to authenticate RFID tags is by means of the following challenge- response mechanism. The RFID reader challenges the tag with a nonce r1 to which the tag replies with a term derived from the nonce r1, some information s identifying the tag, and potentially a nonce r2generated by the tag. If present, the nonce r2serves as the tag’s challenge to the reader in mutual authentication protocols or as a “blinding term” to achieve tag untraceability. We can thus represent the tag’s reply to the reader’s challenge as the term r2, g(r1, r2, s) with the understanding that r2 may be constant or empty. The reader verifies the authenticity by applying the inverse of the function g to the term and checking whether the response contains r1 and a valid s. If g is a one-way function then the reader verifies the authenticity of the tag by computing the function g(r1, r2, s) and comparing it to the received value. The reader can compute this function, since it generated the value r1 itself, the value r2 is supplied by the tag, and the reader has a database with values of s for every tag it may authenticate.

We now argue that the following two properties are necessary in order for the challenge-response mechanism to guarantee recent aliveness of the tag.

Freshness For fixed r2 and s the range of the function r1 → g(r1, r2, s) must be large. More precisely, given r2, s, the adversary’s advantage in guessing g(r1, r2, s) correctly for an unknown, randomly chosen r1 must be negligible.

ARR Let Os(x) be an oracle which upon input x randomly chooses y and returns y and g(x, y, s). If s is unknown, then given access to a polyno- mial number of queries Os(x1), . . . , Os(xl) to the oracle, it is infeasible to compute g(r1, r2, s) for a given r16∈ {x1, . . . , xl} and any r2.

If the freshness property is satisfied, then as stated, the probability of the adversary guessing g(r1, r2, s) is negligible. Thus with overwhelming probability, a response r2, g(r1, r2, s), to the reader’s challenge r1must have been generated after the challenge was sent. This property is obviously necessary for recent aliveness and in particular excludes classic replay attacks.

The ARR (algebraic replay resistance) property guarantees that there is no efficient algorithm to compute a response r2, g(r1, r2, s) to the challenge r1 even after having observed previous challenge-response pairs. Clearly, an attacker’s ability to compute such a response violates recent aliveness and this property is thus necessary for recent aliveness. Such an attack generalizes replay attacks in that instead of merely replaying previously observed information, the attacker combines previously obtained challenge-response pairs to compute the response to a fresh challenge. Hence, we refer to attacks on challenge-response authentication protocols exploiting the lack of the ARR property as algebraic replay attacks.

(9)

It is obvious that for a function g(r1, r2, s) to have the ARR property, it must preserve the secrecy of s. Indeed, cryptographic hash functions are frequently used for the type of challenge-response mechanism considered here. Since the collision resistance property of cryptographic hash functions does not seem necessary for the challenge-response mechanism, the question arises whether all one-way functions satisfy the ARR property and the answer is negative. It is certainly false for all homomorphic one-way functions. Consider, for instance, the Rabin function, defined by x → x² mod N for certain composite integers N . If (r1, r2, s) → g(r1, r2, s) = (r1r2s)² mod N is a Rabin function, then given only one challenge-response pair, r1, g(r1, r2, s) it is easy to compute responses for any challenge r^′₁, since g(r₁^′, r2, s) = g(r1, r2, s) · (r₁^′/r1)².

Furthermore, even non-homomorphic one-way functions will in general not have the ARR property if their argument has algebraic properties. As demon- strated in the examples below, there are several protocols that fail to achieve recent aliveness for this very reason. In these protocols the challenge-response construction can typically be represented as g(r1, r2, s) = f (r1◦ r2, s), where f is a (non-homomorphic) cryptographic hash function and ◦ denotes an operator with the following algebraic property. Given a, b, and c, it is easy to find d with a ◦ b = c ◦ d. This construction clearly does not have the ARR property, regardless of the properties of f . The algebraic replay attack on such a protocol works as follows. An adversary observing one execution of the protocol learns r1, r2, and f (r1◦ r2, s). When challenged with r^′₁, the adversary finds r₂^′ such that r1 ◦ r2 = r₁^′ ◦ r^′₂ and replies with r^′₂, f (r1◦ r2, s). The attack succeeds because f (r1◦ r2, s) = f (r₁^′ ◦ r^′₂, s).

Examples of operators ◦ for which this type of attack succeeds are xor, modular addition, and any associative operator for which it is easy to compute left inverses.

Examples

The protocols by Chien and Huang [CH07], Kim et al. [KCLL06], Lee et al. [LAK06], and Song and Mitchell [SM08], shown in sections 1, 5, 7, 14, respectively, are vulnerable to this type of attack. This is due to the fact that they employ a hash-like function or a cryptographic hash function composed with xor which fits into the challenge-response construction with the function f (r1◦r2, s) shown above.

Attacks which we classify as algebraic replay attacks have also been described by Peris-Lopez et al. [PLHCETR07, §4.2] and Bringer et al. [BCI08]:

1. Chien and Chen [CC07] implement the challenge-response mechanism by composing the cyclic redundancy check (CRC) function with xor. To a challenge r1, the tag responds with r2, CRC(EP C, r1, r2) ⊕ k, where EP C is a constant representing the identity of the tag. The attack on this protocol has been first reported by Peris-Lopez et al. [PLHCETR07, §4.2].

It uses the fact that CRC is a homomorphism, i.e. CRC(a) ⊕ CRC(b) = CRC(a ⊕ b).

(10)

To attack the protocol, the adversary observes one protocol execution.

When challenged with r^′₁ the adversary computes the xor of the observed response CRC(EP C, r1, r2) ⊕ k with

CRC(0EP C, r1, 0r₂) ⊕ CRC(0EP C, r₁^′, 0r₂).

The terms 0EP C and 0r₂ are 0-bit strings of length equal to the length of EP C and r2, respectively. Because CRC is a homomorphism, the computation will result in a correct response CRC(EP C, r^′₁, r2) to the challenge r^′₁.

2. The protocol proposed by Lee et al. [LBV08], described in detail in Sec- tion9, is vulnerable to an algebraic replay attack in which the adversary needs to observe three protocol executions or perform a quality-time attack consisting of three queries. The algebraic replay attack can then be exe- cuted by solving a small system of equations yielding a constant particular to the tag. While this constant does not reveal the tag’s secret information, it can still be used to compute the correct response to a reader’s challenge. This attack has been first described by Bringer et al. [BCI08].

Attribute Acquisition Attacks

A simple, necessary condition for tag untraceability is that an adversary, which has observed a particular tag once, must not be able to recognize the tag as being the same tag in the future. To make this more precise, we call a term, which the adversary can derive from one or more runs of a tag and which identifies the tag to the adversary, a unique attribute of the tag. The necessary condition for a tag to be untraceable then is that the adversary must not be able to derive a unique attribute for the tag. Should the adversary be able to compute a unique attribute, then we refer to the adversary’s steps to arrive at such a term as the attribute acquisition attack.

A simple unique attribute can be found in protocols where the tag’s answer to a challenge c is merely a function f (c, k) of the challenge and a secret (or collection of secrets) k and does not involve any nonce created by the tag. In this case, c is under the adversary’s control, k is unique to the tag, and the adversary learns f (c, k) after one round of communication with the tag. Thus for constant c chosen by the adversary, f (c, k) is a unique attribute of the tag whose secret is k.

To prevent long-term traceability in protocols that employ the challenge- response mechanism described, the tag typically updates its secret k at the end of a run. The secret k must therefore also be updated by the reader and in order to avoid desynchronization attacks, the tag needs to authenticate the communicating reader before updating k. Yet, a tag following such a protocol can still be traced by an adversary between two updates by querying the tag and then aborting the protocol. Furthermore, if the update of the secret k at the end of the protocol involves operators with algebraic properties, it is frequently possible for the adversary to compute a unique attribute for the tag which will

(11)

be valid after the update. References to such protocols are given in the examples section below.

To find unique attributes in general, consider a given RFID protocol in a formal trace model such as the one proposed by Cremers and Mauw [CM05], extended by Van Deursen et al. [DMRV09], or the strand spaces model of Thayer F`abrega et al. [THG98]. Then the unique attribute for the tag role can be obtained, if it exists, by computing the intersection of the adversary’s knowledge with the set of terms which can be constructed from constants that are unique to the tag and terms that are under the adversary’s control. Such a term can be found effectively, provided that the intersection is non-empty.

To find a term in the intersection for the special class of challenge-response protocols in which the tag includes a fresh nonce r in its reply f (c, k, r) to a challenge c, the adversary needs to find challenges c1, . . . , cl and an efficiently computable function g(x1, . . . , xl), such that

g(f (c1, k, r1), . . . , f (cl, k, rl)) = ˜g(c1, . . . , cl, k)

does not depend on the tag’s nonces r1, . . . , rl. In this case ˜g(c1, . . . , cl, k) is the unique attribute. The attribute acquisition problem displayed in this form is more amenable to solutions by algebraic methods, as the following examples show.

Examples

1. A simple attribute acquisition attack exists on the protocol proposed by Kim et al. [KCL07], shown in Section4. In this protocol, the tag’s response can be represented by f (c, k, r) = k1⊕ r, h(c, k2) ⊕ r, where k = k1, k2 is the tag’s secret, c the reader’s challenge and r the tag’s nonce. To find a unique attribute, the attacker challenges the tag with a constant c1 and computes the unique attribute by taking the xor of the two terms in the response: k1⊕ r ⊕ h(c1, k2) ⊕ r = k1⊕ h(c1, k2) = ˜g(c1, k).

2. The protocols by Li and Ding [LD07], Osaka et al. [OTYT06], and Yang et al. [YPL⁺05], shown in Sections10,11,15, respectively, are stateful protocols that update the shared secrets between reader and tag at the end of a successful protocol execution. The updates take the old secret and a fresh value exchanged in the protocol execution, and apply an operator with algebraic properties to obtain the new secret. By observing the messages exchanged in a protocol execution, the attacker can fabricate a challenge to which the tag will respond with the same term: the unique attribute.

In other words, the attacker uses his knowledge to “undo” the update of the tag. In the simplest of these, the protocol by Osaka et al. [OTYT06], the reader’s challenge is c, the tag’s response is f (c, k) = h(k ⊕ c), where k is the tag’s secret. The tag updates its secret by computing the xor of it with a third message r it receives from the reader. Disregarding other flaws this protocol suffers from, the attribute acquisition attack consists in challenging the tag the first time with a constant c1. After an update

(12)

with message r the tag is challenged with c1⊕ r. After the next update with message r^′, the tag is challenged with c1⊕ r ⊕ r^′ and so forth. The tag’s response to these challenges is each time h(k ⊕ c1).

3. A more challenging example is the authentication protocol proposed by Lee et al. [LBV08] and shown in Section 9. The protocol is based on a fixed, system-wide elliptic curve over a finite field. The points P , Y = yP , x1P , x2P on the elliptic curve are publicly known, the scalar y is only known to the reader, and the scalars x1, x2 are unique to each tag and only known to the tag. The elliptic curve is assumed to have been chosen such that the computational Diffie-Hellman problem is hard, that is, given only the points xP , yP , and P on the elliptic curve, it is hard to compute xyP .

In the protocol, the reader challenges the tag with a random number r26= 0 to which the tag responds with two points T1= r1P , T2= (r1+ x1)Y on the elliptic curve and a scalar v = r1x1+ r2x2. Using this information, the reader can infer the tag’s identity.

Thus, this protocol, too, is a challenge-response protocol with challenge r2

and a response that can be written as f (r2, k, r1) = r1P, (r1+x1)yP, r1x1+ r2x2, where k = x1, x2. The points P and yP are constant. To find a unique attribute, the adversary needs to find challenge terms c1, . . . , cland functions g, ˜g such that g(f (c1, k, r1), . . . , f (cl, k, r₁^(l))) = ˜g(c1, . . . , cl, k), where ˜g does not depend on the tag’s random numbers r1, . . . , r^(l)₁ . If we write f (c, k, r1) = T1, T2, v as in the protocol specification, and recall that primes indicate terms transmitted in the second run, then

g(f (c, k, r1), f (c, k, r₁^′)) = T1− T₁^′

v − v^′ = x⁻¹₁ P

depends only on the first part of the secret k = x1, x2. Thus ˜g(k) = x⁻¹₁ P is a unique attribute.

From the definition of the function g, it is now easy to obtain the attribute acquisition attack. By carrying out a quality-time attack, the adversary challenges the tag twice with the same value c. The information received from the tag in the two runs can be used to compute the term x⁻¹₁ P as follows. Observe that v − v^′= (r1− r₁^′)x1 and T1− T₁^′ = (r1− r₁^′)P , thus, multiplying T1− T₁^′ with the inverse of v − v^′ modulo the order of the elliptic curve, the attacker obtains x⁻¹₁ P .

Note that after executing this quality-time attack, it suffices for the adversary to challenge any given tag only once with the previously used value c to determine whether the presented tag is equal to the tag identified by x⁻¹₁ P .

A similar attack on untraceability of the protocol was independently found by Bringer et al. [BCI08]. The authors observe that for any two protocol executions, the following equations hold:

(13)

r2v^′− r₂^′v = (r2r^′₁− r^′₂r1)x1

r2T₁^′− r₂^′T1= (r2r₁^′ − r^′₂r1)P

The attacker may then combine these two equations to obtain x⁻¹₁ P and proceed as described above.

Cryptanalytic Attacks

The authentication and untraceability properties of RFID protocols often rely on the secrecy of shared keys. In some cases, revealing parts of a secret key may already be enough to trace the tag. If sufficiently many bits of a key can be revealed, brute-forcing the remaining bits may become feasible. Formal methods approaches typically do not consider attacks in which an adversary may learn just a few bits of a key, since keys are modeled as atomic terms.

If we assume that operators with algebraic properties are applied to terms sent back and forth between a reader and a tag, then a natural point of attack is to set up equations involving the terms on whose secrecy a protocol depends.

Such equations may be obtained by observing several protocol runs, but also by selectively modifying parts of messages. In other words, one may attempt to apply any cryptanalytic method known to mankind. While this is hardly an original strategy, it turns out to be quite successful in the domain of RFID protocols. One reason for this is the popularity of simple operators with algebraic properties. The other reason is due to the simple structure of typical RFID protocols. The reader challenges the tag with a nonce r to which the tag responds with a message involving that nonce and a secret k. This leads to a function r 7→ f (k, r) which can be compared to a cipher m 7→ C(k, m) or keyed hash function x 7→ h(k, x). The tag’s response can further be analyzed by forwarding a modified version of it to the reader and checking the reader’s response. For RFID protocols with three or more messages, a tag-generated nonce, may frequently be considered as a known plaintext. Finally, stateful RFID protocols, i.e. RFID protocols in which the tag upon successful completion of the protocol updates its secret ID or cryptographic key, can be analyzed by taking advantage of algebraic relations between previous and future ID’s or keys.

Examples

The protocol [KN05], shown in Section6, is vulnerable to cryptanalytic attacks.

There are also several examples of cryptanalytic attacks in the literature:

• In the HB⁺ protocol of Juels and Weis [JW05], tags use the binary inner product and xor operator to hide their secret keys while proving knowledge of it. The attack by Gilbert et al. [GRS05] breaks secrecy of a tag’s key by first modifying the messages exchanged between reader and tag, then observing the reader’s behavior, and finally using the observed information to set up and solve a system of linear equations.

(14)

• Van Deursen et al. [DMR08] use information obtained through eavesdropping on executions of the Di Pietro and Molva protocol [DM07] to expose two thirds of the bits of a tag’s secret key. In the protocol execution, bits of the tag’s secret key are combined with random nonces using xor and logical and and or operators and then sent from the tag to the reader.

The attack is carried out by solving a system of linear equations derived from the observed messages which yields two thirds of the secret key’s bits. This is enough to break untraceability. It furthermore permits a brute force attack on the remaining bits in order to break authentication.

A simpler, but less efficient attack is shown in Section2.

• In the protocols of Peris-Lopez et al. [PLCETR06c,PLCETR06a,PLCETR06b], logical and and or operators are used in addition to xor and modular arithmetic leading to information leaks exploited by Alomair et al. [ALP07] and Li and Wang [LW07].

• Vajda and Butty´an have proposed several lightweight authentication protocols in [VB03]. Their first protocol uses xor and bit permutations to update keys shared between reader and tag. The attack of Alomair et al. [ALP07]

correlates keys across updates thereby breaking authentication. Vajda and Butty´an’s second protocol is vulnerable to an active attack in which the adversary recovers the shared secret by querying the tag with a challenge of his choice and analyzing the response.

(15)

1 [CH07]

1.1 Description

The reader R and tag T share secrets k and ID. The reader starts by sending a random bit string r1. The tag generates a random string r2 and hashes the xor of r1, r2, and the secret k. This hash and ID are used as input for a function in which the ID is rotated by a value depending on the hash. The tag computes the xor of the rotated ID and the hash, before sending the left half of the resulting bits and r2 to the reader. The reader performs the same operations on every pair of ID and k until it finds the corresponding tag. It then sends the right half of the corresponding bits to the tag.

k, ID R

k, ID T noncer1

Query,r₁

noncer₂

˜

g := h(r₁⊕ r₂⊕ k) ID2 := rotate(ID, ˜g) r₂, Left(ID2 ⊕ ˜g)

find ID

˜

g := h(r₁⊕ r₂⊕ k) ID2 := rotate(ID, ˜g)

Right(ID2 ⊕ ˜g)

auth(T) auth(R)

untrac

Figure 2: The protocol

1.2 Claimed Attacks

1.2.1 Tag authentication

To impersonate a tag, it suffices to notice that the tag’s response to the reader’s challenge only depends on r1⊕ r2 and a shared secret. The adversary can

(16)

challenge a tag with any r1to obtain a valid combination of r1, r2, Left (ID2⊕ ˜g).

This information suffices for the adversary to be able to respond to any future challenge r^′₁ received from a reader. When challenged, the adversary sets r₂^′ = r₁^′ ⊕ r1⊕ r2and sends r₂^′, Left (ID2 ⊕ ˜g).

1.3 Related Protocols

We have found the same attack on the protocols [LAK06,KCLL06,SM08].

k, ID

R E

k, ID T noncer₁

Query,r1

noncer₂

˜

g := h(r₁⊕ r₂⊕ k)

ID2 := rotate(ID, ˜g) r2, Left(ID2 ⊕ ˜g)

noncer₁^′

Query,r^′₁

r^′₂:= r₁⊕ r₁^′⊕ r₂ r^′₂, Left(ID2 ⊕ ˜g)

find ID

˜

g := h(r^′₁⊕ r^′₂⊕ k) ID2 := rotate(ID, ˜g)

Right(ID2 ⊕ ˜g)

auth(T)

Figure 3: Attack on tag authentication

(17)

2 [DM07]

2.1 Description

This is an authentication protocol which not only aims to keep tags untraceable, but also to limit the damage a compromised reader can cause.

In the protocol, depicted in Figure 4, the function DP M (x) is defined as the parity of majority functions of consecutive bit-triplets of x. The size of its output is therefore one bit. The protocol begins with the reader sending its name and a nonce r0 to the tag. The tag replies with the message α1, . . . , αq, V, ω, where αi = k ⊕ ri for randomly chosen ri (a bit-string of length ℓ, ℓ = 117 suggested by authors), the i-th bit of V (a bit string of length q) is DP M (ri), and ω = h(k, r0, r1, k). The reader has a database of all tags’ keys it is authorized to identify. The reader can find a particular tag’s key k with the help of the vectors αi and values DPM (ri) by going through all the keys in its database and iteratively excluding the impossible ones, namely those for which DP M (k⊕

αi) 6= DPM (ri). It is expected that each αireduces the number of possible keys by approximately one half. At last, the reader uses ω to uniquely identify the correct key and authenticate the tag. The last message of the protocol allows the tag to authenticate the reader.

k R

k T noncer₀

R, r₀

noncer₁, . . . , rq

αi:= k ⊕ ri

V := DP M (r1), . . . , DP M (rq) ω := h(k, r₀, r₁, k) α₁, . . . , αq, V, ω

find k

h(k, r₁, k)

auth(T) auth(R)

untrac

(18)

2.2 Claimed Attacks

2.2.1 Authentication and Untraceability

In the following we show that over several rund, the protocol leaks ^2ℓ₃ bits of k.

This allows an attacker to brute-force the remaining bits of k for the suggested parameter ℓ = 117.

Let x = x1x2· · · xℓ be a bit string of length ℓ, for some positive integer ℓ divisible by three. Then DP M (x) = M (x1, x2, x3) ⊕ · · · ⊕ M (x_ℓ−2, x_ℓ−1, xℓ), where M (a, b, c) is the majority function on three bits. Let ¯xi denote the com- plement of the bit xi. It is easy to see that M (¯x1, x2, x3) = M (x1, x2, x3) if and only if x2 = x3. Analogous equations hold for the complements of x2 and x3. It follows that

DP M (¯x1, x2, x3, . . .) = DP M (x1, x2, x3, . . .) ⇔ x2= x3, (1) again with analogous equations for any other bit of x.

The adversary can take advantage of the property (1) as follows. Suppose the adversary intercepts the tag’s message, flips the first bit of α2= r2⊕ k to obtain ˜α2 and forwards the modified message to the reader. If the second and third bit of r2 are equal, then DP M (k ⊕ ˜α2) = DP M (k ⊕ α2) = DP M (r2). In this case, the reader will still be able to find the correct key k and answer the tag with the third message of the protocol. However, if the second and third bit of r2are not equal, then DP M (k ⊕ ˜α2) 6= DP M (r2) and the reader will remove the key k from the list of possible keys. No other key will pass the verification with ω, thus the reader will not answer with the third message. The adversary can therefore distinguish the two cases.

It follows that by selectively flipping bits of α2an adversary may, after several protocol executions, determine for each consecutive bit triplet of k which bits are equal to each other. In other words, the adversary may determine the bits of k up to complements of consecutive bit-triplets.

This information can be used to reduce the complexity of computing all bits of k to a brute force search of a space whose size is the cubic root of the full key space. For the parameters of the system suggested by Di Pietro and Molva, this brute force search becomes feasible (2³⁹keys). The knowledge of the secret key k then allows the attacker to also impersonate the tag to the reader, thus breaking the authentication claim of the protocol. By sufficiently increasing the key length, however, this attack becomes infeasible.

To break untraceability, the brute force search is not necessary. The probability that two keys are equal up to complements of consecutive bit-triplets is vanishingly small [DMR08]. Increasing the key length does not prevent this attack.

The attack outlined above is not efficient. In [DMR08] we describe an efficient quality-time attack on this protocol which reveals the same information about k as the attack described above.

(19)

2.3 Related Protocols

The presented attack is similar to the active attack on the HB⁺protocol [JW05]

discovered by [GRS05] in that it exploits an algebraic property by modifying messages and observing the reader’s behavior.

(20)

3 [HMNB07a]

3.1 Description

The protocol starts with the reader querying the tag with a nonce r1. The response of the tag depends on the value of a state variable S. In case the previous run ended successfully the value of S is 0 and the tag will respond with h(ID). In case it did not end successfully the value of S is 1 and the tag will respond with h(ID, r2, r1). In either case, the tag will set its S to 1. The reader will authenticate the tag if the response is equal to HID, h(ID, r2, r1) or h(P ID, r2, r1) for any stored value of HID, ID or P ID. The reader will then update the information for the particular tag according to Table 2. The reader then sends h(P ID, r2) to the tag, after which the tag replaces its ID by h(P ID, r1) and sets S to 0. The protocol is depicted in Figure5.

Table 2: Reader’s verification and update procedure Tag response Reader action

h(ID), r2 ID^′ := h(ID, r1); HID^′:= h(ID); P ID^′ := ID;

h(ID, r2, r1), r2 ID^′ := h(ID, r1); HID^′:= h(ID); P ID^′ := ID;

h(P ID, r2, r1), r2 ID^′ := h(P ID, r1); HID^′:= h(ID); P ID^′:= P ID;

other reject tag

3.2 Claimed Attacks

Note that if no messages are blocked or lost, the tag always responds with h(ID) allowing for an efficient lookup by the reader. An attacker can thus impersonate any tag which is in state 0 by sending a query to it and replaying the tag’s response before the tag has been queried by an authorized reader. The attack is depicted in Figure6.

3.2.2 Untraceability

The tag’s response depends on the value of S, i.e. the state the tag is in. If S = 0 the tag responds with h(ID), r2 and otherwise the tag responds with h(ID, r1, r2). Because the attacker does not know ID, he can not conclude from the response in which state the tag is. However, the attacker may use the fact that if the tag is in state 0, changing r2 does not result in a rejection of the response by the reader. If the tag is in state 1, changing r2 would lead to a rejection of the response and a termination of the execution of the reader.

(21)

3.2.3 Desynchronization resistance

Any tag that is in state S = 0 can be desynchronized from a reader by a man-in-the-middle attack. In a communication between the reader and a tag, the adversary intercepts and modifies the reader’s challenge r1 to any value r₁^′ 6= r1. The adversary then sends the modified value to the tag and forwards all other messages between reader and tag without modification. Since in the case S = 0 the reader does not verify that the tag received the correct value r1, the adversary’s modification goes by unnoticed. Thus, at the end of the protocol execution, reader and tag update ID to different values. The reader stores h(ID, r1), while the tag stores h(ID, r^′₁). Therefore, the reader and tag will be in a desynchronized state and future authentication of the tag becomes impossible. The attack is depicted in Figure7.

ID, P ID, HID R

ID, S T noncer₁

r₁

noncer₂ if S = 0 then P := h(ID) elseP := h(ID, r₂, r₁)

S^′:= 1 P, r2

verifyP, r₂

updateID, P ID, HID

h(P ID^′, r₂)

if h(P ID^′, r₂) = h(ID, r₂) then

ID^′:= h(ID, r₁), S^′:= 0

auth(T) auth(R)

untrac desynchronization resistance

(22)

3.3 Related Protocols

The protocols in [LY07c, LY07a, LY07b, HM04] are challenge-response-based protocols with a similar authentication flaw.

A similar untraceability flaw in [HM04] was found by [Avo05]. There a quality time attack is used to increase a tag’s internal counter to an abnormal level in order to recognize the tag later.

ID, P ID, HID

R E

ID, S = 0 T

noncer^′₁ r^′₁

noncer₂ P := h(ID)

P, r₂

noncer₁

r₁ P, r2

verifyP, r₂ update ID, P ID, HID

h(P ID^′, r₂)

auth(T)

(23)

ID, P ID, HID

R E

ID, S = 0 T noncer₁

r₁

noncer^′₁

r^′₁

noncer₂ P := h(ID) P, r₂

P, r₂

verifyP, r₂ update ID, P ID, HID

h(P ID^′, r₂)

ID^′:= h(ID, r₁) ID^′:= h(ID, r₁^′)

desynchronization resistance

Figure 7: Attack on desynchronization resistance

(24)

4 [KCL07]

4.1 Description

The protocol is depicted in Figure8.

k, ID R

k, ID T noncer₁

r₁

noncer2

ID ⊕ r2, h(r1, k) ⊕ r2

auth(T )

untrac

Figure 8: The KCL07 protocol

4.2 Claimed Attacks

E

k, ID T noncer₁

r₁

noncer₂ ID ⊕ r₂, h(r₁, k) ⊕ r₂

r1

noncer^′₂ ID ⊕ r₂^′, h(r₁, k) ⊕ r^′₂

untrac

Figure 9: The attack on untraceability

To attack untraceability, the adversary challenges the tag twice with the

(25)

same nonce. He can then calculate the xor of the two parts ID ⊕ r2 and h(r1, k) ⊕ r2of the responses, the adversary then twice obtains ID ⊕ h(r1, k), if and only if it was twice the same tag that he challenged. The attack is depicted in Figure9.

(26)

5 [KCLL06]

5.1 Description

The protocol is depicted in Figure10. In the original specification, the protocol control bits (P C) and a CRC are transmitted in the fourth message. These are irrelevant to any of the considered security properties and are therefore left out.

After being powered up, the tag generates a nonce r1 and sends the xor of the nonce and its P IN 1 to the reader. The reader acknowledges the message and generates a nonce r2. Both the acknowledgement and the nonce are sent to the tag. The tag calculates the next message as is displayed in Figure10.

The reader applies a one-way function f to the xor of the two nonces and the P IN 2. The result is xor ed with the P IN and sent to the tag.

EP C, S, P IN 1, P IN 2 R

EP C, S, P IN 1, P IN 2 Query request T

noncer1

r1⊕ P IN 1

noncer₂

ACK(M 1), r₂

M 2 = r₂⊕ P IN 2 ⊕ r₁ M 3 = f (M 2)

T := 0kr₁kM 2kM 3 (minus last bit)

E := (T + S) ⊕ EP C E

P IN ⊕ f (r₂⊕ P IN 2 ⊕ r₁)

auth(R) auth(T )

untrac

5.2 Claimed Attacks

5.2.1 Reader authentication

The adversary can impersonate a legitimate reader by sending a nonce r^′₂ that allows him to replay a message he previously observed as a last message. In

(27)

order to be able to replay P IN ⊕ f (r2⊕ P IN 2 ⊕ r1) in another session, the following condition must be satisfied: r1⊕ r2 = r₁^′ ⊕ r^′₂. This can be done by setting r₂^′ to r1⊕ r2⊕ r^′₁. The attack is depicted in Figure11.

5.3 Related Protocols

We have found a similar attack on the protocols [CH07,LAK06,SM08].

E

EP C, S, P IN 1, P IN 2 T

obtain P IN ⊕ f (r₂⊕ P IN 2 ⊕ r₁)

Query request

nonce r₁ r^′₁⊕ P IN 1

ACK(M 1), (r₁⊕ P IN 1) ⊕ (r₁^′⊕ P IN 1) ⊕ r₂

M 2 = P IN 2 ⊕ r₁^′⊕ r₂ M 3 = f (M 2)

T := 0kr^′₁kM 2kM 3 (minus last bit)

E := (T + S) ⊕ EP C P C, E, CRC16

P IN ⊕ f (r₂⊕ P IN 2 ⊕ r₁)

auth(R)

Figure 11: Attack on reader authentication

(28)

6 [KN05]

6.1 Description

In this protocol, the tag generates a random value r0from a small domain and a random value r1 of length n. The tag sends the two hashes h(ID, r0), h(r1, k) and ID ⊕ r1 to the reader. Using h(ID, r0), the reader finds ID by trying out all combinations of values for ID stored in its database and of all possible values for r0. This is possible for the reader because r0is chosen from a small domain and the number of IDs stored in its database is very small compared to the number of possible IDs. Using ID the reader retrieves k from its database, and using ID ⊕ r1 and ID, the reader finds r1 and may then verify the correctness of the value of h(r1, k). The reader then generates a random value r2 of length n and sends ID ⊕ r2 and h(r1, r2) to the tag. The tag verifies these and sends r1+ r2 mod 2ⁿ back to the reader. Both tag and reader update the ID by xor -ing it with r1⊕ r2.

The protocol is depicted in Figure12. Note that r0 is chosen from a small domain, and can therefore be brute-forced from h(ID, r0) if ID is known.

k, ID R

k, ID Query T

noncer₀ noncer₁ h(ID, r₀), h(r₁, k), ID ⊕ r₁

nonce r₂

h(r₁, r₂), ID ⊕ r₂ r₁+ r₂mod 2ⁿ

k^′:= r1+ r2mod 2ⁿ k^′:= r1+ r2mod 2ⁿ

ID^′:= ID ⊕ r₁⊕ r₂ ID^′:= ID ⊕ r₁⊕ r₂

auth(R) auth(T )

untrac desynchronization resistant

(29)

6.2 Claimed Attacks

An eavesdropping adversary is able to find bits of the ID by combining h(ID, r0), ID ⊕ r1, ID ⊕ r2, and r1+ r2mod 2ⁿobserved in the last three messages of the protocol.

Since hash functions are assumed to be perfect, we consider the terms ID ⊕ r1, ID ⊕ r2, and r1+ r2 mod 2ⁿ, setting up a system of equations involving the variables ID, r1, r2, and the values observed during runs of the protocol. A moment’s thought shows that we may combine the first two equations to obtain r1⊕ r2.

For convenience, we set V = r1+r2mod 2ⁿand W = r1⊕r2. Let V [i] be the i-th bit of V , and similarly for W , r1, and r2. Furthermore, let V [1] be the least significant bit of V . By comparing addition modulo 2ⁿ with xor it is easy to see that V [i + 1] 6= W [i + 1] only if there is a carry bit in the computation of V [i]. If this is the case, then r1[i] 6= r2[i] ⇔ W [i] = 1 and r1[i] = r2[i] = 1 ⇔ W [i] = 0.

Since the latter case determines r1[i] and r2[i] uniquely, it follows that it can be used to find the i-th bit of ID. More bits from ID can be obtained by noticing that a carry bit in V [i] followed by no carry bit in V [i + 1] implies r1[i + 1] = r2[i + 1] = 0.

Since r1 and r2 are chosen at random, on average, every communication session leaks roughly ⁿ⁻¹₄ bits of ID. Revealing all bits of ID, once sufficiently many bits are known, can be achieved with a brute-force search over possible values for ID and r0 and comparing their hash to h(ID, r0). Revealing all bits of ID is made a little more complicated by the fact that reader and tag update ID at the end of every protocol execution by setting it to ID ⊕ r1⊕ r2. The adversary may therefore need to keep track of two or three consecutive protocol executions between the tag and reader before performing the exhaustive search in order to completely reveal the tag’s ID. Knowing the ID, the adversary can impersonate both tag and reader and furthermore trace the tag.

6.2.2 Reader authentication

Revealing the tag’s ID as in Section6.2.1breaks reader authentication as well.

Revealing the tag’s ID as in Section6.2.1breaks untraceability as well.

6.2.4 Desynchronization resistance

Revealing the tag’s ID as in Section6.2.1breaks desynchronization resistance as well since the adversary can falsely authenticate to either the reader or the tag. The result is that reader and tag are desynchronized.

(30)

6.3 Related protocols

Many similar flaws have been documented in the literature. [CLL05] uses a counter in conjunction with xor. In [HMNB07b] the predictability of the counter and its interaction with xor are used to break the protocol. In [PLCETR06c, PLCETR06a,PLCETR06b] logical and and or operators are used in addition to xor and modular arithmetic leading to flaws described in [ALP07,LW07]. The cyclic redundancy check function is used with xor in [CC07] making the proposed protocol vulnerable to impersonation of tags and readers, and traceability of tags discovered in [PLHCETR07]. Finally, [DFJ07] breaks authentication in [VB03]

where xor is used with bit-permutations.

(31)

7 [LAK06]

7.1 Description

The reader and tag share a secret k which is used for mutual authentication. To prevent desynchronization due to message loss, the old values of k is stored in k^′. The reader initiates the protocol by challenging the tag with a nonce r0. The tag generates a nonce r1and computes the response as in Figure13. The reader uses the response to find the corresponding k in its database. The reader xor s the response with the reader nonce and the key and sends the cryptographic hash of the result to the tag.

k, k₀ R

k T noncer0

r0

noncer₁ r₁, h(r₀⊕ r₁⊕ k)

h(h(r₀⊕ r₁⊕ k) ⊕ k ⊕ r₀)

k₀^′:= k k^′ :=

h(k)

k^′:= h(k)

auth(T ) auth(R)

untrac desynchronization resistant

7.2 Claimed Attacks

7.2.1 Tag Authentication

The adversary challenges the tag with a random value r0, obtaining a response r1, h(r0⊕ r1⊕ k). When queried by a trusted reader with challenge r^′₀, the adversary uses the response generated by the tag.

The attack is depicted in Figure14. The adversary may replay h(r0⊕ r1⊕ k) if he ensures that r0⊕ r1= r^′₀⊕ r₁^′. To satisfy this condition the adversary sets r₁^′ to r0⊕ r1⊕ r₁^′.

(32)

7.3 Related Protocols

We have found a similar attack on the protocols [CH07,KCLL06,SM08].

k, k₀

R E

k T noncer0

r0

noncer₁ r₁, h(r₀⊕ r₁⊕ k)

noncer^′₀

r^′₀

r₁^′:= r₀⊕ r₀^′⊕ r₁ r^′₁, h(r₀⊕ r₁⊕ k)

h(h(r0⊕ r1⊕ k) ⊕ k ⊕ r^′₀)

k₀^′:= k k^′ :=

h(k) auth(T )

Attacks on RFID Protocols Ton van Deursen