A Thesis for the Degree of Doctor of Philosophy

Design of Secure Mutual-Authentication

protocols for RFID and Dynamic Hybrid
Routing protocol for MANET

By

Batbold Toiruul

Advisor prof. KyungOh Lee

February 2009

Department of Computer Science

Graduate School
Sun Moon University, South Korea
 Design of Secure Mutual-Authentication
protocols for RFID and Dynamic Hybrid
Routing protocol for MANET

Presented as a Thesis for the Degree of Doctor of Philosophy

February 2009

By

Batbold Toiruul

Department of Computer Science

Graduate School
Sun Moon University, South Korea
 Approved as a Qualified Thesis of Batbold Toiruul for
The Degree of Doctor of Philosophy

Prof. (head of committee): 임기욱 (sign)

Prof. (examiner 2): 권진백 (sign)

Prof. (examiner 3): 신현철 (sign)

Prof. (examiner 4): 박근덕 (sign)

Prof. (advisor): 이경오 (sign)

February 2009

The Graduate School of Sun Moon University

 Abstract

Design of Secure Mutual-Authentication protocols for RFID and

Dynamic Hybrid Routing protocol for MANET

Batbold Toiruul

Department of Computer Science

Graduate School of Computer Science
Sun Moon University

Advisor: Prof. Kyung Oh Lee

This thesis is divided into two distinct parts. The first part of the thesis
concerned design of secure RFID protocols.

The advantage of using RFID technology is growing tremendously and is

gaining much attention as is seen by an increase in its deployment, such as object
tracking and monitoring, supply-chain management, and personalized
information services. However, this pervasive use of RFID tags opens up the
possibility for various attacks violating user privacy.

We proposed 2 secure RFID protocols in this area. First, we are proposing an

advanced mutual-authentication protocol between a tag and the back-end
database server for a RFID system to ensure system security integrity. The three

i
main areas of security violations in RFID systems are forgery of the tags,
unwanted tracking of the tags, and unauthorized access to a tag’s memory. Our
proposed system protects against these three areas of security violations. Our
advanced mutual-authentication protocol uses an AES algorithm as its
cryptograph primitive. Since our AES algorithm has a relatively low cost, is fast,
and only requires simple hardware, our proposed approach is feasible for use in
RFID systems. In addition, the relatively low computational cost of our proposed
algorithm compared to those currently used to implement similar levels of
system security makes our proposed system especially suitable for RFID systems
that have a large number of tags.

Second RFID security protocol describes simple, inexpensive, and untraceable

mutual identification protocols based on modular exponentiation for RFID tags.
We analyzed with issues of the security and privacy of RFID systems. This work
also showed the 8-bit architecture of a low-power and low die-size
implementation of modular exponentiation. The 8-bit modular exponentiation
implementation has a chip area of less than 1 K gates and the encryption of 64
bits requires about 1000 clock cycles. The executing time of the proposed
protocol would range from 12.36 ms to 20.6 ms, with 6–8 tags authenticated per
second.

The second part of the thesis concerned design of mobile ad-hoc routing
protocol. In this paper, we propose new protocol called Dynamic Hybrid Routing
protocol (DHRP) for MANETs. By adopting ZRP, we can transfer message into
very large zone with only a little increase of maintenance cost, but its network
organization is constructed same as clustering. However, its zone center node has
not responsibility to transfer messages through network as much like head node
of clustering protocols. In this proposed protocol the nodes can be classified into

ii
3 types: center node, border node, and normal node. By using three types zone,
the proposed protocol can reach the radius of zone to 3-5 hops while
maintenance cost a little bit higher than ZRP with the radius is only 2 hops. Our
zone maintenance approach has shown that our protocol is much more efficient
than ZRP and clustering protocols. In worst case of DHRP, route finding process
is same as ZRP with R=2 hops, but maintenance cost can be lower than as in
ZRP (in case of all center nodes moved out). Also, each node has its own
depends on their ID-numbers, so our protocol network zone is dynamic.

iii
 Acknowledgments

My sincere thanks go to my supervisor, Kyung Oh Lee, whose dedication has

been outstanding, and who has given generously of his time to guide and
encourage me in my work over the last 4 years. His invaluable comments,
constructive criticism and unwavering support have been crucial in helping me to
achieve my goals and develop as a researcher.
I would like to express my deepest gratitude to ITRC center at the Sun Moon
University, whose generous financial support has enabled me to pursue my
studies. This research was supported by the Ministry of Information and
Communication (MIC), Korea, under the Information Technology Research
Center (ITRC) support program supervised by the Institute of Information
Technology Assessment (IITA-2005-C1090-0502-0031).
I would like to thank my all junior and senior lab members, and all dear
professors in the Computer Science Departments for the support and knowledge I
received.

I would also like to thank my family, parents and friends, near and far, for all
their encouragement over the last 4 years. I have finished studying - at last!

Finally, I want to thank my beloved wife, Enkhchimeg and son Temuge. My

wife has been fantastic in every way, and I couldn’t have done this without her
constant love and support.

This thesis dedicated to my parents, Toiruul and Altanbayar.

iv
 Table of Contents

Abstract..................................................................................................................i
Acknowledgments ...............................................................................................iv
Table of Contents..................................................................................................v
List of Tables........................................................................................................ix
List of Figures........................................................................................................x
List of Acronyms..................................................................................................xi
Chapter 1...............................................................................................................1
Introduction...........................................................................................................1
1.1 Background and Motivation.......................................................................1
1.2 Thesis Structure..........................................................................................4
RFID Secure Protocols..........................................................................................6
Chapter 2...............................................................................................................7
RFID Technology..................................................................................................7
a. Introduction to RFID.....................................................................................7
2.2 Daily Life Examples...................................................................................8
2.2.1 Supply Chain..........................................................................................8
2.2.2 Tags in Libraries....................................................................................9
2.2.3 Subdermal Tags......................................................................................9
2.2.4 Access Control.....................................................................................10
2.3 RFID Architecture....................................................................................11
Reader and Back-end infrastructure ............................................................11
2.4 Tag Characteristics...................................................................................12
2.4.1 Power....................................................................................................12
2.4.2 Communication Range.........................................................................13

v
 2.4.3 Memory................................................................................................13
2.4.4 Computation Capabilities ....................................................................14
2.4.5 Frequency Band ..................................................................................14
2.4.6 Standards .............................................................................................15
2.4.7 Coupling and Data Transfer ................................................................17
2.5 Identification and Authentication protocols.............................................18
2.5.1 Coupling and Data Transfer.................................................................18
2.5.2 Protocols...............................................................................................21
Chapter 3.............................................................................................................23
Security and Privacy............................................................................................23
3.1 Introduction...............................................................................................23
3.1.1 Attack Objective ..................................................................................24
3.1.2 Security Requirements ........................................................................25
3.2 Security Threads.......................................................................................26
3.2.1 Eavesdropping......................................................................................26
3.2.2 Impersonation and Relay Attack..........................................................28
3.2.3 Traceability..........................................................................................29
3.2.4 Virus Attacking....................................................................................31
3.2.5 Some Techniques for RFID security....................................................32
3.2.6 Classic Cryptographic..........................................................................34
3.3 Security Protocols.....................................................................................35
3.3.1 Hash Lock Scheme...............................................................................35
3.3.2 Randomized Hash Lock Scheme.........................................................35
3.3.3 A RFID security approach for a supply chain system..........................36
3.3.4 Cryptographic approach to “privacy-friendly” tags.............................36
3.3.5 Strong Authentication for RFID system using the AES .....................37

vi
 3.3.6 Mutual-authentication protocols .........................................................38
Chapter 4.............................................................................................................40
Proposed Protocols..............................................................................................40
4.1 Advanced Mutual-Authentication Algorithm using AES ........................40
4.1.1 Assumptions and Attacking model .....................................................40
4.1.2 Security Requirements ........................................................................41
4.1.3 Protocol Design ...................................................................................42
4.1.4 Analysis ...............................................................................................45
4.1.5 RFID Tag Architecture .......................................................................48
4.1.6 Conclusions .........................................................................................50
4.2 SLAP protocol..........................................................................................51
4.2.1 Assumption .........................................................................................52
4.2.2 Protocol Design ...................................................................................52
4.2.3 Implementation ...................................................................................58
4.2.4 Evaluation ...........................................................................................62
4.2.5 Conclusions .........................................................................................66
MANET protocol.................................................................................................68
Chapter 5.............................................................................................................69
Mobile Ad-hoc Network......................................................................................69
5.1 Introduction to MANET...........................................................................69
5.1.1 Features of MANET ............................................................................70
5.1.2 MANET Applications .........................................................................72
5.2 MANET Routing Protocols......................................................................74
5.2.1 Zone Routing Protocol (ZRP)..............................................................77
Chapter 6.............................................................................................................82
Dynamic Hybrid Routing Protocol......................................................................82

vii
 6.1 Architecture..............................................................................................82
6.2 Node Identification Process (NIP)............................................................83
6.2.1 Example................................................................................................86
6.3 Routing Process........................................................................................90
6.4 Zone Maintenance.....................................................................................92
6.5 Implementation.........................................................................................94
6.5.1 Install ZRP.........................................................................................102
6.6 Performance evaluation .........................................................................106
6.6.1 Simulation environment and performance criteria.............................106
6.6.2 Performance comparisons .................................................................106
6.7 Conclusions.............................................................................................110
References.........................................................................................................112

viii
 List of Tables

Table 2.1 Main frequency ranges.........................................................................15

Table 2.2 Few examples of commercial RFID tags.............................................17

ix
 List of Figures

Figure 2.1. RFID System......................................................................................11

Figure 2.2. Inductively coupled systems..............................................................18
Figure 2.3. Backscatter coupling..........................................................................18
Figure 2.4. Basic identification protocol..............................................................21
Figure 2.5. Basic Authentication protocol............................................................22

x
 List of Acronyms

RFID Radio Frequency Identification

DoS Denial of Service
AES Advanced Encryption Standard
SLAP Secure but Light Authentication protocol
ME Modular Exponentation
RSA Algorithm of public cryptographic
DSA Digital Signature Algorithm
RF Radio Frequency
LF Low Frequency
HF High Frequency
UHF Ultra High Frequency
EPC Electronic Product Code
ISO International Organization for Standardization
MIT Massachusetts Institute of Technology
NTT Nippon Telegraph and Telephone
ART Authentication for long-range RFID Technology
RNG Random Number Generator
MM Montgomery Multipliers
PAN Personal Area Network
IARP IntrA-zone Routing Protocol
IERP IntEr-zone Routing Protocol
BRP Bordercast Resolution Protocol
NDP Neighbor Discovery Protocol
MAC Media Access Control

xi
 Chapter 1

Introduction
1.1 Background and Motivation

This thesis is divided into two distinct parts. The first part of the thesis
concerned design of secure RFID protocols. Radio-frequency identification
(RFID) is an emerging technology. It is a method of remotely storing and
retrieving data using by RFID tags. Every passive RFID tag has a unique
identification number, so we can identify each product by using this unique
code in RFID system.

However, RFID tags may pose a considerable security and privacy risk to
organizations and individuals using them. Since a typical tag answers its ID to
any reader and the replied ID is always the same, an attacker can easily copy
the system by reading out the data of a tag and duplicating it to bogus tags.
Unprotected tags may have vulnerabilities to eavesdropping, location privacy,
spoofing, or denial of service (DoS). Even when the content of the tags is
protected, individuals may be tracked through predictable tag responses. Even
though many cryptographic primitives can be used to remove these
vulnerabilities, they cannot be applied to a RFID system due to the prohibitive
cost of including protection for each and every RFID tag. Because of this
economic constraints, power consumption, processing time, storage, and gate
count are all severely limited.

In this thesis, we propose 2 secure RFID mutual-authentication protocols.

First mutual authentication protocol uses AES (Advanced Encryption

1
Standard) for the security of a RFID system. In November 2001, NIST
announced that the AES algorithm, based on the Rijndael algorithm, was the
new encryption standard [1], [2]. We chose the AES as our cryptographic
primitive because it is standardized and considered to be secure.

Second, we propose a protocol named SLAP (a Secure but Light

Authentication Protocol) which is a lightweight mutual-authentication protocol
based on modular exponentiation for protecting consumer privacy. Our
protocol meets the consumer privacy protection requirements for tag bearers; it
is untraceable, confidential, anonymous, and has cryptographic integrity. The
proposed protocol is based on modular exponentiation which is one-way
function and it is easy to compute, but its inversion requires the solution of the
discrete logarithm problem. Also, modular exponentiation (ME) is used in
several public-key cryptosystems, e.g., RSA, digital signature algorithm
(DSA), the Diffie–Hellman key exchange protocol, and secure remote
password protocol [3].

The second part of thesis concerned MANET routing protocols. A mobile ad

hoc network (often referred to as MANET) consists of number of mobile
devices that come together to form network as needed, without any support
from any existing Internet infrastructure or any kind of fixed stations.
Formally, a MANET can be defined as an autonomous system of nodes
connected by wireless links. In MANET, network topology may change
dynamically in an unpredictable manner since nodes are free to move and each
node has limited transmitting power, restricting access to the nodes only in the
neighboring range. Networking mechanisms such as routing protocols require
high efficiency because of limited resources in a mobile node.

2
 Routing in MANET depends on many factors, including modeling of the
topology, selection of routers, initiation of a route request, and specific
underlying characteristics that could serve as heuristics in finding the path
efficiently [4]. Existing routing protocols for MANET can be classified into
three categories according to different design philosophies [5] [6]: proactive
protocols, reactive protocols and hybrid protocols.

Proactive protocols attempt to evaluate continuously the routes within the

network, so that when a packet needs to be forwarded, the route is already
known and can be immediately used. Proactive protocols continuously use a
large portion of the network capacity to keep the routing information current.
Since the nodes in MANET move fast and the changes may be more frequent
than the route requests, most of this routing information is never used [4][7].
This is waste of the wireless network capacity.

In contrast to proactive protocol, reactive routing protocols invoke route

determination procedure only on demand. Thus, when a route is needed, some
sort of global search procedure is initiated for finding route to destination. So,
the delay time to determine a route can be significant. Furthermore, the global
flood-search procedure of the reactive protocols incurs significant control
traffic [8]. Therefore, both pure reactive and proactive routing protocols are not
appropriate for the MANET environment.

Hybrid protocols attempt to take advantage of best of reactive and proactive

schemes. The main idea behind such protocols is to initiate route-discovery on
demand operation but at a limited search cost within a small domain to reduce
maintenance overhead.

3
 Our proposed protocol is hybrid routing protocol and it is called Dynamic
Hybrid Routing Protocol (DHRP). By adopting ZRP, we can transfer message
into very large zone with only a little increase of maintenance cost. In the worst
case of DHRP, route finding process of our routing is almost same as ZRP with
R=2 hops, however, maintenance overhead of the network can be lower than as
in ZRP. In the DHRP, we propose Node Identification Process (NIP) to
identify the nodes based on their unique ID numbers. Most of previous
protocols assume each node knows about its neighbors. The advantage of using
NIP is to identify each node type, neighbors and range in the time of
discovering its neighbors. Each node has its own zone depends on their ID-
numbers, so the proposed protocol’s network zone is dynamic. The DHRP is
proposed for large ad-hoc networks same as ZRP.

1.2 Thesis Structure

The content of the thesis is organized as follows.

In Chapter 2, we provide a thorough introduction to the RFID technology.

We present daily life examples; we describe the RFID system’s architecture
and the tag’s characteristics. Then, we discuss the differences between the
notions of identification and authentication.

In Chapter 3, we introduce problems related to security and privacy that

threaten RFID. We also present some attack objects which are discussed in our
paper. We discuss eavesdropping, man-in-the-middle attack, traceability and
some mechanic techniques. Also, we show about classic cryptographic. At last
we discuss some related works to our proposed protocols.

4
 In Chapter 4, in particular we describe our proposed protocols. First we
describe first proposed protocol named “Advanced Mutual Authentication
Algorithm using the AES for RFID system”. Second we describe second
proposed protocol named “SLAP – a Secure but Light Authentication Protocol
for RFID based on Modular Exponentiation”.

In Chapter 5, we introduce introduction of Mobile Ad-Hoc Networks

(MANET). We show short introduction of MANET, features of MANET, and
some MANET applications. Also, in this chapter, we discuss general concept
of MANET routing protocols. At last we give short introduce of Zone Routing
Protocol (ZRP) which is related to our proposed protocol.

In Chapter 6, we describe our proposed protocol named “DHRP: Dynamic

Hybrid Routing Protocol for Large Ad-hoc Networks”.

5
 Part I

RFID Secure Protocols

6
 Chapter 2

RFID Technology
a. Introduction to RFID

Radio frequency identification (RFID) is a method of remotely storing and

retrieving data using by RFID tags. Examples of data may include
identification, location information or details about the tagged object such as
price, color, date of purchase, and so on. Every passive RFID tag has a unique
identification number, so we can identify each product by using this unique
code in RFID system. RFID has many benefits to consumers. It is expected to
have the biggest impact in the supply chain, where it will cut costs, cut
inventories, and reduce the problem of out-of-stock items. Also, some benefits
are minor, such as creating smart appliances that can read a tag to learn how to
cook a frozen pizza or wash a cashmere sweater; others are potentially more
important.

RFID technology is rapidly finding more diversified applications in today’s

marketplace. For example, RFID technology is now being used for automatic
tariff payment in public transport, animal identification and tracking,
automated manufacturing, and logistical control for automatic object
identification since every object can be identified by a unique identification tag
number.

RFID tags only offer weak computation and storage capacities. They are
passive, that is to say, they do not have their own battery, but take their power
from the reader’s electromagnetic field, which in turn implies that their

7
communication distance is relatively short, i.e., a few meters in the best case.
When they are outside the reader’s field, the electronic tags are inert, incapable
of carrying out any sort of calculation or communication. However, their low
cost, expecting to reach 5 Euro cents each in the near future, and their small
size, sometimes less than a square millimeter, gives them undeniable
advantages that could be exploited in innumerable domains. Since they are so
discreet, bearers may not even be aware they are holding any. This opens new
security challenges.

The first part of this dissertation focuses on this kind of RFID technology. In
this chapter, we give an overview of the (powerless) RFID technology, thus
supplying knowledge that will be required in the following chapters, when the
security and cryptographic aspects will be tackled. First of all, we give a few
examples of daily life applications where RFID is involved.

2.2 Daily Life Examples

2.2.1 Supply Chain

Radio frequency identification represents a major step forward in relation to
optical identification found on barcodes. In addition to the tags miniaturization
that allows them to be placed right in the heart of objects, they can be scanned
in large numbers, without having to place the object in the reader’s optical
beam. Let us note that each one possesses a unique identifier: whereas a
barcode represents a group of objects, an electronic tag represents a single
object. Management of stock and inventories in shops and warehouses is a
prime domain for low cost tags. The American mass marketing giant Wal-Mart
has recently begun requiring its main suppliers to put electronic tags in the
pallets and packing cases that they deliver to it. The American Department of

8
Defense has gone down the same route. Migros, leading figurehead in the
Swiss market, would like to put an electronic tag in every product, thus making
it possible to carry out real-time inventories using readers placed along the
shelves and showing customers the contents of their trolley electronically. This
would also allow a reduction in queues at the checkout, by replacing the
charming cashier with an automatic device. However, shoppers will not be able
to enjoy the fruits of this experiment for several years.

2.2.2 Tags in Libraries

The advantages of electronic tags can also be seen in libraries. Inserting a
tag in each volume makes borrowing and returning books easier, because the
user can carry out these operations himself. Better still, they can be completely
automated by using readers on the exit gates. Besides the advantages that the
library users can get from the system, the library staffs see their job made
easier; inventories can be carried out without taking books from the shelves, by
automatically detecting missing or misfiled books, or even by using an
automatic sorter for the returned volumes. Libraries such as K.U. Leuven
(Belgium), Santa Clara (United States), Heiloo (The Netherlands), or
Richmond Hill (Canada) already use this technology. According to the Swiss
company “Bibliotheca RFID Library Systems AG” [9], specialist in this field,
more than 100 million documents have been tagged throughout the world.

2.2.3 Subdermal Tags

Domestic animals identification by RFID is already a part of our daily lives.
But subdermal tags are not only for animal use. A famous example is the
nightclub “Baja Beach Club” in Barcelona, which suggests to its regulars that
they have an electronic tag implanted as a means of identification. The tag is

9
linked to a personal electronic dossier which allows the customer to settle their
accounts and gain access to VIP areas. In Mexico, members of the Attorney
General’s Office have also been “tagged” with subdermal implants, which give
them access to sensitive areas and information. Injecting subdermal tags in
prisoners is maybe not such a distant future plan.

