PRIVACY FOR RFID-ENABLED DISTRIBUTED APPLICATIONS

Design Notes

Mika

el Ates, Jacques Fayolle, Christophe Gravier, Jeremy Lardon

Universit

e de Lyon, SATIn Team, DIOM Laboratory, Telecoms Saint-Etienne

Jean Monnet University of Saint-Etienne, France

Rahul Garg

LNM Institute of Information Technology, Jaipur-302012, India

Keywords:

RFID, Privacy, Modelling.

Abstract:

The concern of this paper is RFID systems coupled with distributed applications. We do not treat known RFID

attacks, we rather focus on the best way to protect the identity mapping, i.e. the association of a tag identiﬁer,

which can be obtained or deduced from the tags or communications including the tags, and the real identity of

its carrier. We rely on a common use case of a distributed application and a modelling approach.

1 INTRODUCTION

A Radio Frequency Identiﬁcation (RFID) system is

interesting for many existing applications, and would

be considered for new ones, since it is wanted to

trigger automated operations encompassing users or

items. As a matter of fact, user tracking systems are

useful to avoid redundant administrative tasks, and to

make human interactions smoother, in multiple iden-

tity checking environments. For instance, to man-

age ﬂows of passengers in airports, patients in hos-

pitals, or employees in access-controlled buildings.

Moreover, most of the services based on the diffu-

sion of personalized information depend on the me-

dia employed and the accuracy of information. Both

depends on the mean for updating the information,

spreading information updates, and making accesses

to this information as simple as possible. RFID sys-

tems contribute to enhance those purposes.

A RFID system(Finkenzeller, 2003)(Glover and

Bhatt, 2006) is based on transponders, also known as

tags, readers and identity backends. Readers broad-

cast radio frequency signals to query tags which

respond with identifying information. Many peo-

ple fears of RFID technologies. It often results

from misunderstanding and over-considering threats

as clandestine scanning, eavesdropping or data leak-

age. RFID deployments must obviously rely on an ar-

chitectural design preventing privacy threats (Westin,

1967), but also, on an advertising plan explaining the

stakes. However, this fear is also often justiﬁed. The

privacy of tag’s carrier can be very threaten by covert

tracking, also known as skimming. More generally,

with RFID systems, private information can be seam-

lessly leaked and multiple readers can collude to track

the movements of a person.

The concern of this paper is RFID systems cou-

pled with distributed application dedicated to user ser-

vices. We do not treat known RFID attacks, as iden-

tity theft by cloning or faking, or as denial of service

by tag disruption. We rather focus on protecting the

identity mapping, i.e. the association of a tag identi-

ﬁer, which can be obtained or deduced from the tags

or communications including the tags, and the real

identity of its carrier. We depict through the paper

a common use case of a distributed application to en-

dorse our proposition.

2 PRIVACY CONCERNS

2.1 Overall RFID Privacy Concerns

The beneﬁts of RFID systems are also often synonym

of privacy threats (Langheinrich, 2007):

• Automation i.e. no user intervention is required to

read a RFID tag.

• Identiﬁcation of a tag carrier.

324

Ates M., Fayolle J., Gravier C., Lardon J. and Garg R. (2009).

PRIVACY FOR RFID-ENABLED DISTRIBUTED APPLICATIONS - Design Notes.

In Proceedings of the 11th International Conference on Enterprise Information Systems - Information Systems Analysis and Speciﬁcation, pages

324-328

DOI: 10.5220/0001862003240328

 SciTePress

• Integration i.e. it can be difﬁcult to visually ascer-

tain the presence of a tag.

• Retrieve information, other than identiﬁcation,

carried by, or linked to, RFID tags.

It is always a better choice to not keep sensitive in-

formation on devices as tags if it possible to do dif-

ferently. But even if there is no other sensitive infor-

mation than an identiﬁer on the tag, this is enough

to be a real concern. Covert tracking for tags carried

by human people threaten their privacy enabling their

localization and the tracking of their activities. More-

over, a tag may reveal the users’ membership to their

organization which delivered their tags. A set of tags

may represent multiple memberships and constitute a

personal proﬁle, e.g. identifying a person as being

customer of some transport companies, of media and

clothes stores, etc.

2.2 Our Privacy Concerns

We are concerned with an RFID system which can

operate with many parts of the information system,

as opposed to closed applications like access building

software which could be, for most of them, isolated

from the rest of the information system. The obvi-

ous primary question is ‘who represent the threat?’.

Attack from the outside would mean that somebody

want to track one of our member, or maybe, if it

knows his real identity, link it with a tag identiﬁer.

So he wants to make one of our tag to leak its iden-

tiﬁer. This means two requirements, our tags should

not respond to readers other than ours, and, to pre-

vent eavesdropping, the tag identiﬁer should not be

