A Platform for RFID Security and Privacy Administration

Melanie R. Rieback Georgi N. Gaydadjiev

Department of Computer Science Department of Computer Engineering
Vrije Universiteit, Amsterdam Delft University of Technology
melanie@cs.vu.nl georgi@dutepp0.et.tudelft.nl

Bruno Crispo, Rutger F.H. Hofman, Andrew S. Tanenbaum

Department of Computer Science
Vrije Universiteit, Amsterdam
{crispo, rutger, ast}@cs.vu.nl

Abstract active tags contain auxiliary batteries on board. Passive

LF tags (125-135 kHz) can be read up to 30 cm away,
This paper presents the design, implementation, and HF tags (13.56 MHz) up to 1 m away, UHF tags (2.45
evaluation of the RFID Guardian, the first-ever unified GHz) up to 7 m away, and active tags up to 100 m away
platform for RFID security and privacy administration. or more.
The RFID Guardian resembles an “RFID firewall”, en-
abling individuals to monitor and control access to their
RFID tags by combining a standard-issue RFID reader
with unique RFID tag emulation capabilities. Our sys-
tem provides a platform for coordinated usage of RFID
security mechanisms, offering fine-grained control over
RFID-based auditing, key management, access control,
and authentication capabilities. We have prototyped the
RFID Guardian using off-the-shelf components, and our
experience has shown that active mobile devices are a
valuable tool for managing the security of RFID tags in
a variety of applications, including protecting low-cost
tags that are unable to regulate their own usage.
Figure 1: Philips I.Code RFID Tags
1 Introduction
Radio Frequency Identification (RFID) tags are 1.1 RFID Applications and Threats
remotely-powered computer chips that augment every-
day objects with computing capabilities. Corporate RFID automation will bring an unfathomable barrage of
executives tout RFID technology as a technological new applications, forever banishing wires, grocery store
means to achieve cost savings, efficiency gains, and cashiers, credit cards, and pocket change from our lives.
unprecedented visibility into the supply chain. Scientific RFID proponents extol its professional uses for real-time
researchers consider RFID technology as nothing short asset management and supply chain management. RFID-
than an embodiment of the paradigm shift towards based access passes help to police residential, commer-
low-cost ubiquitous computing. In both cases, RFID cial, and national borders; drivers have embraced RFID-
tags will blur the boundaries between the online and based retail systems like EZ-Pass, FastPass, IPass, Pay-
physical worlds, allowing individuals to manage hun- Pass, and SpeedPass. RFID-based “feel good” personal
dreds of wirelessly interconnected real-world objects, applications are also proliferating, from “smart” dish-
like dendrites in a global digital nervous system. washers, to interactive children’s toys, to domestic as-
RFID tags may be the size of a grain of rice (or sistance facilities for the elderly. RFID tags identify lost
smaller), and have built-in logic (microcontroller or state housepets, and even keep tabs on people; the data carri-
machine), a coupling element (analog front end with an- ers have assisted with surgeries, prevented the abduction
tenna), and memory (pre-masked or EEPROM). Passive of infants, and tracked teenagers on their way to school.
tags are powered entirely by their reading devices, while Subdermal Verichips are hip accessories for patrons of

1
several European nightclubs, and have been less glam-
orously deployed for identifying deceased victims of hur-
ricane Katrina[1].
RFID technology thus races on at a pace that surpasses
our ability to control it. The same ease-of-use and per-
vasiveness that makes RFID technology so revolutionary
offers less-then-ethical characters unprecedented oppor-
tunities for theft, covert tracking, and behavioral profil-
ing. Without the appropriate controls, attackers can per-
form unauthorized tag reading and clandestine location
tracking of people or objects (by correlating RFID tag
“sightings”). Snooping is possible by eavesdropping on
tag/reader communications. Criminals can also manip-
ulate RFID-based systems (i.e. retail checkout systems)
by either cloning RFID tags, modifying existing tag data,
or by preventing RFID tags from being read in the first
place.
Security and privacy researchers have proposed a wide
array of countermeasures against these threats. The
simplest solution is deactivating RFID tags; perma-
nently (via “frying”[17], “clipping”[13], or “killing”[4]),
or temporarily (using Faraday cages or sleep/wake
modes[20]). Cryptographers have created new low-
power algorithms for RFID tags, including stream ci-
phers [6], block ciphers[5], public-key cryptographic
primitives[9], and lightweight protocols for authenti-
cation [21]. Additionally, researchers have developed
access control mechanisms that are located either on
tag (hash locks[22] / pseudonyms[10]) or off (Blocker
Tag[11], RFID Enhancer Proxy[12]).
Despite this plethora of countermeasures, neither the
threats nor the fears facing RFID have dissipated. The
countermeasures have become somewhat of a band-aid
that can be slapped onto RFID technology later. Some
companies view these results as a desirable way to quiet
down the privacy activists. Other companies in RFID
standardization committees are actively fighting against
adding security into RFID protocol design, because it
will make their current commercial offerings obsolete.
People need a solution that they can physically own and
use, not one that relies upon the RFID companies to de-
cide when privacy will become important.
Another missing element is a means to coordinate the
myriad of incompatible countermeasures as they trickle
onto the market in a piecemeal fashion. Per-tag secu-
rity policies combined with a lack of automation will
form a management nightmare for people, who cannot
be expected to know when or how to apply the appropri-
ate countermeasures. There is no unified framework; no
systematic means to leverage individual RFID counter-
measures to achieve the most important goal of all – the
protection of real people.
2
1.2 RFID Guardian Design Goals
Over the past months, we have designed and prototyped
the RFID Guardian, a system that allows people to ad-
minister the security of their RFID tags. The design of
the RFID Guardian was driven by the following goals,
which follow from the nature of RFID applications and
deployment considerations:
• Centralized use and management.
Most existing RFID countermeasures distribute
their security policies across RFID tags, which
make them very hard to configure, manage, and
use. To address this concern, we designed a sin-
gle platform to leverage RFID countermeasures in
a coordinated fashion. Personalized security poli-
cies are centrally enforced by utilizing novel RFID
security features (auditing, automatic key man-
agment, tag-reader mediation, off-tag authentica-
tion) together with existing ones (kill commands,
sleep/wake modes, on-tag cryptography).
• Context-awareness.
Different countermeasures have strengths and
weaknesses in different application scenarios. Low-
cost Electronic Product Code (EPC) tags require
different access control mechanisms than expensive
crypto-enabled contactless smart cards. Our sys-
tem maintains both RFID-related context (i.e. RFID
tags present, properties and security features, and
their ownership status), as well as personal context
(i.e. the user is in a non-hostile environment). Con-
text is then used in conjunction with an Access Con-
trol List (ACL) to decide how to best protect the
RFID tags in question.
• Ease-of-use.
People do not want to fuss with an RFID privacy
device, so our system must be both physically and
operationally unobtrusive. We envision that our sys-
tem will be eventually integrated into a PDA or mo-
bile phone, so users will not be burdened with car-
rying an extra physical device. Accordingly, the
RFID Guardian uses an XScale processor and sim-
ple RFID HW (barely more complex than RFID
HW already found in Nokia mobile phones). Also,
system operation was designed to be non-interactive
for default situations, and offers a user interface for
the special cases that require on-site configuration.
• Real-world useability.
It is essential that the RFID Guardian work with ac-
tual deployed RFID systems. We chose a single
standard as a proof-of-concept, to prove the tech-
nical feasability our ideas. Our RFID Guardian im-
plementation supports 13.56 MHz (HF) RFID, and
 is compatible with the ISO-15693[2] standard. This