2.2.4 Access Control

Nowadays, access control applications are often based on wireless tokens,
e.g, cards or badges. The wireless property renders control easier: people do
not have to take out their token; controls are systematic, damages to readers
and in particular vandalism are reduced. Systematic controls force two people
accessing the restricted area at the same time, both to pass the check. Beyond
the primary goal of access control, the interest of systematic controls is to
determine, in real time, the people present within a given area. It can be for
safety reasons, e.g., when a building must be evacuated.

A particular example of access control can be found in the automobiles

domain. Early applications were keyless entry: the driver opens and closes the
car using a key fob that contains an active RFID tag. Passive entry systems
appeared recently, e.g., on Renault Laguna, Mercedes-Benz S-class, CL-class,
and Toyota Lexus LS430. The driver, who is carrying a passive RFID tag,
simply approaches the car and the door automatically unlocks itself. Still
further, today, many car keys have an RFID device integrated into them which
activates the fuel injection system, thus preventing the vehicle from starting if
the electronic tag is not present. The tag is activated when the key is inserted in
the starting device and receives a challenge from the reader. Sending a correct
response to this challenge is the condition to starting the vehicle. In some

10
cases, the (physical) ignition key is no longer required. The driver has just to
press a button “start” to ignite the car: the driver has an RFID tag embedded
into a card that can stay in his pocket.

2.3 RFID Architecture

As depicted in figure 2.1, a RFID system consists of three parts: the radio-
frequency (RF) tags, the RF readers, and the back-end infrastructure.

tag
reader tag
tag
tag

Back-end tag
infrastructure
Figure 2.1. RFID System

The back-end infrastructure has a database (denoted DB hereafter) that

contains tag identifiers and information concerning these tags. This database
associates records with the tag data collected by the readers. Tags are typically
composed of a microchip for storage and performing logical operations and a
coupling element such as an antenna coil for wireless communications.
Memory chips on the tags can be read-only, write-once/read-many, or fully
writable. Each memory chip holds a unique ID and other pertinent information
transmitted to the tag reader using a RF. The tag readers interrogate the tags
using a RF antenna and interact with the back-end infrastructure for more
functionality.

2.3.1 Reader and Back-end infrastructure

From the RFID systems security analysis point of view, either the reader is a
simple physical device and is not of significant importance, or the reader has

11
sensible data and we would have to secure both the reader and the
communication between the reader and the back-end infrastructure. For this
reason, the readers and back-end infrastructure are usually considered as a
single entity, called reader or system by convention. Hereafter, we will use
either reader or system when referring to the group that comprises the back-end
infrastructure and its corresponding readers.

Let us note that it could be advantageous to separate these two distinguished

entities. This would allow conceiving and analyzing protocols where the back-
end infrastructure forwards calculations or data to the physical readers.
Ensuring that the back-end infrastructure does not become the system’s
bottleneck is an important problem that will have to be dealt with in the future.

2.4 Tag Characteristics

2.4.1 Power
The power required to communicate and to carry out computations can be
either internal or external to the tags. Passive tags do not possess any internal
energy source. They obtain energy from the reader’s electromagnetic field.
There also exist semi-passive tags where a battery is used for internal
calculations. However, the energy required for transmission still comes from
the reader’s electromagnetic field. Lastly, there exist active tags, i.e., tags that
have a battery that is used for internal calculations and for transmission. Active
and semi-passive tags are more expensive than passive tags, are generally more
cumbersome, and have a limited lifetime. Hereafter, we only consider passive
tags.

12
 2.4.2 Communication Range
The communication range between the reader and the tag depends on
several parameters. It of course depends on the frequency used, but also on the
transmission power, that is standardized in Europe by the ETSI EN 300-330,
EN 300-220, EN 300-440, and EN 300-328 standards. Practically, the RFID
systems communication range using low frequency (LF) and high frequency
(HF) bands is a few decimeters, even centimeters, while systems using the ultra
high frequency (UHF) band can communicate up to several meters. The ranges
mentioned here are obviously the limits that one can practically observe using
standard material and respecting the regulations. However, it is important to
underline that using specific antennas and transmission powers above the legal
limits; we can largely surpass these limits. Lastly, let us highlight that the
ranges mentioned here correspond to the maximum distance between a reader
and a tag, but the information sent by a reader (forward channel) can be
captured at a distance far superior than that sent by a tag (backward channel).

2.4.3 Memory
All tags contain a minimum number of memory bits to store their identifier
(between 32 and 128 bits). Depending on the targeted application, tags can
have ROM, EEPROM, RAM or SRAM. The electronic anti-theft devices
(EAS, Electronic Article Surveillance) that can be found on many items,
require only one bit (enabled EAS / not enabled EAS). One may consider such
devices as RFID tags. However, they do not allow object identification, only its
detection. Thus we are inclined not to include them in our RFID terminology.

13
 2.4.4 Computation Capabilities

Once again, it is hard to establish a tag classification depending on their

computational capabilities. Certain tags have no computational capabilities and
thus only have a simple memory that can be remotely accessed. In this work,
such tags do not interest us since the cryptographic protocols to be
implemented between the tag and the reader are simply non-existent. Other
tags that have a simple design and thus are relatively inexpensive, can perform
certain XOR and AND operations. Next, we have more evolved tags that have
a few thousand logical gates and are thus capable of integrating a symmetric
encryption or a hash function. Lastly, we can think of much more evolved tags
that could use asymmetric cryptography. However, these types of tags cannot
be classified as “low cost” and thus do not follow the trend that focuses on tags
that cost a few Euro cents.

2.4.5 Frequency Band

There exist several frequency bands that can be used for RFID. The
frequency band choice depends on the targeted application as it significantly
influences the communication characteristics between the reader and the tag
(transfer rate, communication range, communication degradation across the
medium, etc.). It also depends on the regulations put in place for the region
where the system will be deployed since it should not interfere with other
systems such as the television, police mobile radio, marine, etc. Table 2.1
summarizes the four main frequency ranges used for RFID: 125–134 kHz (LF),
13.553–13.567 MHz (HF), 860– 960 MHz (UHF), and 2.4000–2.4835 GHz
(UHF). The other frequencies that are also used sometimes are 6.765–6.795
MHz, 7.400–8.800 MHz (used for EAS), 26.957–27.283 MHz, or 5.725–5.875
GHz.

14
 Table 2.1 Main frequency ranges

Frequency range Examples of applications

125–134 kHz (LF) Pet identification, car keylocks, livestock tracking
13.553–13.567 MHz (HF) Smart cards, library books, clothing identification
860–960 MHz (UHF) Supply chain tracking
2.4000–2.4835 GHz (UHF) Highway toll, vehicle fleet identification

Tags using frequencies 13.553–13.567 MHz and 860–960 MHz are

currently in the media’s spotlight for many reasons, among them their
adaptability to stock management. EPCGlobal has also focused its attention on
these frequencies. However, low frequency tags have experienced a remarkable
growth in terms of sales. Compared to the HF and UHF frequencies, with LF
frequencies, there is less heat loss in the water. Thus LF frequencies are often
preferred in biomedical applications.

Usually, higher the frequency, smaller is the antenna. However, this

reasoning is only valid for the UHF frequency band, where the communication
method used is backscatter coupling. In LF or HF bands, the communication
method used is charge modulation by inductive coupling. In this case, not only
do the sizes of the spirals play a role, but also the number of spirals. Thus a
trade-off between the two is required. Thus, a tag designed for the 135 kHz
frequency could be less cumbersome than a tag designed for the 2.45 GHz
frequency.

2.4.6 Standards

In the world of radio frequency identification, it is sometimes difficult not to

lose oneself in the constellation of standards, either published or in the process
of being elaborated. In this field, two main families stand out: ISO

15
(International Organization for Standardization [10]) standards and EPC
(Electronic Product Code [67]) standards.

In the ISO family, the key standards are 14443, 15693 and 18000, which
deal with the communication protocols between tags and readers. Procedures
have been published (ISO 10373 and 18047) to verify the conformity of a
device with these standards. Procedures for measuring the efficiency of a
device (ISO 18046) have also been standardized. Independent of the actual
technology, the data organization on a tag is described in standards 15961,
15962, 15963 and 19789. Finally, some standards are specific to a given
application, for example 17358 and 17363/7 for supply chains and 11785 for
animal identification.

The EPC standards were established by EPCGlobal, a non profit

organization made up of several companies and academics. Its aim is to
standardize and promote very low cost RFID technology, with the goal of
integrating it into supply chains. It is the Auto-ID Center, a research project
that took place in 1999 at MIT, which was split in 2003, that gave birth to
EPCGlobal and to Auto-ID Labs. Auto-ID Labs constitute a research center
spread over seven universities. EPCGlobal distinguishes several classes of tags
according to their function. Class 1 corresponds to the most simple tags, which
have only a unique identifier for the tag by default, a code that allows the
identification of the product to which it is attached and a function permitting
the definitive destruction of the tag. Class 2 offers more memory and allows
authentication functions to be carried out. Class 3 corresponds to semi-passive
tags and finally class 4 corresponds to active tags, which can potentially
communicate with each other. Today, only class 1 for ultra high frequency
(860-960 MHz) is standardized. Ratified in December 2004, this standard,

16
called “Class 1 Gen 2”, principally rests on the first generation specification of
class 1 and of class 0 (which has disappeared from the nomenclature). In June
2005, the ISO confirmed its wish to integrate the EPCGlobal Class 1 Gen 2
standard into its norm 18000-6. In order to illustrate the tags’ capacities, we
supply in Table 2.2 few examples of commercial RFID tags.

Table 2.2 Few examples of commercial RFID tags

Tag Distance Data rate Unique ID
Frequency
(model) (meters) (kbits/s) (bits)
Hitag 1 LF 1.5 4 32
Hitag S LF 2.0 8 32
ICode-1 SL1 HF 1.5 26.5 64
UCode EPC G2 UHF 7.0 640 32

2.4.7 Coupling and Data Transfer

To conclude this technical overview of the tag characteristics, we give a

rough approach of the electronic aspect of the communication between a reader
and a tag. There are two basic techniques for acquiring information from RFID
tags: inductive coupling and backscatter coupling. The former is used with
frequencies less than 400 MHz, in which case, the magnetic component of the
electromagnetic field is dominant. Backscatter coupling is used with higher
frequencies, where the electrical component of the electromagnetic field is the
dominant component.

In inductively coupled systems (see Figure 2.2), the reader’s antenna coil
generates an electromagnetic field that penetrates the antenna coil of the tag.
By induction, a voltage is generated, which is rectified thanks to the diode, and
supplied to the capacitor. When the capacitor is sufficiently loaded, the chip is
activated and it outputs a signal, e.g., its identifier. This signal activates and

17
deactivates a field effect transistor which modulates the signal returned to the
reader.

chip

Reader Transponder
Figure 2.2. Inductively coupled systems

In backscatter coupling systems (see Figure 2.3), a portion of the incoming

energy is reflected by the tag’s antenna and re-radiated outwards. In order to
transmit data, the signal outputted by the chip activates or deactivates a
transistor that modulates the energy reflected by the antenna.

chip

Reader Trans ponder

Figure 2.3. Backscatter coupling

2.5 Identification and Authentication protocols

2.5.1 Coupling and Data Transfer

A major issue when designing a protocol is defining its purpose. This issue,
as trivial as it may seem, does not have any immediate solution when we speak
of RFID. Determining if it is identification or an authentication protocol that is
required, and knowing what each term signifies remains a confusing issue and
has provoked several misunderstandings. We provide our opinion here.

18
 When we analyze RFID applications, it is possible to think of two large
application categories: those whose goal is to provide security to a system, and
those whose goal is to provide functionality, in other term users’ convenience,
without any security concerns. In the first category, we find applications such
as access control (badge to access a restricted area, car ignition key, etc.) or
prevention against counterfeits. In the second category, we find RFID being
used to improve supply chains, to facilitate location and stocking of books in
libraries, to localize people in amusement parks, to facilitate sorting of
recyclable material, to improve consumer services in shops, to count cattle, etc.
Clearly, the security aspect is not the driving force in this category.

However, let us note that sometimes, deployment of an application creates a

security problem that was previously non-existent. For example, using RFID
tags in place of barcodes in shops a priori does not pose any security problems
since an RFID tag is not less secure than a barcode (duplicable by a simple
photocopy). However, since we are always ambitious to go further and further,
removing the cashier poses a security problem. Indeed, there is no more
manual control and we would ask the RFID tag to do more than what was
expected of the barcodes, that is avoid counterfeits. This example can thus be
classified under the first category, the one that requires security.

To summarize, in the first category, the objective is to ensure the tag

authentication. In the second category, the objective is simply to obtain the
tag’s identity, without any proof being required. Below, in the RFID
framework, we define the concepts of authentication, mutual authentication,
and identification.

19
Definition 1 (authentication protocol). An authentication protocol allows a
reader to be convinced of the identity of a queried tag. Conversely, it can allow
a tag to be convinced of the identity of a querying reader. If both properties
are ensured, we speak of mutual authentication.

Definition 2 (identification protocol). An identification protocol allows a

reader to obtain the identity of a queried tag, but no proof is required.

To illustrate our identification concept, we provide an example that only

ensures identification but can be later on integrated in a solution that ensures
authentication. Thus, biometric authentication systems, for example those that
rely on fingerprint recognition, are currently more and more used in physical
access control. Such a system can be deployed for example, to control access to
a building. It is also possible to use such a solution conjointly with a token, for
example a smart card, in which the fingerprint of the person to be authenticated
would be stored. Another solution is to store in a centralized database system,
the fingerprints of all authorized personnel that can enter the building. In this
case, when a per-son presents himself, the system does not know his identity
and must perform an exhaustive search among all the stored fingerprints. If the
number of stored fingerprints is large, this process could take a few seconds
and forces the person to wait in front of the door.

To solve this problem, one solution is to use a token, not for storing the
fingerprint, but for storing the person’s identity. When inserting this token in
the reader, the system immediately identifies which fingerprint it must test,
thus avoiding the exhaustive search on all stored fingerprints. Using a
traditional smart card reader is not in the current trend. On one hand, such a
reader requires that the person take his smart card out of his pocket; on the

20
other hand managing such a large number of readers can be problematic at
times, not only due to breakdowns, but also due to vandalism. The solution
envisaged by certain companies is to use an RFID system whose only objective
is to provide to the biometric system, the identity of the person that presents
himself. Thus, in this case the tag has nothing to contribute to the security and
is only for convenience, it avoids waiting in front of the door while the system
performs its search.

2.5.2 Protocols
We have seen that both authentication and identification protocols are useful
in practice. Of course, authentication protocols also ensure identification, but it
seems obvious that identification protocols may be cheaper than authentication
protocols.

The basic identification protocol that is used in today’s applications (e.g.,

pet identification) is depicted in Figure 2.4. It consists in a request from the
reader to the tag and an answer from the tag to the reader, containing the
identifier ID of the tag. If the tag is a legitimate one, then the system’s database
also contains ID. This protocol is simple, sound, but it brings out privacy
issues.

System (ID) Tag (ID)

request

ID

Figure 2.4. Basic identification protocol

The basic authentication protocol that is used in today’s applications (e.g., car
ignition key) is depicted in Figure 2.5. It consists in a common challenge-

21
response protocol: the reader sends a nonce a to the tag and the latter answers
ID and F(ID, a) where F is a given function, e.g., an encryption function.

System (ID) Tag (ID)

a
pick a
ID, F(ID,a)

Figure 2.5. Basic Authentication protocol

Currently, even though RFID gains more amplitude, many people think that
we could do everything with low cost tags. The threat that lurks is misusing the
solutions for applications that require security, for example, using an
identification protocol for authentication purposes, just for reducing the tag
price. That is precisely what happened at the MIT, where Agrawal, Bhargava,
Chandrasekhar, Dahya, and Zamfirescu have shown that the new MIT ID
Cards that contain RFID tags only send their identifier “in clear” to
authenticate their owners. As Agrawal et al. said [11]: “If you are counting
cattle, the cattle are not going to impersonate each other; there is no need for
strong encryption. Members of the MIT population are not cattle; we need
strong encryption.”

22
 Chapter 3

Security and Privacy

3.1 Introduction
Like all growing technologies, radio frequency identification brings along
its share of security related problems. Threats in RFID systems can be
classified in two categories. The first category, which includes common
security threats, concerns those attacks that aim at wiping out the system’s
purpose. Such attacks can target to crash the system using, for example a denial
of service attack, but it can also be just to impersonate a given tag. The second
category is related to privacy: the problem is information leakage, as a tag may
reveal data about an object or a person (passport, ID-card, medical dossier,
etc.), and traceability. By “traceability” we mean an adversary is able to
recognize a tag that she has already seen, at another time or in another place. In
the near future, people will surely carry several tags on themselves, for
example in their clothes, shoes, or even on their keys, that will serve as a type
of digital fingerprint allowing themselves to be traced.

The defenders of RFID minimize the privacy problems while its detractors
amplify it. More concretely, some companies had to renounce this technology
after being boycotted by organizations that defend individuals’ liberty. This
shows that we need to seriously address this problem. Several palliative
solutions already exist but they involve so many constraints on the tag holders
that their use can be debated. Thus the solution lies in the conception of
identification or authentication protocols that do no threaten the tag holder’s
privacy. The problem is that finding such a protocol is far from being an easy
task, due to the weak resources available on tags.

23
 3.1.1 Attack Objective
The objectives of each attack can be very different. It is important to
identify the potential targets in order to understand all the possible attacks. The
target can be the complete system (i.e. disrupt the whole of a business sys-tem)
or only a section of the entire system (i.e. a particular item).

A great number of information systems focus solely on protecting the

transmitted data. However, when designing RFID systems, additional
objectives, such as tracking or data manipulation should be considered.
Imagine the following example in a store: an attacker modifies the tag content
of an item reducing its price from 100 to 9.90€. This leads to a huge loss for
the store. In this scenario, the data may be transmitted in a secure form and the
database has not been manipulated. However, fraud is carried out because part
of the system has been modified. Therefore, in order to make a system secure,
all of its components should be considered. Neglecting one component,
whatever the security level of the remaining components, could compromise
the security of the whole system.

The attack may be perpetrated to steal or reduce the price of a single item,
while other attacks could aim to prevent all sales at a store. An attacker may
introduce corrupt information in the database to render it inoperative. Some
attacks, such as the Faraday cage or active jamming, are inherent in the
wireless technology employed. Other attacks focus on eliminating physical
access control, and ignore the data. Some involve fraudulent border crossing,
identity stealing from legitimate e-passports, etc.

24
 3.1.2 Security Requirements
To protect user privacy, we consider the following requirement from a
cryptographic point of view.

Data confidentiality: Tag’s private information must be kept secure to

guarantee user privacy, and Tag’s information must be meaningless to any
unauthorized users even though it can be easily obtained through
eavesdropping by an attacker.

Tag anonymity: Although Tag’s data are encrypted; Tag’s unique

identification information can be exposed since the encrypted data are constant.
An attacker can identify each Tag by using its permanent encrypted data.
Therefore, it is important to make the information on Tag anonymous.

Data Integrity: If the memory of Tag is rewritable, forgery and data

modification will occur. Thus, the linkage between the authentication
information and Tag itself must be given in order to prevent a simple copy of
Tag. However, data loss will result from a DoS attack, power interruption,
message hijacking, etc. Thus, authentication information between Tag and
Back-end database must be delivered without any failure, and data recovery
must be provided.

Mutual authentication and reader authentication: In addition to access

control, the mutual authentication between Tag and Back-end database must be
provided as a measure of trust. By authenticating mutually, the replay attack
and the man-in-the-middle attack to both Tag and Reader is prevented.

25
3.2 Security Threads
In our opinion, the first paper which really opened the way to research
devoted to security and privacy in RFID systems is the one of Sarma, Weis,
and Engels [12]. Although informal, this paper lays down the security and
privacy issues in RFID. Since then, many papers have dealt with these issues.
A few reference papers are [13,14,15,16,17,18]. For further views on the risk
of using tags, we suggest the reader to have a look at some other papers, for
example [17,20,21,22,23]. We also suggest the reading of the master thesis of
Yang [24] and Hjorth [25], and the quite innovative master thesis of Weis [26].
Finally, several interesting books related to this topic have been published: [27]
that gives a thorough introduction to RFID; [28], which is more dedicated to
security and privacy; and [29] that focuses on privacy violation.

