Multi-tag and multi-owner RFID ownership transfer in supply chains

Decision Support Systems 52 (2011) 258–270

Contents lists available at SciVerse ScienceDirect

Decision Support Systems

j ourna l homepage: www.e lsev ie r .com/ locate /dss

Multi-tag and multi-owner RFID ownership transfer in supply chains

Gaurav Kapoor a, Wei Zhou b,c, Selwyn Piramuthu a,c,⁎a Information Systems and Operations Management, University of Florida, Gainesville, FL 32611-7169, USAb Information and Operations Management, ESCP Europe, Paris, Francec RFID European Lab, Paris, France

⁎ Corresponding author at: Information Systems andOpeof Florida, Gainesville, FL 32611-7169, USA.

E-mail addresses: [email protected] (G. Kap(W. Zhou), [email protected] (S. Piramuthu).

0167-9236/$ – see front matter © 2011 Elsevier B.V. Alldoi:10.1016/j.dss.2011.08.002

a b s t r a c t
a r t i c l e i n f o
Article history:Received 28 January 2011Received in revised form 31 May 2011Accepted 1 August 2011Available online 16 September 2011

Keywords:RFIDOwnership transferSupply chain

In any supply chain, there is a high likelihood for individual objects to change ownership at least once in theirlifetime. As RFID tags enter the supply chain, these RFID-tagged objects should ideally be able to seamlesslyaccommodate ownership transfer issues while also accomplishing their primary intended purpose. Physicalownership transfer does not translate to strict ownership transfer in the presence of RFID tags given the wire-less nature of communication with these tags. Moreover, whereas existing protocols implicitly assume a sin-gle tag that is owned by a single entity, it is not uncommon to encounter scenarios where tag ownership isshared among multiple entities. A dual of this is the case of an object with multiple tags. We consider own-ership transfer scenarios for shared ownership transfer and single object with multiple RFID tags. In the mul-tiple-tagged object case, we consider the possibility where objects gain and lose tags over time. We alsopresent a protocol for simultaneous transfer of ownership of multiple tags between owners. Since ownershiptransfer without a trusted third party (TTP) is difficult to achieve, we propose a shared ownership sharingprotocol and evaluate its properties.

rationsManagement, University

oor), [email protected]

rights reserved.

© 2011 Elsevier B.V. All rights reserved.

1. Introduction

Ownership transfer issues are common in most supply chainswhere these issues are somewhat readily accomplished when dealingwith physical objects (vs. for example, electronic means). In suchcases, ownership transfer could involve the transfer of a physical ob-ject from the previous owner to the current owner —i.e., after theownership transfer process, the current owner is likely (but not nec-essarily) in physical possession of the object. This process gets com-plicated with the incorporation of item-level RFID-tags to objectsthat move through supply chains simply because of the need to trans-fer ownership both physically and otherwise. For example, a previousowner could possibly continue to remain in (RF) contact with anRFID-tagged object even after the object transfers ownership to anew owner. Therefore, physical ownership transfer does not neces-sarily translate to complete ownership transfer whereby a previousowner cannot access the object of interest after ownership transfer.Researchers and practitioners have addressed this issue throughcryptography.

RFID cryptography has been a very active area for researchers overthe past decade (e.g., [19,20]) to address issues such as authenticationof RFID-tagged objects. A few of these researchers have also devel-oped and studied RFID ownership transfer protocols over the past

several years. A majority of these protocols have been developed forthe single-tag single-owner case with and without the presence of atrusted third party (TTP). An example of a TTP could be a bank orany neutral third party that all members involved in a (here, owner-ship transfer) transaction trust. Since it is common for RFID-taggedobjects to be owned by a single owner at any point in time and anobject is commonly tagged with a single RFID tag, existing protocolsaddress the dynamic associated with these scenarios.

While not as common as the single-tag single-owner scenario, it isnot uncommon for the existence of shared ownership (i.e., an itembeing owned simultaneously by several owners) as well as objectswith multiple RFID tags. Extant RFID ownership transfer literaturedoes not adequately address these scenarios. The purpose of thispaper, therefore, is to fill this gap and propose ownership transferprotocols that are specifically meant for multi-tagged or multi-owner objects as well as scenarios where multiple tags that arerequired to be present together simultaneously transfer ownership.

1.1. Shared ownership transfer

Over its lifetime, an RFID tag can be associated with one or severalowners. Although the single RFID tag ownership scenario is common,it is not uncommon for situations that dictate shared (i.e., multiple)ownership of tags. Examples of shared ownership include VendorManaged Inventory (VMI) in retail stores [25], and access to a taggedobject by multiple entities such as PDA, refrigerator, etc. in a smarthome.

http://dx.doi.org/10.1016/j.dss.2011.08.002

mailto:[email protected]



http://dx.doi.org/10.1016/j.dss.2011.08.002

http://www.sciencedirect.com/science/journal/01679236

259G. Kapoor et al. / Decision Support Systems 52 (2011) 258–270

Using a secure RFID system for inventory management in the sup-ply chain complicates this process. Since the inventory data is basedon information provided by RFID tags, and these tags can only beaccessed by valid owners/readers, the authorization/ownership need-ed to access tags has to be shared by all related owners. In otherwords, the tag has to be simultaneously visible to multiple entities inthe supply chain. Operationalizing such a scenario requires communi-cation protocols (for the tag/reader authentication process) that ad-dress this issue. A single-tag single-owner ownership transferprotocol may not necessarily scale well when applied to shared own-ership. Moreover, although the number of owners who gain access toany given shared tag may increase, the capabilities of the tag itselfwith respect to its processing power and memory do not change.This necessitates utilizing only lightweight cryptographic means indeveloping necessary protocols.

1.2. Objects with multiple tags

While security/privacy authentication protocols consider single-tagged objects, objects with multiple tags do exist and there is aneed to address security/privacy issues in this context. We extendour authentication and ownership transfer protocols for configura-tions where multiple tags may be associated with an object. Depend-ing on the shape of a tagged object, it is likely that embedding justone tag may result in high read rate error. It is common for certain ob-jects (e.g., boxes) to be affixed with several tags, one on each of itsseveral sides for example, to increase its probability of being scannedby the reader thereby improving its read rate accuracy [24]. Anotherscenario where multiple-tagged objects may be present is when anobject is assembled from several RFID-tagged component parts.Here, although each of the tagged component is distinct they are sim-ilar in that they all are a part of this aggregate object of interest.

1.3. Simultaneous ownership transfer of multiple RFID tags

Another stream of research related to RFID authentication proto-cols includes published literature that followed as a direct result ofthe ‘yoking proof’ [11] protocol, ‘grouping proof’ [21] protocol andtheir variants. Essentially, these protocols purport to simultaneouslyauthenticate the presence of multiple tags in the field of the reader.Such a scenario may include, for instance in the example presentedin [11], the necessity of simultaneous presence of a given pharmaceu-tical item along with its instructions. Although the intention is toauthenticate the presence of multiple tags simultaneously, these pro-tocols and a majority of their variants accomplish this in a sequentialmanner whereby the authentication of the first tag is immediatelyfollowed by the authentication of the next tag, and so on. Sincethese authentications are done sequentially as a compact batch, theprocess is almost similar to comparable simultaneous authenticationof these tags.

To our knowledge, extant published literature does not includethe scenario where tags that need to be simultaneously present to-gether change ownership together from the same previous owner tothe same new owner. Given the need for ‘yoking proof’ protocol andits variants and the need for ownership transfer protocols, it is nothard to envision the need for protocols that incorporate the dynamicpresent in both these scenarios. We purport to fill this gap in extantliterature by proposing a protocol for verifying the simultaneouspresence of multiple tags in the field of the reader while ownershiptransfer involving these tags takes place.

We consider the scenario where two tags that need to be simulta-neously present in the field of the reader change ownership in thepresence of a trusted third party (TTP). We do not consider owner-ship transfer for the case where a TTP is absent. Without the presenceof a TTP, it is extremely difficult, if not impossible, to transfer owner-ship of items between two entities without a common shared secret

