eripp-fs: enforcing privacy and security in rfid

SECURITY AND COMMUNICATION NETWORKSSecurity Comm. Networks. 2010; 3:58–70Published online 23 June 2009 in Wiley InterScience(www.interscience.wiley.com) DOI: 10.1002/sec.120

eRIPP-FS: Enforcing privacy and security in RFID

Mauro Conti1, Roberto Di Pietro2‡, Luigi V. Mancini1 and Angelo Spognardi3∗,†1Dipartimento di Informatica, Universita di Roma La Sapienza, Via Salaria 113 - 00198 ROMA, Italy2Dipartimento di Matematica, Universita Roma Tre, L.go S. Leonardo Murialdo, 1 - 00146 ROMA, Italy3Equipe Planete, INRIA Rhone-Alpes, 655 avenue de l’Europe, 38330 Montbonnot St. Ismier, France

Summary

In RFID systems addressing security issues, many authentication techniques require the tag to keep some sort ofsynchronization with the reader. In particular, this is true in those proposals that leverage hash chains. When thereader and the tag get de-synchronized, possibly by an attacker, this paves the way to several denial of service (DoS)attacks, as well as threatening privacy (e.g., via the timing attack). Even if de-synchronization happens for non-malicious causes, this event has a negative effect on performances (for instance, slowing down the authenticationprocess).

In this paper, we provide a solution to cope with the de-synchronization between the tag and the reader whenhash chains are employed. In particular, our solution relies on mutual reader-tag authentication, achieved via hashtraversal and Merkle tree techniques. We show that this techniques applied to an existing security protocol forRFID systems, such as RIPP-FS, make timing attacks hard to succeed. Moreover, the proposed solutions can betransparently and independently adopted by similar security protocols as well to thwart timing attack and/or toprovide reader-tag mutual authentication.

Finally, extensive simulations show that our proposal introduces a negligible overhead to recover de-synchronization. Copyright © 2009 John Wiley & Sons, td.

KEY WORDS: RFID; tag identification; privacy; forward secrecy; authentication; synchronization

1. Introduction

The use of radio frequency identification (RFID) tech-nologies is spreading. For instance, in good’s logisticsit overcomes the bar-code technology by introducingmore features, such as the ability to remotely querythe good’s tag identifier. The typical RFID architec-ture can be shortly summarized: a beckoned serverstores a database associating many information to var-

∗Correspondence to: Angelo Spognardi, Equipe Planete, INRIA Rhone-Alpes, 655 avenue de l’Europe, 38330 Montbonnot St.Ismier, France.

†E-mail: [email protected]‡Roberto Di Pietro is also with UNESCO Chair in Data Privacy, Universitat Rovira i Virgili, Tarragona, Spain.

ious tags IDs; a wireless reader can query the tags andforward the reply to the server; when queried, the tagreplies with its own ID. Hence, the server can identifythe tag and retrieve any further information associatedwith that ID. Due to their reduced size, RFID tags areseverely constrained: they have limited computationalpower and small amount of memory. Moreover, RFIDtags have no autonomous power supply since they usu-ally drain power from the magnetic field generated by

Copyright © 2009 John Wiley & Sons, td.

eRIPP-FS: A NOVEL AUTHENTICATION TECHNIQUE FOR RFID 59

the reader to perform both computation and wirelesscommunications [1] (passive tag). Due to the wire-less radio channel, the communication are inherentlybroadcasted. Messages sent by the reader are receivedby all the tags in the range of the reader transmis-sion power. Then, these tags receive power and canstart their computation. However, when tags reply, acontention-resolving protocol to access the wirelesschannel has to be carried out, like the one describedin the ISO/IEC 18000-x series.

One of the main security issues raised by RFID tech-nology is privacy [1,2]. In fact, a malicious attackereavesdropping on the communication between readerand tags can be aware of the presence of a given tag ortracing the movement of a given object (that is the cor-responding tag). Tag tracing can be simply extended topeople tracing: a person can be associated to a givenset of tags. Further, the wireless channel between thetag and the reader cannot be protected with techniqueslike public key cryptography, as highly demanding withrespect to the limited computation and storage capabil-ities of the tag.

In recent years, research has been addressing securityin RFID systems from several points of view. However,no single silver bullet has been proposed so far thataddresses all the security features needed in RFID sys-tems, such as key secrecy, privacy, forward secrecy, anddenial of service (DoS) resilience, to name the moreimportant issues. To enforce these properties withinthe computational and power constraints of the RFIDtag, a flurry of solutions leveraging hash chain havebeen proposed: a few of them are synthesized in Sec-tion 2. The idea underlying some of these solutions isto use a hash chain, where a value of this chain rep-resents a state. When needed, via hash computation,a tag can synchronize its state with the state of thereader. As shown in next sections, the need for keepingtags and server synchronized is considered a relevantsecurity issue in the literature. However, some of theproposed protocols become vulnerable when the tagand the reader get de-synchronized. For instance, tim-ing attack [3,4] becomes possible, i.e. an attacker couldidentify tags that are missing honest readings, measur-ing the time that the tag uses to compute a reply toa query. This happens when a tag that missed honestreadings has to perform some many computations inorder to keep up ‘synchronized’ with the reader. Evenif the de-synchronization arises due to non-maliciouscauses, the re-synchronization overhead can introducea significant delay.

Our contribution: We describe a novel reader authen-tication mechanism with a constant overhead that can

be easily used together with the two schemes RIPP-FS [5] and FastRIPP [6]. This mechanism solves thepossible timing attack the above protocols are proneto, during the reader authentication phase. The mecha-nisms used to achieve these features is based on Merklehash tree.

