Object Name System Privacy and Security Joseph Timothy Foleyweb.mit.edu/foley/Public/Committee/dissertation.pdf · 5 Acknowledgments Many thanks go to my Thesis Advisor Sanjay Sarma

Object Name System Privacy and Security

by

Joseph Timothy Foley

Submitted to the Department of Mechanical Engineering

in partial fulfillment of the requirements for the degree of

Doctor of Philosophy in Mechanical Engineering

at the

MASSACHUSETTS INSTITUTE OF TECHNOLOGY

May 2005

c© Massachusetts Institute of Technology 2005. All rights reserved.

Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Department of Mechanical Engineering

May 18, 2005

Certified by. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Sanjay Sarma

Associate ProfessorThesis Supervisor

Accepted by . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Lallit Anand

Chairman, Department Committee on Graduate Students

2

DRAFT Id: cover.tex,v 1.7 2005/01/13 02:16:40 foley Exp March 1, 2005

3

Object Name System Privacy and Security

by

Joseph Timothy Foley

Submitted to the Department of Mechanical Engineeringon May 18, 2005, in partial fulfillment of the

requirements for the degree ofDoctor of Philosophy in Mechanical Engineering

Abstract

Items in the modern day have a large amount of information associated with them.The current Auto-ID research focuses on controlling and using this data through theuse of a unique identifier number. This thesis explores the problems that arise whensuch data is available and develop an architectural design for a system capable ofaddressing these issues through a combination of technology and policy.

Thesis Supervisor: Sanjay SarmaTitle: Associate Professor

March 1, 2005 DRAFT Id: cover.tex,v 1.7 2005/01/13 02:16:40 foley Exp

4


5

Acknowledgments

Many thanks go to my Thesis Advisor Sanjay Sarma who provided a great deal of

direction to my research. Thanks also go to Dr. Dan Engles who helped keep the lab

running so I could actually finish this. Erik Nygren was also important, as he helped

come up with the original concept of ONS. Steve Weis must also be thanked for the

related research into this field and some personal help. Rachel Greenstadt helped me

find the bugs in my initial version of the KLite protocol. Finally, I thank my parents

and my girlfriend for their emotional and psychological support.

March 1, 2005 DRAFT Id: cover.tex,v 1.7 2005/01/13 02:16:40 foley Exp

6


Contents

1 Introduction 13

1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2 Prior Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2.1 /etc/hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2.2 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.2.3 UCCNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.2.4 Handle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.2.5 UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.2.6 Yellow Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.2.7 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.2.8 DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.2.9 Basic ONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2 Design 25

2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1.1 Security and Privacy . . . . . . . . . . . . . . . . . . . . . . . 25

2.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Counterfeit Detection 29

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

7

8 CONTENTS

3.2 Controlled Physical Random Functions . . . . . . . . . . . . . . . . . 30

3.3 KLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3.2 Hash Functions on RFID . . . . . . . . . . . . . . . . . . . . . 32

3.3.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.3.4 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 ONS Obfuscation 39

4.1 Silencing Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Anonymization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3 Noisy Bloom Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4 Scrambling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Protection of Supply Chain Data 45

6 Algorithmic Mapping Language 49


List of Figures

9

10 LIST OF FIGURES


List of Tables

1.1 ONS Basic Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

11

12 LIST OF TABLES

DRAFT Id: intro.tex,v 1.6 2005/01/13 04:56:19 foley Exp March 1, 2005

Chapter 1

Introduction

In the modern electronic age, there are a tremendous number of numbers that are as-

sociated with a huge variety of applications. There are Universal Product Code (UPC)

numbers associated with products bought at the supermarket. United Parcel Service

(UPS) uses internal tracking numbers to monitor the state of their shipping network.

The Internet uses Internet Protocol (IP) numbers to uniquely identify servers that

are connected to it. The problem with all of these numbers is that it’s hard to figure

out what item or service they are associated with without having context. Given just

the number “1234567890”, it is extremely hard to figure out what object is associated

with the number or even the service that could tell you this information.

A large amount of effort is going into researching how to process this data and gain

value from it. However, most of these assume a very rigidly defined scheme that is

often proprietary and without wide-range use. The Auto-ID Lab in association with

the UCC Council is trying to unify these varied schemes under one umbrella: The

Electronic Product Code(EPC)[4] which is a unique identifier for each item. However,

the EPC is only half of the story. As previously mentioned, having the number is

not enough. One must be able to associate information with this number, and that

is why the Object Name System(ONS) was developed[12].

13

14 CHAPTER 1. INTRODUCTION

Even with the capability to associate the service and item with the number is

not enough. Even assuming the challenges of trying to associate a number with an

object are solved, unique identification creates new issues. The identifier can be often

associated with a particular individual with a minimum of effort. With that number,

the position and activities of a given individual can be profiled. This could in theory

lead to serious privacy challenges.[5] For instance, a bomb with an RFID tag reader

could be set to go off when a particular set of tags known as a “constellation” passes

in front of it. For those afraid of government conspiracies, with the current trend of

RFID technologies, the tracking of an individual becomes very possible.

In this thesis, we will continue to increase information visibility via these technolo-

gies, while also integrating in concepts of security and privacy to try to address the

issues that are created by the existence of ONS. There are other systems that have

been proposed to try to deal with individual security and privacy concerns, but no

end-to-end solution has been proposed. The breadth of this field means that a gen-

eral survey of multiple solutions will be investigated, but only one will be researched

deeply.

This proposal begins with an introductory section explaining the need for this

research and other attempts at addressing similar problems. The second section

explains design analysis that went into the solutions that are being investigated. The

third second gives an overview of the techniques being investigated. The proposal ends

with a conclusion restating the goals with the context of the rest of the proposal.

1.1 Problem Statement

The problem being addressed by this thesis is problem of integrating the concepts of

security and privacy into the ONS framework.


1.2. PRIOR ART 15

1.2 Prior Art

1.2.1 /etc/hosts

In the early days of the Internet, the 1960’s, when it was still actually called ARPAnet1,

the number of hosts on the network was fairly small, on the order of a few hundred

machines worldwide[21]. The ARPANet was developed to allow researchers at one

