**3. Enabling technologies**

RFID-sensor networks are an emerging part of the Internet of Things [5]. These devices com‐ bine sensing capabilities with an RFID interface that allow the retrieval of sensed data. In fact, they can cooperate with RFID systems to better track the status of things e.g., their loca‐ tion, temperature, movements, etc. A sensor-enabled RFID tag (also known as sensor-tags) is an RFID tag which contains one or more sensors to monitor some physical parameter (e.g., temperature) but also contains the same identification function as a "normal" RFID tag does. This kind of sensor tag may fall into class 2, class 3 or class 4 in EPCglobal's tag classi‐ fication [3]. A fully passive, class 2 sensor-tag can measure physical parameters, i.e., use sen‐ sors, only when powered by a reader. In contrast, class 3 tags are battery assisted. They can

In this chapter, we will discuss different ways to achieve the Internet of Things vision by internetworking passive RFID tags over IPv6. The chapter is organized as follows: Section 2 presents related works and discusses the novelty of the work presented here. Section 3 intro‐ duces the key technologies for the convergence of RFID and Internet namespaces and to provide an address mapping needed to internetwork passive RFID tags. In Section 4, some common examples of RFID usage are given and discussed in the context of globally net‐ worked tags. Subsequently, Section 5 introduces a testbed built to study the interconnection of passive RFID tags over IPv6. The different strategies that can be used for integrating RFID with IPv6 are discussed in Section 6 and this discussion is followed by mobility considera‐ tions in Section 7. Finally, Section 8 concludes the discussion and outlines anticipated future

Most objects in our surrounding are not equipped with microprocessors and hence cannot attach to a computer network. However, these objects can be equipped with passive, lowcost RFID tags either as tags integrated or adhesively stuck to the object and hereby provide a mean of communications. Dominikus et al. [14] has suggested a way to integrate passive RFID systems into the Internet of Things, by using readers that function as IPv6 routers. In their work, an IPv6 addressing scheme that map tag IDs to network addresses was defined. Furthermore, the mobility problem, which arises when tags physically moves around, was investigated and the use of Mobile IPv6 (MIPv6) to cope with tag mobility was suggested. In contrast to the work presented by Dominikus et al. [14], this chapter opens the discussion on the proper formatting of the IPv6 addressing by introducing cryptographic hashing techni‐ ques as well as the possibility of separating identity and location information when forming an IPv6 address. The use of hashing techniques to construct an IPv6 address from an EPC, as opposed by using a compressed EPC format [14], eases practical implementations and al‐

An alternative approach is to provide the tags themselves with the IPv6 protocol stack, mak‐ ing them able to use IPv6 communication over the Internet whenever close to a reader. This requires several changes to the design of existing tags. In this case, the tags do all the work

lows the use of the same mapping scheme for all EPC types.

work independently of the reader and can be suitable for RFID-sensor networks.

work in this area.

112 Radio Frequency Identification from System to Applications

**2. Related works**

There are a couple of ways to interconnect objects by using RFID with IPv6 [6]. One solution would be to give the tags the ability to communicate via the Internet. The communication can be both reader-initiated and tag-initiated. The latter requires specific tags that require electrical and processing power to be available in the tag such as e.g., EPC class 3 tags. Most of the computational work takes place in the tags, i.e., the tag is reachable and visible as an IPv6 connected host as long as it is within the electric field of a reader.

Passive RFID tags, such as EPC class 2 tags, do not have the possibility to power a network protocol stack and therefore a network address cannot be directly assigned to the tag's mi‐ crochip. However, the passive tag can be represented by virtual interfaces residing in the reader interrogating the tag.

#### **3.1. Radio Frequency Identification (RFID)**

RFID systems are composed of one or more readers and several electronic tags. Tags are characterized by a unique identifier that takes the form as a binary number. They are ap‐ plied to objects and even persons or animals as implants. From a physical point of view, an RFID tag is a small microchip attached to an antenna that is used for both receiving the reader signal and transmitting the tag ID. The dimensions of each tag can be very small with tag dimensions down to 0.05 mm x 0.05 mm with a thickness of 0.005 mm [7]. There are more than 60 tag manufacturers world-wide [8].