using symmetric key cryptography. In this case, the protocol becomesan ownership sharing one and not an ownership transfer protocolsince the previous owner may continue to maintain RF access to thetag. Ownership transfer without a TTP through wireless meansusing symmetric key cryptography is difficult since any secret infor-mation shared between previous and current owners who do notshare any secret can be readily picked up by an adversary in the vicin-ity. We do not consider the use of public key cryptography, whichcould allow for ownership transfer without a TTP, in this paper. Thisis left as an exercise for a future paper.

This paper is organized as follows: the next section provides a briefoverview of some related protocols. The proposed Shared ownershiptransfer protocol is presented in Section 3. A shared ownership sharingprotocol is presented in Section 4. Objects with multiple tags are con-sidered in Section 5. Specifically, protocols for inclusion/exclusion ofRFID tagged components in an object of interest as well as for sharedownership transfer are considered in Section 5. Protocol for simulta-neous ownership transfer of multiple tags is presented in Section 6.Section 7 concludes the paper with a brief discussion.

2. Related work

Over the past five years, several ownership transfer protocols forRFID tags have been proposed and studied (e.g., [1,4,10,13,22,28]).Most of these ownership transfer protocols deal with the commonsingle tag — single owner scenario. A majority of these have beenfound to have vulnerabilities that can readily be taken advantage ofby a resourceful active adversary (e.g., [13,14]). We first present andevaluate a few recently proposed ownership transfer protocols andidentify some of their vulnerabilities.

2.1. Notation

The following notations are used throughout the paper:

• Ni: random l-bit nonce generated for entity i• IDR, IDT: reader and tag identifier• Ri, Ti reader/owner i, Tag i• k,ka,k′a: authentication keys• s,s′,si: shared keys between entities• Fu: update flag• V: response value• h,g,H,G: hash functions — {0,1}⁎→{0,1}l

• hk: keyed (with key k) hash function• f ′k, fk: keyed (with key k) encryption function• Ex(m): encrypt message m using object x's public key• Dx(m): decrypt message m using object x's public key• Sx(m): signature using message m and x's private key• Certi: Tagi's ownership certificate• EPC: Electronic Product Code• CRC: Cyclic redundancy check• TID: Transaction identifier• CID: Current identifier• HID: Hashed CID (H(CID))• SN: Serial number• Signx(m): Signature of message m by entity x• ti: shared secret between tagi and TTP• ri: shared secret between reader Ri and TTP

2.2. Protocol of Chen et al.

The protocol of Chen et al. [2] comprises three main phases asgiven in Figs. 1, 2, and 3.

During the first phase (Fig. 1), the previous owner passes onimportant information about the tag (here, Tag i) – the certificate ofownership (Certi) – to the new owner. The second phase (Fig. 2) is

Fig. 1. Ownership transfer — initial phase (Chen et al.).

260 G. Kapoor et al. / Decision Support Systems 52 (2011) 258–270

for mutual authentication between the tag and server. Since thefirst and third phases can operate together to accomplish ownershiptransfer, the purpose of the second phase (mutual authenticationphase) is not clear from an ownership transfer perspective. Thethird phase (Fig. 3) completes ownership transfer by generating anew certificate (Cert′i) and passing the same to the new owner andthe tag.

The mutual authentication phase (Fig. 2) is vulnerable to replayattack from an adversary with the capability to capture, store, and re-play previous messages. This can be accomplished as follows: the ad-versary can capture the first message from Reader to Tag (i.e., request,rR,CRC(Ni⊕ rR)) and repeatedly replay it to the tag while blocking theresponse from the Tag (i.e., rT,Y,Z) from reaching the Reader. The Tagrepeatedly updates its key (ki) whereas the Reader does not havethe opportunity to keep in sync. This leads to de-synchronizationbetween the Tag and the Reader and these two will not be able tocommunicate with each other again, thus leading to Denial of Servicefrom Tag to Reader and vice versa.

The Chen et al. protocol has at least one other vulnerability, whichis serious. This vulnerability is present in the third (i.e., ownershiptransfer) phase. An active adversary can block the message from thenew owner to the server (i.e., ID1, ID2,S2(ID1, ID2),S1(Certi, ID2),Certi)and retrieve Certi, which is in cleartext. This certificate can then beused to provide ownership of the tag to anyone, which includes theadversary. The adversary accomplishes transfer of ownership byknowing Certi and following the first phase of this protocol (Fig. 1).

2.3. Protocol of Lin et al.

The protocol of Lin et al. [17] purportedly accomplishes ownershiptransfer in one short phase (Fig. 4).

The structure of this protocol lends itself to attacks by an adversary toresult in DoS (Denial of Service) attack. The adversary canblock themes-sage from tag to reader, modify it, and then send it to the reader. Specif-ically, the adversary can modify ΔTID to some large value by XORingthis with some large N value. I.e., send N⊕ΔTID⊕H(HCID(SN)⊕rT)

Fig. 2. Ownership transfer — mutual a

instead of ΔTID⊕H(HCID(SN)⊕rT). Now, after observing this huge ΔTIDvalue, the reader would be forced to look for the corresponding CID(andother) values in the receivedmessage butwould fail in its attempts.Another vulnerability is in the message from the reader to the tag. BothrR and rR⊕H(HCID(SN)⊕(rT+1)) can be modified by inserting someδ value as follows: instead of rR, the adversary can block this entiremessage from reader to tag and send δ⊕rR⊕H(HCID(SN)⊕(rT+1)),δ⊕rR,H(rR⊕CID⊕TID) instead. Now, the tag would use the new rR⊕δto update its CID value while at the same time retrieving the new TIDfrom (TID⊕rR⊕δ⊕δ) as (TID⊕δ). This new CID value will be differentfrom the one at the reader's side, therefore leading to de-synchroniza-tion between reader and tag. The reader and tag will never be able tocommunicate with each other.

2.4. Protocol of Song and Mitchell

Ownership transfer in Song and Mitchell [23] is accomplished inseveral steps as follows: (1) the previous owner updates tag secretsfor privacy and forward/backward traceability reasons, (2) the previ-ous owner shares these tag secrets with the new owner through asecure channel, and (3) the new owner updates the secrets to preventthe previous owner from gaining (RF) access to the tag. Step (1) isfairly straight-forward and is readily accomplished without any issuessince the tag and previous owner share those secrets, which are notknown to any other entity. The paper includes a protocol that accom-plishes step (1). Step (2) is also readily accomplished assuming thepresence of a secure channel between the previous and new owners.The paper does not provide a protocol to accomplish this step, prob-ably due to the assumption that this occurs through a secure channeland the possibility of the absence of encrypting any message passedbetween the previous and current owners. Unlike the first twosteps, Step (3) is vulnerable to attacks by an adversary, who couldvery well be the previous owner. Step (3) is carried out by a secretupdate protocol (Fig. 5).

The authors mention the following in the Paragraph beforeSection 6.2.2.: “If P2 completes successfully (and the old owner doesnot eavesdrop on the messages), S and T share new secrets knownonly them, and the old owner is no longer able to identify or traceT". Here, P2 is the ownership transfer protocol (Fig. 5), S and T arethe new owner and tag respectively. Clearly, the previous owner nothaving the capability to eavesdrop on any communication is an inva-lid assumption. If this assumption were valid, why not take it to theextreme and assume that any pair of sender–recipient operates in asterile environment where no one but the intended recipient receives

uthentication phase (Chen et al.).

Fig. 3. Ownership transfer phase (Chen et al.).


the intended message without any corruption? Such an assumptionwould obviate encrypting any of the messages sent between anytwo parties and the need for such ownership transfer protocols.Even assuming an honest previous owner, this is only an ownershipsharing (i.e., not transfer) protocol.