development center to use computing resources at another center. The concept of a

distributed network which had no central controller node was important to enusure

that the network would continue to function in the face of a massive neclear attack.

The capabilities of this network were primarily limited to serial terminal control of

the remote machines[1].

TCP/IP(Transmission Control Protocol/Internet Protocol) was later developed in

the early 1980’s and became the standard host to host protocol with a new addressing

scheme. The simplicity of TCP/IP and that it was included in BSD UNIX meant

that many universities became involved, bringing the number closer to 60,000 and

started being called the Internet..

In order to use this system, one needed to know the address of any machines

involved, which looked something like “4”2[1] or later ”18.18.0.249” 3 Keeping track

of what the address for a given host was proved irritating and prone to mistakes. In

order to make this problem more tractable, researchers began giving their machines

nicknames which were easier to remember.

Then an enterprising researcher decided to build an automatic system (called a

resolver) to map these nicknames to their ARPAnet addresses. This system was based

around a single file called /etc/hosts. Its format was a space-separated two-column

flat list. An entry in the table looked like this:

1Advanced Research Project Agency2ARPAnet only had 8 bits to allocate for address, and therefore only 255 addresses3Internet Protocal Version 4

March 1, 2005 DRAFT Id: intro.tex,v 1.6 2005/01/13 04:56:19 foley Exp


18.18.0.249 vice-grips.mit.edu,vice,vice-grips. The first column indicated

the address and the second indicated the nickname(s), separated by commas. This

file was downloaded from SRI’s Network Information Center(SRI-NIC) and stripped

of unnecessary information. Then the file was uploaded to the other machines via the

network or by SneakerNet4

A person using the system would ask the resolver for the address attached to a

name. The resolver would simply search through the file for a matching name and

return the number in the same record.

This system worked excellently for a while. However, as the number of hosts

increased, it became more and more difficult to keep the file to date on all the machines

that one was administering. Also, doing resolves took more time as the file got larger.

Eventually the problem became apparent enough that another system was developed,

DNS.

1.2.2 DNS

Domain Name System(DNS)[21] was a system to try to make the mapping system

started with /dev/hosts more scalable. It also included a variety of other useful

concepts to make it useful in other domains including directory lookup and email

relaying.

As with a number of the systems of this type, to the casual observer, DNS is

just a large database. A client, still called a resolver, queries a DNS server to gather

the relevant information. There is more going on than a single simple client-server

architecture, as would be expected with a system capable of being used with the

modern Internet. Doing a single query-response exchange with a single server is

insufficient to keep the system scalable and robust5. The designers of DNS realized

4aka. putting the data on a floppy and walking it to another machine.5Imagine a single server responding to the estimated 300 million hosts as of January 2004[19]


1.2. PRIOR ART 17

that their system needed to follow the basic tenets of the ARPAnet: to keep working

in the face of a devastating attack by the enemy. For the ARPAnet, the basic concern

were weapons of mass destruction, like atomic bombs. Since DNS needs the Internet

to be useful, the same attacks are of some concern, but taken care of mostly by the

transport itself. However, there are still bad scenarios to worry about:

• A hacker breaking into the a server and taking the entire system down.

• The number of clients querying the server overwhelming it.

• A rogue administrator trying to feed false information in causing other parts of

the system to malfunction.

• Two administrators decide to pick the same hostname. Which one is valid?

• Lazy admins not keeping their /etc/hosts up to date.

A concept that addresses many of these problems is that of a domain. A domain

is a region of responsibility and control. It also provides a mechanism for delegation

of the responsibility between different parties. The concept of the domain shows up

even in the human representation. Consider the DNS name vice-grips.mit.edu.

DNS uses the separator “.” to indicate a domain6: (‘‘vice-grips’’, ‘‘mit’’, and

‘‘edu’’) These domains are ordered in a hierarchical tree structure, with the root

node starting before the rightmost domain. Next comes a top-level domain, then

second-level, and so on.

vice-grips.mit.edu www.objid.net same root server

vice-grips.mit.edu andrew.cmu.edu and top level server

vice-grips.mit.edu lovecanal.mit.edu and secondary server

6There is an implicit “.” at the right end of each name. Often this is left off to make it look lessconfusing. In the actual encoding of the configuration files, a domain is only complete if it has theclosing “.” If the “.” is left off then the local domain is appended. For instance, ‘‘vice-grips’’would turn into ‘‘vice-grips.mit.edu.’’ but ‘‘vice-grips.’’ would be left alone.



To lookup information associated with a given name, the server starts with break-

ing the name into domains and beginning with the rightmost domain. For our ex-

ample, we will use vice-grips.mit.edu. The first step is bootstrapped by having a

universal set of root servers. This information does not change often and is actively

updated. These machines require a significant amount of bandwidth and processing

power, but not as much as might be expected. The reasons why will become apparent

later. The resolver then looks at the first domain edu and queries the root servers

about the top-level domain’s servers. Then the top-level domain servers, the “edu”

servers, are asked for the info on the next domain mit. Finally, the second-level

servers at MIT are asked for information about vice-grips and are returned the

actual information.

To enhance performance, much of the information is usually cached by the re-

solver7. Information is structured in a manner that is convenient for caching. As

the resolver recurses down the tree structure, it remembers what answer it got for

a particular domain. So once it has seen what the edu servers are, it does not need

to ask again. To make sure that data is kept up to date, there is the concept of a

Time To Live(TTL) for every piece of information. When the amount of time since

a record has been accessed exceeds the TTL, the record is deemed expired and then

deleted.

One of the beauties of the updated system is that a user who was used to a resolver

using /etc/hosts would be able to use a correctly configured DNS resolver with no

change in behavior.

7Early windows resolvers did not, which was irritating as they caused a lot of traffic.


1.2. PRIOR ART 19

1.2.3 UCCNet

A system with a similar purpose is UCCNet.[29] It is designed as a glue protocol and

database between suppliers and retailers. For instance, if Sears wants to produce a

new catalog, they need information about the products: how much it costs, what the

target consumer is, and a picture of the product. This becomes even more necessary

in the world of Internet shopping, where prices are constantly changing and small

internal changes can result in large visible changes.