revealed in clear. Readers authentication by tags and

anonymous communication, hidding the tag identi-

ﬁer, between tags and readers is the ideal. But for

know it is not the common case. We thus make here a

study when tags have no such capabilities. Hence we

have to take in account the leakings of the commu-

nications between tags and readers. We have also to

take care of attacks against RFID information in the

rest of the information system. This means to monitor

carefully the RFID backend mapping tag identiﬁers

and user identiﬁers. And also, the communications

and applications logging records which could allow

to link the real identity with a tag identiﬁer as well.

2.3 RFID Cryptographic Protocols

We should be able to encrypt and authenticate the

communication between the tags and the readers with

cryptographic protocols (Lee et al., 2006; Song and

Mitchell, 2008). A public key infrastructure with an

authority certiﬁcate embedded in tags, and readers

broadcasting their certiﬁcate seems relevant. How-

ever, most of the RFID tags have limited computation

capabilities which, for now, prevent from spreading

asymmetric cryptography in the RFID domain. More-

over, it requires to implement mechanisms which au-

thenticate without compromising anonymity, i.e re-

vealing the tag identiﬁer, which, with symmetric

cryptography, could be resume to the key search is-

sue(Juels, 2006). Finally, the tag identiﬁer should not

be a single static data string. In cryptographic scheme

as the Song’s one (Song and Mitchell, 2008), the tag

identiﬁer changes at each authentication.

3 FOCUS ON THE DISTRIBUTED

APPLICATION

We here rely on a use case which is the deployment

of a trivial application of agenda consultation. This

application consists in a fast and easy way to inform

people of their agendas and updates, thus making the

people inner-organization life easier and lightening

some of the administrative tasks of the bureau. Users

are provided with RFID tags allowing them to trig-

ger the display of their agendas with the help of a

RFID reader standing close to a large screen. We have

chosen a simple application to focus on the privacy

concerns implied by the RFID system, and not on ac-

cess control questions. Our members and their mul-

tiple group memberships (section, language, options,

etc...) are all registered in a central identity registry

(henceforth idregistry). Their agendas are registered

in a database (henceforth agendadb), and only depend

on group memberships, not on their own identity, per-

sonal agenda are not concerned by this application.

Moreover, the agendas are already publicly available

for insiders. Hence, we consider that the service of

displaying agenda is not a privacy threat by itself.

3.1 Overview of the Use Case

As a matter of fact, the main privacy threat comes

from the identity mapping, i.e. the association of a

RFID tag and a person. As a consequence, we have to

take care of:

• User identiﬁable information written on tags;

• Records in the information system linking tags

identiﬁers with users identiﬁers;

• Communications linking tag’s tid with user’s id.

We can however deduce from the agenda depending

only to group memberships, that a tag identiﬁer has

only to be linked to a set of groups, not to a user. The

PRIVACY FOR RFID-ENABLED DISTRIBUTED APPLICATIONS - Design Notes

325

user anonymity should thus be implicitly preserved.

We consider the anonymity as the state of being not

identiﬁable within a set of subjects, the anonymity set

(Pﬁtmann and Kohntopp, 2001). Hence, the set of

group memberships is an anonymity set which does

not allow user identiﬁcation, i.e. it does not exist

in our information system a unique combination of

group memberships identifying a particular user. We

could thus only associate tags with a list of group

membership, and provide users with a tag correspond-

ing to its agenda. As a consequence, it means that, for

a tag, we would not be able to determine which is its

carrier. It is obviously a wise privacy choice. But it is

totally inefﬁcient if we want to update user informa-

tion linked to tags, especially if only a subset of users

are concerned. It would be necessary to update and

redistribute all tags. For this reason, it is necessary to

record the mapping between a tag identiﬁer (hence-

forth tid) and a user identiﬁer (henceforth userid) in

the information system. These recordings are also

synonym with communication containing these map-

pings. And these mappings will be explicitly per-

formed during the administration of the RFID sys-

tem. Considering tags as the most sensitive part of the

system, and also as one of the less controllable, we

do not record on them this association, or any other

identifying information. This mapping information is

recorded in a dedicated database, the RFID database

(henceforth RFIDdb).

3.2 Elements For Modelling

The goal is to represent easily where information

about identity is issued and registered in a distributed

application, and thus, to highlight where it is neces-

sary to use encryption. This representation must en-

compass events to allow their correlation with records

to map identiﬁers. We have choose to not represent

the time to keep this informal model as simple as pos-

sible. However, the notion of event is intuitive. If

someone is currently scanned by a reader, events are

triggered in the distributed application, hence, either

the intruder can capture communications, or look at

the records written at this time. If all the communica-

tions are encrypted and the logs are not time stamped

or encrypted, the problem is solved. So the goal of