frequency and standard is used in a wide array of
RFID applications, due to the availablity of rela-
tively inexpensive commodity HW. The ideas in this
paper can also be extended to other standards or fre-
quencies, given some extra engineering effort.
The remainder of this paper is organized as follows.
Section 2 describes the RFID Guardian’s high-level func-
tionality. Section 3 provides implementation details for
our RFID Guardian prototype, and Section 4 provides a
real-life case study, illustrating the operation of Selec-
tive RFID Jamming. Performance results are reported in
Section 5. Section 6 presents a discussion of potential
attacks, and Section 7 reviews some related work. Our
discussion is then concluded in Section 8.
2 System functionality
The RFID Guardian (first introduced in [19]) is a
portable battery-powered device that mediates interac-
tions between RFID readers and RFID tags. The RFID
Guardian leverages an on-board RFID reader combined
with novel tag emulation capabilities to audit and control
RFID activity, thus enforcing conformance to a central-
ized security policy.
The vast majority of RFID readers will not explicitly
interact with the RFID Guardian. Eavesdropping and
clever tag emulation tactics are necessary to glean infor-
mation from these readers. However, a small group of
RFID readers will have special back-end SW installed,
that provides them with an “awareness” of the Guardian.1
These RFID readers tend to be in familiar locations (i.e.
at home, at the office), and they are intentionally granted
more generous access permissions. These RFID readers
may explicitly cooperate with the Guardian, sending data
containing authentication messages, context updates, or
secret keys.
The rest of this section describes the design of the
RFID Guardian, focusing on four fundamental issues: (i)
auditing, (ii) key management, (iii) access control, and
(iv) authentication.
2.1 Auditing
The RFID Guardian monitors RFID scans and tags in its
vicinity, serving as a barometer of (unauthorized) RFID
activity. RFID auditing is a prerequisite for the enforce-
ment of RFID security policies, plus it furnishes individ-
uals with both the awareness and proof needed to take
legal recourse against perpetrators of RFID abuse.
1 Even these “Guardian aware” readers still use standard RFID hard-
ware and air interfaces.
3
2.1.1 Scan logging
Scan logging audits RFID scans in the vicinity, which
are either displayed (using an LCD or screen) or are
logged for later retrieval. Tag emulation decodes the
RFID reader queries prior to logging the 64-bit UID (tag
ID), an 8-bit command code, and annotations (like a 32-
bit timestamp). Query data is logged by default, unless
the flash memory is almost full.
Audited RFID scans should be filtered to avoid over-
whelming the user with uninteresting information. For
example, the RFID Guardian might be configured to only
log scans targeting tags “owned” by that individual (see
next section). Repeatedly polled queries (like inventory
queries, which ask tags in range to identify themselves)
will also generate a lot of noise, so it is best to have the
SW aggregate these queries (e.g. 1000x inventory query
from time t1-t2).
2.1.2 Tag logging
The RFID Guardian tracks RFID tag ownership and
alerts individuals of newly appearing (possibly clandes-
tine) tags. Ownership of RFID tags can be transferred
explicitly via the user interface or an authenticated RFID
channel (i.e. while purchasing tagged items at an RFID-
enabled checkout). Ownership of RFID tags can also
be transferred implicitly (i.e. when handing an RFID-
tagged book to a friend.) The RFID Guardian detects im-
plicit tag acquisition by conducting periodic RFID scans,
and then correlating the tags that remain constant across
time.
The frequency of RFID tag discovery is adjustable.
Given that not all implicit tag acquisitions are desirable,
the frequency of scanning/correlation/reporting presents
a tradeoff between privacy, accuracy, and battery life.
Our opinion is that infrequent correlation in a controlled
environment is probably the most useful and least error
prone option (i.e comparing RFID tags present at home
at the beginning and end of the day).
2.2 Key Management
Modern RFID tags have a variety of security func-
tionality, ranging from tag deactivation commands, to
password-protected memory, to industrial-grade cryp-
tography. These security features often require the use
of associated key values, which present logistical issues
because the keys must be acquired, stored, and available
for use at the appropriate times.
The RFID Guardian is well suited to manage RFID
tag keys due to its 2-way RFID communications abil-
ities. Tag key transfer could occur by eavesdropping
on the RFID channel when a reader (for example, an
RFID tag “deactivation station”) issues a query contain-
ing the desired key information. Additionally, “Guardian
aware” RFID readers can transfer key information ex-
plicitly over a secure channel, or key values can be man-
ually entered via the user interface. The RFID Guardian
is also an appropriate medium for periodically regener-
ating tag keys, re-encrypting tag data[8], and refreshing
tag pseudonym lists[10].
2.3 Access Control
RFID technologists and privacy activists propose deac-
tivating RFID tags after sale as a means of protecting
consumer privacy (and corporate liability). However, if
you consider that RFID tags represent the future of com-
puting technology, this proposal becomes as absurd as
permanently deactivating desktop PCs to reduce the in-
cidence of computer viruses and phishing. Perhaps RFID
tags are in fact too much like modern computers – their
default behavior is to indiscriminately transfer data to
anyone with compatible equipment. The hope is that
modern security technologies like firewalls and proxies
can be adapted, to protect hapless RFID tags from them-
selves via central monitoring and managing of the com-
munications medium.
2.3.1 Coordination of security primitives
The RFID Guardian maintains a centralized security pol-
icy that dictates which RFID readers have access to
which RFID tags in which situations. This security pol-
icy is implemented as an Access Control List (ACL). The
ACL resembles one used by a standard packet filter, that
allows or denies RFID traffic based upon the querying
reader (if known), the targeted tag(s), the attempted com-
mand, and the context (if any).
Permitted data types in the ACL are values (i.e.
123), text strings (i.e. ’at home’, ’in a para-
noid mood’), groupings (i.e. assigned groups of
tags/readers/context/commands), and wildcards (123*,
*). The user configures the ACL, and constructs the
groups via the user interface.
2.3.2 Context-awareness
Different situations call for different countermeasures.
For example, RFID tagged credit cards require less strin-
gent security at home than at the shopping mall. The
RFID Guardian therefore offers context awareness facil-
ities that perceive an individual’s situation and then reg-
ulate tag access accordingly.
Well defined context like dates and times are easy to
infer, but are marginally useful for describing a person’s
situation, moods, or desires. Alternately, more abstract
4
context information can be represented via “context up-
dates”, which are arbitrary textual strings that represent
some facet of the user’s situation. Context updates could
report anything. For example, an RFID reader at the
front door of a person’s home might inform the RFID
Guardian that it is now leaving a protected area. Context
updates are provided either by user (via the user inter-
face), or by authenticated “Guardian aware” RFID read-
ers.
2.3.3 Tag-reader mediation
The RFID Guardian acts as a mediator between RFID
readers and RFID tags. Just like a packet filter, the
Guardian uses Selective RFID Jamming[18] to enforce
access control by controlling the communications medi-
ation. The RFID Guardian can therefore control access
for low-cost RFID tags that otherwise might not have any
access control primitives available to them.
The RFID Guardian’s selective jamming scheme is
currently optimized for ISO-15693 tags, which use the
Slotted Aloha anticollision scheme (as opposed to EPC-
global’s ’tree-walking’). Selective RFID Jamming uses
tag emulation to decode the incoming RFID reader
query, determines if the query is permitted (according to
the ACL), and then sends a short jamming signal that pre-
cisely blocks the timeslot in which the “protected” RFID
tag will give its response.
Figure 2: Selectively Jamming Tag # 2
There are 16 timeslots after an inventory query, so dur-
ing the first round of anticollision, the jamming has a 1
in 16 chance of accidentally interfering any other RFID
tag present. During each subsequent round of anticol-
lision, the reader issues another inventory query with a
slightly modified mask value, that targets a slightly nar-
rower range of RFID tags than before. Given enough
rounds of anticollision, the mask value will exclude the
RFID tag(s) that are being “protected”, allowing other
tags in the vicinity to get their responses heard by the
RFID reader. This means that in practice, our system has
 Figure 3: RFID Guardian Prototype