Since the previous owner knows the tag's secrets, it can block themessage from the new owner to the tag and send the appropriatefk(rR||x) to the new owner as if this message is from the tag. Thenew owner would validate this to be true and update its s,k, and xvalues. The previous owner can also modify rR,gk(x||rR)⊕(s||k′||c′)with different k′ and c′ values and send it to the tag. The tag wouldnow update its c and k values to those sent by the previous owner.The new owner and tag will be de-synchronized and will never beable to communicate with each other.

An adversary, who need not be the previous owner, can also ac-complish de-synchronization between tag and new owner as follows:the adversary can block the message from the tag to the new owner(Fig. 5). Now, the tag has already updated its c and k values whilethe new owner has not. Since the new owner does not know whetherthe tag received the message it just sent unless it hears from the tag, itwill not knowwhat to send next to begin communicationwith the tag.It has two options: change rR and resend rR,gk(x||rR)⊕(s||k′||c′) —

the tag will not be able to decrypt this message due to differentk-value; change rR and the encryption key to k' in which case s

Fig. 4. Ownership transfer

may not be recognized by the tag (since s and k are related throughk=h(s)).

2.5. Protocol of Ilic, Michahelles, and Fleisch

Ilic, Michahelles, and Fleisch [9] propose a ‘dual ownership model,’where they consider simultaneous ownership in the physical andelectronic worlds. Fig. 6 illustrates the essence of this protocol,which is operationalized using three entities: a back-end server, areader, and tags.

The reader (here, new owner) initiates the proof of ownershipprotocol with a request to the tag, which responds by sending it's IDand secret key k values in cleartext. The new owner then uses its pri-vate key to digitally sign these values and sends it to the back-endserver. The back-end server verifies the ID,k values and then gener-ates a new key (k′). It sends this key to the new owner after encrypt-ing it with the new owner's public key. The new owner then updatesthe tag using this new key.

Unless the authors intended the messages between tag and newowner, this protocol is vulnerable on several counts. The ID of thetag as well as its keys (k,k′) are sent in the open in cleartext. This isa serious vulnerability since knowing these, the tag can readily betracked/traced. Moreover, even worse, the tag can easily be clonedusing this information.

protocol of Lin et al.

Fig. 5. Ownership transfer protocol of Song and Mitchell.


3. The shared ownership transfer protocol

From the perspective of key management, shared ownershiptransfer can be accomplished either by using a single shared keyamong the tag and all its owners or by using a different key for eachtag-owner pair. The latter quickly becomes infeasible due to limita-tions in tag storage space. The former is feasible in this respect withsome minor issues. For example, what if one or few of the owners de-cide or are forced to give up ownership? This necessitates generatinga fresh key for all current owners. How does one accomplish thiswhen the number of owners is dynamic over a tag's lifetime? This isan issue since the owners of a tag have a shared key, what happenswhen the previous owners of a tag listen in on communicationamong current owners and attempt to retrieve the new key? Weare in the process of exploring these issues, and only present thebasic protocol in this paper. We first present our shared ownershiptransfer protocol with a trusted third party and then extend this tothe one without a trusted third party.

As in existing ownership transfer protocols, we assume that twosets of entities are interested in transferring ownership of an objectthat is RFID-tagged. Fig. 7 illustrates this scenario where the numberof owners of a tag can vary across time, which increases from left toright in this Figure. Here, the number of owners (i.e., 1m,2m,⋯,nm)could all be different. Please note that in Fig. 7, 1m, 2m, ⋯, nm arejust nominal labels and 2m is not twice 1m. The trusted third partiestaking part in any ownership transfer process including TTP1,TTP2, ⋯, TTPn−1 need not necessarily be the same. I.e., some of themmay be the same while some others are different — the scenariobeing modeled is flexible in this regard. The ownership transfer pro-cess proceeds from left to right over time across (possibly) differentsets of owners as illustrated in Fig. 7. The dashed lines between anytwo entities (i.e., TTP, Tag, Owner) represent wireless communicationbetween them.

For the remainder of the paper, to prevent DoS attacks, the recip-ient of a freshly generated nonce sent in cleartext (e.g., NP from TTP to

Fig. 6. Proof of ownership protocol of Ilic et al.

Tag in Fig. 8) accepts it only if this nonce is non-null. We also assumethat a message originator waits for a response for a pre-specifiedamount of time and non-response triggers a fresh message. Fromhereon, all messages passed between any two entities are assumedto occur through wireless means (except between the two ownersas represented in Fig. 11). The rationale for this is that most of thecommunication with RFID tags (have to) occur through wirelessmeans and a few of those between fixed entities (e.g., reader, back-end server) may be constrained to occur through secure wired links.For the shared ownership transfer protocol with a TTP (Section 3)and shared ownership sharing protocol without TTP (Section 4), weassume that all involved owners are simultaneously present or arereachable from the tag. We first present a shared ownership transferprotocol with a trusted third party followed by a shared ownershipsharing protocol without a trusted third party. Given limitations inexisting technology and other resource constraints, it is rather chal-lenging to develop a shared ownership transfer protocol in the ab-sence of a trusted third party.

3.1. Shared ownership transfer protocol with a TTP

We consider a scenario with the following parties, namely Tag Ti,TTP, current owner R1 (or group R11,R12,…,R1M) and new owner R2(or group R21,R22,…,R2N). The proposed shared ownership protocol(Fig. 8) in the presence of a TTP is as follows:

Step 1.1 Upon receiving an ownership transfer request, the TTP gen-erates a new key s2. It then generates a fresh nonce NP, andsends f′ encrypted with (NP⊕ ti⊕s1), where s1 is the tag'scurrent key. This authenticates the TTP to the tag, which up-dates s1 to s2.

Step 1.2 The tag acknowledges by generating and sending a freshnonce NT.

Repeat the following steps (i.e., 2, 3.1, 3.2, 4.1, 4.2) once for eachowner in the two (i.e., new owners and previous owners) groups:

Step 2 The TTP informs current owners (R11⋯R1M) that their privi-leges on this tag are being revoked. It sends a simple revokemessage and a keyed cryptographic function, fr1i(s1) to eachof the M current owners (i=1..M).

Step 3.1 Next the TTP grants the new owners (R21⋯R2N) full permis-sions along with any delegation privileges for the tag. Agrant message is issued, along with a freshly generatednonce NP′ and a function encrypted with the key (r2i) sharedbetween new owner and TTP. The function contains the newkey (s2).

Step 3.2 The new owners send an acknowledgment using a one-wayhash with the new key value.

Step 4.1 The new owners then generate a fresh nonce NR2, and estab-

lish contact with the tag by sending NR2and NR2

in anencrypted function (using s2 as the encryption key).

Step 4.2 The tag acknowledges with a one-way hash of a freshlygenerated nonce NT

′ along with NR2and s2.

3.2. Authentication

Now that all involved parties know the shared secret (s2) for thetag of interest, we introduce a protocol that can be used for mutualauthentication of every member of R2 and tag.

The authentication handshake works as follows:

Step 1 The ith new owner queries the tag with NR2i.

Step 2 The tag responds with a freshly generated nonce NT, and akeyed (with NT⊕ s2) hash of NR2i

. Only the tag and its newowners (R2i, where i=1..N) share s2. This authenticates tagto the new owners.

Fig. 7. Shared ownership transfer with TTP.


Step 3 The message from owner i to tag now consists of a freshlygenerated nonce NR2i

′ . This message is encrypted using boththe shared key s2 between tag and new owners, and thenonce generated by the tag in the previous message NT. Thisauthenticates owner i to the tag.

Step 4 To acknowledge receipt of the message in Step 3, the tag sendsHs2(NR2i

′ ) to owner i. If owner i does not receive this messagewithin a pre-determined amount of time, the process is re-peated from Step 1 (Fig. 9).

3.3. Security analysis

We omit detailed security analysis of this protocol since its struc-ture is similar to the one-tag one-reader ownership transfer protocolpresented in [13]. In general, the security design of the protocolsshould not impede normal operations and should prevent a maliciousadversary from retrieving or inferring any information. We first ex-plain the rationale for some communications (and subsets thereof)and then a sketch of the analysis.