this approach is to highlight these communications

and log records, ant then, to design a safe common ar-

chitecture for RFID-enabled distributed applications.

We transcribe any communication and recording

with respectively the primitives com() and rec(). The

real user identity can be deduced from the physical

presence of a human near a reader. We transcribe this

as hum(userid). We represent by map() the informa-

tion of identity mapping. We note linkid an identiﬁer

of a network segment of the distributed application.

We note locid an identiﬁer of a record location.

A mapping can be either directly accessible, and

will then be noted taking userid and tid as pa-

rameters map(userid,tid), or deduced from the

correlation of two events, and represented by

map(linkid,locid) when, respectively, a segment

and a location are identiﬁers of the events which

may be correlated.

We note as follow the events which reveal the userid:

• a user interact with the RFID system and she is

humanly identiﬁable (hum(userid));

• a communication containing a userid

(com(userid,linkid));

• a record containing a userid (rec(userid,locid)).

We note as follows the events which reveal the tid:

• a communication containing a tid

(com(tid,linkid));

• a record containing a tid (rec(tid,locid)).

Two of each kind of these events may be correlated

to reveal a map(userid,tid). For instance, the cor-

relation can be done by deduction from the time the

events happened. Mappings issued from the correla-

tion of distinct events are as follows

• map(linkid,linkid) ← com(tid,linkid) ∧

com(userid,linkid)

• map(linkid,locid) ← com(tid,linkid) ∧

rec(userid,locid)

• map(linkid,hum(userid)) ← com(tid,linkid) ∧

hum(userid)

• map(locid,linkid) ← rec(tid,locid) ∧

com(userid,linkid)

• map(locid,locid) ← rec(tid,locid) ∧

rec(userid,locid)

• map(locid,hum(userid)) ← rec(tid,locid) ∧

hum(userid)

Two elements, one picked from the set TIDS of events

containing tids and one picked from the set USERIDS

of events containing userids.

Although we have use logic symbols, there is here no

more than what have been said, i.e the correlation of two

events to deduce a mapping. In other words, no one should

expect establish a proof with this formalism.

ICEIS 2009 - International Conference on Enterprise Information Systems

326

3.3 Architecture Design

3.3.1 Administration Application

The RFIDdb, which contains all the past and cur-

rent carriers of each tag, is managed by a dedi-

cated administration application (henceforth admi-

nApp). adminApp is used by administrators to entry

the map(tid,userid) in the RFIDdb. These recordings,

and the events triggered, must be secured. An other

functionality of adminApp is to review the historic of

tag carrying. Both require the following steps:

• userids are obtained from the idregistry.

• tids are obtained from the tags by RFID readers.

• maps are recorded in, or read from, the RFIDdb.

The Figure 1 depicts these events, concern-

ing tids, userids and mappings, triggered by ad-

minApp. We can identify the mappings di-

rectly reachable in single events, and the map-

pings issued from the correlation of two dis-

tinct events. There are four mappings directly

reachable in single events(rec(map(userid,tid),db1),

rec(map(userid,tid),log1), rec(map(userid,tid),log4)

and com(map(userid,tid),eth3)). There are nine map-

pings issued from the correlation of two distinct

events. For instance, for the link rf1:

• map(rf1,eth2) ← com(tid,rf1) ∧ com(userid,eth2)

• map(rf1,hum(userid)) ← com(tid,rf1) ∧

hum(userid)

• map(rf1,log3) ← com(tid,rf1) ∧ rec(userid,log3)

3.3.2 RFID-Enabled Distributed Applications

The RFID-enabled distributed applications offering

user services must access to RFIDdb to obtain the

userid from the tid, for next retrieving information

about the tags’ carriers from the information system.

In the agenda application (henceforth agendaApp)

users present their tag in the reader near-ﬁeld region

to display their agendas, which requires the following

steps:

• tids are obtained from tags by RFID readers.

• userids are obtained from RFIDdb thanks to the

recordings containing the tids.

• group memberships are obtained thanks to the

userids from idregistry.

• agendas are obtained thanks to the group mem-

berships from agendadb.

The privacy threats are thus exactly the same as the

one described in Section 3.3.1. The only difference

adminApp

idregistry

RFIDdb

com(tid,eth1)

rec(userid, log3)

com(map(userid,tid),eth3)

rec(map(userid,tid), db1)

rec(map(userid,tid), log4)

RFID Reader

rec(tid, log1)

com(userid,eth2)

rec(map(userid,tid), log2)

hum(userid)

RFID Tag: tid

User: userid

com(tid,rf1)

Figure 1: Events triggered by the adminApp.

is that with adminApp, a uni-directional communi-

cation from adminApp to RFIDdb contain the event

com(map(userid,tid),eth3). Whereas, for agendaApp,

the mapping requires a bi-directional communica-