a negligible chance of blocking the incorrect RFID tag
responses. This makes the RFID Guardian’s manner of
selectively jamming inventory queries far less-obtrusive
than the Blocker Tag’s concept of “privacy zones”[11],
which block entire ranges of tag identifiers (regardless of
who owns the tag.)
2.4 Authentication
Some high-cost RFID tags can directly authenticate
RFID readers, but the majority of RFID tags cannot due
to application constraints (i.e. cost or power). The RFID
Guardian thus authenticates “Guardian aware” RFID
readers on behalf of low-cost RFID tags, adapting the
subsequent access control decisions to reflect the permis-
sions of the newly-identified reader. Prior to authentica-
tion, the RFID Guardian must also exchange authenti-
cation keys with RFID Readers, either ahead of time or
using on-the-fly means (ex. user interface, PKI).
After the successful authentication of a reader, the
RFID Guardian faces a practical problem: for noncryp-
tographic RFID tags there is no easy way to determine
which RFID queries originate from which RFID reader.
The best solution would be for RFID standardization
committees to add space for authentication information
to the RFID air interface. However, until that happens,
we are using our own imperfect solution: in the last
step of authentication an RFID reader announces which
queries it’s going to perform, and these queries are noted
as part of an “authenticated session” when they occur.
3 Implementation
The RFID Guardian prototype, shown in Figure 3, is
meant to help people solve their RFID privacy prob-
lems in a practical way. Therefore, we have tested
5
our system against commonly used RFID equipment –
the Philips MIFARE/I.Code Pagoda RFID Reader, with
Philips I.Code SLI (ISO-15693) RFID tags. This sec-
tion will introduce the hardware and software architec-
ture that our prototype uses to monitor and protect the
RFID infrastructure.
3.1 Hardware
The RFID Guardian hardware architecture is presented
in Figure 4.
Figure 4: RFID Guardian HW Architecture
Our first salient design decision was to make the
RFID Guardian a full-fledged portable computer. We
chose a “beast” of a microcontroller – the Intel XScale
PXA270 processor, with 64 megabytes of SDRAM and
16 megabytes of Flash memory. We rationalized the use
of the XScale by the strict ISO-15693 timing constraints
combined with the computational load of authenticating
RFID readers. (Section 5 analyzes the extent to which
the PXA270 is overkill.) Another benefit of the XS-
cale processor family is its wide deployment in handheld
devices, which eases eventual integration of the RFID
Guardian into PDAs and mobile phones.
 Our prototype has a minimalist User Interface (UI) at
the moment – a serial RS-232 interface to the PC host,
which contains an attached keyboard and screen. While
this is sufficient for our proof-of-concept, we plan to
add a more portable UI to the next version of the RFID
Guardian HW.

3.1.1 RF Design Overview