1. TTP-to-Tag: NP, f(NP⊕ ti⊕ s1)′ (s2)

The nonce NP provides the randomness necessary to prevent areplay attack (wherein an adversary will just replay a messageor some subset thereof). Without the use of nonces, the message

Fig. 8. Shared ownership tra

sent would now be just f(ti⊕ s1)′ (s2), which would elicit the same

response from the tag every time (i.e. H(ti⊕ s1)(s2)), and then anadversary could easily track the tag. Also, we use NP⊕ ti⊕s1 asthe key for the function f′ because 1) it authenticates (to Tagi)the message as coming from TTP, as the key ti is only known tothese two entities, and 2) not using NP in the key can possibly (al-though it is highly unlikely) lead to denial of service (DoS). To seethis, assume that the adversary intercepts the message NP, f(ti⊕ s1)

′

(s2), and sends a different nonce N′P along with the message. Thetag, believing it is from a valid TTP due to the presence of ti,would then respond with NT, H(ti⊕NT)(s2⊕N′P). The TTP (havingsent NP and not N′P) will now discard this and would have to restartthe procedure. An adversary could keep doing this to deny theoperation.

2. Tag-to-TTP: NT, H(ti⊕NT)(s2⊕NP)Here, the keyed hash function first helps authenticate to the TTPthat the message is from Tagi, due to the presence of ti in the keyused. The hash value contains both the new key s2 and the nonceNP to convey that the key s2 has been received by Tagi well as toprevent the problem described above. Also, suppose an adversaryintercepts the message and changes the nonce NT (sent in theclear) to N′T. In that case the hash key and (therefore the computa-tion of the hash value by the TTP) changes, and so the TTP will dis-card the message. Thus, the message integrity will be preserved. In

nsfer protocol with TTP.

Fig. 9. The authentication handshake.

Fig. 11. Shared ownership sharing without TTP: Initialization.


such a scenario, the TTP will re-initiate the procedure. Althoughthis too can potentially be a way for a DoS attack, there is a negligi-ble probability of this happening, as the adversary cannot track thetag or any of its messages.

The same ideas are applied in each communication between the TTPand owners, and between owners and tags. We now present how theprotocol meets the objectives of a general RFID security analysis.

1. Secrecy, Data Integrity and Authenticity: The communications arebased on secret keys and keyed cryptographic functions with littleor no data sent “in the clear”. To intercept and read any message anadversary must know the secret keys. Using hash functions helpspreserve the message integrity. In addition, since there are somekeys known only to entity pairs (as described above), most com-munication can be authenticated as well.

2. DoS and Synchronization problem: Consider a situation where anadversary blocks a message. Since we rely on acknowledgmentsfor the key change and first post key change communique fromnew owner to tag, blocking any message creates no breach in thesystem. In addition, we do not face the de-synchronization prob-lem (i.e. that the tag is unreachable because it has a differentkey). At least one entity (be it a previous owner R1, a new ownerR2 or the TTP) can always communicate with the tag. Supposethe adversary blocks message (1.1): a member of R1 can stillreach the tag, with key s1. Suppose the adversary blocks message(1.2): The TTP is waiting for an acknowledgment and will takeremedial action. Of course, to commit such attacks, an adversarymust know all the parties involved, the sequencing of the mes-sages, and the timing of the messages.

3. Forward Security:Forward security refers to the scenario wherethe current key of a tag is known to the adversary, and can beused to extract previous messages (assuming that some past con-versations are recorded by the adversary). Let's say the adversarysomehow knows the current key s2. The tag always communicatesusing a keyed hash function. The adversary cannot use the key todecode any of the tag's previous messages because the one-wayhash function H is considered computationally un-invertible. I.e.,access to the hash digest table is necessary for any lookups.Moreover, previously used keys cannot be used by the adversaryto decipher/recreate any previously sent messages.

Fig. 10. Shared ownership

4. Shared ownership sharing protocol without TTP

The shared ownership sharing protocol without a TTP is similar tothe one with TTP (Section 1) except for the absence of the TTP. Al-though this protocol is more secure than those in existing literature,it does not transfer ownership in the strict sense since all previousowners can still access the tag. However, since the previous key isnot known to the new owner, it is an improvement over [21].

4.1. The proposed protocol

The scenario considered comprises the following parties, namelyTag, current owner group R11,R12,…,R1N and new owner group R21,R22,…,R2N. We assume that each owner group has a “central author-ity” who is responsible for initiating communication and later propa-gating changes in keys/access to the other members in the group. I.e.,R11 could be such a central authority for group 1, and R21 for group 2.Thus, the ownership transfer steps take place between R11 and R21 inthe Initialization phase, and between R21 and Tag in the Key Changephase. These changes are passed on to the other members of the re-lated owner group. Fig. 10 illustrates this scenario from a high-levelperspective, with the time scale represented from left to right.

Once the request for transfer of ownership has been invoked andapproved, the procedure for the actual transfer of ownership worksas follows:

Step 1 Upon receiving an ownership transfer request, R1 generatesa fresh nonce NR11

, XORs the key shared with the tag (s1)with this nonce and sends it encrypted to the tag and on asecure channel to R2. This is the “initialization” phase asdepicted in Fig. 11.

Step 2.1 Upon receiving NR11⊕s1 from R1, the tag generates a fresh

nonce NT, and sends the nonce XORed with the key s1 to R2(Fig. 12). Now both T and R2 know N, (where N=NR11

⊕NT).As another measure or layer to preserve forward security,R2 is not allowed to know s1.

sharing without TTP.

Fig. 12. Shared ownership sharing without TTP: key change.

Fig. 13. Tag inclusion/exclusion protocol.


Step 2.2 The tag now randomly flips one bit in N, creating N′, andgenerates another fresh nonce NT′ . It sends NT′ and anencrypted function containing N′⊕NT′ , using N′⊕NT′ as thekey and a similarly keyed hash function with the samevalues to R2.

Step 3.1 Knowing N, R2 uses a brute force technique to determine N′so as to decrypt the value sent in f. Since R2 knows that N′ isreally just Nwith only one flipped bit, this process is feasibleand R2 is assumed to possess the necessary computationalresources to accomplish this very quickly. R2 verifies thesolution obtained using the hashed value.

Step 3.2 The new owner R2 now generates and sends a new key tothe tag by XORing and encrypting it with N'. This step isrepeated after a pre-determined time period until step 4happens.

Step 4 The tag acknowledges receipt of the new key using a hashfunction, keyed with the new key s2.

Step 5 To acknowledge receipt of message in Step 4, R2 sends fs2(N′⊕s2) to the tag. If the tag does not receive this withina pre-determined amount of time, the process is repeatedbeginning with Step 1.


We evaluate the ownership transfer protocol without TTP. It isvery similar to the analysis described in Section 3.3, with some nota-ble additions.1. Indistinguishability/Tracking:Using a freshly generated nonce with

almost every message in the protocol, it is difficult to track the tag.Assume that an adversary pretends to be a genuine reader. Hesends out a query, and receives the hash of a message back. Nexttime he sends a query, along with a freshly generated nonce, he re-ceives a different message, so he cannot track the tag. Of course,with multiple tags in an area, tracking a specific tag without keysis extremely difficult.

2. Passive replay:The freshly generated nonce creates an element ofrandomness. However, passive replay is possible in the absenceof a secure channel to do the initialization.

5. Protocols for multi-tagged object

5.1. Inclusion/exclusion of Tag(s)

It is not uncommon to encounter objects with several RFID tags.However, the tags on these objects are generally mobile and movefrom or to (or, both) the object. An example scenario that illustratesthis includes a primary object (e.g., car chassis) with several attachedparts (e.g., car door, wheels) each with its own RFID tag. In such sce-narios, both the number of tags as well as the individual tags them-selves may vary over time. I.e., when a tire is replaced, the new tiremay come with its own embedded RFID tag; when the owner decidesto add a GPS system, it may come with its own RFID tag; when thespare tire is removed from the car, there would be one less RFIDtag on the car. To our knowledge, no existing RFID authenticationprotocol addresses this scenario, and there is a clear need for suchprotocols.