the physical nature of the tag, so that although 64-bit tags may differ from 96-bit tags in the choice of binary header values and in the number of bits allocated to each element or field within the EPC, the pure identity URI format does not require the information system to know about these details. Hence, the pure identity URI can be regarded as a pure identifier [10]. Tags are identified by URIs such as e.g., urn:epc:id:sgtin:0523141.000024.120 that com‐

Encoding is the process of translating the pure identity EPC into a specific instantiation in‐ corporated into tags for a specific purpose. During the encoding process the URI informa‐ tion is translated into a binary encoding that is stored in the tag. Subsequently, translating between the different levels of representation can be accomplished in a consistent way.

Figure 1 shows the structure of the data layout of an EPC code for the Global Trade Item

CRC EPC Password

Item reference

Item reference Check digit

Serial number

Integrating RFID with IP Host Identities http://dx.doi.org/10.5772/53525 115

Serial number

Number (GTIN) and Serialized Global Trade Item Number 96-bit (SGTIN-96) tag.

Company prefix

Indicator digit

EPC generation 1 standards, i.e., class 0 and class 1 tags, use a Cyclic Redundancy Check (CRC) to verify data integrity and a password as a "kill code" to disable the tags. The pass‐ word must never be transmitted under any circumstances [3]. The *Item reference* identifies a class of objects to be tagged and it allows the grouping of items. The *Serial number* identifies an instance of a particular item. Company prefixes (also known as General Manager Num‐ bers) point to the organization responsible for the subsequent partition. Finally, *Indicator dig‐ its* are used to specify length, type, structure, version, and generation of the EPC. This latter part is further used to guarantee uniqueness in the EPC namespace. For the GTIN encoding

Since the EPC is the only required data stored on a tag, it must be used as a "pointer" to find additional data about an object to which it attaches. This additional data should be stored on a server connected to the enterprise network or to the Internet. The server is identified via a

prise both tag number and associated coding scheme.

Indicator digit

Company prefix

**GTIN** Identity structure

**SGTIN-96** Bit-level encoding

**Figure 1.** Tag data layout example.

a *Check digit* is used.

look-up system which is called ONS.

RFID tags will act as electronic identification for physical objects to which they are linked. In the Internet of Things, all objects, virtual as well as physical, are interconnected and reacha‐ ble via for example IPv6 in combination with RFID technology [6]. Essentially, the tag con‐ nects to physical objects that we want to authenticate and track when they come in contact with readers. A reader can read or modify tag's information. The back-end database keeps information related to different tags/readers.

For reader-initiated communication the reader triggers the tag's transmission by generating an appropriate signal, which represents a query for the possible presence of tags in the sur‐ rounding area and for the reception of their identification codes (IDs).

Active tags come with a power source that can drive a microprocessor (or microcontroller). Furthermore, it allows a stronger electromagnetic field to be generated in response to an in‐ coming RFID air protocol message and larger read distances can be achieved. More ad‐ vanced active tags or sensor-tags may run additional software and can be equipped with communication software such as an IP protocol stack [9].

In contrast, passive tags rely on the incoming electromagnetic field from the reader to power the circuit and to deliver power to drive the response to an interrogating request. These devices do not run communication software and cannot be actively involved in a protocol message exchange. To communicate with these devices there is a need for soft‐ ware agents to act on their behalf.

RFID tags can only be "online" when they are in the electric field of a reader field. For high velocity applications, where tags only remain certain seconds in a reader field, the proposed approach of networking these tags is not applicable.

#### **3.2. RFID namespaces**

Essentially, RFID comes with two namespace to be used with RFID applications: the EPC addresses and the Object Name Service (ONS). A namespace can represent objects as well as concepts and may be generalized as a container for a set of identifiers (names). The EPC is an identifier based on the standards established by EPCglobal® [10]. It is designed to allow the automatic identification of objects anywhere. EPC defines three layers of identity: the *pure* identity, the encoding layer identity and the physical realization of an encoding. The EPC tag data standard [10] identify how existing coding systems such as the GS1 family co‐ des for serialized human readable representations e.g. GTIN, GCN, SSCC, GRAI, GIAI, GSRM, GDTI and a small number of other identities should be embedded within the EPC.