The analog part of our prototype consists of an “RFID
reader” front end that uses an RFID reader-on-a-chip,
and an “RFID tag” front end which required building our
own custom tag emulation HW.
Our reader transmitter/receiver was implemented us-
ing an ISO-15693 compliant RFID reader IC from
Melexis (MLX90121)[16] together with a power stage, Figure 5: Normal RFID Tag Signal
based on the application note AN90121 1 [15], that in-
creases the operating range to 30 cm.
Our tag receiver is based on an SA605 IC from carrier frequency. The comparatively tiny sidebands
Philips. The IC is intended for a single chip FM radio, have approximately 90 decibels less power than the
but we used it to implement a high sensitivity AM re- reader-generated carrier signal, and this is the reason why
ceiver. Because our receiver is battery powered (as op- RFID tag responses often have such a limited transmis-
posed to passively-powered RFID tags), it receives RFID sion range.
reader signals up to a half meter away. The secret to creating fake tag responses is to gener-
Our tag transmitter implements “active” tag spoofing ate the two sideband frequencies, and use them to send
using an RF power stage and a dedicated digital part that back properly-encoded responses, that are synchronized
generates and mixes the required sideband frequencies, with the RFID reader’s clock signal. The simplest way
13.56 MHz +/- 423 kHz. By actively generating the side- to generate these sidebands is to imitate an RFID tag, by
band frequencies, we can transmit fake tag responses up turning on and off a load resistor with the correct timing.
to a half meter. The disadvantage of this approach is that passive mod-
We also use our tag transmitter as the basic HW prim- ulation of the reader signal will saddle our fake tag re-
itive to generate the RFID Guardian’s randomized jam- sponse with identical range limitations as real RFID tags
ming signal. (This is described further in the SW sec- (˜10 cm for our test setup).
tion.) A superior alternative is to use battery power to gener-
ate the two sideband frequencies. These super-powerful
sidebands are detectable at far greater distances, thus in-
3.1.2 Tag Spoofing Demystified
creasing the transmission range of our fake tag response.
RFID readers produce an electromagnetic field that pow-
ers up RFID tags, and provides them with a reference sig-
nal (e.g. 13.56 MHz) that they can use for internal timing
purposes. Once an RFID tag decodes a query from an
RFID reader (using its internal circuitry), it encodes its
response by turning on and off a resistor in synchroniza-
tion with the reader’s clock signal. This so-called “load
modulation” of the carrier signal results in two side-
bands, which are tiny peaks of radio energy, just higher
and lower than the carrier frequency. Tag response infor-
mation is transmitted solely in these sidebands2 , rather
than in the carrier signal.
Figure 5 (from the RFID Handbook[6]) illustrates how
these sidebands look, in relation to the reader-generated
2 Sidebands are not just an RFID-specific phenomenon – they are

also commonly used to transmit information in radio and television

broadcasts, long-distance voice communications, and amateur radio. Figure 6: Spoofed RFID Tag Signal

6
 The RFID Guardian prototype utilizes the “active” tag
spoofing approach. Figure 6 shows the signal gener-
ated by our tag transmitter. The spoofed “sidebands” are
transmitted at a power-level roughly equal to the reader’s
carrier signal. This has increased the range of our fake
tag responses – from 10 cm to a half meter away!
3.2 Software
The RFID Guardian is like a watchdog; it sits with a
cocked-ear, waiting for danger to appear. It monitors
real-world activity, from unexpected RFID scans to clan-
destinely located tags, and reacts in real-time lest these
dangers remain undetected and undeterred.
The RFID Guardian’s SW architecture reflects this
event-driven reality. Besides its real-time core, the
Guardian’s 12694 lines of code provide device drivers
(for our RFID HW), a protocol stack (ISO-15693), data
storage libraries, high-level system tasks, and application
libraries. The result is 254728 bytes of cross-compiled
functionality dedicated to RFID security and privacy pro-
tection.
3.2.1 Operating System
The RFID Guardian presents a holistic system to users,
but lurking below the surface are time-critical SW rou-
tines that require central coordination. The e-Cos Real-
Time Operating System (RTOS) takes the place of
taskmaster; it ensures fast and reliable execution, while
simplifying developers’ lives by handling threads, ba-
sic common interrupt handling, and some device drivers
(i.e. RS-232 driver). e-Cos was selected primarily for its
availability for the PXA270 microcontroller, but it also
proved an excellent choice because it is open-source, free
of licensing costs, and has an active developer commu-
nity.
3.2.2 Libraries
A major portion of the RFID Guardian SW handles in-
termediate processing steps; e.g. tag spoofing requires
ISO-compliant frame modulation and encoding, and scan
logging requires a mechanism for caching data in the
Flash memory. This section will describe the low-
and medium-level libraries that support the main RFID
Guardian functionality.
Device Drivers Device drivers are the steering soft-
ware for the RFID Guardian’s HW. Driver pairs con-
trol the RFID tag device (tag transmitter/receiver), RFID
reader device (reader transmitter/receiver), and the jam-
ming signal (random noise generated by the tag trans-
mitter). Device drivers can read/write bytes and RFID
7
markers (EOF, SOF, JAM), and they can also provide
timing information. eCos also conveniently provides de-
vice drivers for the RS-232 “user interface”, which facil-
itates a connection to the user’s keyboard and screen.
Protocol Stack Once the device drivers decode bytes
of raw RFID data, the RFID Guardian needs to make fur-
ther sense out of it; e.g. was it an RFID tag replying to
an inventory query, or an RFID reader attempting to read
a data block? The ability to understand RFID communi-
cations protocols is a prerequisite for making meaningful
high-level security decisions (e.g. was the reader’s read
command authorized?) This is why the RFID Guardian
contains an implementation of Part 2 (device drivers)
and Part 3 (Communications protocol) of the ISO-15693
standard.
Data Storage Once RFID communications have been
interpreted, the internal state of the RFID Guardian is
updated by modifying the contents of one or more data
structures. Generally, this data is stored in the volatile
RAM, but “permanent” data structures are cached into
Flash when the processor is idle. The Journaling
Flash File System (v2) manages the RFID Guardian’s
Flash memory, providing filesystem-style access, offline
garbage collection, balanced erasing of blocks, and crash
resistance.
The data structures themselves collectively reflect the
high-level functionality of the RFID Guardian. Transient
data structures include the tag presence list, partially-
open authentication list, authenticated session list, con-
text list, and timer activity list. Permanent data structures
may also include the RFID scan log, access control list,
reader authentication key list, tag ownership list, and tag
key list.
3.2.3 Tasks
The RFID Guardian’s high-level system tasks are little
virtual pieces of functionality that take turns controlling
the behavior of the system. Each task plays a different
role: the tag task acts like a virtual RFID tag, and the
reader task like a commodity RFID reader. The timer
task is akin to a little alarm clock, that periodically goes
off and spurs other system components into action. The
user input task primarily relays input from the real-life
user input devices to the appropriate SW handler.
Each of these tasks uses a comparable software stack.
A main loop at the top level waits for activity on any
device, and an interrupt prompts the device driver to de-
code and store the frame(s). The task then invokes the
appropriate high-level application routines.