The proposed protocol (Fig. 13) can be used for inclusion and ex-clusion of tags in a multiple-tagged object. We assume that a TTP me-diates between the reader and tags in accomplishing this change inshared secret key. The actors involved in this protocol include thereader, the TTP, and every tag that is a part of the object of interest ei-ther before or after components (tags) were added or removed.

We assume that every component (tag) that is a part of the objectof interest share a common secret key (sc). This key is updated everytime the object of interest experiences addition or removal of a com-ponent or group of components. The primary purpose here is to en-sure that the updated key is known only to the reader, the TTP, andthe tags that are currently attached to the object. The components(tags) that were dropped from this object should not have knowledgeof this new shared key. This is a single round protocol that has threemain “loops". This protocol is repeated for each tag that is associatedwith the object including those that are present on the object andthose that were just removed from the object.

The first loop between the TTP and tag begins the shared keychange process when the TTP generates a new shared secret for thetags and distributes this secret to each tag currently attached to theobject. The TTP waits for response from the tag for a predeterminedamount of time. If the TTP does not hear back from the tag duringthis time, it generates a fresh nonce (NP) and the forward part ofthe loop is repeated. This process continues until this loop is complet-ed. After completion of the first loop, the tag attached to the objectknows the new shared secret (sc+1). For those tags that are no longera part of the object of interest, the same process is followed but withsc+1 set to some predetermined string (e.g., null bits). The secondloop is between the TTP and the reader. Here, the TTP shares thenew shared secret key with the reader. This process is repeated forall relevant readers. The first term (NP, f(ri⊕ sc⊕NP)(sc+1)) is used totransfer the new shared key. The second term (f(ri⊕ sc)(IDtj⊕sc+1))conveys the unique ID value of the tag to the reader so that the readercan associate the ID value with its corresponding shared secret keyvalue. This process is repeated until the TTP hears back from the read-er. Once ID and sc+1 values are retrieved, the reader verifies the newcommon shared secret directly with the tag in the final loop. The thirdloop, initiated by the reader, is between the reader and the tag andit mutually authenticates the tag using the new key (i.e., sc+1). Thethird loop is nested in the second loop. I.e., the reader responds tothe TTP only after successful completion of the third loop.


Analyzing the security of protocols used in RFID tags has its issuessince a majority of such protocols depend on the hardness of exhaus-tive enumeration. For example, the HB+ protocol [12] was proved tobe secure but was later broken with a simple man-in-the-middle at-tack in [5] and others (e.g., [15]). Several methods have been pro-posed to analyze the security properties of cryptographic protocolsover the years and these methods have their own issues (e.g., [3,16]).

Fig. 14. A base object with several components.


GNY logic [7] has been used to check for security issues in a major-ity of RFID protocols (e.g., [6,8,18,26,27]). As far as we can tell fromour experience dealing with related publications, there are very fewpapers (among those dealing with RFID authentication protocols)that use other methods to prove security of RFID authentication pro-tocols. Therefore, we decided to use GNY logic for security analysis inthis paper. In GNY logic, principals are not assumed to be trustworthyand redundancy is always explicitly present in encrypted messages.GNY logic distinguishes between what a principal can possess andwhat it can believe in. It enables the expression of different trustlevels and implicit conditions behind protocol steps. The main issuewith GNY logic is that it has more than forty inference rules, whichhas led many researchers to consider this logic as being impractical.Using GNY logic, we now verify the correctness of the assumptionswith respect to message source as well as the beliefs of the senderand recipient of messages. We proceed by including the individualmessages in the protocol followed by inherent explicit assumptionsand then the goals. We then present proofs of these goals.

Protocol messages:M1 TTP⊲⋆(NR),⋆(fri⊕NR⊕NP

(sc+1))M2 Ri⊲⋆(NP),⋆(fri⊕ sc⊕NP

(sc+1)),⋆(fri⊕ sc⊕NP(IDtj⊕sc+1))

M3 Tj⊲⋆(NP),⋆(ftj⊕ sc⊕NP(sc+1))

M4 TTP⊲⋆(NT),⋆(f(sc+ 1⊕NT⊕NP)(sc+1))M5 Tj⊲⋆(NR′),⋆(fsc+ 1⊕NR

′(sc+1))M6 Ri⊲⋆(NT),⋆(fsc+ 1⊕NR

′(NT))

Assumptions:A1 TTPjNP

A2 TjjNT

A3 Rij(NR,NR′)A4 TTPj≡TTP↔ri Ri

A5 Rij≡Ri ↔ri TTP

A6 TTPj≡Tj↔tj ;scþ1 TTP

A7 Tjj≡TTP↔tj ;scþ1 Tj

A8 TTP|≡#NP

A9 Tj|≡#NT

A10 Ri|≡#(NR,NR′)

Goals of the correctness proof: The primary goals of the proposed proto-col are belief (|≡), and the freshness (#), of the messages between eachpairs of TTP,Ri,Tj. Belief ensures message is from a trusted source. Fresh-ness ensures message was not sent earlier during the same session.G1 TTP|≡Ri|∼#(NR)G2 TTP|≡Ri|∼#(fri⊕NR⊕NP

(sc+1))G3 Ri|≡TTP|∼#(NP)G4 Ri|≡TTP|∼#(fri⊕ sc⊕NP

(sc+1))G5 Ri|≡TTP|∼#(fri⊕ sc⊕NP

(IDtj⊕ sc+1))G6 Tj|≡TTP|∼#(NP)G7 Tj|≡TTP|∼#(ftj⊕ sc⊕NP

(sc+1))G8 TTP|≡Tj|∼#(NT)G9 TTP|≡Tj|∼#(fsc+ 1⊕NT⊕NP

(sc+1))G10 Tj|≡Ri|∼#(NR′)G11 Tj|≡Ri|∼#(fsc+ 1⊕NR

′ (Sc+1))G12 Ri|≡Tj|∼#(NT)G13 Ri|≡Tj|∼#(fsc+ 1⊕NR

′(NT))

G14 TTPj≡TTP↔Scþ1 Ri

G15 Rij≡Ri↔Scþ1 TTP

G16 TTPj≡Tj↔Scþ1 TTP

G17 Tjj≡TTP↔Scþ1 Tj

G18 Tjj≡Ri↔Scþ1 Tj

G19 Rij≡Ri↔Scþ1 Tj

Proof. The logical postulate numbers (e.g., M1, T1,..) referred to inthe following are from [7].

[D1:] TTP⊲NR, fri⊕NR⊕NP(sc+1)
/*M1,T1*/
[D2:] TTPjNR, fri⊕NR⊕NP(sc+1)
/*D1,P1*/
[D3:] TTP|≡#NR,# fri⊕NR⊕NP(sc+1)
/*D2,F10*/
[D4:] TTP|≡Ri|∼#NR
/*A4,A5,D3, I1*/ [D5:] TTP|≡Ri|∼# fri⊕NR⊕NP
(sc+1)
/*A4,A5,D3, I1,P2*/ [D6:] Ri⊲(NP),(fri⊕ sc⊕NP
(sc+1)),(fri⊕ sc⊕NP(IDtj⊕sc+1))
/*M2,T1*/
[D7:] Rij(NP),(fri⊕ sc⊕NP(sc+1)),(fri⊕ sc⊕NP

(IDtj⊕sc+1))
/*D6,P1*/ [D8:] Ri|≡#(NP),#(fri⊕ sc⊕NP
(sc+1)),#(fri⊕ sc⊕NP