For a subscriber fee, UCCNet will setup a manufacturer’s site with their software.

The software implements a fairly general XML DTD which encapsulates the content

that the manufacturer or supplier wants to provide. This information is converted

into another internal representation and stored on a database. The retailers pay their

fee to query the database for the information they desire.

This system does a good job of describing objects in the retail world. However, it

doesn’t have the concept of instances we require for the more interesting applications

we will be mentioning later. It is also very centralized which means it may not scale

to the tremendous numbers we require.

1.2.4 Handle

Handle[14] is a different type of object naming system created by CNRI8 in 1994. It

was created to have a simple mapping of IDs to a persistent network identifier. In

addition, there was demand for a system to control digital rights management called

Digital Object Identifier (DOI) later. The Association of American Publishers wanted

a unified system capable of having a unique ID that was persistent so that the article

could be tracked[15] indefinitely.

The Handle system has much in common with the our requirements(mentioned

8Corporation for National Research Initiatives



below). It creates a unified network database that will return information when given

a unique ID. These IDs are in the form “<NamingAuthority>/<Identifier>”

However, unlike DNS, Handle has only a two-level hierarchy, as should be apparent

from the ID style. Handle uses a combination of a hashing algorithm and cluster of

servers to create a load-balanced, robust, and scalable service. There are interesting

questions about the management of such a system and the limits of its scalability.

One other challenge is that handle software is not considered part of the standard set

of software installed on a computer, though that is changing. If this service takes off,

then that will not be an issue.

1.2.5 UDDI

A more web-focused discovery protocol is Oasis’s Universal Description, Discovery

and Integration(UDDI) protocol. To quote their website[30]:

UDDI creates a standard interoperable platform that enables compa-

nies and applications to quickly, easily, and dynamically find and use Web

services over the Internet. UDDI also allows operational registries to be

maintained for different purposes in different contexts.

This system is another XML based query and response search system. However it

also makes use of the more general publish-subscribe system to distribute constantly

updating information in an efficient manner.

A concept from UDDI that our proposed system should make use of is internal

and external views. Users can see either an internal or external view depending upon

their authorization. This provides a measure of security granularity that is useful for

grouping data and its interpretation together. The way that the data is managed

among the different views is also quite interesting.


1.2. PRIOR ART 21

1.2.6 Yellow Pages

Yellow Pages(YP)[22], now known as Network Information Service(NIS) was a general

directory lookup service, provided by Sun as another alternative to DNS. It was

capable of returning standard address information and could return general table

lookup information.

YP did construct same interesting concepts that were slightly different than DNS.

As with most of these systems, YP defined a set of key-value pairings, but these

pairings could be grouped together into maps. A domain within YP is a category

of maps. These three concepts of key-value, map, and domain allowed YP to model

most simple database information.

YP also had the concept of referral through a mechanism called YPbind. YP uses

YP binder servers to bootstrap the process of finding the correct YP servers to query

for further information. Since YPbind was considered an optional part and is not

very scalable, it is clear that the system was designed mostly for intranets.

1.2.7 LDAP

Lightweight Directory Access Protocol(LDAP) is another query system that was sup-

ported by Microsoft, IBM, Lotus, and Netscape to try to centralize a directory[20].

LDAP has a fairly general purpose query language that includes method for spec-

ifying filters and the formatting of the output. There is also a permission system to

restrict access to only authorized users.

LDAP was designed at the University of Michigan and was based upon an enter-

prise directory system called X.500. X.500 itself was not used as it was too heavy-

weight a protocol and the server itself was a bit much for the PCs available at the

time.

At this time, LDAP is used mostly by modern email clients to associate informa-



tion with and to lookup email addresses, but not much else. Part of the problem is

that LDAP was designed for a centralized service, which has issues on massive-level

scaling.

1.2.8 DNSSEC

In 1990, Steven Bellovin discovered a major security hole in DNS that would allow

an attacker to easily break into a host by hijacking parts of DNS[2]. Bellovin did not

publish the compromise until 1995, as DNS was widespread enough that it might have

caused chaos to erupt[13]. His discovery was that the reverse resolution mechanism

of DNS allowed an interesting way to gain access to machines using the trusted host

mechanism of rlogin and rsh. The exploit made use of the fact that there is not a

strong mechanism to enforce a given hostname(vice-grips.mit.edu) and its reverse

resolution name(18.18.0.249).

He verified that it worked and began thinking of ways to solve the problem. When

he finally published the exploit, an answer was something that became known as

DNSSEC, specified by IETF RFC 2065, 2535, and currently 2535bis. DNSSEC[6]

works by using cryptographic signatures to ensure that information is coming from

an authoritative server.

This is excellent for ensuring that information is valid, but does noting for privacy

alas. There is no encryption specified, only authentication. In order to build a secure

system capable of ensuring privacy, we need something more.

1.2.9 Basic ONS

The system described in [12] is very simple and based upon DNS. In fact, it is built

upon DNS with a careful set of configuration files.

To use ONS with a 128 bit RF-id tag, first separate out the initial header field


1.2. PRIOR ART 23

1. The machine goes to the root name servers and returns “.net” server.

2. The “.net” server returns the “.objid.net” server (which happens to be vice-grips.mit.edu).

3. The “.objid.net” server returns the “.A.rfid.objid.net” server which is one of theDISC serversa.

4. This server returns the address for the “E746F62.6A.rfid.objid.net” server whichwould be under control by the manufacturer.

5. We then have IP address of the server that has information on that tag.

aor whomever this service is farmed out to

Table 1.1: ONS Basic Query

and break the rest up into 4 byte hexadecimal encoded chunks separated by dots.

Then we add on the ID type, the default being “rfid:”

(objidpart4)...(objidpart1).(header).rfid.objid.net

802A69.6E74656C.6C696765.6E746F62.6A.rfid.objid.net

The “magic” occurs in the separations. A machine seeking the webpage with the

data on the object uses them to do the lookup as described in Table 1.1.

The IP number is stored using either a standard DNS server. The machine would

then query that server in some standardized format such as HTTP:

GET http://18.18.0.249/RFID.cgi?ID=802A696E74656C6C6967656E746F626A