"Timer" "UI" "Tag" "Reader"
Wait for tag activity
Read frame
Receive bit pattern
Parse bit pattern (i.e. ISO−15693)
Activate high−level app. functionality
Response:
Nothing
Send "tag" reply
Send jamming signal
Figure 7: “Tag” Task Functionality
Timer Task The RFID Guardian needs to perform ac-
tivities at specific times, either periodically (i.e. polling
to populate the RFID tag presence list), or on a one-time
basis (i.e. timing out a half-opened authentication at-
tempt). The timer task is responsible for keeping track
of scheduled activities, and multiplexing the XScale’s
high-resolution timer interrupts with the corresponding
actions that must occur at those times.
User Input Task On rare occasions, users will want to
explicitly interact with the RFID Guardian. They may
want to configure the ACL, conduct an RFID scan, pro-
vide context data, or execute some other kind of system
command. The user input task collects these commands
from the cornucopia of available input devices, (i.e. RS-
232, keyboard/button/keypad/etc..), and reroutes them to
the system components responsible for the desired high-
level functionality.
Tag Task Tag emulation is one of the highlights of
the RFID Guardian, being frequently used to achieve the
RFID Guardian’s high-level goals – RFID scan logging,
authenticating RFID readers, and spoofing one or several
RFID tags. The tag task is the entity responsible for coor-
dinating the RFID Guardian’s “tag-like” behavior. When
activated by an interrupt from the tag receiver, the task
calls the device driver to demodulate and decode the in-
coming RFID queries. This subsequently activates the
aforementioned high-level functionality, if needed.
Reader Task The reader task, driven by SW requests
from the timer and UI, coordinates use of the Guardian’s
RFID reader-on-a-chip. The task performs specified
queries, (i.e inventory, read/write data), and interprets the
8
tag responses. This is commonly used for detecting (pos-
sibly covert) RFID tags, and activating on-tag security
mechanisms, if any.
3.2.4 Inter-Device Functionality
Lots of high-level application functionality has been in-
troduced in this paper, but little has been said about
the RFID Guardian’s interactions with “Guardian aware”
RFID infrastructure (introduced in section 2).
RFID Guardian-Reader communications use a meta-
language that we call Guardian Language (GL), which
is encapsulated in standard ISO-compliant ’read/write
multiple blocks’ commands. GL uses an 8-bit Distinc-
tive Starting Block, an 8-bit GL Command and a vary-
ing amount of Command Data. The theoretical length
limit for command data is 8 kBytes, although the practi-
cal limit is 128 bytes, which is the capacity of our I.Code
SLI tags.
Here is how GL looks when encapsulated a ’read mul-
1111111111111
0000000000000
tiple block’ response:
0000000000000
1111111111111
0000000000000
1111111111111
Flags GLC Command Data CRC16
0000000000000
1111111111111
SOF DSB EOF
11111111111111111
00000000000000000
0000000000000
1111111111111
8 bits 8 bits 8 bits 256 bits − 64 kbits 16 bits
Here is a non-exhaustive list of GL commands: Ini-
tiate Authentication, Authentication Response, Key Up-
date, Forward Query (proxy mode), Add Tag, Remove
Tag, Add Reader, Remove Reader, and Context Update.
GL also features non-standard configuration commands,
that require some knowledge about the RFID Guardian
internal setup.
One caviat is that, because the RFID Guardian is em-
ulating an RFID tag, Guardian-Reader communications
are constrained by master-slave interactions. In other
words, RFID readers must always initiate communica-
tions with the RFID Guardian. Designers must keep this
in mind when creating interaction patterns for new RFID
security and privacy functionality.
4 Case Study: Selective RFID Jamming
This section will provide a step-by-step demonstration of
how Selective RFID Jamming works.
For demonstration purposes, we have given the RFID
Guardian a minimal tag ownership list that contains only
one tag (UID: 0xe0040100003b0cbd). A single entry in
an equally minimal ACL prescribes blocking all tags in
the ownership list:
We now generate inventory queries with our Philips
MIFARE/I.Code Pagoda RFID Reader, which is driven
from a Windows PC interface. Initially the RFID
Guardian is switched off, and the Philips Reader de-
tects three tags in its vicinity: the one tag that is
 Figure 8: Screenshot During Uninterrupted Query

Figure 9: Screenshot During Selective RFID Jamming

9
 Tag Reader Command Context tack modes.