A canonical representation of an EPC is the *pure identity* Uniform Resource Indicator (URI) representation, which is intended for communicating and storing EPC in information sys‐ tems, databases and applications. The purpose is to insulate EPCs from knowledge about the physical nature of the tag, so that although 64-bit tags may differ from 96-bit tags in the choice of binary header values and in the number of bits allocated to each element or field within the EPC, the pure identity URI format does not require the information system to know about these details. Hence, the pure identity URI can be regarded as a pure identifier [10]. Tags are identified by URIs such as e.g., urn:epc:id:sgtin:0523141.000024.120 that com‐ prise both tag number and associated coding scheme.

Encoding is the process of translating the pure identity EPC into a specific instantiation in‐ corporated into tags for a specific purpose. During the encoding process the URI informa‐ tion is translated into a binary encoding that is stored in the tag. Subsequently, translating between the different levels of representation can be accomplished in a consistent way.

Figure 1 shows the structure of the data layout of an EPC code for the Global Trade Item Number (GTIN) and Serialized Global Trade Item Number 96-bit (SGTIN-96) tag.

**Figure 1.** Tag data layout example.

RFID tag is a small microchip attached to an antenna that is used for both receiving the reader signal and transmitting the tag ID. The dimensions of each tag can be very small with tag dimensions down to 0.05 mm x 0.05 mm with a thickness of 0.005 mm [7]. There are

RFID tags will act as electronic identification for physical objects to which they are linked. In the Internet of Things, all objects, virtual as well as physical, are interconnected and reacha‐ ble via for example IPv6 in combination with RFID technology [6]. Essentially, the tag con‐ nects to physical objects that we want to authenticate and track when they come in contact with readers. A reader can read or modify tag's information. The back-end database keeps

For reader-initiated communication the reader triggers the tag's transmission by generating an appropriate signal, which represents a query for the possible presence of tags in the sur‐

Active tags come with a power source that can drive a microprocessor (or microcontroller). Furthermore, it allows a stronger electromagnetic field to be generated in response to an in‐ coming RFID air protocol message and larger read distances can be achieved. More ad‐ vanced active tags or sensor-tags may run additional software and can be equipped with

In contrast, passive tags rely on the incoming electromagnetic field from the reader to power the circuit and to deliver power to drive the response to an interrogating request. These devices do not run communication software and cannot be actively involved in a protocol message exchange. To communicate with these devices there is a need for soft‐

RFID tags can only be "online" when they are in the electric field of a reader field. For high velocity applications, where tags only remain certain seconds in a reader field, the proposed

Essentially, RFID comes with two namespace to be used with RFID applications: the EPC addresses and the Object Name Service (ONS). A namespace can represent objects as well as concepts and may be generalized as a container for a set of identifiers (names). The EPC is an identifier based on the standards established by EPCglobal® [10]. It is designed to allow the automatic identification of objects anywhere. EPC defines three layers of identity: the *pure* identity, the encoding layer identity and the physical realization of an encoding. The EPC tag data standard [10] identify how existing coding systems such as the GS1 family co‐ des for serialized human readable representations e.g. GTIN, GCN, SSCC, GRAI, GIAI, GSRM, GDTI and a small number of other identities should be embedded within the EPC.

A canonical representation of an EPC is the *pure identity* Uniform Resource Indicator (URI) representation, which is intended for communicating and storing EPC in information sys‐ tems, databases and applications. The purpose is to insulate EPCs from knowledge about

rounding area and for the reception of their identification codes (IDs).

communication software such as an IP protocol stack [9].

approach of networking these tags is not applicable.

more than 60 tag manufacturers world-wide [8].

114 Radio Frequency Identification from System to Applications

information related to different tags/readers.

ware agents to act on their behalf.

**3.2. RFID namespaces**

EPC generation 1 standards, i.e., class 0 and class 1 tags, use a Cyclic Redundancy Check (CRC) to verify data integrity and a password as a "kill code" to disable the tags. The pass‐ word must never be transmitted under any circumstances [3]. The *Item reference* identifies a class of objects to be tagged and it allows the grouping of items. The *Serial number* identifies an instance of a particular item. Company prefixes (also known as General Manager Num‐ bers) point to the organization responsible for the subsequent partition. Finally, *Indicator dig‐ its* are used to specify length, type, structure, version, and generation of the EPC. This latter part is further used to guarantee uniqueness in the EPC namespace. For the GTIN encoding a *Check digit* is used.

Since the EPC is the only required data stored on a tag, it must be used as a "pointer" to find additional data about an object to which it attaches. This additional data should be stored on a server connected to the enterprise network or to the Internet. The server is identified via a look-up system which is called ONS.