Moreover, we extend the aforementioned protocolswith the new mechanism, proposing eRIPP-FS, a pro-tocol that provides the following security features: keysecrecy, reader authentication, privacy in tag identi-fication, forward secrecy, and DoS resilience, whilegranting a fast re-synchronization. Further, the over-head introduced is almost negligible, thwarting in thisway the timing attack. Finally, the authentication mech-anism proposed in this paper can be adopted as abuilding block for many other RFID protocols as well.

As several of the proposals advanced in literature, ourscheme is particularly intended for RFID belonging toGeneration 2 (e.g., tags of classes 2, 3, or 4) with smallamount of RAM and some encryption capabilities [7].

Road map: The reminder of this paper is organizedas follows. In Section 2, an overview of related workin this area is reported. Section 3 presents the previ-ous works RIPP-FS and FastRIPP and exhibits howthose protocols are prone to timing attacks. Section4 introduces the reader authentication mechanism thatsensibly reduces this attacks and presents the eRIPP-FSprotocol, in which this mechanism is adopted. In Sec-tion 5, the simulation results of eRIPP-FS are shown.Finally, Section 6 highlights some concluding remarks.

2. Related Work

Security and Privacy of RFID systems is a challeng-ing research issue, as highlighted in Reference [1]. Inthe following, we report some of the most relevantprotocols proposed in literature.

One of the most known protocols introduced forRFID authentication was proposed by Molnar andWagner [8]: it uses a tree-based mechanism to authen-ticate and renew the identifier of a tag, with a cost of theorder of log N—where N is the number of consideredtags. The main drawback of the scheme is that it doesnot allow the batch mode neither the authentication ofmultiple tags.

A human identification protocol—HB [9]—, wasshown in Reference [10] to be practical for authentica-tion in low-cost pervasive devices. Hence, it could beused to enforce RFID tag authentication. In the samepaper [10], an improved version of HB, named HB+,was proposed to face not only a passive adversary but

Copyright © 2009 John Wiley & Sons, td. Security Comm. Networks. 2010; 3:58–70

DOI: 10.1002/sec

60 M. CONTI ET AL.

also an active adversary. A further work [11] showedthe vulnerability of the HB+ protocol against a manin the middle (MIM) attack. A fix to the MIM attackHB+ was subject to was proposed in Reference [12],through the HB++ protocol. However, HB++ wasproved in Reference [13] to be subject to a particularattack in which the adversary could gain knowledgeof the private key of the tag, hence jeopardizing theauthentication mechanism; this work also depicted asolution to this attack, through a modification of theHB++ protocol.

Many proposals make use of the idea to keep tagsand server synchronized over a one-time value that isupdated at each authentication using a one-way func-tion. A recent authentication protocol where privacy isenforced leveraging this idea is YA-TRAP [14]. How-ever, this protocol suffers from a DoS attack that canbe simply performed by a malicious reader. In partic-ular, every tag has a Tmax as the top value reachableby the time-stamp, that is after reaching this value thetag will not reply to the reader’s queries. Since the tagsupdate their time-stamp with a value provided by anyreader, an adversary could simply provide to the tags atime-stamp far in the future, to make the tag time-stampexceed the value Tmax. Moreover, this protocol does notguarantee the forward secrecy of the identity of the tag:an attacker capturing a tag can link to it a previouslyeavesdropped message originated by the corrupted tag.

Follow up of the YA-TRAP protocol [15--17] attemptto provide a solution to the security issues not addressedin the YA-TRAP protocol design. A complete analysisof other RFID identification protocols security pitfallscan be found in Reference [18].

In Reference [19], the A-TRAP protocol is intro-duced. This protocol offers a limited protection againstde-synchronization attacks: for attacks that interactwith a tag for a time period shorter than s sequentialtime units, this protocol offers provably secure authen-tication, forward-anonymity, and availability.

In Reference [2], a novel, efficient scheme to enforceidentification and authentication in RFID systems isproposed; this scheme leverages controlled informa-tion disclosure, and it is provably secure; however, itrequires a slight higher bandwidth overhead betweenthe tag and the reader.

In Reference [20], Ohkubo, Suzuki, and Kinoshitapropose a lightweight process for tag identification thatprovides indistinguishability and forward security. Theproposal is based on a hash chain and two different hashfunctions H and G: every tag is initialized with a secrets1 and uses the H function to renew the secret afterevery query (i.e., si+1 = H(si)). The reply sent to the

reader, instead, is determined via the G function, that isai = G(si). The back-end database maintains a list ofpairs (ID, si), that is used to check any reply ai receivedfrom the tags, with an exhaustive search. In Reference[21], Avoine and Oechslin modify the previous proto-col: the modification mitigates the scalability issue ofthe original scheme. The idea is to lower its computa-tional complexity using a time–memory trade-off thatreduces the amount of work needed to invert the one-way function, increasing the need for memory. Boththe schemes [20,21] do not offer protection against amalicious reader that attempts to de-synchronize theserver and the tags, hence resulting in a DoS attack.