Since it’s initial design, a number of changes are under development to incorporate

further useful information.

Talk about my autoconfiguration attempts..

Talk about OATsystem’s internal and external views.

Talk about Verisign’s use of PTR records.



DRAFT Id: design.tex,v 1.5 2005/01/13 04:17:35 foley Exp March 1, 2005

Chapter 2

Design

2.1 Terminology

RFID: Radio Frequency Identification

Tag: A complete RFID tag. Consists of an antenna, transciever, and memory.

2.1.1 Security and Privacy

A challenge inherant in considering any design is what aspects to evaluate it upon. In

particular, this thesis wishes to focus on Privacy and Security. Unfortunately, there

is nothing that really conclusively defines how these can be universally quantified.

There are government regulations[23],[16] which we can base our concepts upon. The

familiar concept of secrecy levels defined by damage of disclosure is described in the

Executive Order 12958:

Sec. 1.3. Classification Levels. (a) Information may be classified at

one of the following three levels:

(1) ”Top Secret” shall be applied to information, the unauthorized dis-

closure of which reasonably could be expected to cause exceptionally grave

25

26 CHAPTER 2. DESIGN

damage to the national security that the original classification authority

is able to identify or describe.

(2) ”Secret” shall be applied to information, the unauthorized disclo-

sure of which reasonably could be expected to cause serious damage to

the national security that the original classification authority is able to

identify or describe.

(3) ”Confidential” shall be applied to information, the unauthorized

disclosure of which reasonably could be expected to cause damage to the

national security that the original classification authority is able to identify

or describe.

In addition, the term “unclassified” is defined to be any document that does not

need the lowest level of privacy.

For the generalized application and description of the ONS system, I propose a

similar set of classifications focused on industrial applications:

Arcanum: Information that could bring about the ruin of the owner if it were dis-

closed inappropriately.

Private: Information that could cause possible large monetary, mental, and/or phys-

ical harm to the owner if disclosed inappropriately.

Intimate: Information that would cause significant discomfort to the owner if dis-

closed inappropriately.

Data that is more public than the given classifications would be deemed “Common

Knowledge”

Another valuable, but seemingly obvious concept from the document is that of a

security level watermark. A discrete unit of data is always deemed at a security level

of the highest classification of any single element within the unit. So a document that


2.2. FUNCTIONAL REQUIREMENTS 27

would be “Intimate” becomes “Private” if you add a “Private” piece of information

to it.

Talk about guidelines in Departmont of Defense’s National Industrial Security Pro-

gram Operating Manual for use and operation

2.2 Functional Requirements

The system must be capable of handling a large namespace. In the case of the original

tag design, this was a 96 bit tag; 296 = 7.92E28 possible IDs. From this, there are a

few Functional Requirements necessary:

1. The system must be scalable to 1 trillion(1012) IDs active. We don’t need to

handle all possible ID’s active, as that is beyond any estimation of reasonable

usage, discussed later.

2. The system must be continue to work even when the network is segmented or

disconnected.

3. The system must minimize bandwidth usage to that of a 56K modem for home

users, and a LAN line for commercial use1

4. The system must leverage existing internet tools, architectures, and technolo-

gies.

Conveniently enough, these functional requirements are extremely similar to those

used for developing the Domain Naming System[26]. This fact allowed us to use DNS

to build the initial implementation of ONS that intrinsically meets their requirements.

This research focuses on a few new FR’s.

1. The system must avoid providing information to unauthorized entities.

1This requirement will change as bandwidth avialability increases.

March 1, 2005 DRAFT Id: design.tex,v 1.5 2005/01/13 04:17:35 foley Exp

28 CHAPTER 2. DESIGN

2. The system must assist in the policy development to define what is authorized

and unauthorized.

3. The system must respect the privacy constraints imposed upon it by society

and government regulation.

Mention the routing problem from tho source routing IP design that avoids “bad”

countries.There are some implicit FRs generated by the fact that the systems developed in

this dissertation are expected to be used worldwide, and by a typical human being.

1. The system must have an intiuitive user interface for basic operations.

2. The system must be explainable in colloquial language.

3. In cases where liability is an issue, such as medical or legal information, sufficient

protections must fulfill current government standards.

These new constraints lead to the ideas presented in the next section.

Add wore justification to the various requirements.


Chapter 3

Counterfeit Detection

An inherent problem with a systems that link identities with numbers, is how does

one verify that a particular tag really was with that item in the first place. Someone

listening to a tag could theoretically mimic that response elsewhere and “become”

that entity.

A solution can be created using some cryptographic elements to create a very sim-

ple authentication protocol called KLite[11]. Basically a reader accesses a database

and a secret number on the tag and generates a challenge-response pair that is com-

pared. One of the advantages to this system is that the reader never knows the

actual secret key on the tag, and therefore even if compromised cannot reveal the

information.

The advantages of such a system is that it requires a minimum of additional

electronics on the tag other than a good but small-footprint hash function as proposed

in [31] and some software on the reader.

29

30 CHAPTER 3. COUNTERFEIT DETECTION

3.1 Introduction

Radio Frequency Identification has become an emerging technology with the promise

of changing a number of different paradigms in manufacturing and commerce. The

capability of associating numbers with objects has existed for a while, in the form

of bar-codes such as the UPC, which classify products but not individual instances.

UPS and other shipping companies have been using unique barcodes and therefore

unique id’s to identify individual items in their chain. This means that the item can

be tracked from the point at which it enters the company until it leaves.

The reason that RFID is superior to barcodes is that it gives more flexibility on

the size of the number and loosens the conditions required to read the tag. A barcode

capable of storing multiple kilobytes of information would be excessively large. Also,

the barcode cannot be read if the reader cannot see it.

Regardless of the manner in which the number is stored, a properly designed

idenifier should be unique. Given a unique identifier, we should be able to associate

a variety of information with it. Having such information associated with the item

often increases its utility and value.

3.2 Controlled Physical Random Functions

[3] proposes an interesting concept that is useful to removing the possibility of coun-

terfeits. This paper proposes a Controlled Physical Random Function(CPUF)1 that

makes use of the unpredictable nature of chip manufacturing to generate a unique