... ... ... ...
<ownership list> * * *
5.1 Timing Constraints
The RFID Guardian enforces access control decisions on
in our ownership list, and two unknown tags (UID: the behalf of RFID tags, so real-time performance is re-
0xe0040100003b2252 and 0xe0040100003afab9). (See quired under both normal and hostile conditions. After
Figure 8 for a screenshot.) all, blocking a tag response after it has reached the at-
When the RFID Guardian is enabled, the Philips tacker is not very useful.
Reader’s inventory queries are immediately detected. In the upper time-line of Figure 10 we show the timing
These requests are decoded, and the RFID Guardian’s constraints for an inventory request-response sequence
internal logic determines that the query should be as specified by the ISO standard. Like every other
blocked. The Guardian then sends a short (ca. 350µsec) RFID message, the request is framed by a start-of-frame
jamming signal at timeslot 13 of the inventory se- marker (SOF) and an end-of-frame marker (EOF). Be-
quence, since that slot corresponds to the protected tag: tween these markers, an inventory request carries be-
0xe0040100003b0cbd. tween 40 (mask size is 0) and 104 (mask size is 64) data
Only the two unprotected tags are recognized by the bits. After receiving the request EOF, the tag must wait
Philips reader now, and the jamming caused a CRC error for 320.9 µsec before starting its answer. This is the time
that is reported in the lower central pane of the reader’s the RFID Guardian has to interpret reader requests and
user interface (see Figure 9). respond to them.
Debug output from the RFID Guardian illustrates the The lower time-line of Figure 10 shows the measured
processing steps, including the decision to jam at times- performance of the RFID Guardian. After a complete
lot 13: frame is received (SOF, data, and EOF), it needs 23
µsec to wake up the thread that monitors the receiver
1 Request t_eof 76.877230 RFID_INVENTORY(
1a flags=RFID_FRAME_DATA_RATE_FLAG|
and parses the request frame. Immediately before dis-
1b RFID_FRAME_INVENTORY_FLAG), patching the response frame, another 5 µsec of overhead
1c masklen=0x00,mask=0x0; is spent in firing up the transmitter. In between these
2 Inventory: t_eof 76.877230 s->SN 0 s->NbS 16 two events, the RFID Guardian has 320.9 - (23 + 5) =
3 Inventory: t_eof 76.882010 s->SN 1 s->NbS 16
4 Inventory: t_eof 76.886791 s->SN 2 s->NbS 16 292.9 µsec to consult its ACL (and supporting data struc-
5 Inventory: t_eof 76.888304 s->SN 3 s->NbS 16 tures) and decide whether or not to block the RFID tag
6 Inventory: t_eof 76.891568 s->SN 4 s->NbS 16 response.
7 Inventory: t_eof 76.896340 s->SN 5 s->NbS 16 How long this decision takes depends on how the
8 Inventory: t_eof 76.901120 s->SN 6 s->NbS 16
9 Inventory: t_eof 76.905893 s->SN 7 s->NbS 16 RFID Guardian’s ACL is organized. To find a coarse
10 Inventory: t_eof 76.910673 s->SN 8 s->NbS 16 upper bound on the ACL length that can be handled by
11 Inventory: t_eof 76.915446 s->SN 9 s->NbS 16 the Guardian prototype, we chose the slowest possible
12 Inventory: t_eof 76.920225 s->SN 10 s->NbS 16
implementation for the ACL: an unsorted array of UIDs
13 Inventory: t_eof 76.924999 s->SN 11 s->NbS 16
14 Inventory: t_eof 76.929778 s->SN 12 s->NbS 16 that can only be traversed sequentially to locate a specific
15 Inventory: t_eof 76.934552 s->SN 13 s->NbS 16 UID. An RFID request addressed to the last item in the
16 Inventory JAM t 76.934869 on s->SN 13 s->NbS 16 ACL was sent to the Guardian, forcing it to traverse the
16a mask len 0 mask 0x0
17 Inventory: t_eof 76.939330 s->SN 14 s->NbS 16
entire list. With 2600 entries, the Guardian was able to
18 Inventory: t_eof 76.944107 s->SN 15 s->NbS 16 respond in time.
The Guardian prototype is equipped with a powerful
Lines 1-1c report an Inventory request with a mask XScale processor at high clock speed, 520 MHz. To
length 0, and flags indicating a 16-slot inventory se- find out if a Guardian with less processor power would
quence. Lines 2 through 18 report End of Frame (EOF) still be feasible, we varied the clock speed of the XS-
pulses that mark the start of a new timeslot. (s->SN cale. The results are shown in Figure 11. The ACL
indicates the current slot number.) Line 16-16a corre- length that the Guardian could still cope with decreases
sponds with timeslot 13, and it indicates the generation with clock speed, but much less than linearly. This is at-
of a jamming signal. tributed to two causes: memory speed goes down more
slowly and in coarser steps than CPU speed; and parts of
5 Performance Measurements the device processing are independent of CPU speed. At
208 MHz, the Guardian prototype can process ACLs of
This section will analyze the performance of the RFID length 1800, even with this suboptimal ACL implemen-
Guardian, under a variety of resource constraints and at- tation.

10
 ISO 15693 time SOF Data EOF Waiting Time Response SOF
constraints
75.52 1510.4 to 3927.04 37.76 320.9 µs

Max. Processing
Input Frame (SOF+Data+EOF) Overhead Time Overhead Response SOF
RFID Guardian
time constraints
1623.68 to 4040.32 23 292.9 5 µs

Figure 10: Timing constraints

Of course, with a hash table instead of a linear list, vast would immediately alert the RFID Guardian and it would
numbers of ACLs can be searched in the available 292.9 confuse the tags as well. Attacking between reader com-
µsec. In short, ACL length is not likely to be a problem mands does not constitute a DoS vulnerability of the
even on a very slow XScale. communication channel: it would be the same as a regu-
lar reader action. The attacker could jam the channel, of
3000 course, but then he could not read out any tags, which
is the presumed reason he wants to cripple the RFID
Guardian.
The other potential vulnerability is the limited RFID
2500
Max ACL size

Guardian flash memory. An attack on the flash memory