3.2.1 Eavesdropping
RFID technology operates through radio, so communication can be
surreptitiously overheard. In [19,24], the possible distances at which an
attacker can listen to the messages exchanged between a tag and a reader are
categorized (see Figure 3.1).

Readers tag

operating range
Backward Channel Eavesdropping Range

Malicious Scanning Range

Forward Channel Eavesdropping Range

Figure 3.1. Eavesdropping

26
 • Forward Channel Eavesdropping Range: In the reader-to-tag channel
(forward channel) the reader broadcasts a strong signal, allowing its
monitoring from a long distance.
• Backward Channel Eavesdropping Range: The signal transmitted in
the tag-to-reader (backward channel) is relatively weak, and may
only be monitored in close proximity to the tag.
• Operating Range: The read ranges are the operating read range using
sales-standard readers.
• Malicious Scanning Range An adversary may build his own reader
archiving longer read ranges, especially if regulations about radio
de-vices are not respected. A conversation between a reader and a
tag can be eavesdropped over a greater distance than is possible with
direct communication. For example, tags compliant to ISO 14443
have a reading distance of around 10 cm (using standard equipment).
How-ever, Kfir et al. showed that this distance can be increased to
55 cm employing a loop antenna and signal processing [30].

Eavesdropping is particular problematic for two reasons:

1. Feasibility: it can be accomplished from long distances.

2. Hard Detection: it is purely passive and does not imply any kind of
power signal emission.
Eavesdropping attacks are a serious threat mainly when sensitive
information is transmitted on the channel. To give an example, we consider the
use of RFID technology in payments cards (RFID credit cards) [31]. In an
eavesdropping attack, information exchanged between the credit card reader
and the RFID credit card is captured. Heydt-Banjamin et al. showed how this

27
attack can be carried out [32]. An antenna was located next to an off-the-shelf
RFID credit card reader. The radio signal picked up by the antenna was
processed to translate it into human readable form. In particular, the following
pieces of data were captured: cardholder name, complete credit card number,
credit card expiry date, credit card type, and finally information about software
version and supported communications proto-cols. As the above example
shows, eavesdropping attacks should therefore be considered and treated
seriously.

3.2.2 Impersonation and Relay Attack

Speaking of tags’ impersonation does not make sense when dealing with
identification proto-cols. Indeed, identification protocols do not require an
identity proof. However, being resistant to impersonation is one of the
requirements of authentication protocols, along with completeness:

1. Completeness: the reader always accepts the legitimate tag.

2. Impersonation: the probability is negligible that any adversary other
than the tag, carrying out the protocol playing the role of the tag, can
cause the legitimate reader to complete and accept the tag’s identity.
We emphasize that the theoretical properties given above are not sufficient
to ensure security in practice. Indeed, the fact that the tags can be queried
without the agreement of their carriers opens the way to so-called relay attacks.
It consists, for a pirate, of making the reader believe that the tag is present in its
electromagnetic field, while, in fact, it is not. For that, the adversary uses two
devices: one simulates the legitimate tag in the field of the reader while the
other one simulates a legitimate reader close to the tag (see Figure 3.2).

28
 reader fake tag fake reader tag

Figure 3.2. Impersonation and Relay attack

A relay attack can be passive, meaning that the adversary plays the role of
an extension cord as in the example above, or it can be active, enabling the
adversary to perform more sophisticated man-in-the-middle attacks.

3.2.3 Traceability
Electronic tags are not cut out to contain or transmit large quantities of
information. When a database is present in the system, the tag may only send a
simple identifier, which only people having access to the database can link up
to the corresponding object. However, even if an identifier does not allow
obtaining information about the object itself, it allows us to trace it, that is to
say, to recognize the object in different places and/or at different times. Thus
we can know when a person passed through a given place, for example to work
out his time of arrival or departure from his place of work. We could also piece
together, from several readers, the path taken by a person, for example in a
store or shopping mall.

Other technologies also permit the tracking of people, e.g., video

surveillance, GSM, Bluetooth. However, RFID tags permit everybody to track
people using low cost equipment. This is strengthened by the fact that tags
cannot be switched off, they can easily be hidden, their lifespan is not limited,
and analyzing the collected data can be efficiently automated.

29
 Advocates of this technology arduously refute the argument that electronic
tags put respect for privacy in peril. A maximum reading distance reduced to a
few decimeters is the principal defense argument. In the framework of mass
marketing, the physical or electronic destruction of the tags during their
passage through the checkout is also an approach envis-aged to make this
technology more acceptable. From the opposition’s point of view, the short
reading distance is not a relevant security argument. Indeed, by using a more
efficient antenna and a stronger power, it is possible to go beyond the
presupposed limit. Moreover, there are many cases where an adversary can get
close enough to her victim to read his electronic tags: on public transport,
waiting in line, etc. Finally, the last argument of any substance is that the trend
is not towards HF systems that have a short communication distance, but
towards UHF systems, where the communication distance is a few meters.

Many voices have spoken out through several boycott campaigns, aimed at
reversing the trend for omnipresent electronic tags in everyday life. CASPIAN
(Consumers Against Supermarket Privacy Invasion and Numbering), an
organization for the defense of individual liberties led by Albrecht, have called
for a moratorium on the use of electronic tags for individual items. Wal-Mart,
Procter & Gamble, Gillette and Tesco, who are not in favor of the moratorium,
have had to face particularly virulent boycott campaigns. In Germany, it is the
Metro group who has suffered such attacks at the hands of FoeBud, a militant
human rights organization. They issued a “Big Brother Award” to Metro for
their experimental shop in Rheinberg, where customers’ loyalty cards
unknowingly contained electronic tags.

Consequently, even if the majority of people are hardly worried about the
threat that RFID poses to privacy, the weight of organizations such as

30
CASPIAN and FoeBud is sufficiently great to slow down the deployment of
the RFID market. The problem of malicious traceability of individuals is thus
an aspect of RFID that has to be taken into account and treated seriously.

3.2.4 Virus Attacking

The RFID tag memory generally contains an unique identifier, but
additional data may be stored. This data size varies from a few bytes to several
kilobytes. The memory where this additional information is stored is
rewritable. The information sent by the tags is usually implicitly trusted by the
database, which implies some security threats [33, 34]:

1. Buffer Overflow: Buffer overflow is one of the most frequent sources

of security vulnerabilities in software. Programming languages, such
as C or C++, are not memory safe. In other words, the length of the
inputs is not checked. An attacker could introduce an input that is
deliberately longer, writing out of the buffer. As program control data
is often located in memory areas adjacent to data buffers, the buffer
overflow may lead the program to execute an arbitrary code. As a
great number of tags have severe storage limitations, resource rich tag
simulating devices could be utilized [35].

2. Code Insertion: An attacker might inject malicious code into an

application, using any script language (i.e. CGI, Java, Perl, etc.). RFID
tags with data written in a script language could perform an attack of
this kind. Imagine that the tags used for tracking baggage in the airport
contain the airport destination in its data field. Each time a tag is read,
the back-end system fires the query, “select * form location_table
where airport=<tag data>”. Imagine that an attacker stores in one piece

31
 of baggage “MAD;shutdown”. When this data is read, the database
will be shutdown and the baggage system will crash.

3. SQL Injection. SQL injection is a type of code insertion attack,

executing SQL code in the database that were not intended. The main
objectives of these attacks are the following: enumerate the database
structure, retrieve authorized data, make unauthorized modifications or
deletions, etc. RFID tags could contain data for a SQL injection at-
tack. Storage limitation is not a problem, as it is possible to do a lot of
harm with a very small amount of SQL commands. For example, the
SQL “drop table<tablename>” will delete a specified database table.

Summarizing, an RFID tag is an unsecured and untrusted data source. So the

information obtained from such devices should be analyzed until there is
sufficient evidence that the data is accurate. However, this is not a new
concept, as in all information systems the input data should be examined to
ensure that it will not cause problems.

3.2.5 Some Techniques for RFID security

The first technique that can be used to protect the tag’s holders is to kill the
tags. It is well-suited for example to supply chains: when the tag reaches the
end of the chain, e.g., during the shop checkout, it is killed. The technique is
effective but has several drawbacks: the management of the keys is complex in
case of keyed kill-command, the tag can no longer be used afterwards, and
there is no confirmation of successful disablement.

To avoid these drawbacks, Karjoth and Moskowitz [36] suggest the clipped
tags. These devices are tags whose antenna can be physically separated from

32
the chip. The bearer can carry out this operation by himself, and reactivation of
the tag can only be done intentionally.

A less radical method consists of preventing the tag from hearing the request
by enclosing it in a Faraday cage. This solution is only suitable for a few
precise applications, e.g., money wallets or passports, but is not for general
use: animal identification is an example of an application that could not benefit
from this technique. Future US passports including an RFID tag may contain a
thin radio shield in their cover, preventing the tags from being read when the
passports are closed.

The third technique consists of preventing the reader from understanding the
reply. The best illustration of this technique is surely the blocker tag [37,16]
that aims at preventing a reader from determining which tags are present in its
environment. Roughly speaking, the blocker tag relies on the tree walking
protocol and simulates the full spectrum of possible identifiers.

Another technical approach consists in requiring an optical contact with the

object prior to querying its tag remotely. Such an approach is very restrictive
but is suited to certain applications. It is an approach suggested by Juels and
Pappu [38] to protect banknotes. It is also the approach that may be used to
protect the privacy of the US passport bearers: the officer must swipe the
passport through an optical reader to get the key that gives access to the
electronic data inside the tag.

Finally, a rather different and complementary approach is that of Garfinkel,

who elaborates the so-called “RFID Bill of Rights” [39,40], which outlines the
fundamental rights of the tag’s bearers. Garfinkel claims:

33
 • The right to know whether products contain RFID tags.

• The right to have RFID tags removed or deactivated when they

purchase products.

• The right to use RFID-enabled services without RFID tags.

• The right to access an RFID tag’s stored data.

• The right to know when, where and why the tags are being read.
In the same vein, Albrecht proposed the “RFID Right to Know Act of
2003”, which requires that commodities containing RFID tags bear labels
stating that fact. Even though the methods presented here are efficient, they
have many constraints that render them inconvenient. Thus the objective is to
conceive tags querying protocols that protect the holders’ privacy without
imposing any constraints on them.

3.2.6 Classic Cryptographic

Rewritable Memory: In 2003, Kinoshita [41] proposed an anonymous-ID
scheme. The fundamental idea of his proposal is to store an anonymous ID,
E(ID), for each tag, so that an adversary cannot find out the real ID of the tag.
E may represent a public or a symmetric key encryption algorithm, or a random
value linked to the tag ID. In order to solve the tracking problem, the
anonymous ID stored in the tag must be renewed by re-encryption as
frequently as possible.

Symmetric Key Encryption: Feldhofer [14] proposed an authentication

mechanism based on a simple two-way challenge-response algorithm. The
main problem with this approach is that it requires AES to be implemented in
an RFID tag. In the next section the main block and stream ciphers suitable for
low-cost RFID systems are presented.

34
 Public Key Encryption: There are solutions that use public-key encryption,
based on the cryptographic principle of re-encryption. Readers interested in the
precise details can read Juels’s paper [38]. Two other interesting papers that
tackle the subject of re-encryption are [42] and [43]. Nowadays, other authors
have proposed the use of public cryptographic based on elliptic curve
cryptography.

3.3 Security Protocols

RFID security and privacy issues have been an active and continuing area of
research. We describe some of the related studies below.

3.3.1 Hash Lock Scheme

This scheme is developed by MIT [19]. In this scheme, each tag verifies the
reader as follows. The reader has a key (k) for each tag, and each tag holds the
result metaID, where metaID = hash (k) of a hash function. A tag receives a
request for ID access and sends a metaID in response. The reader sends a key
that is related to the metaID received from the tag. The tag then calculates the
hash function from the received key and checks whether the result of the hash
function corresponds to the metaID held in the tag. Only if both data sets agree
does the tag send its own ID to the reader. However, in this scheme, the
adversary can track the tag via the metaID. Furthermore, both the random key
and the tag ID is subject to eavesdropping by an attacker.

3.3.2 Randomized Hash Lock Scheme

Randomized hash lock scheme, developed by MIT [19]. This is an extension
of the hash lock scheme, and requires the tag to have a hash function and a
pseudorandom generator. Each tag calculates the hash function based on the

35
input from a pseudorandom generated r and id, i.e., c = hash (id, r). The tag
then sends c and r to the reader. The reader sends the data to the back-end
database. The back-end database calculates the hash function using the input as
the received r and id for each ID stored in the back-end database. The back-end
database then identifies the id that is related to the received c and sends the id
to the reader. The tag output changes with each access, so this scheme deters
tracking. However, the attacker can impersonate the tag to a legitimate reader.
Also the attacker can know the r and IDk because eavesdropping is possible.

3.3.3 A RFID security approach for a supply chain system

A RFID security approach for a supply chain system is developed by the
IBM China Research Lab [44]. This approach requires read-access control.
When a tag receives an inquiry from a reader, the tag will first create a random
number k, which it then transmits. After the random number k is received by
the reader, the reader sends k back to the backend database. The backend
database hashes (ReaderID || k) and sends out the hash value to the reader. The
reader then sends it to the tag. In the meantime, the tag also hashes (ReaderID ||
k). Then the tag compares the hash value calculated by the tag to that by the
reader. If they are equal, the reader passes the authentication and the tag can
then provide tag ID-related information. However, in this approach, an attacker
can eavesdrop on the Reader ID as no security is required for the tag to get the
reader ID. Therefore, an attacker can impersonate a reader to a tag.

3.3.4 Cryptographic approach to “privacy-friendly” tags

Cryptographic approach to “privacy-friendly” tags is developed by the NTT
lab [45]. The basic idea of Ohkubo et al. is to modify the identifier of the tag
each time it is queried by a reader so that the identifiers can be recognized only

36
by authorized parties. The tag refreshes its identifier autonomously using two
hash functions, G and H, as described below. Readers are (untrusted) devices
that do not have cryptographic functionalities but a hash function can be
embedded into the tags. Soon, this may well be a realistic assumption. Ohkubo
et al.’s scheme has a complexity of mn hash computations in a closed
environment (2 hash operations are carried out mn/2 times), and of 2 mn in an
open environment since the database computes all of the hash chains when
trying to identify a foreign tag. Thus, when the number of tags, n, or the
number of read operations, m, is large, the complexity becomes unmanageable
so this scheme is not scalable.

3.3.5 Strong Authentication for RFID system using the AES

Strong authentication for RFID systems using the AES algorithm is
developed by project ART [19]. The main theme of this paper is the
assumption that an AES is feasible for current RFID technology without major
additional costs. The ART project team selected AES as a cryptographic
primitive for symmetric authentication. They analyzed several architectural
possibilities for implementing AES-128 encryption functionality. The
implementation of the data path of an AES-128 encryption design has a current
consumption of 8.15 μA on a 0.35-μm CMOS process. It operates at a
frequency of 100 kHz and needs 1,016 clock cycles for encrypting a 128-bit
data block. The required hardware complexity is estimated to be 3,595 gate
equivalents (GEs).

This report uses unilateral authentication, which works as follows. There are
two partners, A and B. Both possess the same private key, K. B sends a random
number, r, to A. A encrypts the random number Ek(r) with the shared key K and

37
sends it back to B. B proofs the result and can verify the identity (in other
words, the possession of K) of A.

In this case, the man-in-the-middle-attack is possible. The attacker sends a

random number to a tag. Then the tag replies with the encrypted value of r to
the attacker. Therefore, it is possible for the attacker to obtain the shared k
value from many combinations of r and Ek(r). Then the attacker can
impersonate a legitimate reader to the tag or a legitimate tag to the reader.
Therefore, we need mutual authentication.

3.3.6 Mutual-authentication protocols

Although many primitive cryptographic systems remove security
vulnerabilities of RFID system, they cannot be applied to the RFID system
because the tags must be low cost, and power consumption, processing time,
storage, and gate count are all highly limited in the manufacturing process [26],
[46]. For these reasons, low-cost mutual authentication is needed. Many
mutual-authentication protocols for security problems have been proposed, but
all were found to be vulnerable to attack soon after their introduction. Yang
[47] proposed a low-cost mutual-authentication protocol, but the tag had hash
function. Because low-cost hash function is still not possible in a RFID, this
protocol is flawed. In addition, under Yang’s [47] proposed scheme; it would
be possible to track the tag. A similar protocol was proposed by Lee [48], but
the tag, which contained a hash function and a random number generator
(RNG), was also found vulnerable to tracking. The RNG is an expensive
operation for a RFID tag [50]. Pedro [49] proposed a reasonable LMAP
protocol, but it was also vulnerable to tracking because the tag responses are
continuous during an unsuccessful session. In addition, the most of the

38
proposed solutions [47, 48, 51] were based on the use of hash functions. The
proposed protocol is sufficiently robust against tracing and active attacks, such
as the man-in-the-middle attack and the replay attack, as well as against data
loss.

39
 Chapter 4

Proposed Protocols
4.1 Advanced Mutual-Authentication Algorithm using AES
We use the notations summarized in Table 4.1 to describe our protocol
throughout the remainder of this chapter.
Table 4.1: Notations

T RF tag, or transponder
R RF tag reader, or transceiver
B Back-end server, which has a database
k1 , k2 Random secret keys, shared between T and B
K Cryptographic key, shared between T and B
Unique identification number of T, shared
IDk
between T and B
Ek ( k1 ⊕ k 2 ) AES cipher text, using k1 , k2 , and k
Ek ( k1 ⊕ k 2 ⊕ IDk ) AES cipher text, using k1 , k2 , k, and IDk

Ek(k1, k2) The notated Ek ( k1 ⊕ k 2 )

Ek(ID) The notated Ek ( k1 ⊕ k 2 ⊕ IDk )

4.1.1 Assumptions and Attacking model

In our protocol, we assume that T has AES encryption cryptographic
hardware. In [52], since an AES encryption and decryption unit with a block
size of 128 bits can be implemented with only about 3.4 K-gates, our protocol
only requires a small gate size. Also, we assume that T only has its
authentication-related information, IDk, Also, T has a memory for keeping
values of IDk, k1, and k2 to process mutual authentication. We assumed that the
communication channel between R and B was secure.

To solve the security risks and privacy issues, the following attacking model
must be prevented [16,54,53,19]. However, in our protocol, we have not
considered a physical attack such as removing a RFID tag physically from a

40
product because it is hard to carry out in public view or on a wide scale without
detection. We consider the following attacks.

Man-in-the-middle attack: The attacker can impersonate a legitimate reader

and get the information from T, so he/she can then impersonate a legitimate T
responding to R. Thus, a legitimate R can easily be fooled into authenticating
an attacker before the next session.

Replay attack: The attacker can eavesdrop on the response message from T,
and retransmit the message to the legitimate R.
Forgery of tags: A simple copy of T’s information can be obtained through
eavesdropping by an attacker.
Unwanted tracking of customers: It is possible to track people’s movements,
social interactions, and financial transactions by correlating data from multiple
tag reader locations.

4.1.2 Security Requirements

To protect user privacy, we consider the following requirement from a

cryptographic point of view [26], [45].

Data confidentiality: T’s private information must be kept secure to

guarantee user privacy, and T’s information must be meaningless to any
unauthorized users even though it can be easily obtained through
eavesdropping by an attacker.

Tag anonymity: Although T’s data are encrypted; T’s unique identification
information can be exposed since the encrypted data are constant. An attacker

41
can identify each T by using its permanent encrypted data. Therefore, it is
important to make the information on T anonymous.

Data Integrity: If the memory of T is rewritable, forgery and data

modification will occur. Thus, the linkage between the authentication
information and T itself must be given in order to prevent a simple copy of T.
However, data loss will result from a DoS attack, power interruption, message
hijacking, etc. Thus, authentication information between T and B must be
delivered without any failure, and data recovery must be provided.

In addition, we had to consider and evaluate the following security feature

in the design of our RFID authentication protocol.

Mutual authentication and reader authentication: In addition to access

control, the mutual authentication between T and B must be provided as a
measure of trust. By authenticating mutually, the replay attack and the man-in-
the-middle attack to both T and B is prevented.

4.1.3 Protocol Design

Our overall protocol is shown in Fig. 4.1. The detailed procedures for each
step are described in the following:

4.1.3.1 Initial setup

Each T is given two fresh random secrets, k1, and k2, and a unique
identification, IDk. The database (D) of B also stores them as the shared secret.
In addition, D manages a record pair for each tag consisting of (IDk, TagID). T
has an AES-128 encryption circuit. If a reader requires a tag’s ID, the tag must
first authenticate the reader. After authentication, the reader can obtain the tag