id. A CPUF has a controlled delay feedback loop that measures the time for a signal

to go through various lengths of “wire” inside of the chip. Manufacturing tolerances

make the chances of any given set of wires having exactly the same series of lengths in

1The acronym actually stands for Controlled Physical Unclonable Function. The alternativeacronym is to avoid namespace collision with Pseudo-Random Functions

DRAFT Id: klite.tex,v 1.5 2005/01/13 04:56:19 foley Exp March 1, 2005

3.2. CONTROLLED PHYSICAL RANDOM FUNCTIONS 31

any given set of chips extremely low. These variations come from differences in tem-

perature during various parts of the IC’s manufacturing, impurities in the substrate,

and various other factors that can only partially controlled.

A delay feedback loop is simply to amplify these differences into unique bits. This

consists of a number of AND gates connected with criss-crossed NOR gates behind

them. This sets up a repeatable race-condition between the incoming signals; if the

top wire is shorter, then the AND returns a 1, otherwise a 0 is returned.

The advantage of this system is that it generates a number associated with a chip

that is almost certainly unique and if carefully constructed, tamper-proof2. This also

proves to be a disadvantage as a manufacturer has no control of what id the chip will

be. Also, the number cannot be changed later, as it is effectively a fingerprint of the

chip.

Still, using this approach for generating the serial number field of an EPC tag

may be exactly what is needed. This would allow a manufacturer to set the version,

manufacturer, and product fields, but allow the tag to set it’s own serial number using

a CPUF that had a fairly low chance of collision and would not tamper-resistant.

Unfortunately, having a tag that cannot be copied is not enough to prove owner-

ship. A malicious attacker could easily read the number while it was being transmitted

and relay or replay the number to forge ownership. We need a means to prove that

the tag is actually the physical entity and not just the number.

2If the design routes the delay-wires through the middle of the chip, or on a top layer, anyonetrying to modify the chip will scramble the number.

March 1, 2005 DRAFT Id: klite.tex,v 1.5 2005/01/13 04:56:19 foley Exp


3.3 KLite

3.3.1 Introduction

Add more about the insipration from Kerberos.

A better method is to add a small amount of intelligence to the reader and tag to

create a zero-knowledge proof system. The important piece we need in order to make

a workable system is a cryptographically secure one-way function “H()” that can be

implemented easily on the RFID tag.

The protocol between the reader and the tag must be very light-weight, and com-

putation non-intensive. The reason is that the tag has very little power (energy and

computation), to reduce cost and increase range, generally desirable characteristics.

It is also expensive to save state, as that requires additional memory that can be

written to. The proposed designs are focused on tags that are generally One-Time-

Programmable. The protocol between the reader and other servers can be heavier,

as it has less restrictive power requirements.

With this in mind, we assume that the Reader(R) and it’s Verification Server(V )

have set up a secure two-way connection using Kerberos 5 or SSL. There should be

lighter-weight protocols that would also work, but since it is a solved problem, we

will not worry as much about it.

When the tag(T ) is programmed, it is also given a secret(s) in addition to it’s

id(i). This s is also stored in V at that time.

3.3.2 Hash Functions on RFID

Creating a crytographically sound hash function on an RFID tag is a non-trivial task,

as is mentioned in [31]. RFID tags have a variety of challenges of working in a normal

environment that become even more significant when trying to do computationally


3.3. KLITE 33

intensive tasks such as hash functions.

1. Power is not guarunteed for any length of time.

2. Transmissions may end at any moment without any warning.

3. Transmissions may be one-sided, especially since the transmission range of the

tag is significantly shorter than the reader.

4. Saving state requires a significant amount of power and additional silicon mem-

ory.

As mentioned in [31] the most promising area is that of cellular automata. Given

the state of current reserach, it seems likely that there will be a sufficient hash function

for non-critical applications fairly soon.

Put something about ultrasmall AES here?

3.3.3 Assumptions

We have to make some assumptions about this problem.

1. There is enough processing power between R and V in order to setup a secure

connection. Seeing as there is current hardware that can make such connections,

and sufficient cryptography interfaces such as SSL2 exist, this is reasonable.

2. An attacker will not be spoofing on both the RF and the physical network

channel. If an attacker can do that, then it is possible to convince the reader of

false authenticity regardless of how it is constricted.

3. There is very little processing power and state on T . Moore’s law is pushing at

this boundary, but it is still true.



4. There exists (and we can use) a one-way collision-resistant hash function that

requires very little processing power and time.

Give an example of a nieve design and why ours is better.

3.3.4 Operation

When the Reader(R) wants to verify authenticity:

1. R queries T for its id.

2. T responds with i.

3. R creates a random number challenge(c) and sends it to T

4. T creates H(c,s)1 and returns it to R

5. R sends c to V via the secure link

6. V creates H(c,i)2 and returns it to R via the secure link

7. R compares H(c,s)1 and H(c,s)2 for verification

The elegance of such a system is that the Reader does not need to know very

much in order to verify the authenticity of the tag. The secret is never transmitted

in a manner that can be reversed thanks to the one-way function. The only thing

that the reader has to actually store is it’s credentials for the secure connection to

the Verification server.

If we could assume that an attacker would not attack both the TR and RV links,

then we wouldn’t need the secure link for RV. However, a determined attacker would

be willing to do so. In such case, an attacker could convince R of it’s false identity by

giving a bogus response as the response to the challenge, and the same response again


3.3. KLITE 35

during the validation step. To do anything more would require more computation on

the part of the tag, which is something that we cannot afford.

A person who sees the random number challenge will only be able to fake the

response to that given random number. Assuming a good generator, the chances of

that should be very small.

Examining the protocol in a more formal context of semantic security, we have

some challenges.

In a semantic security analysis, we play a “game” using the algorithm, with an

adversary playing given a set of rules and information. For instance, an El-Gamal

semantic security analysis using Adaptive Chosen Ciphertext Attack(ACCA)[25] in-

dicates that the ElGamal public key encryption system is not secure given those

conditions. ACCA refers to the limitations/capabilities given to the attacker. The

game is set up as follows with all constants being known by the adversary unless

specified otherwise:

• There are 2 cleartext messages: m0 and m1.

• There is a public key(kp) and private key(ks). The adversary only knows the

public key.

• The mechanism of the game allows the adversary to encrypt any message that

he desires.

• The mechanism will also allow him to decrypt any message except for m0 and

m1.

• To play the game, the mechanism chooses randomly between m0 and m1 and

encrypts one, producing C∗

• The adversary wins if he is able to determing with greater than 50% which

message was encrypted.



The attack that allows the attacker to win this game is to simply multiply C∗ by

a constant a, then decrypt it. Since the message is not m0 nor m1, it is decrypted:

am? The message can be recovered by dividing the result by a since ElGamal is

multiplicatively homomorphic.

Traditionally this test is used for protocols involving encryption, but our prob-

lem is very similar. The game just needs to be modified to allow for different win3

conditions:

• There are two RFID tags with their IDs: i0 and i1 and internal secrets s0 and

s1 respectively.

Win conditions:

• The adversary is able to convince the tester that it possesses

I’m starting to think that this might not be the right approach to analyzing the system.

I’m still thinking about it.

Server Concerns and Attacks

One concern with such a system is the administrative overhead of keeping track of a

multibyte key for each tag. To determine how big of a key is needed to protect the

sensitive information, we must first analyze what the relative worth and longetivity

of the data is so as to not waste resources.

The traditional attacker as mentioned before is trying to counterfeit the identity

presented by the tag. Two reasonable world scenarios exist for when the KLite system

might be in general use:

• Items of great sensitivity are under it’s protection.

• All/Majority of Tags use it.

3Really, “lose” conditions but that’s too confusing.


3.3. KLITE 37

Since we cannot predict the future, which actual application will occur is impossible

to predict. However, as a designer, it is prudent to either make a single design that

incorporates both possibilities or two designes that are dependent upon the emergent

one.

Considering the “worst-case” scenario that all tags make use of the KLite protec-

tion, the amount of data that must be managed becomes quite large. Assuming a

lifetime of 100 years, and the current conservative statistic of 5 billion barcodes gives

an estimate of 182 trillion items to be monitored. A 100 year lifetime also allows

us to estimate how large the key is by using Table 7.1 in [27]. This table gives an

analysis of symmetric keyspace searches in 1995. Moore’s law indicates that comput-

ing power should increase by an order of magnitude every 5 years. Extrapolating,

we know that computers have gotten approximately 100 times faster than they were

back then. Trying to apply this to a 100 year period gives an indication of 20 orders

of magnitude, which seems unlikely. However, even with this absurd level of speedup,

we would need a key that would take 1020 years, which is 1 year after 100 years have

passed. Conveniently enough, the beforementioned table and some extrapolation give

an estimate, with the assumption that a 64 bit key takes 1 year in 1995 at $100K of

hardware:

64 + log2(1020) = 130.4 (3.1)

So a 131 bit key would be sufficient to last for 100 years against $100K of hardware,

scaled for 100 years.

Assuming that we are still using the 96 big EPC tags, each with a 131 bit key, this

comes out to a staggering 5178 Terabytes that needs to be distributed. This fright-

ening number does not take into account the overhead of storing such information

nor its associated data. A reassuring fact is that data storage and bandwidth is also

increasing at a tremendous rate.



Bandwidth analysis

Talk about compression and backup configurations.

Thing about patent in progress.


Chapter 4

ONS Obfuscation

Another problem with the ONS hierarchy is that some information can be gleaned

from the ID itself. For instance, if someone purchased controversial materials in a

store and transported them home, a person wandering by might be able to read the

number off the tag. Given the manufacturer and product id, a malicious user would

be able to get some information about that product without even querying the PML

server. An equivalent mapping is the information that is collected from the cookies

that web-browsers use as they move. There are two obvious ways to deal with this

problem (and still use the system)

1. The tags must have a way to be temporarily silenced.

2. ONS needs a way to hide information away unauthorized entities.

4.1 Silencing Tags

For most tags, the first method is fairly simple. Putting the tag inside a metal

box keeps any RF from reaching the tag to query it. Destroying the tag also works

for silencing it, but this loses the additional value that the tag could bring later.

39

40 CHAPTER 4. ONS OBFUSCATION

Some tags are being worked on that have an external switch that can be removed to

temporarily silence them.

Certain tag systems make evesdropping even easier. In one binary-tree anti-

collision tag system, a reader asks if a tag has a certain bit set to a certain value. It

then listens for a collision. If it hears one, it tells all tags with that value set to check

if another bit is set. This continues until there are no collisions occuring, at which

point the reader asks the tag for the rest of it’s bits. An alternative system simply

asks the field of tags what a particular bit is set to, and listens for collisions. The

second method is a little easier to detect, as there is a good chance that the collisions

will have differing values.

The problem is that an evesdropper does not need to send anything in order to

get the entirety of the bitstring. In fact, to get most of the tag, they don’t even

need to necessarily listen to what the tag says. The reader’s queries generate enough

information for the tag to be identified. This is key, as it is physically much harder

to read a tag’s response, because the power levels are so much smaller.

[8] describes one simple way of making this more difficult. Instead of using it’s

own id to do the anticollision, the tag chooses a random number when powered up.

This number becomes it’s anticollision id for doing the same anticollision algorithm.

Once anticollision negotiation is complete, the tag can transmit it’s real ID. In [8]

the tag would actually continue using it’s anticollision id, as they are trying to make

tracking more difficult.

4.2 Anonymization

We also need a method of anonymization. One proposed method is to create a

scrambled space in the ONS namespace that points at a lot of different things. A

secure proxy would know the correct mapping between the anonimized tag, and it’s

DRAFT Id: obfuscate.tex,v 1.5 2005/01/13 02:16:40 foley Exp March 1, 2005

4.3. NOISY BLOOM FILTERS 41

actual PML server. This would make it very hard for someone to get information

about the product without making a direct request to the PML server which can then

be refused by other security measures.

To assist in anonymization, proxies should be placed somewhat geographically.

For instance, all of the ONS traffic for an apartment building might go through one

proxy such that the finest level of granularity is still broad. For added security, a