ONS acts as a directory service for organizations wishing to look up product numbers (also known as EPC numbers) on the Internet. The ONS is operated as part of the EPCglobal Net‐ work. It is based on the well-known DNS service and it realizes the link between EPC num‐ bers and EPC Information Services (EPCIS) as illustrated in Figure 2. When an RFID reader reads a tag, the EPC is passed to a middleware which then looks the EPC up either on the local machine, or enquires ONS through the Internet.

On the network layer, IP addresses are used. IPv6 was introduced in the 90'ies due to the foreseen lack of globally unique IPv4 addresses, resulting in a protocol specification released in 1998 [17]. The IPv6 address is a 128-bit address that takes the form of a 64-bit network prefix appended by a 64-bit host suffix/interface identifier. The network prefix is used for routing purpose and determines the location of the host in the Internet. The host itself is identified by an interface ID. Figure 3 shows the IPv6 address format and gives an example

X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

**Figure 3.** IPv6 address format compared to a 96-bit General Identifier (GID-96) EPC format. An 'X' indicates a group‐

It can be observed form the figure that not all 96 bits of the EPC can be fitted within the host suffix/interface identifier of an IPv6 address. Because of this deficiency, the imple‐ menters of an RFID-to-IPv6 mapping scheme is faced with a number of design options. These options basically govern the strategy for the mapping and are the subject of our

Cryptographically Generated Addresses (CGAs) are IPv6 addresses for which the host suf‐ fix/interface identifier is generated by computing a cryptographic one-way hash function from a binary input such as e.g., a public key [27]. CGAs are intended to be globally unique in a statistical sense but these may not necessarily be routable addresses at the IP layer [12].

The Overlay Routable Cryptographic Hash Identifiers (ORCHID) is a new, experimental class of identifiers based on CGAs. ORCHIDs have an IPv6-like address format and can be used with existing applications built on IPv6 [12]. These identifiers are intended to be used as pure endpoint identifiers for applications and Application Programming Interfaces (APIs) and not as identifiers for network location. This is in contrast to the IPv6 address that uses

While ORCHIDs use public cryptographic keys as input bit strings, it is possible to use the binary EPC encoding instead. The algorithm to generate an ORCHID in an RFID context is

X X X X X X X X **Manufacturer**

X X X X X X **Product**

X X X X X X X X **Serial Number**

Integrating RFID with IP Host Identities http://dx.doi.org/10.5772/53525 117

**Network prefix Interface ID**

on how a 96-bit EPC can be mapped to a network address.

X X **Header**

**128-bit IPv6 address**

**96-bits EPC structure (GID-96)**

16 bits

ing of 4 bits.

discussion in Section 6.

**3.4. Cryptographically generated addresses**

the 64-bit network prefix as locator [17].

**Figure 2.** The Object Name System (ONS). Adapted from [11].

The ONS resolution process takes the EPC code and returns network location(s) where in‐ formation resides, i.e., the EPCIS server, which typically holds web pages with information about tags. The Physical Markup Language (PML), based on XML technology, is intended to be the standard in which information about tags should be written.

In contrast, the DNS of the Internet will handle many more requests in the future. Therefore, enterprises will likely maintain ONS servers locally, which will store information for quick retrieval. Hence, a manufacturer may store ONS data from its current suppliers on its own network, rather than pulling the information off a Web site every time a shipment arrives at the assembly plant.

#### **3.3. Internet namespaces**

There are two principal namespaces in use in the Internet: IP addresses and domain names. Domain names provide hierarchically assigned names for some computing platforms and some services. Each level in the hierarchy is delegated from the level above. Email, Hyper‐ text Transfer Protocol (HTTP), and Session Initiation Protocol (SIP) addresses all reference domain names to mention its most wide-spread use.

On the network layer, IP addresses are used. IPv6 was introduced in the 90'ies due to the foreseen lack of globally unique IPv4 addresses, resulting in a protocol specification released in 1998 [17]. The IPv6 address is a 128-bit address that takes the form of a 64-bit network prefix appended by a 64-bit host suffix/interface identifier. The network prefix is used for routing purpose and determines the location of the host in the Internet. The host itself is identified by an interface ID. Figure 3 shows the IPv6 address format and gives an example on how a 96-bit EPC can be mapped to a network address.