42
ID by the tag’s response and reference to the database. In addition, both T and
B have a cipher key, k that is a 128-bit key.

4.1.3.2 Detailed description

In the following, we describe our proposed protocol according to the
sequence of message exchange. Also, we discuss the security goals that are
achieved during the execution of each protocol message.

Step 1 (Challenging): In this step, reader R usually applies a collision

protocol such as secure binary tree walking [16], an interleaved protocol [53],
or the standard protocol of ISO 18000-3 MODE [26] to singularize T out of
many. The Reader, R, receives Ek(k1,k2) from the back-end server, B. Then R
sends Ek(k1,k2 ) to the queried T. The cipher key k and random numbers k1 and
k2 are shared by B and T. Therefore, Ek(k1,k2) is used to authenticate the validity
of R.

Step 2 (Authentication of R): When queried, T generates E*k(k1,k2 ) and

verifies whether the received Ek(k1,k2) is valid by comparing Ek(k1,k2) with
E*k(k1,k2). If Ek(k1,k2)==E*k(k1,k2), T authenticates R. Then T generates
Ek ( k1 ⊕ k 2 ⊕ IDk ) , designated as Ek(ID), which is the encryption of the AES-128
cryptographic algorithm. T uses this as the identification information and sends
it to R.

Otherwise, R is not authenticated and T will keep silent. Therefore, being

tracked by an attacker is not possible when no authorized readers are nearby.
Cipher key k and random numbers k1 and k2 are shared only between T and R.
Therefore, T can detect an illegal R and discard the message. Consequently,

43
the man-in-the-middle attack by an illegitimate R and a passive eavesdropper
can be prevented.

If T has successfully authenticated R, T updates the shared secrets keys, k2

and k1 by exclusive-ors with Ek ( k1 ⊕ k 2 ) .

B R T
Ek (k 1 ⊕k 2 ) Ek (k 1 ⊕k 2 )
Verify:
EK(k1,k2) = = E*k(k1,k2)(abort if not )
Encrypt E k(k1,ID k,K2) send to R

Ek ( 1k⊕ k2 ⊕ IDk )
Ek ( 1k⊕ k2 ⊕ ID k )
Then: update k1, k2
Decrypt Ek () then obtain ID k
ID *k== ID k k1 ← k1 ⊕ E k (k 2 ⊕ k1 )
If true, get real TagID from DB k 2 ← k 2 ⊕ E k (k 2 ⊕ k1 )
Then: update k1, k2
k1 ← k1 ⊕ E k (k 2 ⊕ k1 )
k 2 ← k 2 ⊕ E k (k 2 ⊕ k1 )
secure insecure

Figure 4.1. Mutual Authentication protocol

Step 3 (Authentication of T): R simply forwards Ek(ID) to B. Within this

step, B authenticates T with Ek(ID). At first, B decrypts Ek(ID) using cipher key
k and random numbers k1 and k2 and obtains IDk. Then B verifies whether IDk is
valid by comparing the obtained IDk with ID*k. Random secrets, k1 and k2, and
the cipher key, k, are shared only between B and T. Therefore, B can detect an
illegal T and discards the message. Therefore, the man-in-the-middle attack by
an illegitimate T and a passive eavesdropper can be prevented. If T is
authenticated, B retrieves the records corresponding to IDk and gets the real
TagID.

44
 Even if EK (ID) is discovered through eavesdropping, the eavesdropper
cannot know the IDk value, since he/she does not know k1, k2, and the cipher
key k. Since B initially stores the unique identification, IDk, B can evaluate the
linkage between Ek(ID) and T itself in order to prevent forgery. Forgery can be
detected and prevented by B at this time.

At the same time, B can detect and prevent the man-in-the-middle attack
since IDk is used as the factor of the man-in-the-middle attack detection.
Similarly, the replay attack can also be detected and prevented simultaneously.

If B successfully finishes the authentication process, B generates Ek ( k1 ⊕ k 2 )

with its shared random secrets, k1 and k2. The database of B updates the shared

secrets keys, k1 and k2, by exclusive-ors with Ek ( k1 ⊕ k 2 ) . Then, mutual

authentication has finally succeeded.

4.1.4 Analysis

4.1.4.1 Security analysis

We have evaluated our protocol from a security requirement standpoint. Our
protocol guarantees a secure mutual authentication only with AES-128

encryption messages, Ek ( k1 ⊕ k 2 ) , Ek ( k1 ⊕ k 2 ⊕ IDk ) , and IDk, T does not store

user privacy information. Thus, data confidentiality of tag owners is guaranteed
and the user privacy on data is strongly protected. In every session, we use a
fresh random nonce as the keys between entities. These keys are randomized
and anonymous since they are updated for every read attempt. Thus, tag
anonymity is guaranteed and the location privacy of a tag owner is also not
compromised. Based on mutual authentication, our protocol guarantees the

45
data integrity between T and B. The forgery-resistance feature was realized by
exclusive-oring the unique authentication number, IDk, of T with the
authentication information. IDk is originally stored during the initial step.
Whenever T generates Ek(ID), it refers to IDk, so the linkage between IDk and T
itself can be determined. B keeps each tag's IDk initially and authenticates the
ownership of the authentication information for T. Table 4.2 shows the
comparison of the security requirements and the possible attacks.

The man-in-the-middle attack. Through the authentication steps 1 and 2, R

sends Ek ( k1 ⊕ k 2 ) to T and T sends Ek ( k1 ⊕ k 2 ⊕ IDk ) to B for preventing the man-

in-the-middle attack. B can verify IDk with the decryption of the AES-128
cryptographic value of Ek(ID) transmitted from T. The key freshness is also
guaranteed for each session. The replay attack for T and B is detected and
prohibited in step 3 for B and in step 2 for T.

Table 4.2: Comparison of the secure requirements

Protocol HLS[6] RHLS[6] Ref[2] Ref[8] Ref[1] Our scheme

User data confidentially x ∆ ∆ ∆ ∆ O
Tag anonymity x ∆ ∆ ∆ ∆ O
Mutual authentication ∆ ∆ ∆ ∆ ∆ O
Reader authentication x x x x x O
Man-in-the-middle attack ∆ ∆ x ∆ x O
Replay attack prevention ∆ ∆ x ∆ ∆ O
Forgery Resistance x x ∆ ∆ ∆ O
Tracking x x ∆ x x O
Notation: x – not satisfied; O – satisfied; ∆ - partially satisfied

Invulnerable to eavesdropping. In the process of authentication, even when

an attacker eavesdrops on the output of tag, Ek(k1,k2), it can not pretend to be an
authorized reader in the next authentication session since the random secrets, k1
and k2, are changed in every session. Also, the required Ek(k1,k2 ) value is an

46
AES algorithm cipher, and random secrets, k1 and k2, and cipher key k are
shared only between T and B. Since an AES-128 encryption is extremely
difficult to inverse, the tag IDk and random secrets, k1 and k2, are protected even
if the output is captured by an attacker. Therefore, it is invulnerable to
eavesdropping. In one word, our proposed approach is secure when any
communication between readers and tags are subjected to eavesdropping.

Prevent being tracked by adversary. Tags keep silent to attackers. They

only respond to authenticated readers. Furthermore, as explained above, it is
impossible for attackers to pretend to be an authenticated reader. Since no tag
output occurs, attackers are unable to track customers by the tag value that
existed as they checked out. The privacy of location and the secrecy of what
objects that the customers are carrying is protected.

4.1.4.2 Performance analysis

We analyzed the performance of our proposed scheme with respect to
computation and its anticollision mechanism.

Low computation load. When identifying a tag from N known tags, a reader
performs only two AES operations, while for other approaches of randomized
access control, at least N hash operations and N searches [44] are required. In
addition, the AES tag’s hardware has a relatively low cost and fast computation
time [55].

Since the computation load remains low even with an increasing number of
tags, our proposed approach is suitable for protecting RFID systems with a
large number of tags. This feature is very important for a supply chain. Each
part along a supply chain deploys numerous tags. In warehouses or retail

47
stores, thousands of products need to be tagged to accelerate the supply chain
process. Therefore, a secure RFID scheme that is suitable for a large number of
tags is a definite prerequisite for the implementation of a RFID supply chain
system.

Anticollision mechanism. The most important command is the anticollision

sequence, which is a command every tag must implement. Therefore, a reader
sends an initial inventory command. All tags in the environment make a
response that is the tag’s unique ID. If only one tag answers the request, the ID
can be retrieved by the reader and all subsequent commands can be addressed
using the ID that addresses one single tag. If two or more tags answer a
request, a collision occurs. This can be detected at the reader. The reader then
uses a modified inventory request in which it adds a part of the tag’s ID to the
request. Only tags that have this part of the ID are allowed to answer. Once the
ID of one tag is identified, the reader sends a “stay quiet” command to the tag
with the identified ID. This method is used as long as no more collisions occur
and all tags within the environment are identified. In our proposed approach,
we have suggested two anticollision mechanisms, namely the interleaved
protocol [53] and the binary-three algorithm [26].

4.1.5 RFID Tag Architecture

The RFID tag consists of the analog front-end; the controller for
implementing software requirements such as data coding, implementation of
the protocol commands, anticollision mechanisms, and error detection; the
EEPROM that stores k1, k2, IDk, and k; the key for cryptographic algorithms;
and the AES hardware module.

48
 We selected AES as the cryptographic primitive for our proposed approach.
One important criterion for selecting the AES algorithm was its structure
allowing efficient implementation in hardware. In addition, several previous
implementations of the AES have proven it to be low-cost and relatively fast.
The tag cost can be around $0.05 US and the die size is less than 0.25 mm 2.
Power consumption is about 10 µA [53], [55], [56].

Most hardware implementations of the AES algorithm have focused on

realizing a high data throughput. Recently, however, some attention has been
given to hardware implementations that were designed with hardware
efficiency in mind. Hardware efficiency can be increased by lower die sizes
and reduced power consumption. Some recent papers have been published that
focus on this issue [55,56,57,58].

Mangard et al. [57] presented a highly regular approach. It is comparable to

RFID requirements but requires a chip area of 8,500 gate equivalents while
having a higher data throughput of 70 Mbps. The AES hardware of Satoh et al.
[56] is a 32-bit architecture and has a hardware complexity of 5,400 gates and
reaches a throughout of 311 Mbps.

Feldhofer et al. [55] presented a silicon implementation of the AES

optimized for low die size that offers excellent power consumption
characteristics. The AES core of the manufactured chip has an area of 0.25
mm2 on a 0.35 mm CMOS technology, which is comparable in size to a grain
of sand. In terms of circuit complexity, the size equals 3,400 gate equivalents,
and the average power consumption can be lowered to <5 mW when operated
at 100 kHz and 1.5 V. Feldhofer et al. [55] implemented the AES algorithm as
an 8-bit architecture.

49
 Our protocol only uses the encryption circuit of AES. Therefore, our
protocol hardware requires less chip area and power consumption than
previous implementations. It also has several advantages as follows.

• It is an 8-bit implementation of the AES architecture [14], [55].

• We need only the encryption circuit of the MixColumns [55], [56], [58].
• The Rcon function is a constant value. It is implemented as two different
constant values in the encryption and the decryption processes. Only
circuitry to implement a constant value is required for the encryption
process [56].
• By using RAM as detailed in [55], we do not need a ShiftRows
transformation. The ShiftRows transformation can be implemented by an
appropriate addressing of the RAM or we can use an 8-bit register as the
ShiftRows [56].

4.1.6 Conclusions
This paper proposes an advanced mutual-authentication protocol for security
and privacy protection in RFID systems using an AES algorithm as a
cryptographic primitive. This protocol protects high-valued goods against
attackers. With mutual authentication, we can provide a proof for each entity of
a RFID system, and since this proof is based on an AES encryption, our
proposed protocol is sufficiently robust to withstand active attacks such as the
man-in-the-middle attack, the replay attack, the eavesdropping attack, and the
unwanted tracking of customers. Also, our protocols can easily meet current
data rate restrictions and are compliant with existing standards as well as
requirements concerning chip area and power consumption. In addition to
cipher k, our proposed protocol uses k1 and k2 for security. These secret random

50
numbers, k1 and k2, are changed in every session, so the attacker can not obtain
important data from a tag even if the tag’s outputs have been eavesdropped.

All authentication messages are randomized. In addition, each tag has its
own unique identification data, so user data privacy and location privacy are
guaranteed.

4.2 SLAP protocol

The proposed protocol – SLAP (a Secure but Light Authentication Protocol)
is based on modular exponentiation. Although many modular exponentiation
architecture have been proposed, none of the reported architectures meets the
requirements of an ME module for RFID tags regarding low die-size and low
power-consumption requirements [14, 59–64]. Only few paper focus on
hardware efficiency. Nadia et al. [60] presents and compares three different
prototypes for implementing the binary modular exponentiation. We choose
sequential architecture because sequential architecture has less hardware area
than the others. But Nadia et al. [60] use 128-bit systolic architecture of
Montgomery multiplier, and its hardware area and cost are not cheap enough to
RFID system, and also 128-bit architecture consumes too restrictive power to
RFID system. Alexandre et al. [63] proposed a scalable architecture of
Montgomery multiplication. They use Multiple Word Radix-2 Montgomery
Multiplication (MWR2MM) algorithm [63, 64]. But their implementation uses
too many memory and logic gates [63]. Therefore, we proposed new
architecture of 8-bit modular exponentiation for RFID system. This novel
approach for hardware implementation of ME is motivated by two reasons.
First, an 8-bit architecture has efficient hardware area. Second, 8-bit
architecture operations consume significantly less power than others.

51
 4.2.1 Assumption
Our scheme is based on modular exponentiation, and we assume that most
low-cost tags are passive, with communication initiated by readers; we also
supposed that both the backward and the forward channel can be listened to by
an attacker. The passive tags are vulnerable to compromise, and the contents of
a tag can be determined by the attacker once the tag is compromised.

Our protocol assumes that the tag has modular exponentiation hardware, and
the capability to maintain its state during a single session. The widely
acceptable, low-cost RFID tags likely require the use of passive tags [12, 19].
To design our proposed protocol, we assumed that the low-cost RFID tag is
passive and has a rewritable memory, such as EEPROM, and is of a reasonable
size, such as EPC Class 2 of EPC Global [26]. We also assumed that the
modular exponentiation unit with a 64-bit block size can be implemented with
only about 1 K gate. In Section 4.3.2.1, we describe the implementation of this
modular exponentiation hardware in a low-cost RFID tag. We assumed that T
uses the authentication-related information values of pid, sid, and eT to process
mutual authentication, and that we needed 402 bits of rewritable memory
(EEPROM), 8 bits of register four, and 3 bits of register one, in total. Other
required data of T for an application are stored in the database.

4.2.2 Protocol Design

Our key idea in the proposed protocol is shown in Figure 4.2. As illustrated
in Figure 4.2, 64 bits binary plain text is encrypted with modular
exponentiation, byte by byte. After successfully completing each session,
modulus M and exponentiation E must be updated with random number R.

52
Modulus M must be a prime number, so the encrypted value of the ith byte of
64-bit input value is almost never equal to zero.

0 ∙∙∙ 7
i = 0 to 7
∙∙∙ 8 bits
64 bits binary code

ME with E =3 bits and modulus M =8 bits

X Emod M
0 ∙∙∙ 7
i = 0 to 7
∙∙∙ 8 bits
64 bits encrypted code

Figure 4.2. Encryption scheme of the proposed approach

We can split our protocol proposal into three main stages: tag identification,
mutual authentication, and security keys updating. In this section, we outline
how the protocol works; in the section 4.2.4, we present a security and
performance analysis. The detailed procedures for each step are as follows:

4.2.2.1 Initialization phase

For each tag, the server initially stores six values in the tag: (1) sid, denoting
the unique session ID number of the tag; (2) pid, the partner ID number; (3) eT,
the exponentiation number; (4) n, the shift value (which will be updated); (5)
kj, the security key; and (6) a two-sided secure modular exponentiation:

* i eT
KT = (TT )i mod( pid )i (1)

where TTi = ( sid )i eT mod( pid )i is the tag-side secure modular exponentiation in

the ith session. The session key, the partner ID, and the private key eT will be
updated after each successful authentication. For each tag, the server also
maintains a record of seven values in its database: (1) sid, (2) pid, (3) eT; (4)

53
KR*, (5) kj, (6) n, and (7) DATA, which denote all other information about the
tagged object, including the real TagID. After initialization, the reader and the
tag can perform authentications, and the authentication between the tag and the
reader (R) is described as follows:

4.2.2.2 Authentication phase

Tag Identification: Before starting the protocol for mutual authentication,
the reader must identify the tag. The reader sends a random number r to the
tag, which answers by sending the exclusive-ors value, its current session id
number, sid, and jth shifted value kj with random number r. Using this value X,
only an authorized reader will be able to access the tag secret key partner ID,
pid, KR*, and the other security values necessary for the next authentication
stage. The j requires the reader to compute kj. The value of n can be selected by
the user from 1 to 63.

Reader Tag : r -random number

Tag : k j ← ShiftRight k( j -1,n ),X= sid
( ⊕ ) i⊕
r k j

Tag Reader : X, j
Reader : if (sid * ==sid ), take tag sid *from X
i i i

Figure 4.3. Tag Authentication

Mutual Authentication: We describe our mutual authentication process in

below. It basically consists of the exchange of two messages between the
reader and the tag. The protocol works as follows:

1) Reader authentication

The reader receives the modular exponentiation, KR*, from the database
(DB), then sends it to the tag. The tag verifies whether the received value KR* is
valid by comparing KR* with KT*. The tag stores KT* in the initialization phase.

54
If KR* and KT* are equal, the tag authenticates the reader. Then the tag generates
the tag-side secure modular exponentiation value, TTi, and sends it to the reader.
The tag also must execute the key-updating process, or the reader is not
authenticated and the tag will stay silent.

2) Tag authentication

The reader receives TTi and computes KRi in Equation (1). It verifies whether
the computed value KRi is valid by comparing KRi with the stored value KR*. If
they are equal, the reader authenticates the tag and the reader gets the tag
identification number, TagID, from the DB. The reader must then execute the
key-updating process; if it does not, the reader is not authenticated and the tag
will keep silent.

Reader Tag : K R*
Tag : if (K R == K T* ), Authenticated R to T
*

i
i e
then T T ←(sid ) i T mod ( pid ) i
Tag Reader : TTi
i i eiR * i
Reader : K R ← (T T ) mod ( pid) iif, (K R== K R )
Authenticated T to R
get TagID from DB

Figure 4.4. Mutual Authentication

Key Updating: The key-updating process is shown in below. After the

reader and the tag have been authenticated mutually, the key-updating stage
must be performed. We describe it in two sections:

1) Updating the tag keys

55
 After the reader is authenticated, the tag must update four values: sidi+1,
pidi+1, eTi+1, and KT*. These operations require a simple XOR operation, and its
use will not increase the gate counting. The proposed equations for the key
updating are the following:

i
(sid ) i +1 ← (sid ) i ⊕ r ⊕ TT (2)

i +1 i
eT ← eT ⊕ ( r0 + i r63−i r31+ i ) (3)

( pid ) ← Z ⊕ (r r r r r r r r r ) (4)
i +1 i 7 − i 15 + i 23 − i 31+ i 39 − i 47 + i 55 − i 63 − i

i+1
* i +1 e
KT ← (TR ) T mod ( pid ) i+1 . (5)

In Equation (3), the second parameter, (rir63-ir31+i), can be obtained from the
random number r, which has a length of 64 bits. The controller easily collect
ith, (63–i)th, (31+i)th bits’ values from r because eT is a 3-bit binary sequence
and the (rir63-ir31+i) can be a random number. Thus, these updates are easily
performed and fresh in every session. After receiving Z, pidi ,and TRi+1, the tag
checks pidi to determine whether the received values are correct. Z is a prime
number by exclusive-or with the same 8-bit random number in the server.
Therefore, we need to exclusive-or with same 8-bit random number as the
reader to obtain the prime number Z. Also the controller can collect the 8-bit
random number from r. After receiving TRi+1 from the reader, the tag computes
Equation (5) and replaces it with the ith sessions’ value KR* in its EEPROM.
The KR* is the encrypted value of the reader and it will be used to authenticate
the reader in the next session.

2) Reader key updating

56
 After the tag is authenticated, the reader must update the sidi+1, pidi+1, eTi+1,
eRi+1, n, and KR* values for the next session. For updating the pidi+1, the reader
selects the prime number Z and exclusive-ors it with an 8-bit random number
(4), and also computes TRi+1(6). The reader sends those two values to the tag.