Finally, the RIPP-FS protocol, proposed inReference [5], assures a series of security properties:privacy, authentication, and forward secrecy, with thepossibility to read many tags at once. The main ideabehind RIPP-FS is to make use of a Lamport hash chainto enforce authentication: when the reader has to sub-mit a query, it broadcasts a pair (Ti, RKi), where Ti isthe time of the reader and RKi is the associated value ofthe hash chain. To verify the authenticity of the query,a tag has to check if the provided value RKi is the valueof the chain expected at time Ti. To do this, a tag is ini-tially deployed with the values T0 and RK0: for the pair(Ti, RKi) to be authenticated, it has to verify the equa-tion RK0 = H (it)(RKi), where it = Ti − T0 and it > 0.If the pair (Ti, RKi) is authenticated, it can be used asthe new starting point for the verification process of thenext readings; moreover, the tag will reply to the readerwith a value that depends on the received time Ti anda private symmetric key (ki), shared with the server. Ifthe pair (Ti, RKi) fails authentication, the tag will replywith a pseudo-random message, indistinguishable froma correct reply. At each veritable reader authentication,the symmetric key is updated via a one-way-hash-function that takes in input both the old key and thereceived time Ti (ki+1 = h(ki‖Ti)) attaining forwardsecrecy. Further details can be found in Reference [5].

The feasibility of implementing a hash function onRFID tag has been proved in References [22--24], tocite a few. In the following, we will leverage the capa-bility of a tag to compute a hash function. In particular,we assume a tag can compute log n times a hash func-tion during a single reader query—where n is an upperbound on the total number of queries a tag is subjectto. This assumption is coherent with the literature [2,8],where the number of hashes a tag is required to com-pute for each single query is order of the total numberof considered tag, N. For practical scenarios it is rea-sonable to consider log n = c log N, for some smallconstant c (e.g., c = 2). Indeed, if N = 65, 536 we


DOI: 10.1002/sec


have log N = 16 and log n = 2 log N = 32, where 232

queries seem a practical upper bound.

3. Background and Timing Attacks

In this section, we expose the basic techniques RIPP-FSand FastRIPP rely on and highlight how those proto-cols are affected by two main computational issues.Both issues are caused by the synchronization betweenthe reader and the tags and make possible somemalicious tracking attacks, based on differential poweranalysis [25] and timing attack [4]. In the following,we informally introduce some security notion relatedto RFID context that will be used in the next of thepaper:

� Key secrecy: There is no lack of information about acryptographic key during a communication process.In other words: the only way to recover the key(s)used by the tag to secure communication with readeris to read the memory of the tag.

� Privacy protection: A passive attacker (that eaves-drops all the reader-tag communications) cannotdistinguish two answers of a same tag.

� DoS resiliency: An active attacker cannot make a tagno more identifiable by a honest reader (jammingattacks are not considered).

� Forward secrecy: The attacker cannot relate any pre-vious reading(s) of a tag (or set of tags) to a furthercaptured tag (or set).

� Timing attack resiliency: The attacker cannot distin-guish if a tag is synchronized or de-synchronized.

3.1. Updating the Tag Secret Key

RIPP-FS [5] proposed a complete solution to iden-tification of RFID tags with privacy preserving andforward secrecy. The main idea is to renew the secretof a RFID tag, after each tag-reader interaction. Thisidea was firstly introduced in Reference [20]: afterthat, many other protocols adopted the same idea suchas References [21] and [17]. The intuition is easy andelegant. The tag and the back-end server start sharinga unique secret key k1: the tag will use k1 to build thereply to a server query and will renew the key aftereach identification, using two different hash functionsG(·), H(·), as shown in Figure 1. One hash function(G(·)) is used to compute the reply the tag will sendto the reader, using the secret shared key k1 as a seed.The second hash function (H(·)) is used to renew thesecret key. Hence, the tag will compute a different

Fig. 1. An RFID tag computes the reply ai = G(ki) andrenews its secret key ki+1 = H(ki), as in Reference [20].

reply for every reading, hindering the tracking of thetag as well as providing forward secrecy.

The back-end database maintains a list of pairs (ID,ki), one for each tag, and it will access the list everytime it receives an ai value. To identify a tag, thedatabase must be able to link the received ai to theright ki in spite of the fact that the ki as been renewed.In References [20], [21], and [5] different solutionsare provided to this issue.

Ohkubo et al. in Reference [20] propose an exhaus-tive search of ai and the computation of two hashfunctions for all candidates in the database, startingfrom the initial value k1. This solution has a high costfor the back-end server in terms of hash calculations:each value ai received from the reader should be com-pared with each database entry.

Avoine and Oechslin [21] propose an improvementof the previous solution, mitigating the manifest scala-bility issue of the original scheme. The idea is to reducethe complexity of the original solution, introducing acomputation/memory trade-off: the back-end servermust store in its database some special hash chainsobtained applying a family of ‘reduction functions’ tothe values replied by the tags. The server will use suchhash chains to reduce the amount of work needed toinvert the one-way function, since a lower number ofhash applications is required for the identification of atag. Actually, such hash chains have to be pre-computedand stored by the back-end server, hence the ‘memorytrade-off’.

RIPP-FS [5], inspired by Reference [14], proposes adifferent approach, introducing key lookup tables thatare regularly updated with the time t: for each tag,a key lookup table for time t contains the expectedvalue the tag should provide at that time. The valuesai are the result of HMAC functions [26] applied onthe time t, keyed with the renewed key ki, namelyai = HMACki (t). Receiving an identification valueai from the reader at a given time t, the back-enddatabase can efficiently find in the table which tag ownsthe key used to compute ai. Such lookup tables enjoythe following properties:


DOI: 10.1002/sec

62 M. CONTI ET AL.

� the identification protocol requires just two mes-sages;

� tables can be pre-computed, avoiding the server real-time/on-the-fly computations;

� the batch mode of operation can be leveraged, thatis, the reader can scan multiple tags and collect allthe replies, delaying the effective identification of thetags to a subsequent time.