(IDtj⊕sc+1))
/*D7,F10*/
[D9:] Ri|≡TTP|∼#(NP)
/*A4,A5,D8, I1*/ [D10:] Ri|≡TTP|∼#(fri⊕ sc⊕NP
(sc+1))
/*A4,A5,D8, I1,P2*/ [D11:] Ri|≡TTP|∼#(fri⊕ sc⊕NP
(IDtj⊕sc+1))
/*A4,A5,D8, I1,P2*/ [D12:] Tj⊲(NP),(ftj⊕ sc⊕NP
(sc+1))
/*M3,T1*/ [D13:] Tjj(NP),(ftj⊕ sc⊕NP
(sc+1))
/*D12,P1*/ [D14:] Tj|≡#(NP),#(ftj⊕ sc⊕NP
(sc+1))
/*D13,F10*/ [D15:] Tj|≡TTP|∼#(NP) /*A6,A7,D14, I1*/ [D16:] Tj|≡TTP|∼#(ftj⊕ sc⊕NP
(sc+1))
/*A6,A7,D14, I1,P2*/ [D17:] TTP⊲(NT),(f(sc+ 1⊕NT⊕NP)(sc+1)) /*M4,T1*/ [D18:] TTPj(NT),(f(sc+ 1⊕NT⊕NP)(sc+1)) /*D17,P1*/ [D19:] TTP|≡#(NT),#(f(sc+ 1⊕NT⊕NP)(sc+1)) /*D18,F10*/ [D20:] TTP|≡Tj|∼#(NT) /*A6,A7,D19, I1*/ [D21:] TTP|≡Tj|∼#(f(sc+ 1⊕NT⊕NP)(sc+1)) /*A6,A7,D19, I1,P2*/ [D22:] Tj⊲(NR
′),(fsc+ 1⊕NR′(sc+1))
/*M5,T1*/ [D23:] Tjj(NR
′),(fsc+ 1⊕NR′(sc+1))
/*D22,P1*/ [D24:] Tj|≡#(NR
′),#(fsc+ 1⊕NR′(sc+1))
/*D23,F10*/ [D25:] Tj|≡Ri|∼#(NR
′)
/*D24,F1, I1*/ [D26:] Tj|≡Ri|∼#(fsc+ 1⊕NR
′(sc+1))
/*D24,F1, I1,P2*/ [D27:] Ri⊲(NT),(fsc+ 1⊕NR
′(NT))
/*M6,T1*/ [D28:] Rij(NT),(fsc+ 1⊕NR
′(NT))
/*D27,P1*/ [D29:] Ri|≡#(NT),#(fsc+ 1⊕NR
′ (NT))
/*D28,F10*/ [D30:] Ri|≡Tj|∼#(NT) /*D29,F1, I1*/ [D31:] Ri|≡Tj|∼#(fsc+ 1⊕NR
′(NT))
/*D29,F1, I1,P2*/
[D32:] TTPj≡TTP↔Scþ1 Ri
/*A4,D3, J1*/
[D33:] Rij≡Ri↔Scþ1 TTP
/*A4,D32, J1*/
[D34:] TTPj≡Tj↔Scþ1 TTP
/*A6,D16, J1*/
[D35:] Tjj≡TTP↔Scþ1 Tj
/*A6,D34, J1*/
[D36:] TTPj≡Ri↔Scþ1 Tj
/*D32,D34*/
[D37:] Ri ≡TTPj j≡Ri↔Scþ1 TjS

/*D36, J3*/
[D38:] Tj ≡TTPj j≡Ri↔
cþ1 Tj
/*D36, J3*/
[D39:] Rij≡Ri↔Scþ1 Tj
/*D37,D38, J1*/
[D40:] Tjj≡Ri↔Scþ1 Tj
/*D37,D38, J1*/
The proof of goals 1–19 is shown by the verification steps D4, D5,D9, D10, D11, D15, D16, D20, D21, D25, D26, D30, D31, D32, D33, D34,D35, D40, and D39 respectively.

Fig. 15. An object comprising several components.


5.3. Ownership transfer for multiple components

An object (A) can comprise several components (1 …c). There areat least two possible variations: (1) The first (Fig. 14) is where the ob-ject of interest refers to the base object that contains several compo-nents, where the object still exists and can be communicated witheven when all of its component parts are removed. An example sce-nario could be where the base object has an active tag while each ofthe components have passive tags (e.g., master–slave configurationwhere the master tag has a longer life-span compared to that of theslave tag), (2) The second (Fig. 15) is where the object comprisesonly its component parts (i.e., there is no base object). In this scenar-io, the object ceases to exist when all its component parts areremoved. An example of the former (i.e., Fig. 14) is a tag on a palletcontaining several tagged items. An example of the latter (i.e.,Fig. 15) is a bicycle with tags on each of its component parts.

From an ownership transfer perspective, the way in which an ob-ject is assembled (i.e., with or without a base or reference object) af-fects the communication protocol even if only to a minimal degree.For example, in Fig. 14, the components can be assumed to be a partof the object as a whole and may therefore need not explicitly takepart in the ownership transfer protocol. When ownership transfer ofthe base object occurs, the components remain associated with thebase object and this association is independent of the ownership de-tails of the entire object. In this scenario, the base object representsthe entire object for communication with external entities. Therefore,there is no need for the component objects to know of the ownershipdetails other than the fact that they belong to this base object. We dis-cuss simultaneous ownership transfer of several components inSection 6.

In Fig. 15, each of the components independently (sequentially orin parallel) take part in ownership transfer. We need to consider theobject configuration (i.e., with or without the base object) and makenecessary modifications (i.e., one shot ownership transfer for the en-tire object vs. multiple ownership transfers — one for each compo-nent). Simultaneous ownership transfer of all the component partsis explained in detail in Section 6.

Fig. 16. Multi-tag simultaneous ow

5.3.1. Ownership transferWe present a generic case involving the following parties, namely

Tagi, TTP, previous owner R1 and new owner R2. Here, the tag caneither be from the base object (as in Fig. 14) or from each of the indi-vidual components (as in Fig. 15). Once the request for transfer ofownership has been invoked and approved, the procedure for the ac-tual transfer of ownership works exactly the same as in the protocolpresented in Section 3.

5.3.2. AuthenticationThe authentication handshake works exactly the same as the sce-

nario presented in Section 3.

6. Simultaneous ownership transfer of multiple RFID tags

It is not hard to imagine a scenario where two items need to be to-gether (e.g., pharmaceutical item and its accompanying informationmaterials; an electronic item and its necessary accessories such as apower cord) through a large part of their presence in a supply chainwhere they change ownership as a pair (or, as a group of itemswhen there are N2 items). There is, therefore, a need for such a proto-col and we attempt to develop a protocol for such a scenario. Fig. 16illustrates the essence of this scenario with the time scale representedfrom left to right.

The proposed protocol for simultaneous ownership transfer of twoitems that belong together is given in Fig. 17. This protocol comprisesfive ‘loops’ between pairs of entities with the first three initiated bythe trusted third party (TTP) and the other two initiated by the newowner (R2). Fig. 17 illustrates transfer of ownership of entities withtags Ti and Tj that belong together from previous owner (R1) to thenew owner (R2). The process begins when the previous and newowner decide to transfer ownership and inform the TTP of the same.This step is not explicitly or implicitly modeled in the protocol. Al-though this protocol models transfer of ownership of two relateditems, this can readily be extended to any number of related itemsthat need to be in close proximity of one another.

The first ‘loop’ is between the TTP and one of the two tags (here,Ti). This step (NP, f(NP⊕ ti⊕ s1

i )′ (s2i )) from the TTP to tag Ti and NTi,H(ti⊕NTi)

(s2i ⊕NP) from tag Ti to the TTP) essentially accomplishes gen-eration of new shared key for the first Tag Ti (i.e., s2i ) and secure trans-fer of this key to Ti. If the return message is blocked from getting backto the TTP for whatever reason, the TTP waits for a pre-determinedamount of time and re-transmits the first message with a newnonce (NP). Once the first loop is completed, the TTP uses the nonce

nership transfer [with TTP].

Fig. 17. Multi-tag simultaneous ownership transfer protocol with TTP.