i +1
TR
i +1 e
← ( sid )i +R1 mod ( pid )i +1 (6)

i +1 i +1
* i +1 ( eR )∗( eT )
K R ← ( sid R ) mod ( pid ) i+1 (7)

i +1
Tag : (sid ) i +1 ← (sid ) i ⊕ r ⊕T i ,e i
← e T⊕( r 0r+i 63r−i 31)+i
T T

Reader: get Z prime number then :

Z=Z ⊕ ( r r r r r r r r r )
i 7 − i 15 + i 23 − i 31+ i 39 − i 47 + i 55 − i 63 − i

i +1
i +1 eR
TR ← ( sid ) i +1
mod ( pid ) i+1
i +1
Reader Tag : pid i , Z, T R
Tag : if ( pidi == pidi )
( pid ) ← Z ⊕ (r r r r r r r r r )
i +1 i 7 − i 15 + i 23 − i 31 + i 39 − i 47 + i 55 − i 63 − i
i+1
* i + 1 eT
KT ← ( T R
) mod ( pid )i+1
*
then store KT for next session
( eiR+1 )∗( eTi+1 )
Reader: K R* ← ( sid i +1 ) mod ( pid ) i +1
R
*
then store K for next session
R

Figure 4.5. Key Updating process

The sidi+1, eTi+1, and KR* are updated from Equations (2), (3), and (7),
respectively. The eRi+1 is the reader’s random private key and it can be easily
selected by the reader. The KR* is the encrypted value of the reader and the
reader replaces it with the ith sessions’ old value, KR*, in the database. It will be
used as an authentication key in the next session.

57
 4.2.3 Implementation
The architecture of a security-enhanced RFID tag consists of four parts: the
analog front end, digital controller, EEPROM, and modular exponentiation
hardware. The analog front end is responsible for the power supply of the tag,
which is transmitted from the reader to the tag. The digital controller is a finite
state machine that handles communication with the reader, implements the
anticollision mechanism, and executes the commands in the protocol. It also
allows read-and-write access to the EEPROM and the modular exponentiation
hardware. The EEPROM stores pid, sid, e, KT, and other keys.

4.2.3.1 Modular Exponentiation Architecture

Our RFID security protocol is based on modular exponentiation. Modular
exponentiations are typically calculated using repeated square-and-multiply
algorithms with modular reductions in between. The most basic type of these
algorithms is the binary modular exponentiation, which has two variations,
right-to-left and left-to-right. For efficiency, memory requirements, and
simplicity, we chose the left-to-right binary exponentiation in this study. Three
different prototypes exist for implementing the left-to-right algorithm:
sequential, parallel, and systolic architecture [60]. We used sequential binary
modular exponentiation, which is suitable to a RFID system [60], [61] because
of its low cost. It includes two Montgomery multipliers, MM1 and MM2, and
uses 5 byte registers: one for each of T, M, E, R × R (SQUARE) and R × T
(MPRODUCT). Based on the length of E, the controller dictates the number of
iterations required to perform the exponentiation. E is stored in a shift register.
We assigned E to be a 3-bit integer; T would have a length of 64 bits and M an
8-bit length. However, our 8-bit modular exponentiation has to be produced
byte-by-byte, so our protocol is run by the byte-by-byte of T. Either the RAM

58
or the 64-bit shift register saves T’s value and sends its first byte to the modular
exponentiation. This iteration is run eight times until it processes the last byte
of T (Algorithm 1).

Algorithm 1: RFID security 8-bit ME

Input: T = 64 bits and byte-by-byte
Output: C = TE mod M
for j = 1 to 8, do
int Rj = 1;
if ek–1== 1, then Rj = Tj; // in our
case k = 4
for I = k-2 to 0 do
Rj = Rj * Rj mod M;
If ei= =1 then Rj = Rj *Tj
mod M;
C<- Rj

This iteration process can be monitored by the main RFID tag controller.
Because the exponentiation algorithm consists of repeated multiplications and
squarings, an efficient multiplication algorithm is required. Montgomery
multiplication (MM) [61] is a widely used method for performing combined
modular reductions and multiplications [65], [3], [62]. The 8-bit version of
MM utilized in this work is based on Figure 2. The Multiple Word Radix-2
Montgomery Multiplication (MWR2MM) algorithm with word length w
performs bit-level computations and produces word-level outputs [63], [64].
For operands with a k-bit precision, e = [k/w] words are required. The
MWR2MM algorithm scans the word-wise operand R (multiplicand) and M,
and the bit-wise operand X(multiplier). This decision enables us to obtain an
efficient hardware implementation. The details of the MWR2MM algorithm
are given in [63]. The MWR2MM algorithm computes a partial sum S for each
bit of X, scanning the words of Y and M. However, Y and M have values of 8

59
bits in our RFID security protocol, so the algorithm does not need to scan Y and

M (Fig. 4.6). The total computation time T (in clock cycles) when n ≤ pmax
modules are used in the pipeline is

 x + 1
T =
 n  (e + 1) − 1 + 2( n − 1) . (8)

8
Tj
8 bit control register
1

i −1
Rj 8
8 S0
8
Mj DP i −1 Control 8
S1 Switch Sj
8

8
8

Figure 4.6. Montgomery multiplier organization

Because e = [k/w], k = 8 bits, and word size w = 8 bits, the number of words,
e, equals 1, so we need only one data path (DP). The DP receives the inputs
i i
from the registers, and computes the next internal sums, S0 and S1 , in parallel.
When computing the bits of step i, the circuit generates w–1 bits of Si, and the
most significant bit of Si–1. The bits of Si–1 computed at step i–1 must be
delayed and concatenated with the most significant bit generated at step I [63].
Depending on the signal from the control register, the control switch
determines whether to switch to the final sum Sj or the internal sum S0 and S1. If
MM finishes processing all eight xi values, the controller switches to the final
sum Sj; otherwise it switches to internal sums.

60
 Table 4.3: Features of the proposed architectures with E=3

Sequential Parallel
Controller 60 120
MM 152*2 152*4
MUX*2 8 8
Total Logic Gates 372 736
Clock Cycles 816 412
Answer/second 122 244
Registers 5 8
EEPROM 402 bits 402 bits

We need 816 clock cycles to compute one modular exponentiation when

exponentiation eT = 3 and k = 64 bits, and the protocol needs to compute the
modular exponentiation at least twice. We can use the modular exponentiation
in parallel with the parallel version requiring half the encryption time.
However, the parallel version requires almost twice the circuitry as the serial
algorithm. Table 4.3 shows the features of the proposed architectures.

If the protocol runs a 64-bit modular exponentiation with m = 8 bits, we

need 816 clock cycles for serial architecture and 412 clock cycles for parallel
architecture. Therefore, if the clock frequency is set to 100 KHz, the tag
answers in 8.16 ms in the serial architecture, and 4.12 ms in the parallel. A tag
can authenticate the serial and parallel architecture 122 and 244 times per
second, respectively, so the temporary requirements are fulfilled in all of the
cases. Another important aspect to study is the number of logical gates that are
necessary to implement low-cost RFID protocol. Our protocol requires 372
logic gates in the serial configuration and 736 logic gates in parallel. In
addition, 20% of logic gates are needed for control functions. We compute the
clock cycle of MM using Equation (8).

61
 Finally, although we have not yet physically implemented the circuit, it is
known that the power consumption and circuit area are proportional to the
number of logical gates, so our implementation should be suitable even for
very low-cost RFID tags.

4.2.4 Evaluation
We will now evaluate the security and efficiency of the protocol.

4.2.4.1 Security Analysis

The most important security requirement for consumer privacy is that the
information not be traceable [66]. To be perfectly untraceable, protocols must
satisfy indistinguishable and forward security [45]. If the protocols satisfy
these conditions, total consumer privacy is provided because these two security
requirements contain other RFID security requirements, such as tag anonymity
and prevention of eavesdropping.

Modular Exponentiation Safety: Although no proof exists of modular

exponentiation, the protocol is a one-way function, and one-way functions are
widely believed to have modular exponentiation [3], [67]. The modular
exponentiation is easy to compute, but its inversion requires the solution of the
discrete logarithm problem in Zp* [3]:

• Exponentiation modulo p. Let p be a prime and let a be a generator of Zp*.

The function f(x): Zp* —› Zp* is defined as f(x) = ax mod p.

Therefore, modular exponentiation of long integers is required in several

public-key cryptosystems, e.g., RSA, digital signature algorithm (DSA), the
Diffie–Hellman key exchange protocol, and secure remote password protocol
[3]. In addition, Carolina J. Kudla, in [67], describes modular security proofs of

62
the many protocols that use modular exponentiation. Our proposed protocol
encrypts plain text to cipher code with private key eT, eR, and modulo pid using
byte by byte (Fig. 4.1). Therefore, our protocol’s primitive cryptographic is
very secure and one-way.

Attacks on Tag Identification: The sidi is a shared key and used as a tag
identification key. An adversary (A) may eavesdrop on the communication
between the reader and the tag. A can collect X, and j during each response of
the tag. Because X is randomized and j is meaningless to A, A cannot trace the

tag. The kj and sidi are shared keys and the X value is X = sid i ⊕ k j // r , so A
cannot distinguish sidi from the X random value. Furthermore, kj is rotationally

shifted by n bit in each response of the tag, k j ← ShiftRight ( k j -1 , n) , so A sees

sid i ⊕ k j as a random value. In addition, after each successful session, sidi, kj,
and the n values have to be updated. Thus, A cannot trace the tag at this stage.

Attacks on Mutual Authentication: KR* is a two-sided security key that

will be used to authenticate the reader tag, and TTi is a tag-side security key that
will be used to authenticate the reader tag. The proposed encryption scheme is
shown in Figure 4.1. This simple scheme helps encrypt sidi into the pseudo
modular exponentiation values KR* and TTi using their private keys eR and eT,
and the shared key partner ID, pidi. These two values may look like a random
code to A, who will not be able to distinguish pidi and the private keys eT and
eR. After each authentication process, eT, eR, and pidi must be updated, so the
KR* and TTi values are randomized and meaningless to A in every session. Also,
modular exponentiation is almost one way, so our protocol can satisfy forward
security. Therefore, A cannot trace the tag by eavesdropping at this stage.

63
 Attacks on Key Updating: Z is a random value and TRi+1 is a reader-side
security key, and also a random oracle. The reader computes TRi+1 after update
eR and pidi, and is a random oracle, so A cannot trace the tag using the output
value of the reader. In addition, A may try to perform a desynchronizing attack
by updating secret information in the tag. However, secret keys will be updated
after the reader is authenticated to the tag and A cannot know the value of pidi
because A does not know the bit-choosing process for pidi+1. Although A can
know pidi at update time, pidi will be not useful in the next session. Therefore,
A cannot succeed in this attack.

4.2.4.2 Efficiency Considerations

The proposed protocol uses modular exponentiation to encrypt 64-bit plain
text to a 64-bit cipher key using the 3-bit private keys, eR and eT, and the 8-bit
partner ID, pidi . In the tag identification stage, the 64 bits rotate the shift
register for kj, the 64-bit random value is r, j is 8 bits, and the shifter value, n, is
user-selectable (0 < n < 64 bits) and can be 63 bits; 136 bits of data are shifted
per reader. In the mutual authentication stage, the reader and tag exchange 128
bits of data per session. The tag requires 64 bits of memory for KR*, 64 bits for
the session’s unique identification number, 3 bits for the tag private key, eT, 8
bits for the pidi, and 64 bits for the tag side-security key, TTi. In total, the tag
requires 203 bits of memory for data, 8 bits for register four, and 3 bits for
register one, to execute the modular exponentiation. In the key updating stage,
the tag must update the security keys. These operations are managed by the
controller. The controller has to select random bits from the random value r to
refresh eT and pidi. In total, each tag then needs to store 402 bits of rewriteable
data and exchange 264 bits of data during the entire protocol.

64
 If the protocol runs a 64-bit modular exponentiation with m = 8 bits, we
require 816 clock cycles for serial architecture. The protocol requires twice the
amount of time, at a minimum, to compute the modular exponentiation in the
tag. However, we can run the modular exponentiation in parallel with the
parallel version using half the encryption time and 412 clock cycles for parallel
architecture. If the clock frequency is set to 100 KHz, the tag can execute the
modular exponentiation in 8.16 ms in the serial configuration, and 4.12 ms in
the parallel. In [68], the EPC code for encryption was in 64 bits, and the
performance of a 64-bit block cipher was tested with DES and Jigsaw
encryption algorithms to determine their speeds. The measurement of Jigsaw
encryption included the times for linear shifting and hashing. The results,
shown in Table 4.4, indicate the encryption time of different algorithms for
comparison. Modular exponentiation encryption with eT = 3 bits, pidi = 8 bits,
and sidi = 64 bits, in the parallel architecture, was faster than the Jigsaw and
DES encryptions. However, our proposed protocol uses at least double the time
for this encryption, so we computed that the executing time of our proposed
protocol would range from 12.36 ms to 20.6 ms, with 6–8 tags authenticated
per second.

Table 4.4: The time comparison of encryption

Cipher Time (ms)

DES in ECB encryption 82.65
Jigsaw encryption 15.75
ME with sequential architecture 8.16
ME with parallel architecture 4.12

65
 Table 4.5 shows a comparison of the security and efficiency our protocol to
those of other mutual authentication schemes. In the table, BO is a basic
operation and ME is modular exponentiation.

Table 4.5: The comparison of security and efficiency

Protocol [16] [11] [13] SLAP

Tag’s 3Has 3Hash
19BO 2ME
complexity h +4BO
Untraceable x ∆ ∆ O
Memory of 9 1
9L 9 L 6L 4 L
tag 2 2
Notation: x, not satisfied; O, satisfied; ∆, partially satisfied

4.2.5 Conclusions
We have proposed a low-cost but secure lightweight mutual authentication
protocol named SLAP based on modular exponentiation for protecting
consumer privacy threatened by the pervasive use of RFID tags. Our protocol
has three stages; 1) tag identification 2) mutual authentication 3) key updating.
In each stage, our protocol uses fresh random variables to produce modular
exponentiation. Modular exponentiation is one-way, and it is easy to compute,
but its inversion requires the solution of the discrete logarithm problem. This
makes our SLAP protocol easy to implement but highly secure. As shown in
Table 1 and Table 2, our protocol has superior benefits compared to several
solutions based on hash functions and other security mechanisms.

Also, we proposed the architecture of a low-power and low die-size

implementation of 8-bit modular exponentiation. The 8-bit modular
exponentiation implementation has a chip area of less than 1 K gates and the
encryption of 64 bits requires about 1000 clock cycles. The executing time of

66
the proposed protocol would range from 12.36 ms to 20.6 ms, with 6–8 tags
authenticated per second.

Finally, although we have not yet physically implemented the circuit, it is

known that the power consumption and circuit area are proportional to the
number of logical gates, so our implementation should be suitable even for
very low-cost RFID tags.

67
 Part II

MANET protocol

68
 Chapter 5

Mobile Ad-hoc Network

5.1 Introduction to MANET
In the next generation of wireless communication systems, there will be a
need for the rapid deployment of independent mobile users. Significant
examples include establishing survivable, efficient, dynamic communication
for emergency/rescue operations, disaster relief efforts, and military networks.
Such network scenarios cannot rely on centralized and organized connectivity,
and can be conceived as applications of Mobile Ad Hoc Networks. A MANET
is an autonomous collection of mobile users that communicate over relatively
bandwidth constrained wireless links. Since the nodes are mobile, the network
topology may change rapidly and unpredictably over time. The network is
decentralized, where all network activity including discovering the topology
and delivering messages must be executed by the nodes themselves, i.e.,
routing functionality will be incorporated into mobile nodes.

The set of applications for MANETs is diverse, ranging from small, static
networks that are constrained by power sources, to large-scale, mobile, highly
dynamic networks. The design of network protocols for these networks is a
complex issue. Regardless of the application, MANETs need efficient
distributed algorithms to determine network organization, link scheduling, and
routing. However, determining viable routing paths and delivering messages in
a decentralized environment where network topology fluctuates is not a well-
defined problem. While the shortest path (based on a given cost function) from
a source to a destination in a static network is usually the optimal route, this
idea is not easily extended to MANETs. Factors such as variable wireless link

69
quality, propagation path loss, fading, multiuser interference, power expended,
and topological changes, become relevant issues. The network should be able
to adaptively alter the routing paths to alleviate any of these effects. Moreover,
in a military environment, preservation of security, latency, reliability,
intentional jamming, and recovery from failure are significant concerns.
Military networks are designed to maintain a low probability of intercept
and/or a low probability of detection. Hence, nodes prefer to radiate as little
power as necessary and transmit as infrequently as possible, thus decreasing
the probability of detection or interception. A lapse in any of these
requirements may degrade the performance and dependability of the network.

5.1.1 Features of MANET

MANET is a collection of mobile computing devices that communicate via
wireless links, without the aid of infrastructures such as a base station or an
access point. Unlike Wireless Local Area Network (LAN), MANET does not
rely on centralized administration and coordination. Instead, the control of the
network is distributed among the nodes. MANET topology is dynamic and
unpredictable, while mobile nodes are free to move, join, and leave the
network randomly. Each participating node may function as a router to assist
other nodes searching for route. For multihop communications, the node needs
to use intermediate nodes to relay the messages hop by hop. This widens the
feasibility of MANET by expanding the service area and prolonging the
connection time of mobile nodes [69]. Thus, MANET may operate in a
standalone fashion, or may be connected to the larger Internet.

In general, the characteristics specific to MANET can be summarized as

follows:

70
 Autonomous and infrastructure-less. MANET is self-organized and
independent of any established infrastructure and centralized network
administration. Each node runs as a router and operates in distributed manner.

Multihop routing. As there is no dedicated router, every node functions as a

router and aids in forwarding each others’ packets to intended destination.
Hence, information sharing among mobile nodes is made available.

Unpredictable and dynamic network topology. Since MANET nodes move

randomly in the network, the topology of MANET changes frequently, leading
to regular route changes, network partitions, and possibly packet losses.

Variation on link and node capabilities. Each participating node may be

equipped with different type of radio devices that have varying transmission
and receiving capabilities, and possibly operate on multiple frequency bands
[70].

Asymmetric links might be resulted due to this heterogeneity in the radio

capabilities. Additionally, different software or hardware configuration might
result in variability in processing capabilities. Thus, designing and
standardization of MANET protocols and algorithms for this heterogeneous
network are complicated as dynamic adaptation is required.

Energy-constrained operation. The processing power of node is restricted

because the batteries carried by portable mobile devices have limited power
supply. As a result, the services and applications that can be supported by each
node are limited. Network protocols must be developed to be power-aware
since each node is functioning as both an end system and a router.

71
 Network scalability. Many MANET applications may involve large
networks with tens of thousands of nodes especially that can be found in
tactical networks [71]. Scalability is crucial to the successful deployment of
MANET.

5.1.2 MANET Applications

Historically, MANET has primarily been used for tactical network related
applications to improve battlefield communications and survivability.
MANET technology assists in maintaining an information network among
soldiers, vehicles and their headquarters. Due to the frequent change of
military operations, the military can not depend on access to a fixed pre-placed
communication infrastructure in battlefield. MANET has created a suitable
framework to provide a multihop wireless network without pre-placed
infrastructure [71].

In the past several years, with the rapid advances in mobile ad hoc
networking research, MANET has attracted intensive attention and interests
from commercial business industry, academic institutions as well as the
standards community. The introduction of new technologies such as the
Bluetooth and IEEE 802.11 greatly facilitates the deployment of ad hoc
technology outside of the military domain. Table 5.1 shows the current and
possible applications in categories.

72
 Table 5.1: MANET Applications

Applications Descriptions
Tactical Networks Military operations and battlefields
Home applications that are context-aware; with embedded
Sensor Networks smart sensors in electronic appliances
Environmental applications include biological detection.
Search and rescue for disaster recovery
Emergency Operations Replacement of a fixed infrastructure in case of natural
catastrophes
E-commerce such as electronic payments made from
anywhere
Commercial Usage
Vehicular services that include transmission of news,
weather, audio/video clips and traffic conditions
Multi-user online games
Infotainment
Outdoor Internet access
Location Aware Services Follow-on services such as automatic call- forwarding
Educational Tools Virtual classrooms or instantaneous conferences

The typical applications of MANET are diverse, ranging from large-scale