The batch mode can be useful if the reader has no accessto the back-end server, for instance because the latteris off-line, or over-loaded, or it suffers temporary con-nection problems. A more detailed analysis of the batchmode can be found in Reference [17]. However, the effi-cient solution proposed in Reference [17] introducesa certain degree of synchronization between the tagsand the server: a tag has to update its secret key at thesame time of the server; this way the tag can reply withthe ai expected by the server. This kind of synchro-nization was not taken in account in Reference [20],neither in Reference [21], since the association ai ↔ ki

is done via exhaustive search, ignoring the dependenceof the value ai on time t. In RIPP-FS as well as inReference [14], to be synchronized, the reader activelysends for each identification the time t to the tags, sothat the tags can compute the reply expected by theserver. More precisely, every tag stores the last receivedtime tstored and the last renewed key kstored; when thetag receives from the reader the new time ti > tstored, itwill renew the key as many times as needed. Namely,the tag will compute it = ti − tstored and will apply ititerations of the hash function H(·) to the key kstored.The resulting key ki becomes the new kstored, and it isused to generate the reply ai the tag will send to thereader: ai = HMACki (ti). Since the key is never trans-mitted, but only used to evaluate the reply once beforebeing updated via a non-invertible function, forwardsecrecy is obtained: even if the adversary captures atag and extracts the key ki, he will be unable to recoverany key kj with j < i and to link any previous value aj

to that tag.As introduced in the previous section, tags and reader

share a value v of a Lamport chain, associated to thelast time tstored received by the reader. Each time thereader wants to query a tag at time ti, it also disclosesthe corresponding value vi of the chain, as authentica-tion token. The tag, before to perform the key-updateprocess and to send the correct reply ai, uses the value vto check if the received token is valid, namely if it cor-responds to the value vi related to the time ti > tstored ofthe Lamport chain. If this check fails, the tag does notupdate its key and replies with a pseudo-random value.

The use of a pseudo-random reply in case of wrongreader authentication makes useless any type of replayattack: even replying an authentic token, the adversarythat does not know the key of a tag (shared only withthe server) is unable to distinguish between a correctanswer and a pseudo-random reply. This is assuredbecause the correct answer is computed it via an HMACfunction: any answer provided by the tag looks like arandom number, generated by either the HMAC func-tion or by the pseudo-random generator.

The main drawback introduced by synchronizationin RIPP-FS is that when a tag loses many readings,the number of hash iterations (it) required to updatethe key can be significantly large and consequently canintroduce a noticeable delay before providing the reply.To reduce this delay, next section introduces the secondbuilding block of our eRIPP-FS protocol, that is thefractal hash chain traversal technique.

3.2. Fast Resynchronization with FractalHash Chain Traversal

To shorten the time required to renew the shared key,in the case a tag missed some queries, FastRIPP [6]introduced a new resync procedure. This procedureexploits a mechanism based on the hash chain traversalamortization technique proposed by Jakobsson [27].While this technique was thought to efficiently com-pute the consecutive pre-images of a hash chain, itscore mechanism can be also used to efficiently com-pute the values of a hash chain. The solution proposedby FastRIPP inherits the concept of pebble table,namely a data-structure that maintains a few values ofthe hash chain and amortizes the cost of its update eachtime it has to output a value. Our idea is to leveragethe fractal hash traversal to pre-compute some furthervalues of the chain. These values are used to speed-upthe output computation in the case the tag loses somereader’s queries. A simple example follows. Assume atag computes the value of the currently used hash chainposition, e.g. v1 for time t1, and then it loses manynext reader’s queries, e.g. 100 queries. Without thefractal hash pre-computation at the next query, the tagshould apply the hash function 101 times. Instead, ifat time t1 the tag already computed some further valueof the chain (a pebble), say the 50th, after loosing 100queries it only has to apply 51 times the hash function.In general, if n is the length of the chain, the pebbletable is made of O(log n) pebbles. In our scenario n,the length of the chain, corresponds to an upper boundon the total number of queries made by the reader. Foreasy of exposition we assume n = 2m, for some natural


DOI: 10.1002/sec


number m. Pebbles can be considered as markersthat move on the chain: each pebble has a position,a destination, and a hash value vj , corresponding toits position in the chain, i.e. a pebble in position istores the value vi of the chain. Each pebble moves ifits position is different from its expected destinationand makes a few little steps toward its destination anytime a new value of the chain has to be output (i.e., foreach reader’s query). An accurate initial distributionover the chain and the constant update of the pebbletable makes possible the resynchronization in a reallyefficient way, with a resync procedure that requiresjust O(log n) hash computations.

The procedure is the following: given the positionsof the pebbles associated to the last output value kstored

(synchronized with the reader time tstored) and the newreader time ti, the tag has to evaluate ki. The tag findsthe pebble pz in the position tz closer to ti (i.e., tz < ti)and leverages the value kz of the pebble as startingpoint for the iteration process. That is, located pz, itcomputes the missing steps t = ti − tz and evaluateski as ht(kz), that is h(h(..h

︸︷︷︸

t

(kz))..). Figure 2 shows the

Fig. 2. Example of FastRIPP pebble movements: a pebble inposition i stores the key ki; moving from position i to position

i + 2 implies to evaluate ki+2 = h(h(ki)).

displacements of pebbles during subsequent steps ofthe procedure.

Algorithm 1 reports the pseudo-code of the resyncprocedure, where we assumed that the pebbles are orga-nized in a table P. Steps 1.10 and 1.11 are used to movethe pebbles in the expected position as for time ti. Weassumed that a tag could evaluate 2m hash functionsevery reading: it will exploit all the iterations not usedin the previous steps to bring the pebbles in the ‘stablestate’, that is in the positions they should be as if theywere regularly updated, without any reading lost.