system of mix-nets, could be used to make this even harder[10]. A mix net is a large

network of servers that take packets and randomly (or pseudo-randomly in some cases

such that a return path is possible) routes them through the network. This convoluted

routing makes it very hard to determine where the original packet came from.

A current line of research is to go one step further and try to dissassociate the

product’s ownership from the manufacturer so that a manufacturer cannot trace where

it is and who has it. A proposed solution is to have a section of the ONS mapping be

scrambled, but this does create other challenges. This makes administration of that

space difficult and makes application design hard.

4.3 Noisy Bloom Filters

Another idea for improving security of a tag mentioned in [7] is to use a noisy Bloom

filter. A Bloom filter is a set of hash functions to represent a data set via a different

bit-based representation. To calculate filter’s output, the input x is run through

some k independant hash functions hk(x) with output values in the range 1, ..., m.

The value of the hk(x) bit of the output is set to one for each hash.

To check if there is a match in a Bloom filter, a given input is run through the

same set of hashes, and the bits set to 1 are compared. If they are the same (or at least

above some threshold) then there is a high probability of a match. Unfortunately,

there is a possibility of false positives using this method of probability sk, where s is

March 1, 2005 DRAFT Id: obfuscate.tex,v 1.5 2005/01/13 02:16:40 foley Exp


the ratio of bits set to all bits on output.

The difference between a Bloom filter and a noisy Bloom filter is that a noisy

Bloom filter has a random generator set some number of bits to 1. This makes

dictionary attacks much harder, and does not make valid matches invalid. Adding

additional 1s increases the chance of false positives, but as long as the number of bits

is sufficient, the probability is low. In [7] the randomizer is called a one-way noise

imposer, and does an additional function: it sets the saturation(s) of the noisy Bloom

filter’s output. This has the effect of ensuring that the false positive rate is sk and

can be controlled.

One attack against such a system is to request information from the same tag

repeatedly. Since the one-way noise imposer can only set some number of bits to 1

and cannot set any to 0, once you’ve seen enough noisy Bloom filters, you can filter

out the noise as the bits that change. Once the original Bloom filter is isolated, one

can forge valid noisy Bloom filters by adding in new noise.

Regardless, the noisy Bloom filter does give a concept for identifying an ID without

using the ID itself.

4.4 Scrambling

However, we may be able to scramble some of the information without losing all of the

capability. An idea mentioned in [17] describes using a hash keyed upon the tag’s own

number. This has the advantage that the tag can have a direct one-way deterministic

translation to a new number. This does have one caveat, as doing a hash only at the

levels of manufacturer, product, and serial numbers will not provide total anonimity to

an item. A passive attacker can build a dictionary of the endpoint translations from a

given set of products, then test the information against the requests that he sees. The

best approach to this is possibly reassembling the manufacturer and product fields

DRAFT Id: obfuscate.tex,v 1.5 2005/01/13 02:16:40 foley Exp March 1, 2005

4.4. SCRAMBLING 43

back into one number, hashing it, then redividing it back into the original bitmask.

This has the advantage that the serial number does not change and so can be easily

compared to the physical packaging. It does obfuscate the manufacturer and product,

as an attacker would have to try a large number of combinations to find the match.

The disadvantage is that now the products types are no longer grouped under a single

manufacturer. This is an acceptable loss for products for which that information is

priviledged.

March 1, 2005 DRAFT Id: obfuscate.tex,v 1.5 2005/01/13 02:16:40 foley Exp


DRAFT Id: protection.tex,v 1.3 2005/01/13 02:16:40 foley Exp March 1, 2005

Chapter 5

Protection of Supply Chain Data

An application that many are interested is the application of ONS to supply chain

management. ONS combined with savants1 and EPC is capable of tracking objects

with very fine granularity. One of the early things learned from studies of supply

chains is that information normally travels very slowly and this is a serious liability.

A standard demonstration of this is an exercise called The Beer Game[18]. Pro-

ducing a beverage like beer is an involved process:

1. Raw materials are produced

2. Raw materials are harvested

3. Raw materials are sold and transported to the Factory

4. Then the materials are processed, Fermentation begins

5. Fermentation finishes and is bottled

Part of the challenge lies in that some steps take a significant amount of time

before they can proceed. This results in a large amount of Work In Progress and

1A savant is a processor that sits on the network and answers queries about the state of thereaders.

45

46 CHAPTER 5. PROTECTION OF SUPPLY CHAIN DATA

inventory, which can cause enormous shortages and surpluses along the same supply

chain.

The ONS infrastructure enables higher visibility in the chain. This means that

decisions and predictions can be made about all of the information regarding the

chain at any given moment. Conceptually, the system can then be treated like a

much tighter closed-loop control system with many points of feedback to keep the

WIP swing low.

With the higher visibility, distribution of information while preserving privacy

becomes challenging. The value of the information about a company’s supply chain

may be valuable to itself and vendors, but is often worth even more to it’s competitors.

One possible approach to this problem is to have ONS act as mediator. During

transfer of ownership, the new owner would use ONS to follow a link to the old owner

and negotiate the transfer electronically using a separate protocol. At the end of the

transaction, ONS would be instructed to delete the ownership pointer and/or update

it such that any new requests would always go to the new owner.

Even then, some sort of language needs to be used to control the accessibility of

the data to the desired users. Systems such as SIREN: Role Based Access Control[28]

give a variable granularity access control language which may be sufficient, but there

needs some further development in the software before it can be used. Other similar

systems based upon web-content(P3P)[24] and enterprise data(EPAL)[9] also define

XML languages that may form the basis for our access control.

The Access Control problem for as ubiquitous a system as is expected is tremen-

dous. Part of the problem lies in dealing with the multiple roles of a given user. A

consumer who picks up a product to interact with it may be a customer, restocker, in-

spector, thief, administrator, or some combination of these. Each of these roles should

have a different view of the world and should only be allowed what is reasonable2.

2Reasonable is a dangerous and vague word, but is appropriate here.

DRAFT Id: protection.tex,v 1.3 2005/01/13 02:16:40 foley Exp March 1, 2005

47

Most Access Control languages are designed with a specific situation and set of

