164 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICSPART C: APPLICATIONS AND REVIEWS, VOL. 42, NO.

2, MARCH 2012
Single RFID Tag Ownership Transfer Protocols
Gaurav Kapoor and Selwyn Piramuthu
AbstractSecurity/privacy issues are of paramount importance
for widespread acceptance and use of radio-frequency identica-
tion (RFID) tags. Over the last few years, researchers have ad-
dressed this issue through lightweight cryptographic means. While
a majority of existing RFID security/privacy protocols address au-
thentication issues, the ability to change as well as share ownership
of these tagged objects is equally important. We consider a few
RFIDownership transfer variations and propose protocols that are
lightweight and secure. We consider ownership transfer scenarios
for single tagsingle owner with and without a trusted third party
(TTP). We provide security analysis to evaluate the accuracy, con-
dentiality, and forward security of the proposed protocols from a
cryptography perspective.
Index TermsAuthentication, lightweight cryptography, own-
ership transfer (OT), radio-frequency identication (RFID).
I. INTRODUCTION
R
ADIO FREQUENCY IDENTIFICATION (RFID) tags
are extremely resource-constrained devices. Given their
limited memory and processing power, lightweight cryptogra-
phy has been extensively utilized for communication in RFID-
tagged systems. Protocols that address security/privacy issues
have been extensively studied and reported in the literature
(see [12]).
RFIDtags are increasingly being used in disparate domains to
identify, track, and sense ambient conditions of tagged objects.
A majority of these applications dictate that these RFID-tagged
objects be owned by different entities at different points in time.
This necessitates the existence of a mechanism for seamless
ownership transfer (OT) of tagged objects. For example, in a
supply chain, change in ownership of a tagged object may occur
when a distributor physically delivers it to a retailer. While
OT can be temporary or permanent, the underlying dynamic is
similar from a cryptographic perspective.
We propose lightweight protocols that meet the security re-
quirements of RFID devices and use them for OT and tag au-
thentication. Extant protocols either lack the ability to do both
or have inherent aws in their construction. We consider sce-
narios with and without a trusted third party (TTP). The latter
rely on previous owners being nonmalicious to avoid becoming
an ownership sharing protocol.
Manuscript received September 15, 2010; accepted October 6, 2010. Date
of publication December 20, 2010; date of current version February 17, 2012.
This paper was recommended by Associate Editor V. Marik.
G. Kapoor is with the Institute of Management and Computer Studies, Uni-
versity of Mumbai, Mumbai, India (e-mail: gkapoorumkc@gmail.com).
S. Piramuthu is with the Information Systems and Operations Man-
agement, University of Florida, Gainesville, FL 32611-7169 USA (e-mail:
selwyn@u.edu).
Digital Object Identier 10.1109/TSMCC.2010.2091501
This paper is organized as follows. The following section pro-
vides a brief overview of some related protocols. The proposed
OT protocol for single tag and single owner case with a TTP is
presented in Section III. This is extended to the case without a
TTP in Section IV. Section V concludes this paper with a brief
discussion.
II. RELATED WORK
OT, as the name implies, is the change in ownership (and
therefore control) of a particular tag. The main issue here is the
fact that unless some measures are taken, the previous owner
continues to maintain RF access to the tag. In cryptographic
terms, if Alice gives a tag (and therefore its access) to Bob,
how does Bob prevent Alice from accessing it at a later point
in time? Several extant protocols (see [2], [8], [11], and [14])
have addressed this issue, most using an external entity (TTP)
to coordinate the transaction. There have been relatively few
attempts without using a TTP (see [7] and [13]), and there are
fundamental problems with these protocols.
We begin by providing an overview of a selected few related
protocols and identify their vulnerabilities. We omit a few oth-
ers (see, [9] and [10]) due to space limitations. The protocol
proposed in [10] has been found to be vulnerable since several
tags share common bits of information which is a liability when
one of the tags is compromised. The last step for the tag in [9]
does nothing when c
i
> m. An adversary can use this to track
the tag. A few recent OT protocols are analyzed in [6]. We con-
sider symmetric cryptographic hash functions. An adversary is
assumed unrestricted and can be either passive or active.
A. Notation
The following notations are used throughout this paper:
Cred
J
credibility vector for entity J;
F
u
update ag;
f
/
k
, f
k
keyed (with key k) encryption function;
h, H, G hash functions0, 1