For example, pebble p3 lies in position 4. Whenthe value v4 is output, p3 will move to position 16(the initial position of pebble p5) and will receive asnew destination the position 12. When v5 is output, p3moves to position 14; similarly, when v6 is output, p3moves to position 12, reaching its destination. Again,when v12 is output, p3 will jump to position 24 and willreceive as new destination position 20.

The pebbles movements to reach their destinationsare reported in Figure 3: it shows the positions of thepebbles related to the widest intervals with m = 28,as they were always perfectly synchronized with thereader time. It is possible to evince a recurrent evo-lution, composed of three phases: a stationary phase,a jump phase, and a sliding phase. The stationaryphase corresponds to the pebble lying in its destina-tion, that can be its initial position or the end of itsmovement.


DOI: 10.1002/sec

64 M. CONTI ET AL.

Fig. 3. Position of some selected pebbles according to the current time.

The jump phase happens when the reader outputsthe value associated to the position of the pebble: thisreceives a new destination and moves into the positionof the pebble closer to its destination. Notice that,this phase happens during one single reader query.The figure shows that the position a pebble jumps to(namely, the starting point of the next adjacent intervalof the same size) is occupied by another pebble byconstruction.

The sliding phase follows the jump phase and takesseveral consecutive reader queries. During this phase,the pebble moves toward its destination, going forward2 positions per reader query.

For example, the pebble 7 is initially deployed inposition 64; when this value is output, the pebble ismoved (jumps) to position 128, already occupied bypebble 8. During the next readings, the pebble contin-ues sliding forward to reach position 192: it gets thatposition when the value in position 96 is output. Whenthe position of pebble 7 is reached again by the reader,the pebble moves to position 256, its final destination.

Further details about this technique and a muchdeeper explanation are provided in References [6] and[27]. Section 5 describes the results of our simula-tions, showing the effective speed-up obtained whenemploying fractal hash traversal.

3.3. Timing Attack on FastRIPP

FastRIPP protocol presented an efficient way to solvethe tag key synchronization issue of the original

RIPP-FS protocol, as described in Section 3.2. Whilethe slow resynchronization was the main drawback ofRIPP-FS, another issue is left open by FastRIPP: theverification process of the authenticity of the readerquery. During a reader query, the tag receives froma reader the time ti and a message authenticationtoken vi: this value is the element with index i of aLamport hash chain. Before providing a correct reply(and updating the secret key), a tag has to verify theauthenticity of the query, checking that v0 = hti (vi).If the check fails, the tag will not update its key andwill reply with a pseudo-random value. If the checksucceeds, the tag updates its secret key and generatesthe right reply to be provided to the reader. Note that,the check v0 = hti (vi) can be speeded-up storing thenewest value vj verified in the last valid reading, with0 < j < i. In such a way, the number of iterations canbe reduced from ti to i − j; however, the cost in termsof hash computations can be still high (namely, it islinear in the number of the lost readings). The timeneeded to compute i − j hash (or, even worse, ti) canbe exploited by a malicious reader to implement somesophisticated tracking attacks, based on timing attack[4] or differential power analysis [25]. Both thesetechniques are extremely powerful analysis tool thatcan be exploited to extract secret keys from crypto-graphic devices. These attacks are not aimed to exploitthe security of an algorithm itself; they aim, instead,to analyze the time a system takes to respond to aspecific queries in order to extract information relatedto the security of the system itself. The peculiarity of


DOI: 10.1002/sec


those attacks is to relay more on the implementationof a specific algorithm, then on its own security:in Reference [28] Josher introduces many practicaltechniques to attack implementations of the mostsecure cryptographic schemes (as Diffie-Hellman,RSA, and DSS), showing how to extract exponentsand keys with simple, but accurate, measurements.For example, if an algorithm takes x �sec to processa 0 bit of a key and y � x �sec to process a 1 bit, themeasurement of the total processing time can leak thenumber of 0 bits of a key. If the response time is alwaysx �sec, there were no possibility to mount timingattacks. On the same time, making the response timeof an algorithm independent from its input data shouldnot compromise the efficiency of the algorithm itself.

In such scenario, fast and power machines makethose attacks harder to realize, since require theuse of more sophisticated devices to obtain accuratemeasurements. On the other side, devices with lowcomputational power tend to stretch time required byany single operation, accentuating the dependency onthe time of an algorithm. Since RFIDs are commonlyknown as power constrained devices, unable to useindependent power sources and to exploit fast CPUs,such systems are specially exposed to timing attacks.

4. Merkle Tree for Reader’s QueryAuthentication

To reduce the computational cost and to thwart theabove mentioned attacks, we propose to implement averification process that involves the use of a Merkletree. Note that with this solution the verification pro-cess for a query is fixed to log n hash computations,independently from the number of lost readings. Inthe following, we adopt of the notation summarizedin Table I.

4.1. The Core Idea

A Merkle tree is a tree in which each leaf is the hash ofthe value to be authenticated while the internal nodes

Table I. Summary of notation.

n Number of authenticated readingsti Time ivi Value for reader authentication at tim Height of the Merkle treeH Hash value of the root of the Merkle treeh Hash functionuk

j jth internal node of level k of the Merkle tree

Fig. 4. Example: the reader sends the authenticated query attime ti.

are the results of the hash of the concatenation of theirown children.

Figure 4 presents an instance of the Merkle tree usedto authenticate the messages of the reader. We build theMerkle tree in the following way:

1. a sequence of n random values v1, . . . , vn is gener-ated (for simplicity n = 2m);

2. every vi is bounded/associated with a time ti;3. a binary tree is built where:

• the leaves are all the pairs vi, ti (ordered w.r.t. thetimes ti)

• the internal nodes at level 1, that will be denotedas u1, . . . , um are hash values obtained evaluatingui = h(vi, ti);

• every internal node ukj at level k is the hash value

obtained evaluating h(uk−12j−1, u

k−12j );

• the root is um+11 , and will be denoted as H.

4. all the tags receive the value H.

Once the tags are deployed, they will update their key aswell as providing a reply, only if reader authenticationsucceeds.

4.2. Authentication

To generate a message that a tag can later authenti-cates, the reader sends for every reading: the values ofthe leaves related to time i and the values of all of thesiblings of the nodes on the path to the root. Referringto Figure 4, the root is H and the reader wants to authen-ticate the values v4, t4, with path to the root u4, u1

2, u21.

Then, it will send the values v4, t4, u3, u11, u2

2; note thatthe length of such a message is just log n + 1.

To verify the authenticity of the message receivedfrom the reader, every tag checks whether the receivedvalues can be used to derive the root H. With ref-


DOI: 10.1002/sec

66 M. CONTI ET AL.

erence to the above example, tags have to verifythat h(h(u1

1, h(u3, h(v4, t4))), u22) = H . The computa-

tional cost to authenticate a message is of log n hashonly.

4.3. The eRIPP-FS Protocol

The new eRIPP-FS protocol is made on three mainbuilding blocks, namely:

1. the renewal of the secret key used to identify the tagafter every query—to enable privacy and forwardsecrecy;

2. the algorithm based on the fractal hash chain traver-sal [27] (Section 3.2)—to speed-up the computationof the tag reply;

3. the above introduced algorithm, based on the Merkletree (Section 4)—to authenticate the query of areader.

Combining these three elements, the eRIPP-FSprotocol is able to provide: key secrecy, readerauthentication, privacy in tag identification, forwardsecrecy, and DoS resilience, while granting a fastre-synchronization.

The eRIPP-FS protocol executed by the tag can besummarized as

(i) it receives a token from the reader;(ii) it evaluates the authenticity of the received token.

To do so the tag needs to reckon the sequence ofvalues embedded in the token. In particular, the ithas to reconstruct a leaf-root path of the Merkletree using the received values and to check whetherthe obtained root matches with the authenticatedvalue H.

(iii) it sends to the reader the correct reply, only if thetoken is authenticated;

(iv) it updates its secret key and compute the rightanswer for the reader. To do so, the tag uses itspebble table invoking the resync procedure.

Algorithm 2 shows the corresponding pseudo-code,while details follow:

� Step 2.2: the tag receives from the readerthe authentication value vi, the actual time tiand the sequence used to authenticate ti: ubr(i),u1

un(br(i)), . . . , um−1unm−1(br(i)). The function br(i) gives

the subscript index of the sibling of ui: that isbr(i) = i + 1 if i is odd and i − 1 otherwise. Thefunction un(i) gives the subscript index of the ‘uncle’

of ui: that is un(i) = �i/2� + 1 if �i/2� is odd and�i/2� − 1 otherwise.

� Step 2.3: the tag computes the number it of lost read-ings.

� Step 2.4: the tag verifies that the received time isgreater than the time associated to the authenticatedmessage and that the received sequence matches theroot H of the Merkle tree, as described in the previoussection.

� Steps 2.5–2.7: if the check succeeds, the tag updatesits key (ki) and computes the reply for the reader.

� Step 2.9: if the check of the received authenticationfails, the tag generates a random reply to be sent.

� Step 2.10: the tag sends to the reader the messagebuilt as detailed above.

Remember that the random reply of Step 2.9 cannot beforeseen by an adversary without the compromising ofthe tag itself. Then, an adversary that does not knowthe shared key ki, even if it can eavesdrop Step 2.10cannot distinguish if Hi was evaluated via the HMACof Step 2.7 or via the PRNG of Step 2.9.Computational complexity. First, assume a tag is syn-chronized with the server. In this case, it will requirelog n hashes in order to authenticate the reader, onehash to updated its private key and O(log n). Hence,the overall overhead is O(log n).


DOI: 10.1002/sec


Fig. 5. Average reply time (in terms of hash operations): comparison with RIPP-FS for m = 8.

However, if the tag gets de-synchronized, it will com-pute log n hashes in order to authenticate the reader.As far as the hash operations required to update thetag’s private key, we performed extensive simulationsto study this case as reported in next section.

5. Simulations and Discussion

The timing attack the original RIPP-FS protocol [5]was subject to is related to the following protocol’scharacteristic: a tag that is ‘synchronized’ with thereader (i.e., the tag answered to all of the honest read-ings the reader made) needs less time to answer the nextreading compared to a tag that is ‘not synchronized’.In this way, an attacker can replicate a reader query to atag in order to understand if this tag was synchronizedwith the reader or not.

In this section, we investigate through simulationsthe exposition of the eRIPP-FS protocol, proposedin this paper, to the timing attack. Since the cost ofan authentication is constant when tag and server aresynchronized, we evaluate the performances of ourprotocol only in extreme scenarios, assuming tag andserver are severely de-synchronized.

First, we observe that the reader authentication mech-anism used by eRIPP-FS (Section 4) requires to asynchronized tag an higher number of hashes (i.e., moretime) in order to authenticate the reader, if comparedto its previous versions [5,6]. However, it requires,