#### **128-bit IPv6 address**

ONS acts as a directory service for organizations wishing to look up product numbers (also known as EPC numbers) on the Internet. The ONS is operated as part of the EPCglobal Net‐ work. It is based on the well-known DNS service and it realizes the link between EPC num‐ bers and EPC Information Services (EPCIS) as illustrated in Figure 2. When an RFID reader reads a tag, the EPC is passed to a middleware which then looks the EPC up either on the

Local system

ONS resolver

EPCIS server

PML files

URI conversion

**Internet** ONS/DNS

The ONS resolution process takes the EPC code and returns network location(s) where in‐ formation resides, i.e., the EPCIS server, which typically holds web pages with information about tags. The Physical Markup Language (PML), based on XML technology, is intended to

In contrast, the DNS of the Internet will handle many more requests in the future. Therefore, enterprises will likely maintain ONS servers locally, which will store information for quick retrieval. Hence, a manufacturer may store ONS data from its current suppliers on its own network, rather than pulling the information off a Web site every time a shipment arrives at

There are two principal namespaces in use in the Internet: IP addresses and domain names. Domain names provide hierarchically assigned names for some computing platforms and some services. Each level in the hierarchy is delegated from the level above. Email, Hyper‐ text Transfer Protocol (HTTP), and Session Initiation Protocol (SIP) addresses all reference

local machine, or enquires ONS through the Internet.

server

be the standard in which information about tags should be written.

**Figure 2.** The Object Name System (ONS). Adapted from [11].

domain names to mention its most wide-spread use.

Reader

116 Radio Frequency Identification from System to Applications

**Tag**

the assembly plant.

**3.3. Internet namespaces**

**Figure 3.** IPv6 address format compared to a 96-bit General Identifier (GID-96) EPC format. An 'X' indicates a group‐ ing of 4 bits.

It can be observed form the figure that not all 96 bits of the EPC can be fitted within the host suffix/interface identifier of an IPv6 address. Because of this deficiency, the imple‐ menters of an RFID-to-IPv6 mapping scheme is faced with a number of design options. These options basically govern the strategy for the mapping and are the subject of our discussion in Section 6.

#### **3.4. Cryptographically generated addresses**

Cryptographically Generated Addresses (CGAs) are IPv6 addresses for which the host suf‐ fix/interface identifier is generated by computing a cryptographic one-way hash function from a binary input such as e.g., a public key [27]. CGAs are intended to be globally unique in a statistical sense but these may not necessarily be routable addresses at the IP layer [12].

The Overlay Routable Cryptographic Hash Identifiers (ORCHID) is a new, experimental class of identifiers based on CGAs. ORCHIDs have an IPv6-like address format and can be used with existing applications built on IPv6 [12]. These identifiers are intended to be used as pure endpoint identifiers for applications and Application Programming Interfaces (APIs) and not as identifiers for network location. This is in contrast to the IPv6 address that uses the 64-bit network prefix as locator [17].

While ORCHIDs use public cryptographic keys as input bit strings, it is possible to use the binary EPC encoding instead. The algorithm to generate an ORCHID in an RFID context is outlined below [12]. The algorithm takes a bitstring and some *context identifier* as inputs and produces an ORCHID output that is formatted as an IPv6 address.

$$\text{Input} \;:\text{=} \text{anybit} \\ \text{string} \tag{1}$$

**3.5. Host identities and host identity protocol**

protocol [15][16].

End-point

Location IP address

Service Socket

A host identity is an abstract concept assigned to a computing identity platform. In this sec‐ tion, we will generalize this concept to cover thin compact platforms that can be equipped with RFID tags. The discussion starts by introducing the host identities and the host identity

The Host Identity Protocol (HIP) supports an architecture that decouples the transport layer (TCP, UDP, etc.) from the internetworking layer (IPv4 and IPv6) by using public/private key pairs, instead of IP addresses, as host identities [15][16]. The public keys are typically, but not necessarily, self-generated. HIP introduces a new Host Identity (HI) namespace, based on these public keys, from which end-point identifiers are taken. Host identifiers are used to bind to higher layer protocols instead of binding to IP addresses. A key benefit of this ap‐ proach is that it is compatible with existing APIs such as the socket API. HIP uses existing IP