highly dynamic networks, to small-scale static networks. For example,
emergency rescue operations relay information via the infrastructure-less
MANET especially during disasters such as fire, flood or earthquake. Vehicles
on a highway can create an ad hoc network for use in disseminating traffic
information. They can operate as a pure ad hoc network in which an individual
vehicle detects traffic events and initiates a broadcast to other vehicles.
Alternatively, cellular or Internet access points placed near the road can
transmit the information. Apart from that, MANET technology is broadly
applied in commercial sector, conference or classroom to exchange ideas,
Personal Area Network (PAN) and many more with the ever- increasing
research work.

73
 It is also likely that there are other applications for MANETs that are not
presently realized and envisioned by researchers. For example, recently small
electronics devices are being developed that could be worn on human body and
communicate with each other to deliver exciting services. Such developing
technologies of a mobile ad hoc network “wearable” computing and
communications provide innovative applications for MANETs [71].

5.2 MANET Routing Protocols

The unpredictable changes of network topology add complexity to the
routing among the mobile nodes. Based on the highly dynamic and volatile
nature of MANET, most of the main functionalities of the classical networking
protocols need to be redesigned [71]. These include network and transport
protocols in the Internet architecture. In MANET, the routes are often
multihop due to the limited radio propagation range of wireless devices. The
routing schemes must handle frequent topology changes resulting from node
mobility, channel fading, and interference. At the same time, nodes within the
MANET need to contend for the limited bandwidth and conserve battery
power. The challenges and complexities, together with the critical importance
of routing protocol in establishing communications among mobile nodes, make
routing area the most active research area within the MANET domain [72].

MANET inherits the traditional problems of wireless and mobile

communications, such as bandwidth optimization, power control, and
transmission-quality enhancement [72]. Additionally, their multihop nature
and the possible lack of a fixed infrastructure introduce new research problems
such as network configuration, device discovery, and topology maintenance, as
well as ad hoc addressing and self-routing.

74
 Routing in MANET depends on many factors, including modeling of the
topology, selection of routers, initiation of a route request, and specific
underlying characteristics that could serve as heuristics in finding the path
efficiently [4]. In MANET, the network topology can change very frequently,
so this nature introduces difficulties in end-to-end route finding. Existing
routing protocols for MANET can be classified into three categories according
to different design philosophies [6] [5]: proactive protocols, reactive protocols
and hybrid protocols.

Proactive protocols attempt to evaluate continuously the routes within the

network, so that when a packet needs to be forwarded, the route is already
known and can be immediately used. Proactive routing protocol includes:
Destination Sequenced Distance Vector (DSDV) [73], Cluster Head Gateway
Switch Routing (CGSR) [74], Optimized Link-State protocol (OLSR) [75] etc.

In contrast to proactive protocol, reactive routing protocols invoke route

determination procedure only on demand. Thus, when a route is needed, some
sort of global search procedure is initiated. Reactive routing protocol includes:
Temporally Ordered Routing Algorithm TORA [76], Dynamic Source Routing
DSR [77], and Ad-hoc On-demand Distance Vector AODV [78] protocols.

In reactive protocols, because route information may not be available at the

time datagram is received, the delay to determine a route can be significant.
Furthermore, the global flood-search procedure of the reactive protocols incurs
significant control traffic [8]. Proactive protocols continuously use a large
portion of the network capacity to keep the routing information current. Since
the nodes in MANET move fast and the changes may be more frequent than
the route requests, most of this routing information is never used [4][7]. This is

75
waste of the wireless network capacity. So, both pure reactive and proactive
routing protocols are not appropriate for the MANET environment.

Table 5.2: Comparison between Reactive and Proactive MANET routing protocols

Reactive
Suitable for networks with fewer
communicating nodes
Higher latency during
establishment of new routes
Lower overhead of message and
storage
Difficult to implement QoS
Pro-active
Suitable for networks with many
communicating nodes
Lower latency during connection
establishments
Higher overhead in maintaining
route to all destinations
Easier to implement QoS

Hybrid protocols attempt to take advantage of best of reactive and proactive

schemes. The main idea behind such protocols is to initiate route-discovery on
demand operation but at a limited search cost within a small domain to reduce
maintenance overhead. Hybrid routing protocol includes: ZRP Zone Routing
Protocol (ZRP) [79], Landmark Routing for MANET with Group Mobility
(LANMAR) [80] etc.

ZRP divides the network topology into zones and seeks to use different
routing protocols within and between the zones based on the weaknesses and
strengths of these protocols. ZRP is modular. Thus, any routing protocol can
be utilized within and between zones.

Consider the fact that mobile devices have limited power and radio
transmission consumes extra power, the activity of the radio interface should
be limited. Thus, regular sending and maintenance of topology updates that
consumes large power and memory must be avoided. If the units of the
network are moving constantly, it becomes even more expensive to always

76
maintain a global knowledge of all the routes in the network, making a pro-
active protocol expensive to use.
Moreover, pro-active protocol incurs temporary loops as opposed to most
reactive routing that ensures routing freedom. Reactive protocols are therefore
more suitable for the small low-power units with high mobility, which will be
the wireless device of the future.

5.2.1 Zone Routing Protocol (ZRP)

The Zone Routing Protocol, as its name implies, is based on the concept of
zones. A routing zone is defined for each node separately, and the zones of
neighboring nodes overlap. The routing zone has a radius expressed in hops.
The zone thus includes the nodes, whose distance from the node in question is
at most hops.

The nodes of a zone are divided into peripheral nodes and interior nodes.
Peripheral nodes are nodes whose minimum distance to the central node is
exactly equal to the zone radius. The nodes whose minimum distance is less
than are interior nodes. [81] [82]

The number of nodes in the routing zone can be regulated by adjusting the
transmission power of the nodes. Lowering the power reduces the number of
nodes within direct reach and vice versa. The number of neighboring nodes
should be sufficient to provide adequate reachability and redundancy. On the
other hand, a too large coverage results in many zone members and the update
traffic becomes excessive. Further, large transmission coverage adds to the
probability of local contention. [81]

77
 ZRP refers to the locally proactive routing component as the IntrA-zone
Routing Protocol (IARP). The globally reactive routing component is named
IntEr-zone Routing Protocol (IERP). IERP and IARP are not specific routing
protocols. Instead, IARP is a family of limited-depth, proactive link-state
routing protocols. IARP maintains routing information for nodes that are
within the routing zone of the node. Correspondingly, IERP is a family of
reactive routing protocols that offer enhanced route discovery and route
maintenance services based on local connectivity monitored by IARP. [82]
[83]

The fact that the topology of the local zone of each node is known can be
used to reduce traffic when global route discovery is needed. Instead of
broadcasting packets, ZRP uses a concept called bordercasting. Bordercasting
utilizes the topology information provided by IARP to direct query request to
the border of the zone. The bordercast packet delivery service is provided by
the Bordercast Resolution Protocol (BRP). BRP uses a map of an extended
routing zone to construct bordercast trees for the query packets. Alternatively,
it uses source routing based on the normal routing zone. By employing query
control mechanisms, route requests can be directed away from areas of the
network that already have been covered. [84]

In order to detect new neighbor nodes and link failures, the ZRP relies on a
Neighbor Discovery Protocol (NDP) provided by the Media Access Control
(MAC) layer. NDP transmits “HELLO” beacons at regular intervals. Upon
receiving a beacon, the neighbor table is updated. Neighbors, for which no
beacon has been received within a specified time, are removed from the table.
If the MAC layer does not include a NDP, the functionality must be provided
by IARP. [85]

78
5.2.1.1 Routing
A node that has a packet to send first checks whether the destination is
within its local zone using information provided by IARP. In that case, the
packet can be routed proactively. Reactive routing is used if the destination is
outside the zone. [84]

The reactive routing process is divided into two phases: the route request
phase and the route reply phase. In the route request, the source sends a route
request packet to its peripheral nodes using BRP. If the receiver of a route
request packet knows the destination, it responds by sending a route reply back
to the source. Otherwise, it continues the process by bordercasting the packet.
In this way, the route request spreads throughout the network. If a node
receives several copies of the same route request, these are considered as
redundant and are discarded [83], [84]

The reply is sent by any node that can provide a route to the destination. To
be able to send the reply back to the source node, routing information must be
accumulated when the request is sent through the network. The information is
recorded either in the route request packet, or as next-hop addresses in the
nodes along the path. In the first case, the nodes forwarding a route request
packet append their address and relevant node/link metrics to the packet. When
the packet reaches the destination, the sequence of addresses is reversed and
copied to the route reply packet. The sequence is used to forward the reply
back to the source. In the second case, the forwarding nodes records routing
information as next-hop addresses, which are used when the reply is sent to the
source. This approach can save transmission resources, as the request and reply
packets are smaller.

79
 The source can receive the complete source route to the destination.
Alternatively, the nodes along the path to the destination record the next-hop
address in their routing table. [83]

In the bordercasting process, the bordercasting node sends a route request

packet to each of its peripheral nodes. This type of one-to-many transmission
can be implemented as multicast to reduce resource usage. The zone radius is
an important property for the performance of ZRP. If a zone radius of one hop
is used, routing is purely reactive and bordercasting degenerates into flood
searching. If the radius approaches infinity, routing is reactive. The selection of
radius is a tradeoff between the routing efficiency of proactive routing and the
increasing traffic for maintaining the view of the zone. [83]

5.2.1.2 Route maintenance

Route maintenance is especially important in ad-hoc networks, where links
are broken and established as nodes move relatively to each other with limited
radio coverage. In purely reactive routing protocols, routes containing broken
links fail and a new route discovery or route repair must be performed. Until
the new route is available, packets are dropped or delayed. [83]

In ZRP, the knowledge of the local topology can be used for route
maintenance. Link failures and sub-optimal route segments within one zone
can be bypassed. Incoming packets can be directed around the broken link
through an active multi-hop path. Similarly, the topology can be used to
shorten routes, for example, when two nodes have moved within each other’s
radio coverage. For source-routed packets, a relaying node can determine the
closest route to the destination that is also a neighbor. Sometimes, a multi-hop

80
segment can be replaced by a single hop. If next-hop forwarding is used, the
nodes can make locally optimal decisions by selecting a shorter path. [83]

81
 Chapter 6

Dynamic Hybrid Routing Protocol

Our proposed protocol is hybrid routing protocol and it is called Dynamic
Hybrid Routing Protocol (DHRP). By adopting ZRP, we can transfer message
into very large zone with only a little increase of maintenance cost, but its
network organization is constructed same as clustering. However, its zone
center node has not responsibility to transfer messages through network as
much like head node of clustering protocols. In this proposed protocol the
nodes can be classified into 3 types: center node, border node, and normal
node. By using three types zone, the proposed protocol can reach the radius of
zone to 3-5 hops while maintenance cost a little bit higher than ZRP with the
radius is only 2 hops. Our zone maintenance approach has shown that our
protocol is much more efficient than ZRP and clustering protocols. In worst
case of DHRP, route finding process is same as ZRP with R=2 hops, but
maintenance cost can be lower than as in ZRP (in case of all center nodes
moved out). Also, each node has its own depends on their ID-numbers, so our
protocol network zone is dynamic.

6.1 Architecture
The nodes in the network can be classified into 3 types.

1 Center nodes know some border nodes and normal nodes in the network. It
is the highest ID number node in the 1-hop radius zone within border zone.
It has responsibility to border nodes within the network for connecting with
normal nodes.

82
2 Border nodes know about the nodes in the 2-hop neighbors and Center
Nodes. These nodes’s ID higher than normal node’s ID. It has
responsibility to connect with other zones.

3 Normal nodes know the nodes in the 1-hop nodes. It is the lowest ID nodes
in the 1 hop radius zone.

It uses the bordercasting transfer from ZRP, but its network organization is
constructed same as Cluster Heading Protocol. However, its zone center node
has not responsibility to transfer messages through network as much like head
node of CHP. Nodes can be identified by its ID-number.

Table 6.1: Notations

Symbol Meaning
P() Signal power of nodes
H() HELLO message from 1-hop neighbors
H’() HELLO message from 2-hop neighbors
R() REPLY message from 1-hop neighbors
R’() REPLY message from 2-hop neighbors
A,K,Y, The nodes
L
IDlowest Lowest ID-number in the neighbors
IDthighest highest ID-number in the neighbors
tH The waiting time of HELLO messages
tR The waiting time of REPLY messages

6.2 Node Identification Process (NIP)

We show the Node Identification Process (NIP) in below:

1. Each nodes send HELLO messages to its neighbors.

2. If node receives HELLO message from its neighbors, it forwards
HELLO message to its neighbors, but depends on cases:

83
 • case1: Each node compares its neighbor’s unique ID number, and
saved them in the table.
• (rule1) case3: if node’s 1-hop node’s ID number lower than itself, it
not forward that node’s H() message to others.
• (rule2) in other case, node forwards H() messages to its neighbors.

H(neighbors) Node 1
If ID(n) > ID(1)
forward H(n)
else
not forward

3. If node receives H'() message from its 2-hop nodes, it turns on the
waiting time, tH, for receiving H'() messages from its 2-hop neighbors. After
finish the tH, it checks and finds min and max ID numbers. Then it reply R()
message to that nodes depends on cases:

• (rule3) case1: if it is not the lowest ID node in its 1-hop nodes, it reply
R() message to the lowest ID node. Then this node is turned into Border
node. Even if it receives R() messages from other nodes, it keep silent.
• (rule4) case2: if it is the lowest ID node itself in the neighborhood, it is
turned to be Normal node. And it turns on, tR, waiting time for R()
messages.

Node 2
H'(n)
: tH
H'(n)
If has the lowest ID number node
tR replay R(1) to that node and turn to Border Node
Else
it is turned to Normal Node

84
 4. If node receives REPLY messages from its neighbors during its on-
time, tR, it acts depends on cases:
• (rule5) case1: If node receive R() messages, it is going to find
maximum ID-number node. Then it sends R'() to max ID-number node.
If it has the lowest ID number node and also this node did not receive
H'() messages from its second hop nodes, it is going to be border node.
• (rule6) case2: if node receives R'() message from its 2-hop neighbor
and it has no higher node, it is turned to be Center node.
a)
Node 1
R(n)
: tR
R(n) R'(n)
To the highest ID number Node
If has the lowest ID node and didn ’t receive H’()
it is going to be Border Node

b)

R'(n) Node 1
If has no higher ID node
it turn to Center Node
Else
forward R’() to the highest ID node
If nodes have other border nodes and normal nodes and they located in the
2-hop radius of center node they send information of border node and normal
nodes to center node. So, Center node can know nodes in the extended zone,
indeed, border nodes only know other border nodes and center nodes within 2-
hop radius. Like 2-hop clustering algorithm [86], nodes collaborate with each
other in at most two hops to determine nodes. However, nodes communication
range availabilities are different than clustering. In the 2-hops clustering, nodes
communicate with each other in at most two hops, but in our protocol, nodes

85
are classified into 3 different types. Each type nodes have different range than
others. Border node has 2-hop radius zone communication range with other
nodes. Center nodes communication range is flexible; it depends on border
nodes location.

Node follows below process to register the other neighbor nodes into its
routing table.
1 Node register its 1-hop nodes when it receive HELLO messages from its 1-
hop neighbors
2 Node register its 2-hop nodes when it generate REPLY messages, then it
send R() message to the lowest node. If it has no the lowest node, it does
not need to generate REPLY messages. REPLY message includes its all 1-
hop and some of 2-hop neighbors.
3 If node receive R() messages from its 2-hop nodes, it register all nodes
which is included in the R() message.

6.2.1 Example
Now, Now, we explain our protocol on the example 1. Figure 6.1 shows the
Node Identification Process of DHRP on the example.

86
 K X
Step1: X Step2: RK(K,D,A)
K H’(D) L
L
D
D H’(A)
H’(K)
H’(Z)

A
A R A(X,L,K,Z,H)
H’(H)
H’(Z) Z
Z RH(A,Z,B) RZ(A,H,B)
H’(A), H’(Z)
H’(H), H’(Z)
H
H B
B

Step3: X
K R’K(K,D,A)
L Normal node Border node
D
R’ K(K,D,A) Center node

Z
H R’Z(), R’A(), R ’H()
Figure 6. 1: Node
B Identification Process

First, the nodes exchange HELLO message to each other. Then the nodes
follow the protocol. Each node receives HELLO messages from its neighbors,
and then each node calculates ID numbers of HELLO messages (see table 6.2).
As shown in step 1 of figure 6.1, the nodes forward Hello messages to other
neighbors. Since X, B, and L nodes have smallest ID-numbers in theirs 1-hop
neighbors, they turned into normal nodes (see rule 4). Node receives Hello
message from neighbor. If ID number of the neighbor is higher than its ID-
number, it just forwards Hello messages to other its neighbors. If not, it is not
forward that Hello message. Hello messages of normal nodes are not
forwarded, because normal nodes have smallest ID numbers in its 1-hop
neighbors (see rule 1 and 2). In step 2 of figure 6.1, K, A, Z, and H nodes
turned into border nodes, because they generate REPLY messages, and send
REPLY messages to normal nodes that have smallest ID number nodes in their
1-hop neighbors (see rule 3). In the step 3, D and Z nodes turned into center

87
nodes, because they receive REPLY messages from its second hop neighbors
and they are highest ID-number nodes in its 1-hop neighbors (see rule 6). Even
though Node K received REPLY message from its 2-hop neighbors, it has
highest ID-number node D, so it forwards R'(K,D,A) message to node D (see
rule 5).

Table 6.2: Steps of the NIP

P(
Node H() H'() R() R'() R'() Node type
)
D 4 K - K Center
K 3 X,D A X Border
X 2 K,A D,Z K Normal
X,B,L, K,H,
A 3 Border
Z Z
L 2 A Z Normal
Z 4 A,B A,H B Center
A,
B 1 H,A,Z Z Normal
H
H 2 B A,Z Border

Table 6.2 shows the steps of NIP. In this table, column 2 shows the unique
ID numbers of nodes. Column 2, and 3 show HELLO messages from the 1-
hop, and 2-hop neighbors respectively. Also, column 4, and 5 show REPLY
messages from the 1-hop, and 2-hop neighbors respectively. For example, node
A receives HELLO messages from X, B, L, and Z nodes, and also receives
HELLO messages from its 2-hop neighbors X, H, and Z nodes (see table 2).
After tH finish, node A produce REPLY message and send it to node B. This
REPLY message includes all 1-hop, and 2-hop neighbors of node A. Node B
also receive REPLY message from node H. After tR finish, node B forward it to

88
node Z, because node Z is the highest ID-number node in the network for node
B. This node identification process with times is described in figure 3.

D K X A Z B H
H(D) H(K) H(A) H(Z) H(Z) H(H)
PD>PK
H'(D) H'(K) H(A)
tH H'(A) H'(Z)
H'(A) H'(H) H'(H)
H'(Z) PZ>PH>PA>PB
PA>PX PZ>PA
tR PD>PD>PK R(K) R(A) R(H)
R'(K) R'(X) R'(A), R'(H)
Figure 6. 2. The NIP with tH and tR

After receiving the HELLO messages from its 1-hop neighbors, nodes turn
on the waiting time, tH. During this time, nodes receive HELLO messages from
its 2-hop neighbors. After finish the tH, nodes turn on time tR then nodes reply
REPLY message to its 1-hop the lowest node. During this time, nodes receive
REPLY messages from its 1-hop nodes. Once the time, tR, turn off, node
forward REPLY message to its 1-hope the highest node. In our example, after
completed the NIP process, center node Z knows nodes H, B, A, L, X, and K,
D knows nodes K, X, and A, border node K knows nodes A, X and D, A
knows nodes K, L, X, A, B, H, and K, H knows nodes B, A, and Z.
From table 6.3, we can see that center nodes know nodes 3-hop away from
itself. Instead, border nodes know nodes within 2-hop radius. The normal
nodes only know 1-hop nodes.

Table 6.3: Range of nodes after the NIP

Nodes Z D H A K B X L
1-hop B, A K B X, L, B, Z D, X A, Z, H K, A A
2-hop H, X, L X Z, A K, H A
3-hop K A

89
6.3 Routing Process
As in ZRP, source mobile node in DHRP sends out a route finding request.
However, route finding process used in ZRP, needs to be modified in order to
support our protocol in the following:

1. First, if it is normal node, it checks the destination in its 1-hop

neighbors. If not find, it sends RREQ packet to its 1-hop nodes.
2. The border nodes check the destination in its routing table. If not
find, it sends RREQ packet to Center nodes. If border has no center node,
it sends RREQ packet to its peripheral nodes (2-hop border nodes) using
Bordercast Resolution Protocol (BRP) [84].
3. The center node checks whether the destination is within its local
zone. If not found, it sends packet to its peripheral nodes using BRP.
Since its zone radius is bigger than border node’s zone, it is efficient to
decrease long route request delays, and flood traffic the entire network.
Also, bordercasting used in ZRP, needs to be modified in order to support
our protocol in the following:

1. If intermediate node is center node, it stops to forward the RREQ

message, and check the destination in its routing table. If not found, it
sends RREQ to its peripheral nodes.
2. If peripheral node has center node, first check the destination in its
routing table, then it send RREQ to center node.
3. Any intermediate nodes do not need to check the destination in its
routing table, if it is not center node. It saves system overhead.
If the destination node is in the zone of sender node, the packet can be reach
directly. The Reply phase is almost same as ZRP. If the receiver of a route

90
request packet knows the destination, it responds by sending a route reply back
to the source. Otherwise, it continues the process by bordercasting the RREQ
packet.

Any node that can provide a route to the destination sends the reply. To be
able to send the reply back to the source node, routing information must be
accumulated when the request is sent through the network. But if intermediate
nodes are normal nodes, they not record their address and relevant node/link
metrics to the packet. Only the information of border nodes and center nodes is
recorded in the route request packet. We think that this approach can save
transmission resources, as the request and reply packets are smaller. When the
packet reaches the destination, the sequence of addresses is reversed and
copied to the route reply packet. The sequence is used to forward the reply
back to the source [83]. Same like ZRP, in our protocol, if a node receives
several copies of the same route request, these are considered as redundant and
are discarded [83], [84].

a) DHRP: b) ZRP(R=2):
RREQ(D,H) X K RREQ(D,H) X
K RREQ(D,H)
RREQ(D,H)
D RREQ(D,H) D RREP(D,X,B,H)
RREQ(D,X,H)
RREP(D,A,H)
RREP(D,X,B,H)
RREP(D,A,H) L
L A
A RREQ(D,X,H)
RREP(D,X,B,H)

Z Z
H H
B B
Figure 6. 3. Route finding process a) DHRP b) ZRP(R=2)

We are going to explain routing process of our protocol on the example 1.

We can see different result in one example from figure 6.3. If node D wants to
connect node H, node D send RREQ(D,H) packet to it peripheral node A in our

91
protocol. Since node A has node H, node A reply RREP(D,A,H) packet to D
node. In ZRP with R=2 hop, D send RREQ(D,H) to X, then X send
RREQ(D,X,H) to B. Then B node reply (D,X,B,H) to X node. We can see the
difference between ZRP with R=2, and DHRP. Our protocol the request and
reply packets are smaller than the packets used in ZRP(R=2), so our protocol
can save transmission resources.

6.4 Zone Maintenance

According to our protocol, there are three type nodes in the network.
Therefore, each type node’s zone maintenances are different than each other.
Normal node needs to check only its 1-hop nodes. Border node needs to check
the nodes in the zone with 2 hops radius. As in ZRP, border nodes can use the
TTL (Time-to-Live) field in update packets to detect a change of link
connectivity. However, center nodes needs to do 2 steps for updating its
routing table. First, it checks the nodes in its zone with 2 hops radius. If any
changes are detected, it updates its routing table. Second, it sends update packet
to its peripheral nodes. If the peripheral nodes detect any changes in the zone
from its own update of the zone, it reply alert message to center node. If
intermediate border nodes has changes after its own zone maintenance, it send
alert message to center nodes, because intermediate nodes, which is located
within the zone with 2 hops radius of center node, know the center node. We
show this process in the figure 6.4.

K node is center node, A and B are border nodes, and F node is normal
node. Node K check the changes in its zone A1 (red), and node A checks the
changes in its zone. If node A detects any changes of link connectivity within
A2 field (blue), it sends alert message to center node K. However, node B can

92
not send alert message to center node, even tough it detect any changes in its
zone, because it does not know center node. So, center node K sends update
package to B node since B is peripheral node of K. if B node detects any
changes within A3 field (green), it responds alert message to center node. From
example, node F moved out to p2 position form p1 position of B’s zone. Then
B node replay alert message to K node. Then node K removes F node from its
routing table.

K A B
A3
p1
A1 A2 F
p2
F

Figure 6. 4. Zone maintenance of Center node K

If any node joins to network, it just communicates with the nodes in its zone
with 2 hops radius. And if it is the lowest ID-number node, it is going to be
normal node; if not, it is going to be border node. In order to reduce the
maintenance overhead of the zone, the NIP process is executed in some time
interval. We think this time interval can be 3-4 bigger time than zone
maintenance time interval. It means that after some update process is executed,
the NIP is going to perform again. This time interval is referred to network
average mobility and the number of center nodes. If system has many center
nodes, system has high ability to transfer RREQ packets through center nodes.
At least one center node exists in the network, system finding route
performance is better than ZRP. Therefore, if network mobility is high, center

93
nodes have high possibility to move out of the zone. In case, NIP process time
interval has to be short. May be it can be equal 2-3 update processes. If
network mobility is low and the number of center nodes is high, NIP process
time interval can be long. In case of all center nodes are moved out of the
network, route finding process of our routing is almost same as ZRP with R=2
hops. However, maintenance overhead of the network can be lower than as in
ZRP, because normal nodes only need to update its 1-hop nodes in case of all
center nodes are moved out. So, border nodes, and normal nodes only need to
update the zones.

6.5 Implementation
We developed DHRP on Windows-XP operating system. We use cygwin,
ns-2.30 version, and Eclipse for implementing DHRP. We describe the steps of
develop DHRP in below.

• Download Cygwin from internet.

• Install Cygwin

• Run setup.exe
• Choose a root directory, i.e. c:\cygwin
• Make sure, unix/binary text file type is selected
• Click Next
• Choose a package directory, this is where your downloaded
files will be put in
• Select an internet connection and a download mirror
• Make sure you install the following packages:

94
xorg-x11-bin, xorg-x11-bin-dlls, xorg-x11-devel,
xorg-x11-libs-data, xorg-x11-etc, gcc, gcc-g++,

gawk, tar, gzip, make, patch, perl, w32api

95
• Start cygwin.bat to create a user

96
• Download NS2 (ns-allinone-2.30.tar.gz from internet)
• Build NS2

• Start Cygwin.bat to get into cygwin shell

• Extract NS2 to a cygwin folder, i.e. c:\cygwin\home\bbold\ns-
allinone-2.30 (tar xvfz ns-allinone-2.30.tar.gz to
C:\cygwin\home\bbold)
• cd to your NS2-directory, default: /home/bbold/ns-allinone-2.30

97
• Type "./install"
• Type "./validate" if you want to validate your build
• These steps may take a while
• Add paths to ~/.bashrc

# LD_LIBRARY_PATH
OTCL_LIB=/home/bbold/ns-allinone-2.30/otcl-1.12
NS2_LIB=/home/bbold/ns-allinone-2.30/lib
X11_LIB=/usr/X11R6/lib
USR_LOCAL_LIB=/usr/local/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OTCL_LIB:
$NS2_LIB:$X11_LIB:$USR_LOCAL_LIB

# TCL_LIBRARY
TCL_LIB=/home/bbold/ns-allinone-2.30/tcl8.4.13/library
USR_LIB=/usr/lib
export TCL_LIBRARY=$TCL_LIB:$USR_LIB

# PATH
XGRAPH=/home/bbold/ns-allinone-2.30/bin:/home/bbold/ns-
allinone-2.30/tcl8.4.13/unix:/home/bbold/ns-allinone-
2.30/tk8.4.13/unix
NS=/home/sucha/ns-allinone-2.30/ns-2.30/
NAM=/home/sucha/ns-allinone-2.30/nam-1.12/
PATH=$PATH:$XGRAPH:$NS:$NAM

98
 Download Eclipse SDK

• Download Eclipse C++ Development Tooling for Windows

• Extract Eclipse SDK to a folder, i.e. c:\eclipse
• Extract Eclipse CDT to the same folder

Start Eclipse

• Choose your ns2 folder as your workspace folder,

default:c:\cygwin\bbold\username\ns-allinone-2.30
• Create new C++ Project

• Select File->New->Project...
• Select C++->Standard C++ Make Project
• Click Next
• Enter ns-2.30 as your project name
• Click Finish

• Change the Binary Parser

• Select Project->Properties
• Select C/C++ Make Project
• In the Binary Parser Tab, select Cygwin PE Parser and PE
Windows Parser
• Click OK

• Create a Launch Configuration

99
 • Select Run->Debug...
• Select C/C++ Local Application
• Click "New Launch Configuration"
• Under Project, click Browse and select "ns-2.30"
• Under C/C++ Application, click Search Project and select
"ns.exe"
• Under the Arguments tab, put the location of tcl example
• Click Apply
• Click Close
• Build all Project

The debugger needs debug information to be generated by the compiler. To

make the compiler generate these information, we edit the NS2 makefile. Edit
".../ns-allinone-2.30/ns-2.30/Makefile" or edit ".../ns-allinone-2.30/ns-
2.30/Makefile.in" and run "./configure" after that. Add those lines anywhere:

CCOPT = -g

100
DEFINE = -DNDEBUG

101
 DEFINE = -DDEBUG

6.5.1 Install ZRP