2000
1500
150 300 450
CPU speed (MHz)
Figure 11: Maximum ACL size that can be processed at
a given CPU speed
5.2 DoS Resistance
Now let us consider how attackers will try to defeat the
RFID Guardian. They may use malicious readers or fake
tags that try to confuse or lock up the RFID Guardian, so
that the tags it protects can be read anyway. The primary
defense against well-known exploits like buffer overruns
must be very careful programming of the RFID Guardian
software, which is helped by its limited code size.
Failing that, their next attack is likely to be a
DoS (Denial-of-Service) attack to overload the RFID
Guardian and prevent it from doing its job. Two RFID
Guardian resources are obvious candidates for attack: its
limited radio bandwidth and its limited memory. RFID
communications always follow the master-slave pattern,
where the tag (slave) must respond after a well-defined
delay. Attacking during this delay is not feasible: it
may target any one of three data structures: the tag own-
ership list, the tag presence list, or the scan audit log.
If an attacker with a battery-powered device simulated
thousands of new tags in an attempt to fill up the own-
ership list or the current list, the RFID Guardian could
warn the user about this abnormal activity.
600 Alternatively, the DoS attacker could try to fill up
the audit logs. This does not cause a loss in protection
of the owner’s tags, but it certainly hampers the RFID
Guardian’s auditing capabilities. The maximum rate at
which requests can be launched is determined by the
bandwidth of the radio channel and the minimum frame
size, both of which are specified by the standard. The
data rate is 26.48 kbps. The minimum frame is (SOF,
32 data bits, EOF) which takes 1.322 ms followed by
a mandatory silence of 320.9 µs, which works out to a
maximum of 613 requests/sec.
An audit log entry contains the index of the tag be-
ing targeted, an index of the context, the command and
a timestamp, which results in 2+2+1+4 = 9 bytes bytes.
With 613 requests/sec, the attacker can fill up 5517 bytes
of flash memory per second. The RFID Guardian proto-
type has 16MB of flash, of which 14MB is available for
logging. Thus a maximum-speed attack would need 42
consecutive minutes of blasting away at full speed to fill
the memory. Needless to say, the RFID Guardian should
be sounding an alarm long before the memory begins to
fill up, thus fulfilling its job of warning the user of an
attack. Besides, flash memory is very cheap: another 16
MB might would add less than 2 dollars to the production
cost.

11
 To summarize, the RFID Guardian seems immune to
the DoS attacks that we can identify, either because they
would also disturb regular RFID interaction, or because
the RFID Guardian has enough resources to defend it-
self long enough to alarm its owner after the threat has
continued for some while.
6 Discussion
In contrast to the aforementioned Denial of Service at-
tacks, there are a number of attacks that are successful
against the RFID Guardian.
The RFID Guardian faces the ’hidden station’ prob-
lem, which is a geometric problem that depends entirely
upon radio ranges. However, we assume that an attacker
wouldn’t be able to maintain this for long, so we only
deal with the “single reader” problem in this paper.
RFID readers could potentially trace the collision
space, using collisions to resolve the IDs of RFID
Guardian-protected protected RFID tags. We can im-
prove this situation by adding some extra collisions,
which will cause the algorithm to traverse a greater part
of the ID space, making it look like more than one pro-
tected tag is present.
Another weakness of the RFID Guardian is its inabil-
ity to jam reader queries. Selective RFID jamming only
jams tag responses – not queries. However, queries can
modify an RFID tag in unauthorized ways, like perform-
ing unauthorized data writes, or tag “killing”. Other
mechanisms can protect RFID tags from this, like tempo-
rary tag dectivation PETs (i.e. sleep/wake modes). How-
ever, this remains problematic for low cost RFID tags
that might not support these other modes.
Finally, attackers can evade RFID Guardian protection
by tracking people using tags with pseudonyms. If the
RFID Guardian has the pseudonym list (or PRNG seed),
it can correlate the IDs, remaining aware that it is dealing
with only one tag. If the RFID Guardian doesn’t have the
list (or seed), it will think that it is dealing with multiple
tags that are only observed once. The RFID Guardian
also has trouble dealing with tags working with unknown
standards/frequencies.
7 Related Work
Given how great the threat of RFID technology is to
privacy, it is not surprising that other researchers are
also thinking about privacy defenders. Probably the
closest work to ours is the RFID Enhancer Proxy[12],
which shares some similarities with the RFID Guardian.
The REP, too, is an active mobile device that performs
RFID tag security managment, using a two-way com-
munications channel between the REP and RFID Read-
12
ers. However, the REP has some key differences from
the RFID Guardian. The most important differences
are as follows. First, the REP explicitly ”acquires” and
”releases” RFID tag activity, which the Guardian does
not require. Second, the REP’s two-way communica-
tions channel is ”out-of-band,” which requires extra in-
frastructure. Third, the ”tag relabeling” mechanism re-
quires RFID tags to generate random numbers (or have a
sleep mode), which many of them cannot do (or do not
have). Fourth, the REP is purely theoretical; in contrast
the RFID Guardian has been implemented and tested.
RFID tag auditing (and cloning) are supported by sev-
eral devices. FoeBuD’s Data Privatizer[7] will detect
RFID scans, find and read RFID tags, and copy data read
to new tags. The Mark II ProxCard Cloner, by Jonathan
Westhues[23] is a more general-purpose proximity-card
cloner, that supports the emulation of several RFID fre-
quencies and standards (the HW is elegant, but the SW is
pending). Neither of these perform all the auditing, key
management, access control, and authentication func-
tions that the RFID Guardian does.
A less sophisticated approach to privacy protection is
to block scans irrespectively of their originating reader.
The Blocker Tag (Juels)[11] originated the concept of
’RFID blocking’ as a form of off-tag access control. It
is designed to abuse the tree-walk anticollision proto-
col, and RFID readers are forced to traverse the entire
id namespace when trying to locate RFID tags. This ap-
proach does not analyze incoming scans, look up infor-
mation in an access control list, and depending on what
it finds, take action as the RFID Guardian does. Also, it
has not been implemented. (A purely SW-based “soft”
blocker tag has been implemented, but it expects RFID
readers to self-regulate their behavior.)
An active device that can detect RFID scans is the
M.I.T. RFID Field Probe[14]. It is a portable device,
created by Rich Redemske at MIT Auto-ID Center, that
integrates an RFID tag emulator and sensor probe. The
HW consists of a semi-passive tag, a power level detec-
tor, and a helper battery. The RFID field probe gives au-
dio and visual representations of the field signal strength
and signal quality. However, its function is not to pro-
tect its owner’s privacy, but as a tool to help vendors
determine where on their pallets to attach the RFID tag
to maximize signal strength for supply-chain manage-
ment applications. Consequently, it does not have any-
thing like our software, which is the heart of the RFID
Guardian’s privacy defense.
Several other RFID-based technologies support the
concept of two-way RFID communications. Near Field
Communications[3] is a peer-to-peer RFID-related com-
munications technology. NFC devices can query RFID
tags, and can also communicate with other NFC-enabled
devices. However, NFC devices cannot talk with non-
 Tool Name Tag emulation (SW) Tag emulation (HW)