to both synchronized and non-synchronized tags, thesame constant number of hashes (i.e., constant time):(m applications of hash function on the tag side, twohash invocations on the reader side). As a result, theattacker cannot relies on this part of the eRIPP-FSprotocol to distinguish between synchronized and non-synchronized tag. So, in this section, we report thesimulations investigation for the other part of the eRIPPprotocols, inherited by FastRIPP, which time execu-tions actually depends on the tag status: synchronizedor not. In particular, higher is the number of readingsthat the tag lost, higher is the time the tag will requireto update its own key. Note that, the number of hashapplications directly affect the response time. Further,the time taken to perform these computations couldbe used to perform timing attack: reducing this timeto an almost constant value, would greatly improve theresilience to this type of attack. We simulated the resyncprocedure, based on the algorithm shown in Section3.2. Our simulations consisted in keeping a tag syn-chronized until a certain reading and counting, fromthat stable state, how many hash evaluations it hasto perform to correctly reply to a subsequent reading,assuming lost all the readings in the between.

Figures 5 and 6 report the average number ofhash applications with respect to the number of lostreadings. Namely, in each plot of the figures, the x-axisrepresents the number of readings lost by the tag, whilethe y-axis is the average number of hash iterations toupdate the secret key kstored and to compute the right


DOI: 10.1002/sec

68 M. CONTI ET AL.

Fig. 6. Average reply time (in terms of hash operations): comparison with RIPP-FS for m = 14. The small box is a magnificationof the interval [0:256].

reply. To evaluate the average, we fixed the value x andcounted the number of hash applications for all thepossible stable states of a tag. Notice that, a tag in a sta-ble state can have several pebbles moving toward theirdestinations: the dynamism of the pebbles affects thecost of the resync procedure. Considering all the pos-sible stable states in our simulations allowed to capturethe influence of the moving pebbles on the resync cost.

Figures 5 and 6 reports the results collected for thesimulations with m = 8 and 14, respectively. Further-more, Figure 6 also shows a magnification for theinterval [0:256] in the small plot in the box. For compar-ison, the plots also report the values of the RIPP-FS pro-tocol, that are linear w.r.t. the number of lost readings.

It can be observed the strong correlation of the resultswith the pattern of the resync procedure. In particular,two main fractal properties emerge: the scaling prop-erty and the self-similarity property. Again, the samescaling property of the fractals can be observed for dif-ferent values of m. As an example, the plot for m = 8(in Figure 5) is a scale of the plot shown for m = 16,shown in Figure 6.

The self-similarity property of the fractals is reflectedby the similarity of the shape at different magnifica-tions. This property is underlined by the small box inFigure 6: if we start from the plot of the interval [0:216]and compare it with the magnification of the intervals[0:215], [0:214], and so on, we will see always the sameshape trend, with the characteristic ‘humps’. These

humps are caused by the dynamism of the pebbles: if apebble is still moving toward its destination, it will bea starting point farther than if it were lying in its desti-nation. So, when a tag exploits a moving pebble in theresync procedure, it receives ‘less advantage’ insteadof exploiting a lying pebble. Both plots also report thestandard deviation of the reply time experienced in oursimulations: the number of hash operations a tag has toperform does not deviate too much from the average.This highlights as the average can be considered as agood estimator of the eRIPP-FS performances.

In Figure 7, we reported the average resynchroniza-tion time, namely the number of readings that a tag hasto exploit to return to a stable state. This measure char-acterizes how fast a tag can reset its pebbles to be ableto quickly recover subsequent lost readings. To obtainthese plots, we counted, for all of the possible num-ber of lost readings, the average number of subsequentreadings a tag has to use to reach a stable state. The aver-age was taken in account considering for every numberof lost queries, the subsequent readings to exploit fromevery possible stable states. We assumed that a tag cancompute 2m hash every reading; these computationsare used to update the pebbles.

The plots in Figure 7 shows the results for n = 12.Comparing this Figure with the plots for n = 10 (notreported for space limitation) the same scaling propertyof the plots for the reply time can be observed. Recov-ering a stable state after 200 lost readings requires only


DOI: 10.1002/sec


Fig. 7. Average resynchronization time (in terms of readings), n = 12.

five queries for n = 12 and six queries for n = 10.Again, the relatively small standard deviation helpsto notice that the average can be considered a ‘tight’measure.

6. Conclusions

Many RFID authentication techniques require that thetag and the reader keep a form of synchronization. Inparticular, this is recurrent when the security mecha-nism is based on hash chain. Generally, if the tag and thereader get de-synchronized, the aftermath could jeop-ardize security and/or privacy. Indeed, if the attack canexploit the re-synchronization, it can result in a DoS oreven more harming attacks.

In this paper, we have introduced a mechanism basedon fractal hash traversal and Merkle tree that providesmutual reader-tag authentication. This solution has asa side effect to thwart de-synchronization. We haveproposed eRIPP-FS, a security protocol implement-ing these mechanisms. Extensive simulations showthat, introducing a negligible overhead on the tagside, the tag and the reader can easily recover fromde-synchronization. The recovery is performed withalmost negligible overhead, thwarting timing attack aswell.

Finally, the proposed solutions can be transparentlyand independently applied to similar secure protocolsas well.

Acknowledgement

This research was supported in part by the SpanishMinistry of Science and Education through projectsTSI2007-65406-C03-01 ‘E-AEGIS’ and CON-SOLIDER CSD2007-00004 ‘ARES’, and by theGovernment of Catalonia under grant 2005 SGR00446. The EU FP6 projects: ‘European SatelliteCommunications Network of Excellence’ (SatNEx II,IST-27393); PERSONA (contract N. 045459); INTER-MEDIA (contract N. 38419). The authors thank theanonymous reviewers for their helpful comments.

References

1. Juels A. RFID security and privacy: a research survey. IEEEJournal on Selected Areas in Communications 2006; 24(2): 381–394.