0, 1
l
(or, 0, 1
k
);
h
k
keyed (with key k) hash function;
ID
R
, ID
T
reader and tag identiers;
k, k
a
, k
/
a
authentication keys;
N
J
random l-bit nonce generated by entity J;
PIN unique personal identication number (PIN);
R
i
, T
i
reader/owner i, Tag i;
r
i
shared secret between reader R
i
and TTP;
SL server location;
s, s
/
, s
i
shared keys between entities;
t
i
shared secret between tag
i
and TTP;
V response value.
1094-6977/$26.00 2010 IEEE
KAPOOR AND PIRAMUTHU: SINGLE RFID TAG OWNERSHIP TRANSFER PROTOCOLS 165
Fig. 1. Three-party model (Saito, Imamoto, and Sakurai).
Fig. 2. Two-party model (Saito, Imamoto, and Sakurai).
B. Protocols of Saito, Imamoto, and Sakurai
Among the earliest protocols addressing OT exclusively was
by Saito et al. [13]. They proposed two related protocols, with
and without a TTP.
1) Three-Party Protocol With TTP: The goal here is to trans-
fer ownership from one entity R
1
to another R
2
with a TTP
mediating the process. Owner 1 (R
1
) initiates the protocol (see
Fig. 1) by sending key s
1
to Owner 2 (R
2
) through a secure
communication channel. R
2
then generates a new key s
2
and
sends both s
1
and s
2
to the TTP through a secure channel. The
TTP generates a ciphertext C = f
s
(s
1
, s
2
) by using his (veri-
able) key s and sends the ciphertext to R
2
. R
2
then sends C to
Tag T (N.B.: in Fig. 1, C goes over TTP). Finally, T decrypts C
using its shared secret (s) with the TTP. If s
1
is valid, T changes
it to the new key (s
2
).
An adversary can block the message from R
2
to the tag. The
tag is unaware of change in ownership and has its previous key
while TTP and R
2
have the new key, thus leading to desynchro-
nization between reader and tag. This can be prevented by TTP
and R
2
storing the previous key. However, forward security is
violated since R
2
knows s
1
.
2) Two-Party Model, Without TTP: Owner 1 (R
1
) begins the
two-party model without a TTP (see Fig. 2) by sending key s
1
to Owner 2 (R
2
) through a secure communication channel. R
2
then sends a query to tag T. T responds by generating a random
nonce N
T
and sending it to R
2
. R
2
then generates a new key s
2
and a ciphertext C = f
N
T
(s
1
, s
2
) and sends C to T. Finally, T
decrypts C. If s
1
is valid, T changes s
1
to s
2
.
Since N
T
and f
N
T
(s
1
, s
2
) are sent in the open, knowing the
construction of f, an adversary can obtain s
1
and s
2
. Also, keys
should not be shared between owners because not only can R
1
Fig. 3. Protocol of Osaka et al.
eavesdrop on the communication and decipher s
2
, but sharing
keys with R
2
compromises forward security.
C. Protocol of Osaka et al.
This [11] protocol attempts OT without a TTP (see Fig. 3).
The reader initiates the process by sending a random nonce
(N
R
) to the tag, which replies by encrypting this nonce and its
ID. The reader then relays this to the database for validation.
When valid, it generates a newk (i.e., k
/
) and sends information
about the tag along with k
/
. When not valid, it does not send
information about the tag to the reader. The reader then relays
the new k (i.e., k
/
) to the tag which then updates its current
value.
An adversary can intercept the rst message from reader to
tag, modify N
R
, and send (query, N
R
= 0) to the tag. The tag
then responds with H(f
k
(ID)) as long as k remains the same.
This can be used to track the tag. When the database changes k
to k
/
, the adversary can capture the (last) message from reader
to tag f
k
(ID) f
k
/ (ID) and use this instead of N
R,
the next
time the reader queries the tag. In the next session, when the
reader sends (query, N
R
) to the tag, the adversary can capture it
and instead send (query, f
k
(ID) f
k
/ (ID)) to the tag. The tag
now computes H(f
k
/ (ID) [f
k
(ID) f
k
/ (ID)]= H(f
k
(ID)),
which is the same output as before k was changed to k
/
. The
adversary may, therefore, continue to track the tag. This protocol
is also vulnerable to denial-of-service (DoS) attack which an
adversary can accomplish by adding a small noise (N
A
) to the
last message from reader to tag (i.e., f
k
(ID) f
k
/ (ID) N
A
).
Now, the tag updates the new secret as f
k
/ (ID) N
A
, whereas
the database and reader have f
k
/ (ID) as the new secret. This
leads to desynchronization. However, this is easily preventable
from the perspective of the database by storing the previous
secret. However, the reader is not supposed to knowthe previous
secrets since it would violate forward security and, therefore,
does not know the previous key.
Several authors have attempted to improve this protocol.
For example, J appinen and H am al ainen add N
DB
, H(f
k
/ (ID)
N
DB
) to the last message from the database to the reader to the
tag. However, an adversary can intercept the message between
reader and tag and modify N
DB
= 0 and (f
k
(ID) f
k
/ (ID))
to (f
k
(ID) f
k
/ (ID) N
DB
). The tag now computes its new
f
k
(ID) = f
k
/ (ID) N
DB
, which is different from f
k
/ (ID) in
the reader and database. This leads to desynchronization, and
therefore DoS, between the tag and reader/database.
166 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICSPART C: APPLICATIONS AND REVIEWS, VOL. 42, NO. 2, MARCH 2012
To the last message from database to reader, Chen et al. [1]
append (H(H(f
k
(ID) N
R
), f
k
/ (ID), f
k
(ID)), which is then
communicated to the tag by the reader. They claim that this
additional verication prevents DoS attack when the adver-
sary tries to modify the last message from reader to tag.
However, their modication still leaves the protocol vulner-
able in at least two counts. An adversary can still track the
tag through (query, N
R
= 0) and (query, f
k
(ID) f
k
/ (ID))
as described earlier. Moreover, the adversary can also reset
the secret to its previous value by impersonating the reader
as follows: 1) The adversary passively observes communica-
tion between reader and tag and copies N
R
, f
k
(ID) f
k
/ (ID),
and H(H(f
k
(ID) N
R
), f
k
/ (ID), f
k
(ID)); 2) the tags cur-
rent secret is f
k
/ (ID). When the adversary wants the tag
to reset its secret to its previous value f
k
(ID), it sends
(query, f
k
(ID) f
/
k
(ID) N
R
) as the rst message to the
tag; 3) the tag responds with f
k
(ID) N
R
, which is already
known to the adversary who can use it to track the tag; 4) the
adversary then sends H(H(f
k
(ID) N
R
), f
k
/ (ID), f
k
(ID)),
f
k
(ID) f
k
/ (ID); and (5) the tag validates these messages and
updates its secret to f
k
(ID).
Yoon and Yoo [19] modify the last messages fromdatabase to
reader and reader to tag in [11]. The message from reader to tag
is now H(f
k
(ID)) f
k
/ (ID), H(f
k
(ID) f
k
/ (ID)). Although
they claim that this prevents DoS attacks, when an adversary
blocks this last message, the database and reader have the new
key whereas the tag has the previous key. This issue can be pre-
vented by storing both previous and current keys at the database
level. However, the new owner cannot have the previous key
due to forward security violations. This protocol has a more
serious vulnerability. An active adversary can obtain the shared
secret (i.e., f
K
(ID)) as follows: 1) The adversary intercepts the
rst message from reader to tag and sends (query, N
R
= 0) to
the tag. The tag then responds with H(f
k
(ID)) as long as k
remains the same. 2) The adversary then sends some random
message to the tag in return and this lets the tag keep its current
secret. 3) The adversary observes all communication between
reader and tag during the next authentication phase between
tag and reader. 4) Now, f
k
/ (ID) can be easily determined since
both H(f
k
(ID)) f
k
/ (ID) and H(f
k
(ID)) are known to the ad-
versary. Knowing f
k
/ (ID), which is the only shared secret, the
adversary can track and trace the tag as well as clone the tag
if necessary. Knowing f
k
/ (ID) also results in forward security
violations.
D. Protocol of Seo, Asano, Lee, and Kim
The back-end server is the TTP in this protocol (see Fig.
4). The current owner R
1
initiates the process by sending a
random nonce N
R
to the tag, which responds with C. The
current owner then sends the encrypted PIN to the new owner,
who is authenticated by the server. The new owner updates the
PIN (i.e., PIN
/
) and noties the tag.
An adversary can impersonate a reader by sending query|N
R
to the tag using any N
R
, and the tag would reply with
the same C in C|N
R
until it is updated by a proxy
or a reader. In Fig. 4, D = f
s
(s
R2
, M
R1
|SL|PIN), E =
Fig. 4. Protocol of Seo, Asano, Lee, and Kim.
Fig. 5. Protocol of Koralalage et al. [7].
f
s
(s
R1
, Sig
R2
(M
R1
)|Cert
R2
), F = f
s
(s
R2
, x
/
|m), and J =
(C
/
|PIN
/
) G(PIN). The last message from new owner R
2
to tag (N.B.: J goes over R1) can be blocked by an adver-
sary, leading to synchronization problems: R
2
has the updated
PIN (i.e., PIN
/
) while the tag still has the previous PIN. Unless
the reader (R
2
) kept the previous PIN, it would not be able to
authenticate the tag.
E. Protocol of Koralalage et al.
This protocol requires interactions only between the new
owner and the tag. The new owner sends shared information
to the tag, which validates it and then replies with its identity
information. Based on the requirement (i.e., disable, update s,
etc.), the new owner sends the appropriate information to the
tag, which veries the message and responds with the validation
information.
An adversary can capture the rst message from reader to
tag (I, h
k
a
I, N
R
, ID
R
, s, ID
T
) and repeatedly replay this to
the tag to receive ID
R
, h
k
a
ID
R
, N
R
, N
T
from the tag. Even
though the tag freshly generates N
T
for every session, the ID
R
value remains the same.
Note that although ID
R
is a readers identity, it is irrelevant
since this (second) message is dependent on the rst message
KAPOOR AND PIRAMUTHU: SINGLE RFID TAG OWNERSHIP TRANSFER PROTOCOLS 167
Fig. 6. Delegation request protocol of Fouladgar and A.
Fig. 7. OT protocol of Fouladgar and A.
that is replayed by the adversary to the tag. The adversary can
use this to track the tag. It is unclear as to what happens when
an adversary blocks the last message from reader to tag or even
tag to reader since by this time the reader has already updated s
and k
a
while the tag has not.
F. Protocol of Fouladgar and A
The protocols proposed by Fouladgar and A (see [2] and
[3]) achieve delegation (i.e., provide a reader with temporary
credentials for communicating with the tag, without having to
communicate with a database every time) as well as OT. These
are similar to [11] in that the reader sends a query to the tag,
which responds with encrypted information that is unintelligible
to the reader. The reader relays it and its credentials to the
database, which validates it and sends the secret key and ID of
the tag if valid or just sends the IDif invalid. For OT, the database
sends the tags keys in encrypted formto the reader, which relays
it to the tag. The tag validates it and increments a bounded
counter used to prevent unlimited tries from an adversary.
The reader sends its Cred
R
in plaintext to the database (see
Figs. 6 and 7). This is vulnerable to replay attacks. Although
the authors mention that the interactions between database and
reader occur over a suitable secure communications protocol,
their protocol is vulnerable to replay attacks when the reader is
mobile. In the delegation request protocol, an adversary can im-
personate a valid reader and obtain ID for any tag from database
by replaying the Cred
R
value that is sent in cleartext.
An adversary can impersonate the tag to a reader (see Fig. 6)
by replaying r
T
, H(r
T
k
p
) unless the reader keeps track of
replayed values. This is an implementational issue. The reader
can also be programmed to receive a maximum of c responses
froma tag with the same k
p
value. Although not a vulnerability,
it takes three rounds for new owner to obtain all it needs from
tag. The OT protocol merely resets the counter to c
max
. The new
Fig. 8. Protocol of Lei and Cao.
owner needs to run the delegation update and delegation request
protocols to obtain k
p
for the tag.
G. Protocol of Lei and Cao
Like [2] and [3], this protocol is similar to [11] in that the
reader queries the tag, which responds with encrypted infor-
mation. The reader relays it and its credentials to the database,
which validates it and sends the secret key and ID of the tag if
valid or just sends the ID if invalid.
A vulnerability of this protocol (see Fig. 8) is due to fail-
ure in explicitly authenticating the reader. An adversary can
impersonate an honest reader and send (Query, N
r
) to the
tag, which responds with (N
T
, H(f
k
(ID) N
R
|N
T
)). The ad-
versary then forwards (N
T
, N
R
, H(f
k
(ID) N
R
|N
T
)) to the
database, which shares information about the tag with the ad-
versary [Info(ID)]. This could be prevented by including some
reader-specic information in the messages.
Moreover, this is an ownership sharing (and not OT) protocol
since previous owners could maintain access to the tag. When
a new owner gets a new key (k
/
), it sends (e, m) to the tag in
a channel that is not secure. A previous owner can passively
observe this and get f
k
/ (ID) (= e H(f
k
(ID))). Since the tag
uses f
k
/ (ID) until the next OT, previous owners have continued
access to tag.
H. Protocol of Song
The rst stage transfers ownership from one owner R
1
to
another R
2
and the second stage updates the secret. The new
owner initiates the process by sending a random nonce to the
168 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICSPART C: APPLICATIONS AND REVIEWS, VOL. 42, NO. 2, MARCH 2012
Fig. 9. OT protocol of Songtransfer secrets to new owner.
tag, which generates another randomnonce and sends a message
with these. The newowner then contacts the previous owner who
validates the information and shares tag information when valid.
Now, both (new and previous) owners know the tags secrets.
The new owner then generates a new set of secrets and shares
them with the tag. The tag validates it and updates its keys when
valid. It also responds to the new owner with random nonces
encrypted with a secret key. The new owner updates the keys
after the message is successfully validated.
Curiously, communication between the two owners (see Fig.
9) is secure one way (i.e., R
1
to R
2
) and not the other (i.e., R
2
to R
1
). Herein lies one of the vulnerabilities. An adversary can
hijack the communication from R
2
to R
1
and replay this to the
current owner (i.e., R
1
) and continue with the remainder of the
protocol to obtain ownership of the tag. This can be prevented
through a secure two-way channel between R
1
and R
2
.
Another vulnerability is desynchronization between tag and
new owner R
2
that can arise when R
2
has the new key (t, s)
while the tag has the previous key when an adversary blocks the
last communication M
3
between R
2
and tag in the OT protocol
(see Fig. 9). Although R
1
can transfer the previous secrets (i.e.,
t
/
, s
/
) as a part of Info, it would violate forward security since the
newowner can decrypt previous messages knowing the previous
secret and messages encrypted with that secret. Even worse, an
adversary can impersonate the tag by copying r
1
, M
1
, and M
2
from an authentication round (see Fig. 9) and during a later
authentication round when the reader sends a new r
1
(say, r
1
/
),
the adversary can respond with M
1
r
1
r
1
/
, M
2
.
This is strictly not an OT protocol since previous owners
continue to maintain access to a tag. Although the paper claims,
Protocol P2 should be performed at a distance fromany readers
connected to S
j
, in order to prevent S
j
eavesdropping on the
messages, (here, P2 is Fig. 10 and S
j
is R
2
) this may not be
valid. If this assumption were valid (i.e., the absence of any
other reader in the vicinity of the new reader), there is no need
to encrypt messages.
Fig. 10. OT protocol of Songupdate tag secret.
Fig. 11. Proposed OT Protocol with TTP.
III. OWNERSHIP TRANSFER PROTOCOL WITH
TRUSTED THIRD PARTY
A. OT
We now present the rst of our OT protocols.
As in existing OT protocols, we assume that two entities are
interested in transferring ownership of an object that is RFID
tagged. For example, such an OT protocol may be used when a
customer buys a tagged object from a retailer. For the remainder
of this paper, to prevent DoS attacks, the recipient of a freshly
generated random nonce sent in plaintext (e.g., N
P
fromTTP to
tag in Fig. 11) accepts it only if this random nonce is non-null.
We assume that a message originator waits for a response for
a prespecied amount of time and nonresponse triggers a fresh
message.
The proposed OT procedure is accomplished as follows:
Step 1.1: Upon receiving an OT request, the TTP generates a
new key s
2
. It then generates a fresh random nonce N
P
,
and sends f
/
encrypted with (N
P
t
i
s
1
), where s
1
is the
tags current key. This authenticates the TTP to the tag, which
updates s
1
to s
2
.
Step 1.2: The tag acknowledges by generating a random nonce
N
T
.
KAPOOR AND PIRAMUTHU: SINGLE RFID TAG OWNERSHIP TRANSFER PROTOCOLS 169
Fig. 12. Authentication handshake.
Step 2: The TTP informs current owner R
1
that his privileges
are being revoked. It sends a simple revoke message and a
keyed cryptographic function f
r
1
(s
1
).
Step 3.1: Next, the TTP grants the new owner R
2
full per-
missions along with any delegation privileges for the tag. A
grant message is issued, along with a freshly generated ran-
dom nonce N
/
P
and a function encrypted with the key r
2
shared between new owner and TTP. The function contains
the new key s
2
.
Step 3.2: The new owner sends an acknowledgment using a
one-way hash with the new key value.
Step 4.1: The new owner then generates a fresh random nonce
N
R
2
, and establishes contact with the tag by sending N
R
2
and N
R
2
in an encrypted function (using s
2
as the encryption
key).
Step 4.2: The tag acknowledges with a one-way hash of a new
random nonce N
/
T
along with N
R
2
and s
2
.
B. Authentication
Now that all involved parties know the shared secret s
2
for
the tag of interest; we introduce a protocol that can be used for
mutual authentication of R
2
and tag.
The authentication handshake works as follows:
Step 1: The new owner queries the tag with N
R
2
.
Step 2: The tag responds with a freshly generated randomnonce
N
T
, and a keyed (with N
T
s
2
) hash of N
R
2
. Only the tag
and its new owner R
2
share s
2
. This authenticates tag to
owner.
Step 3: The message fromowner to tag nowconsists of a freshly
generated randomnonce N
/
R
2
, and an optional operation. (An
example op would be to update a tag register.) This message
is encrypted using both the shared key s
2
between tag and
new owner and the nonce generated by the tag in the previous
message N
T
. This authenticates the owner to the tag.
Step 4: To acknowledge receipt of the message in Step 3, the
tag sends H
s
2
(N
/
R
2
) to the owner. If the owner does not
receive this message within a predetermined amount of time,
the process is repeated from Step 1.
C. Security Analysis
The security design of the protocols should not impede nor-
mal operations and should prevent a malicious adversary from
retrieving or inferring any information. The sketch of the anal-
ysis considers relevant measures.
1) Secrecy/data integrity and authenticity: The cryptographic
methods used (e.g., the function ensemble f
s
i
) reasonably
guarantees the secrecy of the message. The authenticity
of the communicating parties is guaranteed by the keyed
hash functions.
2) DoS/synchronization problem: We address the DoS prob-
lem in the following way: Consider a situation where an
adversary blocks a message. Since we rely on acknowl-
edgments for the key change and rst postkey change
communique from new owner to tag, blocking any mes-
sage creates no breach in the system. In addition, we do
not face the desynchronization problem (i.e., that the tag
is unreachable because it has a different key). At least one
entity (be it previous owner R
1
, new owner R
2
, or the
TTP) can always communicate with the tag. The follow-
ing discussion will make this more clear. There are many
scenarios where an adversary could try and compromise
the system. Block message (1.1): R
1
can still reach the tag.
Block message (1.2): The TTP is waiting for an acknowl-
edgment and will take remedial action. Block message
(2): Once the keys are changed, R
1
cannot access the tag.
Block message (3.1): Now the tag has a new key s
2
, but
R
2
has not received it yet; therefore, the tag is temporarily
unreachable, except by the TTP. However, the acknowl-
edgment (3.2) that TTP is waiting for will never arrive,
and, so the TTP can now take remedial action. Block mes-
sage (4.1): Again, the tag is unreachable, except by the
TTP, but R
2
is waiting for an acknowledgment. There-
fore, it can take remedial action. It must be emphasized
that such DoS problems are considered beyond the scope
of the communication protocol in a majority of related
literature, but our OT protocol takes it into account. Of
course, to commit such attacks, an adversary must know
all the parties involved, the sequencing of the messages,
and the timing of the messages.
3) Forward security: Forward security refers to the scenario
where the current key of a tag is known to the adversary,
and can be used to extract previous messages (assuming
that all its past conversations are recorded by him). Let
us say the adversary somehow knows s
2
. The tag always
communicates using a keyed hash function. The adver-
sary cannot use the key to decode any of the tags mes-
sages because the one-way hash function H is considered
computationally uninvertible. That is, access to the hash
digest table is necessary for any lookups. Also, the adver-
sary cannot decipher/recreate any past messages sent with
previously used keys.
4) Passive replay: The freshly generated random nonces cre-
ate an element of randomness in the OT process. In addi-
tion, using freshly generated random nonce in the crypto-
graphic functions or the keyed hash functions reduces the
possibility of successful replay attacks. Assume that an ad-
versary wants to replay the last message fromthe tag to the
new owner. This message is N
/
T
, H
(N
/
T
s
2
)
(N
R
2
s
2
).
When R
2
receives this a second time, it checks to ensure
that the N
R
2
in the message matches with the one it had
recently sent to the tag. When it identies the message as
corrupt (or, replay of a previous message, which can be
considered a corrupted message at this point in time), it
repeats its previous message to the tag.
170 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICSPART C: APPLICATIONS AND REVIEWS, VOL. 42, NO. 2, MARCH 2012
We now verify the correctness of the assumptions with re-
spect to message source as well as the beliefs of the sender
and recipient of messages using GNY logic [4]. We proceed
by including the individual messages in the protocol followed
by inherent explicit assumptions and then the goals. We then
present proofs of these goals using GNY logic.
Protocol messages:
M1: T (N
P
), (f
/
(N
P
t
i
s
1
)
(s
2
))
M2: TTP (N
T
), (H
(t
i
N
T
)
(s
2
N
P
))
M3: R1 f
r
1
(s
1
)
M4: R2 (N
/
P
), (f
(r
2
N
/
P
)
(s
2
r
2
))
M5: TTP H
r
2
(s
2
N
/
P
)
M6: T (N
R
2
), (f
/
s
2
(N
R
2
))
M7: R2 (N
/
T
), (H
N
/
T
s
2
(N
R
2
s
2
))
Assumptions:
A1: TTP (N
P
, N
/
P
)
A2: T (N
T
, N
/
T
)
A3: R
2
N
R
2
A4: TTP[ TTP
t
i
,s
1
T
A5: T[ TTP
t
i
,s
1
T
A6: TTP[ TTP
r
2
R
2
A7: R
2
[ TTP
r
2
R
2
A8: TTP[ #(N
P
, N
/
P
)
A9: T[ #(N
T
, N
/
T
)
A10: R
2
[ #(N
R
2
)
Goals of the correctness proof: The primary goals of the
proposed protocol are belief ([), and the freshness (#), of
the messages between each pairs of TTP, R
2
, T. Belief ensures
that message is from a trusted source. Freshness ensures that
message was not sent earlier during the same session.
G1: T[ TTP[ #(N
P
)
G2: T[ TTP[ #(f
/
(N
P
t
i
s
1
)
(s
2
))
G3: T[ TTP[ #(N
T
)
G4: T[ TTP[ #(H
(t
i
N
T
)
(s
2
N
P
))
G5: R
2
[ TTP[ #(N
/
P
)
G6: R
2
[ TTP[ #(f
(r
2
N
/
P
)
(s
2
r
2
)
G7: TTP[ R
2
[ H
r
2
(s
2
N
/
P
)
G8: T[ R
2
[ #(N
R
2
)
G9: T[ R
2
[ #(f
/
s
2
(N
R
2
)
G10: R
2
[ T[ #(N
/
T
)
G11: R
2
[ T[ #(H
N
/
T
s
2
(N
R
2
s
2
)
G12: TTP[ TTP
s
2
T
G13: T[ TTP
s
2
T
G14: TTP[ TTP
s
2
R
2
G15: R
2
[ TTP
s
2
R
2
G16: T[ T
s
2
R
2
G17: R
2
[ T
s
2
R
2
Proof:
The logical postulate numbers (e.g., M1, T1,...) referred to in
the following are from [4]
[D1:] T N
P
, f
/
(N
P
t
i
s
1
)
(s
2
) /* M1,T1 */
[D2:] T N
P
, f
/
(N
P
t
i
s
1
)
(s
2
) /* D1,P1 */
[D3:] T[ #N
P
, #f
/
(N
P
t
i
s
1
)
(s
2
) /* D2,F10 */
[D4:] T[ TTP[ #N
P
/* A4,A5,D3,I1 */
[D5:] T[ TTP[ #f
/
(N
P
t
i
s
1
)
(s
2
) /*A4,A5,D3,I1,P2*/
[D6:] T[ TTP
s
2
T /* A5,D3,J1 */
[D7:] TTP[ TTP
s
2
T /* A4,D3,D6,J1 */
[D8:] TTP N
T
, H
(t
i
N
T
)
(s
2
N
P
) /* M2,T1 */
[D9:] TTP N
T
, H
(t
i
N
T
)
(s
2
N
P
) /* D8,P1 */
[D10:] TTP[ #N
T
, #H
(t
i
N
T
)
(s
2
N
P
) /* D9,F10 */
[D11:] T[ TTP[ #N
T
/*D9,D10,F1,I1*/
[D12:] T[ TTP[ #H
(t
i
N
T
)
(s
2
N
P
) D9-10,F1,I1,P4/
[D13:] R2 N
/
P
, f
(r
2
N
/
P
)
(s
2
r
2
) /*M4,T1*/
[D14:] R2 N
/
P
, f
(r
2
N
/
P
)
(s
2
r
2
) /*D13,P1*/
[D15:] R2[ #N
/
P
, #f
(r
2
N
/
P
)
(s
2
r
2
) /*D14,F10*/
[D16:] R2[ TTP[ #N
/
P
/*D14,D15,F1,I1*/
[D17:] R2[ TTP[ #f
(r
2
N
/
P
)
(s
2
r
2
) D14-5,F1,I1,P2/
[D18:] TTP[ TTP
s
2
R
2
/* A6,D15,J1 */
[D19:] R
2
[ TTP
s
2
R
2
/* A7,D15,D18,J1 */
[D20:] TTP H
r
2
(s
2
N
/
P
) /*M5,P1*/
[D21:] TTP[ R
2
[ H
r
2
(s
2
N
/
P
) /*D20,F1,I1,P4*/
[D22:] T N
R
2
, f
/
s
2
(N
R
2
) /* M6,T1 */
[D23:] T N
R
2
, f
/
s
2
(N
R
2
) /* D22,P1 */
[D24:] T[ #N
R
2
, #f
/
s
2
(N
R
2
) /* D23,F10 */
[D25:] T[ R
2
[ #N
R
2
/* D23,D24,F1,I1 */
[D26:] T[ R
2
[ #f
/
s
2
(N
R
2
) /* D23,D24,F1,I1,P2 */
[D27:] R2 N
/
T
, H
N
/
T
s
2
(N
R
2
s
2
) /* M7,T1 */
[D28:] R2 N
/
T
, H
N
/
T
s
2
(N
R
2
s
2
) /* D27,P1 */
[D29:] R2[ #N
/
T
, #H
N
/
T
s
2
(N
R
2
s
2
) /* D28,F10 */
[D30:] R2[ T[ #N
/
T
/* D29,F1,I1 */
[D31:] R2[ T[ #H
N
/
T
s
2
(N
R
2
s
2
) /*D29,F1,I1,P4*/
[D32:] TTP[ T
s
2
R
2
/* G12,G14 */
[D33:] T[ TTP[ T
s
2
R
2
/* D32,J3 */
[D34:] R
2
[ TTP[ T
s
2
R
2
/* D32,J3 */
[D35:] T[ T
s
2
R
2
/* D33,D34,J1 */
[D36:] R
2
[ T
s
2
R
2
/* D33,D34,J1 */
The proof of goals 117 are shown by the verication steps
D4, D5, D11, D12, D16, D17, D21, D25, D26, D30, D31, D7,
D6, D18, D19, D35, and D36, respectively.
In GNY logic, the principals are not assumed to be trustwor-
thy and redundancy is always explicitly present in encrypted
messages. GNY logic distinguishes between what a principal
can possess and what it can believe in. It enables expressing
different trust levels and implicit conditions behind protocol
steps.
In general, proving that an authentication protocol meets its
specication involves proving the following three properties.
1) All entities learn what they should learn.
2) What the entities learn is indeed true.
3) No entity learns (its) forbidden facts.
GNY logic addresses aforementioned properties 1 and 2. To
prove property 3, the limitations of the entities need to be mod-
eled and these limitations effectively obstruct these entities from
inferring these (forbidden) facts. We considered several scenar-
ios where property 3 could be violated earlier in this section
and showed that the proposed protocol is secure under the con-
sidered threats. Furthermore, we now prove the correctness of
KAPOOR AND PIRAMUTHU: SINGLE RFID TAG OWNERSHIP TRANSFER PROTOCOLS 171
the proposed protocol (property 3) using strand space (see [16])
by following the logic presented by its authors. We use P
OT
to represent the proposed protocol and use guarantees from the
responders and initiators side through propositions to develop
the proof.
We use the following notations for proof using strand space:
1) T, : penetration strand space, strand space;
2) T, T
name
: set of text representing atomic messages;
3) (: bundle;
4) t
1
i
: inverse (key);
5) K
P
: keys known to the penetrator;
6) : precedence relationship;
7) : subset.
Denition 1: An inltrated strand space T, is a P
OT
space
if is the union of three kinds of strands.
1) Penetrator strands s T.
2) Initiator strands with trace Init[TTP, Tag
i
, N
P
, N
T
] de-
ned to be
+N
P
, f
/
(N
P
t
i
s
1
)
(s
2
), N
T
, H
(t
i
N
T
)
(s
2
N
P
)),
where TTP, Tag
i
T
name
but N
P
/ T
name
.
3) Its complement, the responder strands with trace
Resp[TTP, Tag
i
, N
P
, N
T
], dened to be
N
P
, f
/
(N
P
t
i
s
1
)
(s
2
), +N
T
, H
(t
i
N
T
)
(s
2
N
P
)),
where TTP, Tag
i
T
name
but N
T
/ T
name.
1) Responders Guarantee (Agreement):
Proposition 1: Suppose
1) is a P
OT
space and ( is a bundle containing a responders
strand s with trace Resp[TTP, Tag
i
, N
P
, N
T
];
2) t
1
i
/ K
P
; and
3) N
P
,= N
T
and N
T
is uniquely originating in ; then (
contains an initiators strand t with trace Init[TTP, Tag
i
,
N
P
, N
T
].
We prove this proposition using the following lemmas.
Lemma 1: N
T
originates at the second message (the one from
Tag
i
).
We know N
T
Tag
i
(say, node n
o
) and the sign for the
second message (say, v
o
) is positive since it originates from
Tag
i
. We, therefore, need to verify that N
T
is not in the preceding
node (here, TTP) in the strand, which is the preceding node on
this strand, i.e., N
T
,= N
P
, N
T
,= t
i
, N
T
,= s
1
, and N
T
,= s
2
.
These are all true by denition.
Lemma 2: The set S = n ( : N
T
term(n) v
o
,
term(n) has a _-minimal node n
2
. The node n
2
is regular
with a positive sign.
We need to check if n
2
lies on a penetrator strand p.
S: If g h term(m), where m is a positive node on a strand p
/
of kind S, then g h term(p
/
, 1)). Minimality of m in T is
contradicted by p
/
, 1) m.
E.(D.): If g h term(m), where m is a positive node on a
strand p
/
of kind E (D, respectively), then g h term(p
/
, 2)).
Minimality of m in T is contradicted by p
/
, 2) m.
C: If g h term(m), where m is a positive node on a strand p
/
of kind C and m is minimal in T, then g h = term(m) and p
/
has trace g, h, +gh). This contradicts the minimality of
n
2
in S since term(p
/
, 1)) = term(n
2
) and p
/
, 1) n
2
.
Lemma 3: Node n
2
follows n
1
on the same regular strand t,
and term(n
1
) = N
T
, H
(t
i
N
P
)
(s
1
N
T
).
From Lemma 1 and by denition, we know that N
T
origi-
nates at n
o
and its uniqueness in . We also know that n
2
,= n
o
since v
o
term(n
o
) and v
o
, term(n
2
). Therefore, N
T
does
not originate at n
2
, and there is a node n
1
preceding n
2
on
the same strand such that N
T
term(n
1
). By the minimal-
ity property of n
2
, N
T
, H
(t
i
N
P
)
(s
1
N
T
) term(n
1
). Here,
N
T
, H
(t
i
N
P
)
(s
1
N
T
) =term(n
1
) since no regular node con-
tains an encrypted term as a proper subterm.
Lemma 4: The regular strand t containing n
1
and n
2
is con-
tained in ( and is an initiator strand.
If t were a responder strand, it would contain only a subse-
quent negative node. Here, n
2
is a positive node. The last node
of t (i.e., n
2
, which follows n
1
) as well as the previous nodes is
contained in (.
Lemmas 3 and 4 prove Proposition 1.
2) The Initiators Guarantee (Secrecy and Agreement):
Proposition 2: Suppose
1) is a P
OT
space and ( is a bundle containing an initiators
strand s with trace Init[TTP, Tag
i
, N
P
, N
T
];
2) t
1
i
/ K
P
; and
3) N
P
is uniquely originating in ; then for all nodes m (
such that N
P
term(m) either N
P
, f
/
(N
P
t
i
s
1
)
(s
2
)
term(m) or N
T
, H
(t
i
N
P
)
(s
2
N
T
) term(m).
Proposition 3: Suppose
1) is a P
OT
space and ( is a bundle containing an initiators
strand s with trace Init[TTP, Tag
i
, N
P
, N
T
];
2) t
1
i
/ K
P
; and
3) N
P
is uniquely originating in ; then ( contains the rst
two nodes of a responders strand t with trace Resp[TTP,
Tag
i
, N
P
, N
T
].
The set m ( : N
T
, H
(t
i
N
P
)
(s
2
N
T
) term(m) is
nonempty since it contains s, 2), i.e., it contains a minimal
member (m
o
). Now, the regular strand t can be shown to have
trace Resp[TTP, Tag
i
, N
P
, N
T
] if m
o
lies on t. The regu-
lar strand t can also be shown to have at least two nodes
in (. However, if m
o
lies on a penetrator strand t, then t
can be shown to be an E-strand with trace t
i
, N
T
, s
2

N
T
, +N
T
, H
(t
i
N
P
)
(s
2
N
T
)). However, this contradicts
Proposition 2, which implies that N
P
does not appear in the
form shown in node t, 2). The proofs for the other loops in
the protocol are similar in structure and are hence omitted for
brevity considerations.
IV. OWNERSHIP SHARING PROTOCOL WITHOUT TRUSTED
THIRD PARTY
This is similar to the one with TTP (see Section III), except
that the TTPis absent. Although this protocol is more secure than
those in the existing literature, it does not transfer ownership in
the strict sense since all previous owners can still access the tag.
However, it is an improvement over [13], since we do not pass
the original key to the new owner.
Once the request for transfer of ownership has been invoked
and approved, the procedure for the actual transfer of ownership
works as follows:
172 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICSPART C: APPLICATIONS AND REVIEWS, VOL. 42, NO. 2, MARCH 2012
Fig. 13. OT protocol without TTP: Initialization.
Fig. 14. OT protocol without TTP: Key change.
Step 1: Upon receiving an OT request, R
1
generates a fresh
random nonce N
R
1
, XORs the key shared with the tag s
1
with this nonce, and sends it encrypted to the tag and on a
secure channel to R
2
. This is the initialization phase, as
depicted in Fig. 13.
Step 2.1: Upon receiving N
R
1
s
1
from R
1
, the tag generates
a fresh random nonce N
T
and sends the nonce XORed with
the key s
1
to R
2
(see Fig. 14). Now, both T and R
2
know
N (where N = N
R
1
N
T
). As another measure or layer to
preserve forward security, R
2
is not allowed to know s
1
.
Step 2.2: The tag now randomly ips one bit in N, creating
N
/
, and generates another fresh random nonce N
/
T
. It sends
N
/
T
and an encrypted function containing N
/
N
/
T
, using
N
/
N
/
T
as the key and a similarly keyed hash function with
the same values to R
2
.
Step 3.1: Knowing N, R
2
uses a brute force technique to de-
termine N
/
to decrypt the value sent in f. Since R
2
knows
that N
/
is really just N with only one ipped bit, this pro-
cess is feasible, and R
2
is assumed to possess the necessary
computational resources to accomplish this very quickly. R
2
veries the solution obtained using the hashed value.
Step 3.2: The new owner R
2
now generates and sends a new
key to the tag by XORing and encrypting it with N
/
. This
step is repeated after a predetermined time period until Step
4 happens.
Step 4: The tag acknowledges receipt of the new key using a
hash function, keyed with the new key s
2
.
Step 5: To acknowledge receipt of message in Step 4, R
2
sends
f
s
2
(N
/
s
2
) to the tag. If the tag does not receive this within
Fig. 15. Comparison of protocols.
a predetermined amount of time, the process is repeated be-
ginning with Step 1.
A. Security Analysis
We evaluate the OT protocol without TTP.
1) Secrecy/authentication: Using key-based cryptographic
function ensembles (H
s
i
, f
s
i
, etc.), we assure the recipient
that the messages originates from valid sources.
2) Indistinguishability/tracking: Using a freshly generated
random nonce with almost every message in the protocol,
it is difcult to track the tag. Assume that an adversary
pretends to be a genuine reader. He sends out a query and
receives the hash of a message back. Next time he sends
a query, along with a freshly generated random nonce, he
receives a different message so that he cannot track the
tag. Of course, with multiple tags in an area, tracking a
specic tag without keys is extremely difcult.
3) Forward security: Let us say the adversary somehow
knows s
2
. The tag always communicates using a keyed
hash function. The adversary cannot use the key to de-
code any of the tags messages. Also, he cannot deci-
pher/recreate any past messages sent with previously used
keys.
4) Passive replay: The freshly generated nonces create an el-
ement of randomness. However, passive replay is possible
in the absence of a secure channel to do the initialization.
In Fig. 15, we compare the security performance of SIS-I&II
(Saito, Imamoto, Sakurai), OTYT (Osaka, Takagi, Yamazaki,
Takahashi), KRMGC (Koralage, Reza, Miura, Goto, Cheng),
FA (Fouladgar, A), SALK (Seo, Asano, Lee, Kim), and OT-
I&II (proposed protocols with and without TTP, respectively).
The entries denote the performance of each protocol against the
relevant security parameter. Here, Y = Fully satised, N =
Not satised, P = Partially satised, X = Can be fullled by
implementation, and N/A = Not Applicable.
V. DISCUSSION
As we have seen in this paper, most existing protocols for OT
have vulnerabilities. To address this issue and, therefore, inspire
more condence in this technology, the contribution of this pa-
per is threefold. First, we provide an overview of published OT
protocols and identify some of their security-based vulnerabili-
ties. Second, we propose OT protocols that are more secure than
those currently existing and yet just as lightweight. We also show
KAPOOR AND PIRAMUTHU: SINGLE RFID TAG OWNERSHIP TRANSFER PROTOCOLS 173
how the same protocol can be used for tag authentication and
secure communication between tags and readers without modi-
cation. Most current protocols require multiple suites to perform
both actions, if at all. Finally, during OT we provide a way to
prevent DoS attacks using an acknowledgment-based scheme.
We provided security analysis for validating these claims by
considering some scenarios where we duplicate the intent of a
malicious adversary.
Although it is not easy to accomplish OT in the presence of
a TTP, achieving the same without a TTP is rather challenging.
The high proportion of RFID OT protocols with TTP compared
to those without TTP attest to this difculty. Moreover, the
cases without TTP are not OT protocols in the strict sense since
previous owners may continue to maintain RF access to tags.
The protocols presented for the cases where a TTP is absent
are somewhat vulnerable to attack from a determined and re-
sourceful adversary simply because OThere essentially involves
sharing information between entities that have no shared secrets.
However, just like in other similar scenarios, we attempted to
add additional locks to render it difcult for adversaries to re-
trieve secret keys. We sincerely hope that this paper motivates
researchers to develop improved OT protocols.
ACKNOWLEDGMENT
The authors would like to thank the two reviewers for their
detailed constructive comments and suggestions on an earlier
version of this paper, which was under review for over two
years and ve revisions due to an obstructive reviewer, that
have helped to improve both the content and presentation. They
are also grateful to the Editor-in-Chief, Prof. V. Marik, for his
understanding of the unpleasant situation created by this third
reviewer.
REFERENCES
[1] H.-B. Chen, W.-B. Lee, Y.-H. Zhao, and Y.-L. Chen, Enhancement of
the RFID security method with ownership transfer, in Proc. Int. Conf.
Ubiquitous Inform. Manage. Commun., 2009, pp. 251254.
[2] S. Fouladgar and H. A, A simple delegation scheme for RFID systems
(SiDeS), in Proc. IEEE Int. Conf/RFID, 2007, pp. 16.
[3] S. Fouladgar and H. A, An efcient delegation and transfer of owner-
ship protocol for RFID tags, in Proc. 1st Int. EURASIP Workshop RFID
Technol., 2007, pp. 5962.
[4] L. Gong, R. Needham, and R. Yahalom, Reasoning about belief in crypto-
graphic protocols, in Proc. IEEE Symp. Security Privacy, 1990, pp. 234
248.
[5] P. J appinen and H. H am al ainen, Enhanced RFID security method with
ownership transfer, in Proc. Int. Conf. Comput. Intell. Security, 2008,
pp. 382385.
[6] G. Kapoor and S. Piramuthu, Vulnerabilities in some recently proposed
rd ownership transfer protocols, IEEE Commun. Lett., vol. 14, no. 3,
pp. 260262, Mar. 2010.
[7] K. Koralalage, S. Reza, J. Miura, Y. Goto, and J. Cheng, POP Method:
An approach to enhance the security and privacy of RFID systems used in
product lifecycle with an anonymous ownership transferring mechanism,
in Proc. ACM Symp. Appl. Comput., 2007, pp. 270275.
[8] H. Lei and T. Cao, RFID protocol enabling ownership transfer to pro-
tect against traceability and DoS attacks, in Proc. 1st Int. Symp. Data,
Privcacy E-Commerce, Nov. 2007, pp. 508510.
[9] C. H. Lim and T. Kwon, Strong and robust RFID authentication enabling
perfect ownership transfer, in Proc. Int. Conf. Inf. Commun. Security,
2006, pp. 120.
[10] D. Molnar, A. Soppera, and D. Wagner, A scalable, delegatable
pseudonym protocol enabling ownership transfer of RFID tags, in Proc.
Sel. Areas Cryptogr., 2005, pp. 276290.
[11] K. Osaka, T. Takagi, K. Yamazaki, and O. Takahashi, An efcient and
secure RFID security method with ownership transfer, in Proc. Int. Conf.
Comput. Intell. Security, LNAI 4456, 2007, pp. 778787.
[12] S. Piramuthu, Lightweight cryptographic authentication in passive RFID-
tagged systems, IEEE Trans. Syst., Man, Cybern. C, vol. 38, no. 3,
pp. 360376, May 2008.
[13] J. Saito, K. Imamoto, and K. Sakurai, Reassignment scheme of an RFID
tags key for owner transfer, in Proc. IFIP Int. Conf. Embedded Ubiqui-
tous Comput. Workshop, LNCS 3823, 2005, pp. 13031312.
[14] Y. Seo, T. Asano, H. Lee, and K. Kim, A lightweight protocol enabling
ownership transfer and granular data access of RFID tags, in Proc. Symp.
Cryptogr. Inf. Security, 2007, pp. 17.
[15] B. Song, RFID tag ownership transfer, in Proc.. RFIDSec, 2008, p. 16.
[16] F. W. Thayer F abrega, J. C. Herzog, and J. D. Guttman, Strand spaces:
Proving security protocols correct, J. Comput. Security, vol. 7, pp. 191
230, 1999.
[17] Y.-J. Tu, W. Zhou, and S. Piramuthu, Identifying RFID-embedded objects
in pervasive healthcare applications, Decis. Support Syst., vol. 46, no. 2,
pp. 586593, 2009.
[18] M. Waller, M. Johnson, and T. Davis, Vendor-managed inventory in the
retail supply chain, J. Bus. Logistics, vol. 20, no. 1, pp. 183203, 1999.
[19] E.-J. Yoon and K.-Y. Yoo, Two security problems of RFID security
method with ownership transfer, in Proc. IFIP Int. Conf. Netw. Parallel
Comput., 2008, pp. 6873.
Gaurav Kapoor received the Ph.D. degree in information systems from the
University of Florida, Gainesville, in 2008.
He is an Assistant Professor with the Institute of Management and Computer
Studies, University of Mumbai, Mumbai, India. His research interests include
radio-frequency identication systems (especially issues related to security,
privacy, and ownership transfer and protocols addressing the same) and text
mining. His work has appeared in journals such as Decision Support Systems
and the European Journal of Information Systems.
Selwyn Piramuthu received the Ph.D. degree in information systems from the
University of Illinois at Urbana-Champaign, in 1992.
He is currently a Professor of Information Systems with the University of
Florida, Gainesville. He is a member of the RFID European Laboratory, Paris,
France, and an Associate Researcher of Information Systems and Technologies
with ESCP-Europe, Paris. His research interest includes pattern recognition and
radio-frequency identication systems.