NFC X X
Data Privatizer X X
Blocker Tag X X
Field Probe X X
ProxCard Cloner X X
RFID Enhancer Proxy X X
RFID Guardian X X
Table 1: RFID Tag Emulators for Security/Privacy
NFC enabled RFID readers and do not do privacy pro-
tection.
Finally, the RFID countermeasures described in Sec-
tion 1.1 are all complimentary to the RFID Guardian, in
the sense that the RFID Guardian could leverage them
as part of its framework, for helping to provide personal-
ized access control. However, none of them are discrete
devices that protect privacy.
8 Conclusion
If we are ever immersed in a sea of RFID chips, the RFID
Guardian may provide a life raft. This battery-powered
device, which could easily be integrated into a cell phone
or PDA, can monitor scans and tags in its vicinity, warn-
ing the owner of active and passive snooping. It can also
do key management, handle access control, and authen-
ticate nearby RFID readers automatically, taking its con-
text and location into account, for example, acting differ-
ently at home and on the street. Furthermore, it can man-
age access to tags with sensitive content using Selective
Jamming. No other device in existence or proposed has
all of these capabilities. The RFID Guardian thus rep-
resents a major step that will allow people to recapture
some of their privacy that RFID technology is threaten-
ing to take away.
However, what we have described here is only one
step. We intend to further develop and improve the
RFID Guardian by giving the prototype more capabil-
ities. These capabilities include support for more fre-
quencies and standards, improving the communication
range, and simplifying the HW design. We also intend to
further develop the security protocols that are needed for
the authentication and key management facilities, think-
ing particularly about interaction requirements with the
surrounding RFID infrastructure.
8.1 Acknowledgments
The authors would like to thank Serge Keijser, Tim
Velzeboer, Dimitris Stafylarakis, and Chen Zhang for
their technical contributions. We also thank Anton
13
Scan auditing Access control Authentication Implementation
X
X
X X
X X
X X
X X X X
Tombeur, Eduard Stikvoort, and Koen Langendoen for
their friendly advice and help.
This work was supported by the Nederlandse Or-
ganisatie voor Wetenschappelijk Onderzoek (NWO), as
project #600.065.120.03N17.
More information is available at the RFID Guardian
project homepage at:
http://www.rfidguardian.org/
References
[1] Hold off on that chip, says thompson,
http://worldnetdaily.com/news/
article.asp?ARTICLE ID=47853.
[2] ISO/IEC FDIS 15693, Identification cards – con-
tactless integrated circuit(s) cards – vicinity cards,
2001.
[3] ECMA-340, Near field communication interface
and protocol (nfcip-1), Dec 2004.
[4] EPCglobal, 13.56 MHz ISM band class 1 radio fre-
quency (RF) identification tag interface specifica-
tion.
[5] Martin Feldhofer, Sandra Dominikus, and Jo-
hannes Wolkerstorfer, Strong authentication for
RFID systems using the AES algorithm, Workshop
on Cryptographic Hardware and Embedded Sys-
tems, LNCS, vol. 3156, Aug 2004, pp. 357–370.
[6] Klaus Finkenzeller, RFID Handbook: Fundamen-
tals and applications in contactless smart cards and
identification, John Wiley & Sons, Ltd., 2003.
[7] FoeBuD, Data privatizer, Jul 2005, https:
//shop.foebud.org/product info.
php/cPath/30/products id/88.
[8] P. Golle, M. Jakobsson, A. Juels, and P. Syverson,
Universal re-encryption for mixnets, Proceedings
of the 2004 RSA Conference, 2004.
 [9] Johann Großschädle and Stefan Tillich, Design [21] István Vajda and Levente Buttyán, Lightweight au-
of instruction set extensions and functional units thentication protocols for low-cost RFID tags, 2nd
for energy-efficient public-key cryptography, Work- Workshop on Security in Ubiquitous Computing,
shop on RFID and Lightweight Crypto, Jul 2005. Oct 2003.

[10] Ari Juels, Minimalist cryptography for low-cost
RFID tags, The Fourth International Conf. on Secu-
rity in Communication Networks, LNCS, Springer-
Verlag, September 2004.
[11] Ari Juels, Ronald L. Rivest, and Michael Szydlo,
The blocker tag: Selective blocking of RFID tags
for consumer privacy, Proceedings of the 10th
ACM Conference on Computer and Communica-
tions Security, ACM Press, 2003.
[22] Stephen Weis, Sanjay Sarma, Ronald Rivest, and
Daniel Engels, Security and privacy aspects of low-
cost radio frequency identification systems, Secu-
rity in Pervasive Computing, LNCS, vol. 2802,
2004, pp. 201–212.
[23] Jonathan Westhues, For anything: proxmarkii, Dec
2005, http://cq.cx/proxmarkii.pl.

[12] Ari Juels, Paul Syverson, and Dan Bailey, High-

power proxies for enhancing RFID privacy and
utility, Proc. of the 5th Workshop on Privacy En-
hancing Technologies, 2005.

[13] Günter Karjoth and Paul Moskowitz, Disabling

RFID tags with visible confirmation: Clipped tags
are silenced, Workshop on Privacy in the Electronic
Society, Nov 2005.

[14] Rick Lingle, MIT’s economical RFID field probe,

Packaging World (2005).

[15] Melexis, Application Note: A power booster for

MLX90121, 001 ed., Apr 2004, http://www.
melexis.com.

[16] Melexis, MLX90121: 13.56MHz RFID transceiver,

006 ed., Dec 2005, http://www.melexis.
com.

[17] Minime and Mahajivana, RFID Zapper, 22nd

Chaos Communication Congress (22C3), Dec
2005.

[18] Melanie R. Rieback, Bruno Crispo, and Andrew S.

Tanenbaum, Keep on blockin’ in the free world:
Personal access control for low-cost RFID tags,
Proc. 13th Cambridge Workshop on Security Pro-
tocols, Apr 2005.

[19] , RFID guardian: A battery-powered mo-

bile device for RFID privacy management, Proc.
10th Australasian Conf. on Information Security
and Privacy (ACISP 2005), LNCS, vol. 3574,
Springer-Verlag, July 2005, pp. 184–194.

[20] Sarah Spiekermann and Oliver Berthold, Maintain-

ing privacy in RFID enabled environments – pro-
posal for a disable-model, Workshop on Security
and Privacy, Conf. on Pervasive Computing, Apr
2004.

14