tion, com(tid,eth3) from agendaApp to RFIDdb, and

com(userid,eth3) from RFIDdb to agendaApp. Then,

for any application based on this distributed applica-

tive scheme, the threats are the same. It should be

taken into account architectures with multiple RFID

readers which only add events com(tid,[rfx]) between

tags and readers. [rfx] is the notation for the set of

identiﬁers of these links. Furthermore, we can gener-

alize the architecture to any RFID-enabled distributed

applications if we consider that, in the part of the dis-

tributed application not being directly in charge of

RFID processes, no event containing tids should hap-

pen. We can thus split the RFID-enabled distributed

application in two parts. The part with RFID can be

made of multiple distinct agents in charge of read-

ers. We assume that there is only one RFIDdb per

RFID-enabled distributed application. Hence, the Ad-

minApp should only reside in the RFID side and its

communications only authorized to the RFIDdb. For

RFID-enabled distributed applications, it means to

identify communications required to satisfy the RFID

concerns. Then, communications containing RFID

information between those two parts should only be

authorized from the host performing the requests of

mapping and only to the RFIDdb.

3.3.3 Security Mechanisms

According to the mappings identiﬁed in Section 3.3.1,

the sensitive events are known. All the communi-

cations and time stamped log records should be en-

crypted, transcribed with enc().

We consider that it is unfeasible to act on the event

hum(userid).

PRIVACY FOR RFID-ENABLED DISTRIBUTED APPLICATIONS - Design Notes

327

The access control, transcribed with authz(), relies on

only two roles granted for accessing the RFIDdb: the

former with read/write rights for the adminApp role,

and the latter with only read rights for the application

role. A safe implementation should rely on a single

agent allowing to assume the adminApp role. Any

other authorized distinct agent should assume the ap-

plication role with its own identity. enc(authz(com()))

means that the communication is encrypted and that

the requestor must authenticate and be authorized.

The resulting architecture for agendaApp is de-

picted in Figure 2.

distr_App_RFIDpart

RFIDdb

enc(authz(com(tid,[ethy])))

enc(authz(com(map(userid,tid),eth1)))

enc(rec(map(userid,tid), db1))

enc(rec(map(userid,tid), log1))

RFID Readers

enc(rec(tid, [logx]))

enc(rec(map(userid,tid), [logy]))

hum(userid)

RFID Tag: tid

User: userid

enc(authz(com(tid,[rfx])))

distr_App_withoutRFID

enc(com(userid,[ethz]))

enc(rec(userid, [logz]))

Figure 2: Implementing privacy for any RFID-enabled dis-

tributed application.

4 CONCLUSIONS

We have depicted a RFID system coupled with a

distributed application through a simple use case,

enough to highlight privacy concerns. We have

mainly taken care to the mapping between a tag’s car-

rier and its real identity. We have then proposed an

informal method, and its associated model, for this

privacy threat analysis in a distributed environment.

In a ﬁrst time, to specify the functionalities of the

expected application revealing each event containing

identiﬁers. Then, to model the application thanks to

the elements of modelling highlighting possible cor-

relations leaking the identity mappings. Once the

threats are known, it is a trivial implementation con-

cern to identify where it is required to secure the ap-

plication. And, splitting the distributed application in

two parts, one with RFID, and one without, highlights

the sensitive information ﬂows which should be mon-

itored.

REFERENCES

Finkenzeller, K. (2003). RFID Handbook: Fundamentals

and Applications in Contactless smartcards and Iden-

tiﬁcation, 2nd edt. John Wiley and Sons.

Glover, B. and Bhatt, H. (2006). RFID Essentials. O’Reilly.

Juels, A. (2006). Rﬁd security and privacy: A research sur-

vey. IEEE Journal on Selected Areas in Communica-

tion.

Langheinrich, M. (2007). Privacy and rﬁd. In Security, Pri-

vacy, and Trust in Modern Data Management, pages

433–450. Springer.

Lee, H., Yang, J., and Kim, K. (2006). Enhanced mutual

authentication protocol for low-cost rﬁd. Technical

report, Auto-ID Labs.

Pﬁtmann, A. and Kohntopp, M. (2001). Anonymity, un-

observability, and pseudonymity - a proposal for ter-

minology. In Lecture Notes in Computer Science:

Designing Privacy Enhancing Technologies, volume

2009, pages 1–9. Springer Berlin / Heidelberg.

Song, B. and Mitchell, C. J. (2008). Rﬁd authentication pro-

tocol for low-cost tags. In WiSec’08: Proceedings of

the 2008 ACM Conference of Wireless Security. ACM.

Westin, A. F. (1967). Privacy and freedom. Atheneum Pub-

lishers.

ICEIS 2009 - International Conference on Enterprise Information Systems

328