Figure 4 illustrates the difference between binding of the logical entities service and endpoints to an IP address (left side of figure). The service typically binds to the IP stack via the socket API. By using the host identity abstraction of the HIP architecture, the service and the end-point bind to the host identity whereas the location is still anchored with the IP address.

End-point

Location IP address

Service Socket

Integrating RFID with IP Host Identities http://dx.doi.org/10.5772/53525 119

Host identity

addressing and forwarding for locators and packet delivery, respectively.

**Figure 4.** Illustration of the difference between the bindings of the logical entities. Adapted from [15].

consisting of a public and private key, it turns IP addresses into pure locators.

There are two main representations of the host identity, the full Host Identifier (HI) and the Host Identity Tag (HIT). The HI is a public key and directly represents the identity. The HIT is the operational representation of a host. It has a 128-bit long representation and is used in the HIP payloads to index the corresponding state of the end hosts. By introducing an iden‐ tity concept at the network layer, where every host is represented by an asymmetric key pair

The proposed HI namespace fills an important gap between the IP and DNS namespa‐ ces. A public key is used as the HIP Host Identity (HI), while the private key serves as proof of ownership of the public key. To seamlessly integrate HIP with protocols above the network layer, a 128-bit cryptographic hash of the HI, i.e., the HIT, was introduced to fit the IPv6 address space. The HIT is a statistically unique flat identifier. When HIP

$$\text{HashInput} \; := \text{ContextID} \; \mid \; \text{Input} \tag{2}$$