(i.e., NTi) generated by the first tag (or, any tag, if there are severaltags) to communicate with the second (or, next, if there are severaltags) tag. The message used in the second loop follows a similar pat-tern as that in the first loop and the newly generated shared key (i.e.,s2j) is securely sent to the second tag (Tj). The TTP again waits for reply

from the second tag. If this reply is not received within a pre-determined amount of time, it repeats only this loop with a freshlygenerated nonce (N″P). When there are more than two tags that be-long together and need to verified of their simultaneous presence inthe field of the reader, the second loop is modified appropriately –

with the nonce generated by the previous tag in the sequence, thetag's shared key with the TTP, its current key, and its next key thatis generated by the TTP – and repeated for each of these tags. TheTTP verifies the acknowledgment from the tags for their authenticity.

The third loop is between the TTP and the new owner and is ini-tiated by the TTP. This loop involves the transfer of the tags' secretkeys (here, s2i , s2

j) to the new owner. The new owner acknowledgesreceipt of these keys with Hr2(s2

i ⊕ s2j⊕N′P), where r2 is the shared

key between the TTP and this owner and N′P is the nonce generatedand sent by the TTP. When there are more than two tags, the mes-sages are modified appropriately to incorporate the same. I.e.,when c is the last tag in the sequence, the TTP modifies and includesthe following for every tag that needs to be verified: f(r2⊕N′P)(s2

c⊕ r2)for the last tag in the sequence, with the appropriate s2⁎ for each ofthe other tags in the sequence. Similarly, the new owner sends Hr2(s2i ⊕ s2

j⊕⋯⊕ s2c⊕N′P) to the TTP where c is the last tag in the se-

quence. Like in the first two loops, the TTP waits for acknowledg-ment from the reader. Again, if the acknowledgment fails tomaterialize, the TTP repeats only this loop with a freshly generatednonce (N′P).

Upon successful completion of this third loop in the protocol, thenew owner is made aware of the tags' keys. The new owner com-pletes the next two loops – i.e., the new owner authenticates thetwo tags using the next two loops – before acknowledging receiptof message to the TTP. I.e., the fourth and fifth loops are nested withinthe third loop. These next two loops (i.e., loops four and five) are ini-tiated by the new owner (with NR2

, fs2′ (NR2)) and are similar in struc-

ture with the use of the same freshly generated nonce (NR2), except

for the encryption keys used. The new owner waits for responsefrom all the tags in the set that are verified for their simultaneous

presence. If it does not hear back from even one of the tags, it re-transmits its message to all the tags with a different nonce (i.e.,NR2

). The response from the tags is verified for their authenticity.Once the tags' authenticity is verified, the new owner acknowledgesthe same to the TTP.

When the TTP gets the acknowledgment from the new owner, itsends the last message in the protocol (i.e., the message from TTP tothe previous owner) informing the previous owner (i.e., R1) with amessage that is encrypted with the shared key (i.e., r1) between theTTP and the previous owner that the previous keys (i.e., s1i , s1

j) areno longer valid. The previous owner ceases to have access to thesetags while the new owner begins to have access to these tags.

The protocol seems rather busy with several messages. However,it is a one-pass protocol between every pair of entities and we believeit is reasonable given what it accomplishes. We kept the following inmind while developing this protocol: (1) generate fresh nonce everytime a new loop is run to ensure freshness of the message and toavoid repeating previously sent message, (2) reduce use of one-wayhash functions since these are (computational) resource intensive,while using one-way hash function when necessary (3) the originat-ing message in each loop is synchronous in a sense since it expects therecipient to acknowledge with a response, which when not receivedwould trigger repeating the loop with a freshly generated nonce,(4) previous owner should not have access to the new tag secretswhile the new owner does, (5) messages sent to the tags after the‘first’ tag depend on and are derived frommessage sent to or generat-ed by the ‘previous’ tag to ensure dependency among the authenticat-ed set of tags and to prevent insertion of a fake tag by an adversary,and (6) not sending any identification information in cleartext. By fol-lowing the above, the resulting protocol is free ofobvious vulnerabil-ities that have been identified in the literature on cryptanalysis ofexisting RFID protocols. This, however, obviously does not provideany guarantees of the security of the proposed protocol. The securityof this protocol can only be ascertained through detailed analysis andeven then the nature of RFID protocols precludes any claims to itscomplete security against attacks from a resourceful adversary.

One issue that is not addressed here is the possibility of ‘de-yoking’the tags when necessary in-between two consecutive ‘yoked’ owner-ship transfers. We thank one of the reviewers of this paper for pointingthis out. We do not have a solution to this switching issue. We do,


however, acknowledge the possibility of such a scenario and deferaddressing this issue to future work.


We provide a brief security analysis of the proposed protocol con-sidering some of the common vulnerabilities that are generally pre-sent in such protocols and provide brief discussions on each.

1. Authenticity, secrecy, data integrity:The messages that are seemingly vulnerable use one-way hashfunctions to ensure that they are not easily tampered with andother messages between any pairs of entities (tag, reader, TTP)are also encrypted and no clearly identifiable information is sentin cleartext.

2. DoS/synchronization problem:A means to denial of service (DoS) attack through blocking of mes-sages or de-synchronization of secret keys is prevented throughrequirement of acknowledgment in all five loops in the protocol.I.e., the sender waits for the recipient to acknowledge its messagebefore proceeding further. This mechanism facilitates alleviatingissues including those associated with adversaries blocking mes-sages between any two entities.

3. Relay attack:Relay attack and its variants (e.g., Mafia attack, Terrorist attack)cannot be prevented using the proposed protocol since it is notprotected against such attacks. A majority of existing RFID proto-cols are not immune to relay attacks. Although several means toaddress relay attacks exist, none of them completely prevent suchattacks since these protocols use the round-trip time taken bymessages between any two entities and measuring these necessi-tates access to extremely sensitive devices since these distancesare generally small (e.g., a few centimeters to a few meters at themost) and it is extremely difficult to identify latency.

4. Prevention of replay attack:The proposed protocol addresses this issue through two means:(1) freshly generated nonce in every loop, and (2) no two mes-sages between different pairs of entities are the same. While theformer prevents an adversary from simply capturing and replayingthe captured message to the same entity at a later point in time,the latter prevents copying message from an entity and replayingit with or without appropriate modifications to another entity.

5. Forward security:Knowing the current key, an adversary will not be able to decipherpast messages between the entity of interest and any other entity.This is due to the one-way hash functions used to encrypt mes-sages in every loop in the protocol.

7. Discussion

The importance of RFID security/privacy issues and their direct in-fluence on consumers are a relatively recent phenomenon. A majority,if not all, of the literature in this area has addressed these issues fromthe perspective of a single-tagged object. However, since objects withmultiple tags are not uncommon, there is a need to develop privacy/security protocols that address this configuration — i.e., protocols forauthentication of objects with multiple RFID tags. Although not anissue in the single-tagged scenario, objects with multiple tags face theissue of components (i.e., tags) being added or removed over time.We presented a protocol for inclusion and exclusion of tags on an objectof interest. We also considered ownership transfer issues when multi-ple tags exist on an object.

We considered several variations that can arise when transferringRFID tag ownership. We presented ownership transfer protocols formultiple tag and/or multiple ownership cases. Moreover, we consid-ered scenarios with and without a TTP. We also developed a

protocol that simultaneously accomplishes two tasks: verifying thesimultaneous presence of multiple tags in the field of the reader andownership transfer of multiple tags between two owners (repre-sented by readers, here) in the presence of a trusted third party. Ex-tant protocols accomplish either of these tasks separately but notboth in one protocol. Incorporating both these tasks in one protocolaccomplishes these with less overhead when a scenario dictatesseamlessly accomplishing both these tasks. While the proposed pro-tocol only considered two tags, extensions to multiple tags are easilyaccomplished by appropriately modifying and repeating the mes-sages between tag and TTP, tag and new owner, and TTP and newowner. The proposed protocol is certainly not immune to relay at-tacks like other extant ownership transfer protocols as well as ‘yokingproof’ protocol and its variants.