2. Di Pietro R, Molva R. Information confinement, privacy, andsecurity in RFID systems. In 12th European Symposium onResearch in Computer Security (ESORICS’07), 2007; 187–202.

3. Weis SA, Sarma SE, Rivest RL, Engels DW. Security and pri-vacy aspects of low-cost radio frequency identification systems.In First International Conference on Security in Pervasive Com-puting, 2003; 201–212.

4. Brumley D, Boneh D. Remote timing attacks are practical. Com-puter Networks 2005; 48(5): 701–716.

5. Conti M, Di Pietro R, Mancini LV, Spognardi A. RIPP-FS: an RFID identification, privacy preserving protocol withforward secrecy. In Proceedings of the Fifth Annual IEEEInternational Conference on Pervasive Computing and Commu-nications Workshops (PERCOMW’07), 2007; 229–234.


DOI: 10.1002/sec

70 M. CONTI ET AL.

6. Conti M, Di Pietro R, Mancini LV, Spognardi A. FastRIPP: RFIDprivacy preserving protocol with forward secrecy and fast resyn-chronization. In 33th Annual Conference of the IEEE IndustrialElectronics Society (IEEE IECON 07), 2007.

7. Corporation AT. EPCglobal class 1 gen 2 RFID specification.Whitepaper, 2005.

8. Molnar D, Wagner D. Privacy and Security in Library RFID:Issues, Practices, and Architectures. ACM Computer and Com-munications Security (CCS’04), 2004.

9. Hopper NJ, Blum M. Secure human identification protocols. InProceedings of the 7th International Conference on the The-ory and Application of Cryptology and Information Security(ASIACRYPT’01), 2001; 52–66.

10. Juels A, Weis S. Authenticating pervasive devices with humanprotocols. Advances in Cryptology (CRYPTO’05), LNCS 2005;3126: 293–308.

11. Gilbert H, Robshaw M, Sibert H. An active attack againstHB+—a provably secure lightweight authentication protocol.Cryptology ePrint Archive, Report 2005/237, 2005.

12. Bringer J, Chabanne H, Emmanuelle D. HB++: a lightweightauthentication protocol secure against some attacks. In IEEEInternational Conference on Pervasive Services, Workshop onSecurity, Privacy and Trust in Pervasive and Ubiquitous Com-puting (SecPerU’06), 2006; 28–33.

13. Piramuthu S. HB and related lightweight authenticationprotocols for secure RFID tag/reader authentication. Col-laborative Electronic Commerce Technology and Research(CollECTeR’06), 2006.

14. Tsudik G. YA-TRAP: Yet another trivial RFID authentica-tion protocol. In Proceedings of the Fourth Annual IEEEInternational Conference on Pervasive Computing and Commu-nications Workshops (PERCOMW’06), 2006l; 640.

15. Burmester M, van Le T de Medeiros B. Provably secure ubiq-uitous systems: Universally composable RFID authenticationprotocols. In Conference on Security and Privacy for EmergingAreas in Communication Networks (SecureComm’06), 2006.

16. Chatmon C, van Le T, Burmester M. Secure anonymous RFIDauthentication protocols. Technical Report TR-060112, FloridaState University, Department of Computer Science, Tallahassee,Florida, USA, 2006.

17. Tsudik G. A family of dunces. In Proceedings of the SeventhWorkshop on Privacy Enhancing Technologies (PET’07), 2007,pp. 45–61.

18. Juels A, Weis SA. Defining Strong Privacy for RFID. In Proceed-ings of the Fifth IEEE International Conference on PervasiveComputing and Communications Workshops (PERCOMW’07),2007; 342–347.

19. van Le T, Burmester M, de Medeiros B. Forward-secure RFIDauthentication and key exchange. Cryptology ePrint Archive,Report 2007/051, 2007.

20. Ohkubo M, Suzuki K, Kinoshita S. Cryptographic approach to“privacy-friendly” tags. In 2003 MIT RFID Privacy Workshop,2003.

21. Avoine G, Oechslin P. A scalable and provably secure hash basedRFID protocol. In International Workshop on Pervasive Comput-ing and Communication Security (PerSec’05), 2005; 110–114.

22. O’Neill (McLoone) M. Low-cost SHA-1 hash function architec-ture for RFID Tags. In Conference on RFID Security, 2008.

23. Paise R, Vaudenay S. Mutual Authentication in RFID: Securityand Privacy. In ACM Symposium on Information, Computer andommunications Security (ASIACCS’08), ACM Press, 2008; 292–299.

24. Shamir A. Squash: a new one-way hash function with provablesecurity properties for highly constrained devices such as RFIDtags. In Conference on RFID Security, 2007.

25. Kocher PC, Jaffe J, Jun B. Differential power analysis. InProceedings of the 19th Annual International CryptologyConference on Advances in Cryptology (CRYPTO’99), 1999;388–397.

26. Bellare M, Canetti R, Krawczyk H. Keying hash functions formessage authentication. In Proceedings of the 16th Annual Inter-national Cryptology Conference on Advances in Cryptology(CRYPTO’96), LNCS, vol. 1109, Springer, 1996; 1–15.

27. Jakobsson M. Fractal hash sequence representation and traversal.In Proceedings of the 2002 IEEE International Symposium onInformation Theory (ISIT’02), 2002; 437–444.

28. Kocher PC. Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems. In Proceedings of the16th Annual International Cryptology Conference on Advancesin Cryptology (CRYPTO’96), 1996; 104–113.


DOI: 10.1002/sec

eripp-fs: enforcing privacy and security in rfid

Documents