users. Effectively, they work within a closed universe. It is very clear what an entity

is, and how it interacts. For example, in the Andrew File System, an ACL data-

structure is used to control who has access to which directories. The data-structure

consists of a list of user and permission mappings for the given directory. These

permissions are normally additive, whereby a subset of users that are in two groups

are given the sum of the two priviledges. However, there is a concept of negative

ACLs as well, to deal with when you want an exclusive or subtractive grouping.

March 1, 2005 DRAFT Id: protection.tex,v 1.3 2005/01/13 02:16:40 foley Exp

48 CHAPTER 5. PROTECTION OF SUPPLY CHAIN DATA

DRAFT Id: algolang.tex,v 1.5 2005/01/13 02:16:40 foley Exp March 1, 2005

Chapter 6

Algorithmic Mapping Language

Another strategy to mapping codes is via a language. The 0.9 version of ONS used

a combination of DNS lookups and bit-division and hex-encoding to produce a more

compact, flexible representation. We can extend this idea, and have a general-purpose

encoding language capable of handling these translations on the fly. This means that

a client that wishes to convert it’s RFID tag into a GTIN or other mapping only

needs to lookup up the entry for it’s encoding scheme and apply it. If the scheme

needs to change, then it can be globally or incrementally updated using a DNS-like

structure if not DNS. The current research in ONS is trying to use NAPTR records to

store the translation information. This scheme is remarkably similar to the way the

the MIT Athena environment stores it’s various server and user information, called

Hesiod.

Hesiod is also built upon DNS, has a heirarchical tree construction. It stores it’s

information in TXT records under the HS(Hesiod) class[21]. To give an examples, if

we wished to find out the unix /etc/password entry information for the user “foley”,

we would type host -t txt foley.passwd.ns.athena.mit.edu which would return

“”foley:*:7812:101:Joe Foley,Crazy old Joe,NE46-6FLR,4522918,6172256696:/mit/foley:/bin/athena/tcsh”

Examining the fields of the query shows us how it breaks down:

49

50 CHAPTER 6. ALGORITHMIC MAPPING LANGUAGE

Position Value Description

1 foley Username of person being looked up

2 passwd Type of query

3 ns Refers to nameservice, short for Domain Name Service

4-6 athena.mit.edu The domain and associated server to be queried

As a method for intentional obfuscation, the mapping language can make it more

challenging for an observer to figure out what the original item was. The transorma-

tion could be as simple as flipping all of the bits. Mind you, this only protects against

very nieve monitoring.


Bibliography

[1] The arpanet, the internet and tcp/ip.

[2] Steven M. Bellovin. Using the domain name system for system break-ins. Pro-

ceedings of the Fifth Usenix UNIX Security Symposium, June 1995.

[3] Marten van Dijk Blaise Gassend, Dwaine Clarke and Srinivas Devadas. Con-

trolled physical random functions. Laboratory for Computer Science.

[4] David Brock. The electronic product code(epc): A naming scheme for physical

objects. AutoID Center, January 2001.

[5] Roberta Brody. Consequences of electric profiling. IEEE Technology and Society,

18(1):20–27, Spring 1999.

[6] Dnssec - - dns security extensions, securing the domain name system.

[7] Yusuki Doi, Shirou Wakayama, Masahiro Ishiyama, and Satoshi Ozaki. Privacy

enhanced rfid tag with noisy bloom filter. Conference on Pervasive Computing,

2005.

[8] Sandra Dominikus and Elisabeth Oswald. Symmetric authentication protocols

for rfid systems. Conference on Pervasive Computing, 2005.

[9] Enterprise privacy authorization language.

51

52 BIBLIOGRAPHY

[10] Simone Fischer-Hubner. Privacy enhancing technologies, phd course.

[11] Joe Foley. Klite: A rfid tag anti-counterfeit system. AutoID Center, November

2003.

[12] Joseph Timothy Foley. An infrastructure for electromechanical appliances on

the internet. Master’s thesis, Massachusetts Institute of Technology, Cambridge,

MA 02139, May 1999.

[13] Miek Gieben. Dnssec.

[14] CNRI’s Handle Website.

[15] IETF’s Request For Comment Articles on the Handle System.

[16] The White House. Executive Order 12958. April 1995.

[17] Yih-Chun Hu and Adrian Perrig. A survey of secure wireless ad hoc routing.

IEEE Security & Privacy, May-June 2004.

[18] MIT Forum For Supply Chain Innovation. The mit beer game.

[19] Isc internet domain survey.

[20] What is ldap?

[21] Paul Albitz & Cricket Liu. DNS and BIND. O’Reilly & Associates, Inc., Se-

bastopol, California, second edition, 1997.

[22] Protocols.com: Sun protocols family.

[23] US Department of Defense. National Industrial Security Program Operating

Manual. Change two edition, 2001.

[24] Platform for privacy preferences (p3p) 1.0 (p3p1.0) specification.


BIBLIOGRAPHY 53

[25] Ron Rivest. Notes on semantic security from mit 6.857: Computer and network

security. November 2004.

[26] Anthony Rutkowski. Assigning names and numbers: A brief history of the in-

ternet domain naming system. Journal of Engineering Design, 8(4):10–13, De-

cember 1997.

[27] Bruce Schneier. Applied Cryptography. John Wiley & Sons, Inc., New York, New

York, second edition, 1996.

[28] Arundhati Singh. Siren: a sql-based implementation of role-based access con-

trol(rbac) for enterprise networks. Master’s thesis, Massachusetts Institute of

Technology, Cambridge, MA 02139, May 2002.

[29] The UCCNet Homepage.

[30] Oasis uddi.

[31] Stephen August Weis. Security and privacy in radio-frequency identification

devices. Master’s thesis, Massachusetts Institute of Technology, Cambridge, MA

02139, May 2003.

March 1, 2005 DRAFT Id: algolang.tex,v 1.5 2005/01/13 02:16:40 foley Exp

Documents

Object Name System Privacy and Security Joseph Timothy Foleyweb.mit.edu/foley/Public/Committee/dissertation.pdf · 5 Acknowledgments Many thanks go to my Thesis Advisor Sanjay Sarma