$$\text{Hash} \quad \text{:=} \quad \text{Hash} \quad \text{function(} \{ \text{HashInput } \} \tag{3}$$

$$\text{CORCHID} \; := \; \text{Prefix} \; \mid \; \text{Encode}\_n \; \text{(Hash } \;) \tag{4}$$

Concatenation of bitstrings is denoted '|'. The *Input* is a bitstring that is unique within a giv‐ en context. The *Context ID* is a randomly generated value defining the expected usage con‐ text for the particular ORCHID and the hash function to be used for generation of ORCHID in this context. The purpose of a context ID is to be able to differentiate between various ex‐ periments that share the ORCHID namespace. The *Hash\_function* is a one-way hash function to be used to generate ORCHIDs such as SHA1 [23] or MD5 [24]. SHA1 and MD5 produce a 160-bit and a 128-bit output, respectively. *Encoden* is a function to extract an *n*-bit-long bit‐ string from its argument. Finally, *Prefix* is an IPv6 network prefix.

To construct a CGA an input bitstring and context identifier are concatenated to form an in‐ put datum, which is then fed to the cryptographic hash function. The result of the hash func‐ tion is processed by an encoding function, resulting in an *n*-bit-long output. This value is prepended with the network prefix resulting in a 128-bit-long bitstring identifier that can be used for programming with the IPv6 API.

To create a CGA namespace for RFID tags the EPC of a tag and the network prefix assigned to the reader that interrogates the tag are used as input. Furthermore, an Encode64 function is used to extract 64 bits from the hash. A key advantage of using hash values over the ac‐ tual raw host identity resulting from the EPC is its fixed length. This makes protocol imple‐ mentations easier and it alleviates the management of packet sizes. However, a claimed drawback is that CGAs work one-way, meaning that it is not possible directly to create the original identity from the hash.

A CGA can be globally unique or globally unique in a statistical sense. That is, the probabili‐ ty of the same CGA being used to refer to different entities in the Internet must be sufficient‐ ly low so that it can be ignored for all practical purposes. Even though CGA collisions are expected to be extremely rare, collisions may still happen since it is possible that two differ‐ ent input bitstrings within the same context may map to the same CGA. A second type of collision can happen if two input bitstrings, used in different contexts, map to the same CGA. In this case, the main confusion is about which context to use. In order to preserve a low enough probability of collisions, it is required that applications ensure that distinct in‐ put bitstrings are either unique or statistically unique within a given context. By adhering to the EPCglobal standards, this requirement is fulfilled.

#### **3.5. Host identities and host identity protocol**

outlined below [12]. The algorithm takes a bitstring and some *context identifier* as inputs and

Concatenation of bitstrings is denoted '|'. The *Input* is a bitstring that is unique within a giv‐ en context. The *Context ID* is a randomly generated value defining the expected usage con‐ text for the particular ORCHID and the hash function to be used for generation of ORCHID in this context. The purpose of a context ID is to be able to differentiate between various ex‐ periments that share the ORCHID namespace. The *Hash\_function* is a one-way hash function to be used to generate ORCHIDs such as SHA1 [23] or MD5 [24]. SHA1 and MD5 produce a 160-bit and a 128-bit output, respectively. *Encoden* is a function to extract an *n*-bit-long bit‐

To construct a CGA an input bitstring and context identifier are concatenated to form an in‐ put datum, which is then fed to the cryptographic hash function. The result of the hash func‐ tion is processed by an encoding function, resulting in an *n*-bit-long output. This value is prepended with the network prefix resulting in a 128-bit-long bitstring identifier that can be

To create a CGA namespace for RFID tags the EPC of a tag and the network prefix assigned to the reader that interrogates the tag are used as input. Furthermore, an Encode64 function is used to extract 64 bits from the hash. A key advantage of using hash values over the ac‐ tual raw host identity resulting from the EPC is its fixed length. This makes protocol imple‐ mentations easier and it alleviates the management of packet sizes. However, a claimed drawback is that CGAs work one-way, meaning that it is not possible directly to create the

A CGA can be globally unique or globally unique in a statistical sense. That is, the probabili‐ ty of the same CGA being used to refer to different entities in the Internet must be sufficient‐ ly low so that it can be ignored for all practical purposes. Even though CGA collisions are expected to be extremely rare, collisions may still happen since it is possible that two differ‐ ent input bitstrings within the same context may map to the same CGA. A second type of collision can happen if two input bitstrings, used in different contexts, map to the same CGA. In this case, the main confusion is about which context to use. In order to preserve a low enough probability of collisions, it is required that applications ensure that distinct in‐ put bitstrings are either unique or statistically unique within a given context. By adhering to

*Input* : =*anybitstring* (1)

*HashInput* : = *ContextID* | *Input* (2)

*Hash* : = *Hash* \_ *function*( *HashInput* ) (3)

*ORCHID* : = *Prefix* | *Encoden*( *Hash* ) (4)

produces an ORCHID output that is formatted as an IPv6 address.

118 Radio Frequency Identification from System to Applications

string from its argument. Finally, *Prefix* is an IPv6 network prefix.

used for programming with the IPv6 API.

the EPCglobal standards, this requirement is fulfilled.

original identity from the hash.

A host identity is an abstract concept assigned to a computing identity platform. In this sec‐ tion, we will generalize this concept to cover thin compact platforms that can be equipped with RFID tags. The discussion starts by introducing the host identities and the host identity protocol [15][16].

The Host Identity Protocol (HIP) supports an architecture that decouples the transport layer (TCP, UDP, etc.) from the internetworking layer (IPv4 and IPv6) by using public/private key pairs, instead of IP addresses, as host identities [15][16]. The public keys are typically, but not necessarily, self-generated. HIP introduces a new Host Identity (HI) namespace, based on these public keys, from which end-point identifiers are taken. Host identifiers are used to bind to higher layer protocols instead of binding to IP addresses. A key benefit of this ap‐ proach is that it is compatible with existing APIs such as the socket API. HIP uses existing IP addressing and forwarding for locators and packet delivery, respectively.

Figure 4 illustrates the difference between binding of the logical entities service and endpoints to an IP address (left side of figure). The service typically binds to the IP stack via the socket API. By using the host identity abstraction of the HIP architecture, the service and the end-point bind to the host identity whereas the location is still anchored with the IP address.

**Figure 4.** Illustration of the difference between the bindings of the logical entities. Adapted from [15].

There are two main representations of the host identity, the full Host Identifier (HI) and the Host Identity Tag (HIT). The HI is a public key and directly represents the identity. The HIT is the operational representation of a host. It has a 128-bit long representation and is used in the HIP payloads to index the corresponding state of the end hosts. By introducing an iden‐ tity concept at the network layer, where every host is represented by an asymmetric key pair consisting of a public and private key, it turns IP addresses into pure locators.

The proposed HI namespace fills an important gap between the IP and DNS namespa‐ ces. A public key is used as the HIP Host Identity (HI), while the private key serves as proof of ownership of the public key. To seamlessly integrate HIP with protocols above the network layer, a 128-bit cryptographic hash of the HI, i.e., the HIT, was introduced to fit the IPv6 address space. The HIT is a statistically unique flat identifier. When HIP is used, the transport layer binds to HITs. In this process it becomes unaware of the IP addresses that are used for routing.

Upon reception of the *Initiate 2* packet, the responder can now generate the keying material, and it is capable of using it in encryption and integrity protection algorithms. The Response 2 packet completes the HIP Base Exchange. After the Base Exchange, there is no longer dif‐ ference between the Initiator and Responder and data can securely be exchanged between

Integrating RFID with IP Host Identities http://dx.doi.org/10.5772/53525 121

RFID applications are numerous and far reaching [8]. The most interesting and widely used applications include those for security and access control, supply chain management, and the tracking of important objects and personnel. This section outlines a number of common‐ ly encountered use cases for RFID technology, and discusses these in the context of net‐

Access control systems are an important part of the security of government buildings, com‐ panies, schools, residences and private areas and RFID technology has been widely adopted in access control systems. These systems often use RFID identification cards based on the IEC/ISO 14443 [18], IEC/ISO 15693 [19], or IEC/ISO 18000 standards [20]. The identification cards work much like a traditional key for unlocking doors or otherwise granting access. However, RFID technology does not provide authentication to the holder of the RFID card (or tag). Any unauthorized people holding an authorized RFID card could get access to se‐ cured area. Therefore, RFID technology should be combined with other means of identifica‐ tion such as e.g., face recognition to strengthen the security of the access control system.

By associating a passive RFID tag such as a key card with a globally unique IPv6 address we will be able to use access control and security policy mechanisms with Internet technologies to provide the desired access control applications. In this scenario a door locking mechanism

Most supply chain applications involve the concept of inventory tracking. An example of a

To illustrate the potential of using network RFID tags with supply chain applications an ex‐ ample taken from the Tag Data Standard v1.6 issue 2 [10]. The example text is quoted below:

"… a shipment arriving on a pallet may consist of a number of cases tagged with SGTIN identifiers and a returnable pallet identified by a GRAI identifier but also carrying an SSCC identifier to identify the shipment as a whole. If a por‐ tal reader at a dock door simply returns a number of binary EPCs, it is helpful to have translation software which can automatically detect which binary values correspond to which coding scheme, rather than requiring that the coding

would be connected over the Internet resulting in a more open system architecture.

proposed use of RFID is to ensure safety in the supply chain [21].

scheme and inbound representation are specified in addition to the input value."

the communicating peers.

worked RFID tags.

**4.1. Access control**

**4.2. Supply chain management**

**4. Use cases and application examples**

To be able to setup communication between peers that use HI, a light-weighted protocol exchange called the HIP Base Exchange has been specified. In Figure 5, the HIP Base Ex‐ change is adapted to an RFID setup. The setup is somewhat similar to the one presented by Urien et al. [11].

Since the deployed tags are passive, there is a need for a proxy to act on behalf of the tags in the protocol exchange. The role of this proxy will be explained further in Section 5.

**Figure 5.** HIP Base Exchange adapted to a RFID communication scenario. Adapted from [15].

The HIP Base Exchange is a four-way handshake between two hosts wanting to initiate com‐ munication (see Figure 4). The *Initiate 1* packet is the first packet sent in the handshake. It is an unencrypted and unsigned packet, meaning that the Initiator would like to talk HIP with the Responder. The HIP packet contains the HIT of the Initiator (HITI) and the Responder (HITR). The responder's IP address can be derived from the DNS. *Respond 1* is sent as a reply to the *Initiate 1* packet. Besides the HITI-HITR identity pair, it contains a cryptographic puz‐ zle challenge, and Diffie-Hellman parameters (DHR) for the Diffie-Hellman key agreement. The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communication chan‐ nel. Subsequently, the secret key can be used for encryption and integrity protection of the communication channel. The purpose of the HIP puzzle mechanism is to protect the Res‐ ponder from denial-of-service attacks. The *Initiate 2* packet returns the corresponding Diffie-Hellman parameter (DHI) to the Responder. It carries an encoded solution to the puzzle. Upon reception of the *Initiate 2* packet, the responder can now generate the keying material, and it is capable of using it in encryption and integrity protection algorithms. The Response 2 packet completes the HIP Base Exchange. After the Base Exchange, there is no longer dif‐ ference between the Initiator and Responder and data can securely be exchanged between the communicating peers.