As was observed earlier (e.g., [13]), it is rather challenging to developownership transfer protocols without the presence of a trusted thirdparty. The best one can do in such a situation (i.e., without a TTP) is aownership m sharing (as opposed to transfer) protocol where every pre-vious owner continues tomaintain RF access to the tag. Depending on thecontext of interest, this may not even be an issue. However, identifying aprotocol as an ownership transfer protocol necessitates that it indeedstrictly transfers ownership between entities and not a looser versionwhere ownership is shared among current and all previous owners.

Given the track record of protocols developed for RFID authentica-tion, such protocols are secure only until a vulnerability is identifiedregardless of any proof claiming otherwise. As have been illustratedin numerous other cases where protocols had been proven to be se-cure against attacks, only to be shown to be vulnerable to some attackby a resourceful adversary using an identified loop-hole. Regardless,as more and more applications using RFID tags become a reality it isnecessary to develop secure protocols that can protect and secureRFID-tagged objects from resourceful adversaries that attempt to vio-late the security and privacy of these objects. We considered a fewvariations of the single-tag single-owner ownership transfer scenari-os that involve multiple tags and/or multiple owners and developedprotocols for the same. This is only a first step in the direction of de-veloping secure protocols for such scenarios that are not so uncom-mon in supply chains.

Acknowledgments

The authors thank the three reviewers for their detailed construc-tive comments and suggestions that have helped improve both thecontent and presentation of this paper.

References

[1] H.-B. Chen, W.-B. Lee, Y.-H. Zhao, Y.-L. Chen, Enhancement of the RFID securitymethod with ownership transfer, Proceedings of the ICUIMC, 2009, pp. 251–254.

[2] C.-L. Chen, Y.-L. Lai, C.-C. Chen, Y.-Y. Deng, Y.-C. Hwang, RFID ownership transferauthorization systems conforming EPCglobal class-1 generation-2 standards,International Journal of Network Security 12 (3) (May 2011) 221–228.

[3] Choo, Boyd, Hitchcock, Examining indistinguishability-based proof models forkey establishment protocols, Advances in Cryptology — Asiacrypt05, Springer-Verlag, 2005.

[4] T. Dimitriou, RFIDDOT: RFID delegation and ownership transfer made simple,Proceedings of the 4th International Conference on Security and Privacy for Com-munication Networks (SecureComm), 2008.

[5] Gilbert, Robshaw, Sibert, An active attack against HB+ — a provably secure light-weight authentication protocol, IEEE Electronic Letters 41 (21) (2005)1169–1170.

[6] G. Godor, M. Antal, Improved lightweight mutual authentication protocol for RFIDsystems, Wireless and Mobile Networking, IFIP International Federation for Infor-mation Processing, Volume 284, 2008, pp. 71–482.

[7] L. Gong, R. Needham, R. Yahalom, Reasoning about belief in cryptographic proto-cols, Proceedings of the IEEE Symposium on Security and Privacy, 1990,pp. 234–248.

[8] A.M. Hamad, W.I. Khedr, “Ad-hoc on Demand Authentication Chain Protocol— AnAuthentication Protocol for Ad-hoc Networks", SECRYPT, 2009.

[9] A. Ilic, F. Michahelles, E. Fleisch, “The Dual Ownership Model — A Concept for Ef-ficient Access Management of Item-Level Data in Pharmaceutical Supply Chains",Auto-ID Labs White Paper, 2007.


[10] P. Jäppinen, H. Hämäläinen, Enhanced RFID Security Method with OwnershipTransfer, Proceedings of the International Conference on Computational Intelli-gence and Security, 2008, pp. 382–385.

[11] A. Juels, Yoking proofs for RFID tags, Proceedings of the First International Work-shop on Pervasive Computing and Communication Security, IEEE Press, 2004.

[12] A. Juels, S. Weiss, “Authenticating pervasive devices with human protocol",advances in cryptology — CRYPTO 2005, LNCS 3621 (2005) 293–308.

[13] G. Kapoor, S. Piramuthu, Single RFID tag ownership transfer protocols, IEEE Trans-actions on Systems, Man, and Cybernetics — Part C, 2011.

[14] G. Kapoor, S. Piramuthu, Vulnerabilities in some recently proposed RFID owner-ship transfer protocols, IEEE Communications Letters 14 (3) (March 2010)260–262.

[15] E. Levieil, P.-A. Fouque, An attack of HB+ in the detection-based model, Securityand Cryptography for Networks, September 2006.

[16] Li, Ma, Moon, On the security of the Canetti–Krawczyk Model, Proceedings of CIS,Part II, LNAI 3802, Springer-Verlag, 2005, pp. 356–363.

[17] I.-C. Lin, C.-W. Yang, S.-C. Tsaur, Non-identifiable RFID privacy protection withownership transfer, International Journal of Innovative Computing, Information,and Control 6 (4) (April 2010).

[18] J.-H. Oh, H.-S. Kim, J.-Y. Choi, A secure communication protocol for low-cost RFIDsystem, Proceedings of the 7th IEEE International Conference on Computer andInformation Technology, IEEE Computer Society, 2007, pp. 949–954.

[19] S. Piramuthu, Protocols for RFID tag/reader authentication, Decision SupportSystems 43 (3) (2007) 897–914.

[20] S. Piramuthu, RFID mutual authentication protocols, Decision Support Systems50 (2) (2011) 387–393.

[21] J. Saito, K. Sakurai, Grouping proof for RFID tags, Proceedings of the 19th Interna-tional Conference on Advanced Information Networking and Applications(AINA'05), 2005, pp. 621–624.

[22] B. Song, RFID tag ownership transfer, Proceedings of RFIDSec08, 2008.[23] B. Song, C.J. Mitchell, Scalable RFID security protocols supporting tag ownership

transfer, Computer Communications (2010).[24] Y.-J. Tu, W. Zhou, S. Piramuthu, Identifying RFID-embedded objects in pervasive

healthcare applications, Decision Support Systems 46 (2) (2009) 586–593.

[25] M. Waller, M. Johnson, T. Davis, Vendor-managed inventory in the retail supplychain, Journal of Business Logistics 20 (1) (1999).

[26] X.-F. Wang, J.-G. Liu, J. Xu, S.-L. Liu, Mobile RFID security protocol and its GNYlogic analysis, Journal of Computer Applications 28 (9) (2009) 2239–2241.

[27] M.-H. Yang, Lightweight authentication protocol for mobile RFID networks, Inter-national Journal of Security and Networks 5 (1) (2009) 53–62.

[28] E.-J. Yoon, K.-Y. Yoo, Two security problems of RFID security method with owner-ship transfer, Proceedings of the IFIP International Conference on Network andParallel Computing, 2008, pp. 68–73.

Gaurav Kapoor received his Ph.D. (Information Systems) from the University ofFlorida in 2008. His research interests include RFID systems (especially issues relatedto security, privacy and ownership transfer and protocols addressing the same) andtext mining. His work has appeared in journals such as Decision Support Systems,European Journal of Information Systems, and IEEE Transactions on Systems, Manand Cybernetics.

Wei Zhou received his Ph.D. in Information Systems from the University of Florida in2008. His research interests include RFID-enabled item-level information visibility, In-ternet advertising, and knowledge-based learning systems. His work has appeared inEuropean Journal of Operational Research, IEEE Transactions on Geosciences and Re-mote Sensing, International Journal of Electronic Commerce, and Optical Engineering.

Selwyn Piramuthu is a professor of Information Systems at the University of Florida.He is also a member of the RFID European Lab in Paris. His research interests includeRFID systems, pattern recognition and its application in computer-aided manufactur-ing, financial credit-risk analysis, health care management, and supply chainmanagement.

Multi-tag and multi-owner RFID ownership transfer in supply chains

Documents

Transcript of Multi-tag and multi-owner RFID ownership transfer in supply chains