We use the source code of ZRP which is made by Cornel University. This
source code is implemented by Prashant Gopal Inamti in 2003. Also, this code
was written according to the IETF draft specification. For installing ZRP on ns-
2.30, we have to follow below steps:
• Download source code from internet
• tar xvfz ns2_zrp_code.tar to home directory of ns-2, i.e: ns-2.30
• edit Makefile at ns-allinone-2.30/ns-2.30/Makefile, (after "dsdv/dsdv.o
dsdv/rtable.o queue/rtqueue.o \") insert the zrp code objects:
dsdv/dsdv.o dsdv/rtable.o queue/rtqueue.o \
zrp/zrp.o zrp/zrp_table.o \
routing/rttable.o \

Now we need to modify some ns2 code. First, we need to add ZRP packet type.
We define it inside file common/packet.h
• Add this line to defines
#define HDR_CDIFF(p) (hdr_cdiff::access(p))
/* chalermak's diffusion*/
#define HDR_ZRP(p)(hdr_zrp::access(p)) // add this line

• insert new packet types here

PT_ZRP, // add ZRP packet type
PT_NTYPE // This MUST be the LAST one

• find definition of p_info class. Inside constructor we provide a textual

name of out packet type.
name_[PT_SRM]= "SRM";
name_[PT_ZRP]= "ZRP";

102
Second, we need to do some changes in Tcl files. Actually we are going to add
our packet type, give default values for binded attributes and provide the
needed infrastructure to create wireless nodes running our ZRP routing
protocol.
• tcl/lib/ns-packet.tcl
foreach prot {
GAF
UMP
ZRP
Pushback
NV
} {

• tcl/lib/ns-agent.tcl
Agent/AODV set sport_ 0
Agent/AODV set dport_ 0

Agent/ZRP instproc init args {

$self next $args

}
Agent/ZRP set sport_ 0
Agent/ZRP set dport_ 0

• tcl/lib/ns-default.tcl
# Routing protocol agents
Agent/Mcast/Control set packetSize_ 80
Agent/ZRP set packetSize_ 100
#Agent/ZRP set sport_ 0
#Agent/ZRP set dport_ 0

• tcl/lib/ns-lib.tcl
- switch -exact $routingAgent_ {
ZRP {
set ragent [$self create-zrp-agent $node]
}
DSDV {
- Simulator instproc create-zrp-agent { node } {
set ragent [new Agent/ZRP [$node id]]
$node set ragent_ $ragent
#$node attach $ragent 255
$self at 0.0 "$ragent start" ;# start updates

103
 return $ragent
}

Simulator instproc create-tora-agent { node } {

Third, for simulation’s aim is to gets a trace file describing what happened
during execution. A Trace object is used to write wanted information of a
packet everytime it is received, sent or dropped. To log information regarding
our packet type we implement the format_zrp() function inside the CMUTrace
class. Trace support for wireless simulations is provided by CMUTrace objects
[87].
• Trace/cmu-trace.cc // show different types of traces

// pgi - added for zrp

void
CMUTrace::format_zrp(Packet *p, int offset)
{
struct hdr_cmn *ch = HDR_CMN(p);
struct hdr_ip *ih = HDR_IP(p);

// hack the IP address to convert pkt format to hostid

format
// for now until port ids are removed from IP address.
int src = Address::instance().get_nodeaddr(ih->saddr());
int dst = Address::instance().get_nodeaddr(ih->daddr());

if (pt_->tagged()) {
// Need to determine tag names for this data
//sprintf(pt_->buffer() + offset,
// "",
// );
} else if (newtrace_) {
sprintf(pt_->buffer() + offset,
"-Is %d.%d -Id %d.%d -It %s -Il %d -If %d -Ii %d -Iv %d ",
src, // packet src
ih->sport(), // src port
dst, // packet dest
ih->dport(), // dst port
packet_info.name(ch->ptype()), // packet type
ch->size(), // packet size
ih->flowid(), // flow id
ch->uid(), // unique id

104
 ih->ttl_); // ttl
} else {
sprintf(pt_->buffer() + offset, "------- [%d:%d %d:%d
%d %d] ",
src, ih->sport(),
dst, ih->dport(),
ih->ttl_, (ch->next_hop_ < 0) ? 0 : ch->next_hop_);
}
}

• Also, In order to call this recently created function we must change the
format() in trace/cmu-trace.cc.

void
CMUTrace::format(Packet* p, const char *why)
{
// pgi - added for ZRP
case PT_ZRP:
format_zrp(p, offset);
break;
// pgi - added for ZRP

• We must add our new function to trace/cmu-trace.h file.

// PGI$$ - ZRP additions
#define DROP_RTR_HIYA "HIYA"
#define DROP_RTR_IERP "IERP"
#define DROP_RTR_IARP "IARP"

#define MAX_ID_LEN 3
#define MAX_NODE 4096

void format_zrp(Packet *p, int offset); // pgi added for zrp

void format_arp(Packet *p, int offset);

Now, we need to type on cygwin shell to make sure we re-compile newly

added code.

% cd ~/ns-allinone-2.30/ns-2.30
% touch common/* tcl/lib/* trace/*

Then type "make -k" within the "~/ns-allinone-2.30/ns-2.30/" directory, the ns-
2 code should re-compile.

105
6.6 Performance evaluation

6.6.1 Simulation environment and performance criteria

Simulation study was conducted to compare the performance of HDRP with
original ZRP[88]. Therefore, we modified some functions of ZRP to our
protocol.

The MANET in the simulation consists of 100 mobile nodes, whose initial
positions are chosen from a uniform random distribution over an area of 1000
m by 1000 m. A mobile node starts its journey from its initial position to a
random destination with a randomly chosen speed (uniformly distributed
between 0 and 10 m/s).

Once the destination is reached, another random destination is targeted after a

pause. We vary the pause time, which affects the relative speeds of the mobile
nodes. Simulations are run for 3000 simulated seconds. The transmission
radius of each mobile node is 150m, which means a communication link exists
between two mobiles nodes whose distance are less than 150m. Criteria for
performance evaluation and comparison include: (1) maintenance overhead
(number of maintenance packets per second), (2) route finding cost (number of
route request packets generated per route).

6.6.2 Performance comparisons

We compare the performance of DHRP with corresponding schemes of ZRP
with 2-hop and 3-hop radius.

106
 700

Average maintenance cost (pkt/sec)

600
ZRP (R=2)
500
DHRP (R=2)
400
ZRP (R=3)
300

200

100

0
0 100 200 300 400 500 600 700 800 900
Pause time (sec)
Figure 6. 5. Average maintenance cost

As shown in figure 6.5, the maintenance overhead of DHRP is much smaller

than ZRP with 3-hops radius. Also, as network’s mobility is decreased, the
maintenance overhead of DHRP is getting close to the overhead of ZRP with
2-hop radius. The purpose of DHRP is little increase of maintenance overhead
with better route finding process. As shown in figure 6.5, the maintenance
overhead of DHRP is slightly higher than ZRP with 2-hop. The average route
finding costs for DHRP and ZRP are displayed in Fig. 6.6.

450
400
Average route finding cost (pkt)

ZRP (R=2)
350 DHRP (R=2)
300 ZRP (R=3)

250
200
150
100
50
0
0 100 200 300 400 500 600 700 800 900
Pause time (sec)
Figure 6. 6. Average route finding cost

107
The route finding cost of DHRP is much smaller than that of ZRP with 2-hop
radius since center nodes can reach 3 to 5 hops away that can effectively
reduce the cost of bordercasting. Also, the route finding cost of DHRP is
higher than that of ZRP with 3-hops radius. However, the results show that
DHRP has more efficient route finding cost than ZRP(R=2) with a little bit
increase of maintenance overhead.

The disadvantage of DHRP is that NIP needs to be performed after some time
interval. We choose this time interval equals four times bigger than time
interval of maintenance of network in the fig. 6.5 and fig. 6.6. After 4 times the
zone maintenance of network is performed, NIP is implemented again. In order
to investigate more about the impact of time interval of NIP on the
performance of DHRP, we calculate the maintenance overhead as well as the
route finding cost for 3 different value of the time interval of NIP.

700
Average maintenance cost (pkt/sec)

4 x Time interval of ZM
600
2 x Time Interval of ZM
1 x Time Interval of ZM
500
ZRP (R=3)

400

300

200

100

0
0 100 200 300 400 500 600 700 800 900
Pause time (sec)
Figure 6. 7. Average maintenance cost with 3 different values

108
 350

300 4 x time of ZM

Average route finding cost (pkt)

2 x time of ZM
1 x time of ZM
250 ZRP (R=3)

200

150

100

50

0
-100 100 300 500 700 900
Pause tim
Figure 6. 8. Average route finding es (sec)
cost with 3 different values

For reducing the maintenance overhead in DHRP, it is better to choose the

value of time interval of NIP that makes DHRP only increases a little bit of the
maintenance cost with much better route finding process than ZRP with same
radius as DHRP. Fig. 6.7 shows the average maintenance overhead of DHRP
with 3 different values and pause time. Also, fig. 6.8 shows the route finding
cost of DHRP on the 3 different values of time interval of NIP.

We made analysis from both figs. 6.7 and 6.8 on following cases.

Case 1: the time interval of NIP is same as time interval of zone

maintenance.

The maintenance overhead of DHRP is almost same as that of ZRP with 3

hops radius in fig. 6.7. Also, if pause time is increased (high mobility), the
route finding cost of DHRP is slightly lower than that of ZRP with 3 hops
radius, and if pause time is increased (low mobility), it is slightly higher
than that of ZRP with 3 hops radius in fig. 6.8.

109
 Case 2: the time interval of NIP is 2 times bigger than the time interval of
zone maintenance.

If the time interval of NIP is 2 times bigger than the time interval of zone
maintenance, the route finding cost of DHRP is slightly higher than that of
ZRP with 3-hops radius. However, the maintenance overhead of DHRP is
lower than that of ZRP with 3-hops radius.

Case 3: the time interval of NIP is 4 times bigger than the time interval of
zone maintenance.

The maintenance overhead of DHRP is slightly higher than ZRP with 2-

hop, but the route finding cost of DHRP is much smaller than that of ZRP
with 2-hop radius.

From the results of experiments, if network has more center nodes, network
has high ability to transfer RREQ packets through center nodes. So, network
need to choose the value of time interval of NIP has to be short. However, from
the aspect of maintenance overhead, the value of time interval of NIP needed to
be long. The results show us that system need to choose this value to take best
possible balance of maintenance overhead and route finding cost. In our
example, the value of time interval of NIP is 4 times bigger than the time
interval of zone maintenance is good choice for DHRP.

6.7 Conclusions
In this chapter, an efficient and dynamic hybrid routing protocol that
modifying ZRP with clustering structure is proposed. In the DHRP, we propose
Node Identification Process (NIP) to identify the nodes based on their unique
ID-numbers. Most of previous protocols assume each node knows about its

110
neighbors. The advantage of using NIP is to identify each node type, neighbors
and range in the time of discovering its neighbors. By using three types node,
this approach can save transmission resources in the route finding process, as
the request and reply packets are smaller than used in ZRP.

In the DHRP, each type node’s maintenance cost of zone is different than
each other. Normal node needs to check only its 1-hop nodes. Border node
needs to check the nodes in the zone with 2 hops radius. However, center nodes
needs to do 2 steps for updating its routing table. New idea of zone
maintenance approach is used by this paper. In order to reduce the maintenance
overhead of the zone, the NIP process is executed in some time interval. This
time interval can be 3-4 bigger time than zone maintenance time interval. This
time interval is referred to network average mobility and the number of center
nodes. At least one center node exists in the network, system finding route
performance is better than ZRP. In case of all center nodes are moved out of
the network, route finding process of our routing is almost same as ZRP with
R=2 hops. However, maintenance overhead of the network can be lower than
as in ZRP.

From the experiments of paper, our proposed protocol is efficient to

decrease long route request delays, and flood traffic the entire network while
the maintenance cost only increases a little bit.

111
 References

[1]. J. Daemen and V. Rijmen, “The design of Rijndael.” AES—The Advanced

Encryption Standard (Springer–Verlag, Berlin, Heidelberg, New York, 2002)
[2]. National Institute of Standards and Technology (NIST). “FIPS-197: advanced
encryption standard, November 2001.” http://www.itl.nist.gov/fipspubs/,
accessed 18 March, 2006.
[3]. Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone, “Handbook of
Applied Cryptography”. CRC Press, ISBN: 0-8493-8523-7, 5th print, August,
2001
[4]. D. P. Agrawal, and Qing-An Zeng, “Introduction to Wireless and Mobile
Systems”, Thomson, ISBN: 0534493033, 2nd edition, 2006, chapter 13, pp306-
324.

112
[5]. Nadia Nedjah and Luiza de Macedo Mourelle, “Three Hardware
Implementations for the Binary Modular Exponentiation: Sequential, Parallel
and Systolic” Proceedings of the 15th Symposium on Computer Architecture
and High Performance Computing (SBAC-PAD’03), 2003, IEEE
[6]. Timo Alho, Panu Hämäläinen, Marko Hännikäinen, Timo D. Hämäläinen,
“Design of a Compact Modular Exponentiation Accelerator for Modern FPGA
Devices” World Automation Congress 2006 (WAC 2006) - Special Session on
Information Security and Hardware Implementations, Budapest, Hungary, July
24-26, 2006, 7 pages.
[7]. E. Royer and C.K. Toh, “A Review of Current Routing Protocols for Ad Hoc
Mobile Wireless Network”, IEEE Personal Communications, Vol. 7, No. 4,
pp.46-55, April 1999.
[8]. P. Jacquet and L. Viennot, “Overhead in mobile Ad Hoc Networks Protocols”,
INRIA Research report RR-3965, available at
http://www.inria.fr/recherche/equipes/hipercom.en.html
[9]. Bibliotheca RFID Library Systems AG. http://www.bibliotheca-rfid.com.
[10]. International Organization for Standardization. http://www.iso.org.
[11]. Priya Agrawal, Neha Bhargava, Chaitra Chandrasekhar, Al Dahya, and J.D.
Zamfirescu. “The MIT ID Card System: Analysis and recommendations”
December 2004. MIT, Massachusetts, USA.
[12]. 12. Sanjay Sarma, Stephen Weis, and Daniel Engels. “RFID systems and
security and privacy implications”. Workshop on Cryptographic Hardware and
Embedded Systems – CHES 2002, volume 2523 of Lecture Notes in Computer
Science, pages 454–469, Redwood Shores, California, USA, August 2002.
Springer-Verlag.
[13]. Gildas Avoine and Philippe Oechslin. “RFID traceability: A multilayer
problem”. Financial Cryptography – FC’05, volume 3570 of Lecture Notes in
Computer Science, pages 125–140, Roseau, The Commonwealth Of Dominica,
February– March 2005. IFCA, Springer-Verlag.

113
[14]. Martin Feldhofer, Sandra Dominikus, and Johannes Wolkerstorfer. “Strong
Authentication for RFID systems using the AES algorithm”. Workshop on
Cryptographic Hardware and Embedded Systems – CHES 2004, volume 3156
of Lecture Notes in Computer Science, pages 357–370, Boston, Massachusetts,
USA, August 2004. IACR, Springer-Verlag.
[15]. Ari Juels. “RFID security and privacy: A research survey”. IEEE Journal on
Selected Areas in Communication, 2006.
[16]. Ari Juels, Ronald Rivest, and Michael Szydlo. “The blocker tag: Selective
blocking of RFID tags for consumer privacy”. Conference on Computer and
Communications Security – CCS’03, pages 103–111, Washington, DC, USA,
October 2003. ACM, ACM Press.
[17]. Gildas Avoine. “Privacy issues in RFID banknote protection schemes”.
Internationa Conference on Smart Card Research and Advanced Applications –
CARDIS, pages 33–48, Toulouse, France, August 2004. IFIP, Kluwer Academic
Publishers.
[18]. David Molnar and David Wagner. “Privacy and security in library RFID: Issues,
practices, and architectures”. Conference on Computer and Communications
Security – CCS’04, pages 210–219,Washington, DC, USA, October 2004.
ACM, ACM Press.
[19]. Stephen Weis, Sanjay Sarma, Ronald Rivest, and Daniel Engels. “Security and
privacy aspects of low-cost radio frequency identification systems”.
International Conference on Security in Pervasive Computing – SPC 2003,
volume 2802 of Lecture Notes in Computer Science, pages 454–469, Boppard,
Germany, March 2003. Springer-Verlag.
[20]. Gildas Avoine, Etienne Dysli, and Philippe Oechslin. “Reducing time
complexity in RFID systems”. Selected Areas in Cryptography – SAC 2005,
Lecture Notes in Computer Science, Kingston, Canada, August 2005. Springer-
Verlag.

114
[21]. Benjamin Fabian, Oliver Gunther, and Sarah Spiekermann. “Security analysis of
the object name service for RFID”. In International Workshop on Security,
Privacy and Trust in Pervasive and Ubiquitous Computing – SecPerU’05,
Santorini Island, Greece, July 2005. IEEE, IEEE Computer Society Press.
[22]. Nathan Good, John Han, Elizabeth Miles, David Molnar, Deirdre Mulligan,
Laura Quilter, Jennifer Urban, and David Wagner. “Radio frequency
identification and privacy with information goods”. Workshop on Privacy in
the Electronic Society – WPES, pages 41–42, Washington, DC, USA, October
2004. ACM, ACM Press.
[23]. Ari Juels. “Minimalist cryptography for low-cost RFID tags”. International
Conference on Security in Communication Networks – SCN 2004, volume 3352
of Lecture Notes in Computer Science, pages 149–164, Amalfi, Italia,
September 2004. Springer-Verlag.
[24]. Yang Jeongkyu. “Security and privacy on authentication protocol for low-cost
radio frequency identification”. Master thesis, Information and Communications
University, Daejeon, Korea, December 2004.
[25]. Thomas Hjorth. “Supporting privacy in RFID systems”. Master thesis,
Technical University of Denmark, Lyngby, Denmark, December 2004.
[26]. Stephen Weis. “Security and privacy in radio-frequency identification devices”.
Master thesis, Massachusetts Institute of Technology (MIT), Massachusetts,
USA, May 2003.
[27]. Klaus Finkenzeller. RFID Handbook. Wiley, England, second edition, 2003.
(70)
[28]. Gildas Avoine, Etienne Dysli, and Philippe Oechslin. “Reducing time
complexity in RFID systems”. Selected Areas in Cryptography – SAC 2005,
Lecture Notes in Computer Science, Kingston, Canada, August 2005. Springer-
Verlag.
[29]. Katherine Albrecht and Liz McIntyre. “Spychips: How Major Corporations and
overnment Plan to Track Your Every Move with RFID”. Nelson Current, 2005.

115
[30]. Z. Kfir and A. Wool. “Picking virtual pockects using relay attacks on contacless
smartcard systems”. In Proc. of SecureComm’05. IEEE Computer Society, 2005.
[31]. J. Atkinson. Contactless credit card consumer report.
http://www.findcreditcards.org, 2006.
[32]. T. S Heydt-Benjamin, D. V. Bailey, K. Fu, A. Juels, and T. Ohare.
“Vulnerabilities in first-generation RFID-enabled credit cards”. In Proc. Of
FC’07, volume 4886, pages 2–14, 2007.
[33]. M. Rieback, C. Bruno, and A. Tanenbaum. “Is your car infected with a
computer virus?” In Proc. of PerCom’06. IEEE Computer Society, 2006.
[34]. F. Thornton, B. Haines, A. Das, H. Bhargava, A. Campbell, and J.
Kleinschmidt. “RFID Security”. Syngress Publishing, 2006.
[35]. B. Jamali, P. H. Cole, and D. Engels. “Networked RFID Systems and
Lightweight Cryptography, chapter RFID Tag Vulnerabilities in RFID
Systems”, pages 147–155. Springer, 2007.
[36]. Gunter Karjoth and Paul Moskowitz. “Disabling RFID tags with visible
confirmation: Clipped tags are silenced”. In Workshop on Privacy in the
Electronic Society – WPES, Alexandria, Virginia, USA, November 2005. ACM,
ACM Press.
[37]. Ari Juels and John Brainard. “Soft blocking: Flexible blocker tags on the
cheap”. Workshop on Privacy in the Electronic Society – WPES, pages 1–7,
Washington, DC, USA, October 2004. ACM, ACM Press.
[38]. Ari Juels and Ravikanth Pappu. Squealing euros: “Privacy protection in RFID-
enabled banknotes”. Financial Cryptography – FC’03, volume 2742 of Lecture
Notes in Computer Science, pages 103–121, Le Gosier, Guadeloupe, French
West Indies, January 2003. IFCA, Springer-Verlag.
[39]. Simson Garfinkel. “Adopting fair information practices to low cost RFID
systems”. Ubicomp 2002 – Workshop on Socially-informed Design of Privacy-
enhancing Solutions in Ubiquitous Computing, September 2002.

116
[40]. Simson Garfinkel. “An RFID bill of rights”. Technology Review, October 2002.
[41]. S. Kinoshita, F. Hoshino, T. Komuro, A. Fujimura, and M. Ohkubo. “Low-cost
RFID privacy protection scheme”. In IPS Journal 45:(8), pages 2007–2021,
2003.
[42]. P. Golle, M. Jakobsson, A. Juels, and P. Syverson. “Universal reencryption for
mixnets”. In CT-RSA’04, volume 2964 of LNCS, pages 163–178. Springer-
Verlag, 2004.
[43]. J. Saito, J.-C. Ryou, and K. Sakurai. “Enhancing privacy of universal re-
encryption scheme for RFID tags”. In Proc. of EUC’04, volume 3207 of LNCS,
pages 879–890. Springer-Verlag, 2004.
[44]. X. Gao, Z. Xiang, H. Wang, J. Shen, J. Huang, and S. Song. "An approach to
security and privacy of RFID system for supply chain," CEC-East, pp. 164–
168, IEEE International Conference on E-Commerce Technology for Dynamic
E-Business (CEC-East'04), 2004.
[45]. M. Ohkubo, K. Suzuki, and S. Kinoshita, “Cryptographic approach to “privacy-
friendly” tags.” In RFID Privacy Workshop, MIT, USA, 2003.
[46]. Sanjay E.Sarma, Stephen A. Weis and Daiel W. Engels, “Radio-Frequency
Identification: Secure Risks and Challenges”, RSA Laboratories Cryptobytes,
vol. 6, no.1, pp.2-9. Spring 2003
[47]. J. Yang, J. Park, H. Lee, K. Ren, and K. Kim, “Mutual authentication protocol
for low-cost RFID”, Encrypt Workshop on RFID and Lightweight Crypto, 2005.
[48]. S.M. Lee, Y.J. Hwang, D.H. Lee, and J.I.L. Lim, “Efficient authentication for
low-cost RFID systems”, In Proc. of ICCSA’05, volume 3480 of LNCS, pages
619–627, Springer-Verlag, 2005.
[49]. Pedro Peris-Lopez, Julio Cesar Hernandez-Castro, Juan Estevez-Tapiador, and
Arturo Ribagorda, “LMAP: A real lightweight mutual authentication protocol
for low-cost RFID tags” printed handout of Workshop on RFID, Security –
RFIDSec 06, July 2006.

117
[50]. Datasheet Helion Technology, MD5, SHA-1, SHA-256 hash core for Asic,
http://www.heliontech.com, 2005.
[51]. E.Y. Choi, S.M. Lee, and D.H. Lee, “Efficient RFID authentication protocol for
ubiquitous computing environment”, In Proc. of SECUBIQ’05, LNCS, 2005.
[52]. N. Pramstaller, S. Mangard, S. Dominikus, and J. Wolkerstorfer, “Efficient AES
implementations on ASICs and FPGAs.” Proc. Fourth Workshop on the
Advanced Encryption Standard ‘‘AES—state of the crypto analysis.’’ AES
2004, LNCS 3373, pp. 98–112, Springer, 2004.
[53]. M. Aigner and M. Feldhofer. “Secure symmetric authentication for RFID tags.”
Telecommunication and Mobile Computing, March 2005
[54]. D. Henrici and P. Muller, “Hash-based enhancement of location privacy for
radio-frequency identification devices using varying identifiers.” PerSec'04 at
IEEE PerCom, pp. 149–153, March 2004.
[55]. M. Feldhofer, J. Wolkerstorfer, and V. Rijmen, “AES implementation on a grain
of sand.” IEE Proceedings Information Security, October 2005, Vol. 152, Issue
1, pp. 13–20.
[56]. A. Satoh, S. Morioka, K. Takano, and S. Munetoh, “A compact Rijndael
hardware architecture with S-Box optimization.” Proc. 7th Int. Conf. on the
Theory and Application of Cryptology and Information Security, Advances in
Cryptology, ASIACRYPT 2001, Gold Coast Australia, December 2001, LNCS
2248, pp. 239–254, Springer, 2001.
[57]. S. Mangard, M. Aigner, and S. Dominikus, “A highly regular and scalable AES
hardware architecture.” IEEE Trans. Comput., 2003, 52 (4), pp. 483–491
[58]. J. Wolkerstorfer, “An ASIC implementation of the AESMixColumn operation.”
Proc. Austrochip 2001, Vienna, October 2001, pp. 129–132.
[59]. C. D. Walter, “Montgomery Exponentiation Needs No Final Subtractions”,
Electronics Letters, vol. 35 no. 21, October 1999, pp 1831-1832.
[60]. Nadia Nedjah and Luiza de Macedo Mourelle, “Three Hardware Implementations
for the Binary Modular Exponentiation: Sequential, Parallel and Systolic”

118
 Proceedings of the 15th Symposium on Computer Architecture and High
Performance Computing (SBAC-PAD’03), 2003, IEEE
[61]. Timo Alho, Panu Hämäläinen, Marko Hännikäinen, Timo D. Hämäläinen,
“Design of a Compact Modular Exponentiation Accelerator for Modern FPGA
Devices” World Automation Congress 2006 (WAC 2006) - Special Session on
Information Security and Hardware Implementations, Budapest, Hungary, July
24-26, 2006, 7 pages.
[62]. T. Blum, and C. Paar, “Montgomery modular exponentiation on reconfigurable
hardware” Proceedings of the 14th IEEE Symposium on Computer Arithmetic
(Adelaide, Australia), on page(s): 70-77. ISBN: 0-7695-0116-8, 1999
[63]. Alexandre F. Tenca and Cetin K. Koc, “A Scalable Architecture for
Montgomery Multiplication”, Cryptographic Hardware and Embedded
Systems, CHES 99, Lecture Notes in Computer Science, No. 1717, pages 94,
Springer-Verlag, 1999.
[64]. Martin Simka and Milos Drutarovsky, “Montgomery Multiplication
Coprocessor on Reconfigurable Logic” In Proceedings of 13th International
Czech-Slovak Scientific Conference Radio electronic, pages 95-98, Brno, Czech
Republic, May 6-7, 2003.
[65]. RSA Hardware implementation, Version-1, August,
http://islab.oregonstate.edu/papers/r02rsahw.pdf
[66]. Gildas Avoine “Radio frequency identification: adversary model and attacks on
existing protocols", Technical Report LASEC-REPORT-2005-001, EPFL,
Lausanne, Switzerland, September 2005.
[67]. Caroline J. Kudla, “Special Signature Schemes and Key Agreement Protocols”,
PhD thesis, Royal Holloway, University of London, 2006,
http://www.isg.rhul.ac.uk/~kp/CKthesis.pdf
[68]. Kirk H.M. Wong, Patrick C.L. Hui, Allan C.K. Chan “Cryptography and
authentication on RFID passive tags for apparel products”, Computers in
Industry, Volume 57, Issue 4, Pages 342-349, May 2006.

119
[69]. Tatsuaki Osafune, Kazuya Monden, Shoji Fukuzawa, and Susumu Matsui.
“Performance Measurement of Mobile Ad Hoc Network for Application to
Internet-ITS”. Proceedings of the 2004 International SAINT’04. Jan., 2004.
Tokyo: IEEE. 2004. 25-30.
[70]. D. M. Blough, G. Resta, P. Santi. “A Statistical Analysis of The Long-run Node
Spatial Distribution in Mobile Ad hoc Networks”. Proceedings of the 5th ACM
MSWIM’02. Sep. 2002. Atlanta: ACM. 2002. 30-37.
[71]. Imrich Chlamtac, Marco Conti, and Jennifer J. –N. Liu. “Mobile Ad-hoc
Networking: Imperatives and Challenges”. Elsevier Ad Hoc Networks Journal.
2003. Vol. 1(1): 13-64.
[72]. Jie Wu and Ivan Stojmenovic. Ad Hoc Networks. Journal of IEEE Computer
Society. 2004. 29-31.
[73]. Perkins and P. Bhagwat, “Highly dynamic destination-sequenced distance
vector routing (DSDV) for mobile computers”, in: Proceedings of the
Conference on Communications Architectures, Protocols and Applications
(ACM SIGCOMM '94), London, United Kingdom, August-September 1994, pp.
234-244.
[74]. C.C. Chaing, “Routing in Clustered Multihop, Mobile Wireless Networks with
Fading channel,” Proceedings of IEEE SICON, pp.197-211, April 1997.
[75]. A. Laouiti, L. Viennot, and T. Clausen, “Optimized link state routing protocol”,
Internet Draft, draft-ietf-manet-olsr-04.txt, 2001.
[76]. V.D. Park and M.S. Gorson, “A Highly Adaptive Distributed Routing
Algorithm for Mobile and Wireless Networks”, Proceedings of IEEE
INFOCOM’97, pp. 103-112, April 1997.
[77]. D.B. Johnson, D.A. Maltz, Y.-C. Hu, and J.G. Jetcheva, “The dynamic source
routing protocol for mobile ad hoc networks”, Internet Draft, draft-ietf-manet-
dsr-05.txt, 2001.

120
[78]. C.E. Perkins and E. Royer, “Ad hoc on-demand distance vector (AODV)
routing”, in: Proceedings of the 2nd IEEE Workshop on Mobile Computing
Systems and Applications (WMCSA), February 1999, pp. 90-100.
[79]. N. Beijar, “Zone Routing Protocol (ZRP)”, in Ad Hoc Networking, Licentiate
course on Telecommunications Technology, 2002
[80]. G. Pei, M.Gerla, and X. Hong, “LANMAR: landmark routing for large scale
wireless ad hoc networks with group mobility”, ACM MobiHoc, Boston, MA,
August 2000.
[81]. Pearlman, Marc R., Haas, Zygmunt J. “Determining the Optimal Configuration
for the Zone Routing Protocol”, August 1999, IEEE Journal on Selected Areas
in Communications, Vol. 17, No. 8
[82]. Haas, Zygmunt J., Pearlman, Marc R., Samar, P. “Intrazone Routing Protocol
(IARP)”, June 2001, IETF Internet Draft, draft-ietf-manet-iarp-01.txt
[83]. Haas, Zygmunt J., Pearlman, Marc R., Samar, P. “Interzone Routing Protocol
(IERP)”, June 2001, IETF Internet Draft, draft-ietf-manet-ierp-01.txt
[84]. Haas, Zygmunt J., Pearlman, Marc R., Samar, P. “The Bordercast Resolution
Protocol (BRP) for Ad Hoc Networks”, June 2001, IETF Internet Draft, draft-
ietf-manet-brp-01.txt
[85]. [14]Haas, Zygmunt J., Pearlman, Marc R.: “Providing Ad-hoc Connectivity
With Reconfigurable Wireless Networks”, Ihaca, New York,
http://www.ee.cornell.edu/~haas/wnl.html
[86]. Lin, C.R. and Gerla, M., “Adaptive clustering for mobile wireless networks”,
IEEE Journal on Selected Areas in Communications. Vol. 15 i7. 1265-1275.
[87]. The VINT Project. The ns Manual, December 2003.
http://www.isi.edu/nsnam/ns/ns-documentation.html.
[88]. Cornell University WNL Projects, Implementation code of ZRP, 2003,
http://people.ece.cornell.edu/haas/wnl/wnlprojects.html

121