Passive RFID Technology for the Internet of Things - Semantic Scholar

Download PDF
3 downloads 23938 Views 176KB Size Report
Comment
and the data portion. The basic IPv6 header has a fixed ... This fixed-size basic header can be augmented by so-called ..... [11] S. Kent and K. Seo. RFC 4301: ...
Passive RFID Technology for the Internet of Things Sandra Dominikus, Manfred Aigner, Stefan Kraxberger Institute for Applied Information Processing and Communications, Graz University of Technology fi[email protected]

Abstract RFID tags can no longer be treated as pure bar-code substitutes as their functional capabilities increase rapidly. Many of them are able to store and compute data, or hold sensors. The data flow in the EPCglobal network, which was created for “traditional” low-cost tags, does work oneway: from tags to a couple of servers where data for the tags is stored and can be accessed by other readers or servers. To draw advantage from the increased functionality of the tags it will become important to have a two-way end-to-end communication between servers and tags, e.g. to remotely change data on the tags. In this paper we show how to modify RFID readers and low-cost tags to make them suitable for a remote two-way communication. We consider the required capabilities of readers and tags and show how communication can be done via mobile IPv6. Security considerations round the description before we can conclude, that also passive low-cost RFID tags are able to become part of the future Internet of Things.

1. Introduction In [14] Sarma et al. presented their vision towards an Internet of Things (IoT) on basis of RFID-tagged items. They illustrate a system that allows tracking and tracing of items by individual identification of items on basis of low-cost RFID tags. Meanwhile, the idea has evolved to the de-facto standard in modern supply-chain management. Low-cost RFID tags, as suggested by Sarma et al., are widely available and the EPCglobal network was defined to support open-loop supply chain applications. Although RFID technology is quite accepted in closed-loop applications, the evolvement towards open-loop systems using the EPCglobal network with distributed databases, did not take place as predicted due to major problems in management of access control to the data in such a system. Former RFID tags were considered as mere bar-code replacement. Cost optimization was the main objective during

specification of those tags. Bulk-reading and no requirement for direct line of sight were considered as the main advantages of such tags over bar codes. The main functionality of the EPCglobal network is to provide data assigned to a specific tag, so that each participant, scanning a tag, can store the scanning event in a distributed database in a way that applications can be built on this data. Since the tags were not considered to carry or compute additional data, the EPCglobal network does not provide a mechanism to address remote tags from a networked application while they are in the readers’ reception area. Meanwhile RFID tags provide more functionality: They can store data in non-volatile memory, they provide additional commands for electronic article surveillance, or they can be permanently disabled. Future versions will provide even more functionality, like extended memory, cryptographic authentication, or even sensors. Whenever a networked application would like to store data or change the configuration of the tags via remote readers, addressing of the tags via Internet is required. IPv6 provides an address space that is large enough to include tagged items. It foresees mobile nodes moving from one part of the network to another. In this work we present an approach how to realize the vision of the Internet of Things on basis of passive RFID tags with IPv6 networks. This approach is compatible with current RFID systems and allows direct addressing of RFID tags via IPv6 addresses as long as they are present in the field of a reader that acts as the network bridge. In the following section we give a short overview over the application scenario. Section 3 describes some related work on this topic. This is followed by a short introduction to mobile IPv6. In sections 5 and 6, the requirements for the RFID components are defined and a concept for an RFIDenhanced IoT is elaborated. The paper concludes with some security considerations.

2. Definitions and Motivation In our scenario we have four types of participating parties: the tag manager, the Internet, RFID readers, and tagged items. The tag manager issues and manages RFID tags.

During issuing, an UID and other personalization information is assigned to the RFID tag, which can then be used to tag an item. In many of the cases, the tag manager is also the manufacturer of the item. The intention of the tag manager, in our scenario, is to be able to communicate with the tag to get information from it or to change information stored on the tag. The Internet provides the routing mechanisms for IPv6 communication. Readers are connected to the Internet and are able to “translate” RFID protocol requests into IPv6 messages. The tagged items are mobile and are expected to move through different reader fields. As the tags are passive low-cost RFID tags, they can only be “online” when they are in a reader field. We call the tags, we want to introduce in this paper, IPv6-enabled tags, although they communicate to the reader via their standard RFID protocol. The reader acts as a translator between the RFID protocol and the IPv6 protocol. In figure 1 the communication processes between the parties are shown. Tag Manager

IPv6 RFID Protocol Internet

Reader

Tagged Item

Figure 1. Communication Scenario In this work we address the remote communication between tag and tag manager, but this approach can also be used to allow tag-to-tag communication via the Internet, which is also a very promising feature to create new applications. In our system, two-way communication is possible: the tag (when online) can send a message to the tag manager. This is a similar procedure like in the EPCglobal network, where the reader reports the tag status to a central database. In our approach, also the tag manager is able to contact the tag and send messages to it. Of course, the contact attempt will only be successful if the tag is in a reader field. We think of application scenarios where the tag manager wants to • change the tag status (e.g. revocation, call-back), • write data on the tag (e.g. guarantee, maintenance), • poll the recent tag status (e.g. sensor data).

We assume, that the IPv6-enabled tags remain a certain time in a particular reader field. For high-velocity applications, where tags only remain certain seconds in a field, our approach is not applicable. We also assume, that the RFID readers are polling their environment continuously, so that they can sense each new tag in the field within an adequate time. As shown in figure 1, the passive tags are not able to do IPv6 on their own. In this work we show how such tags can be integrated into an IPv6 network with the use of adapted readers. As the tags are supposed to be mobile and may be online via different readers, we will use the mobile IPv6 approach to handle these tags. In the next section we present some work that has already be done on RFID technology and IPv6.

3. Related Work In 2002, Engels compared the EPC identification scheme with the IP address identification scheme in a paper [4]. He came to the conclusion, that both identification schemes are very similar in structure, but neither of them can be used to replace the other scheme. Both of them are needed to do item-level identification and network communication because IPv6 addresses cannot be used as unique item identifiers and EPCs cannot be used as routing addresses in their original intention. In 2007 Sang-Dong et al. propose to use objects EPCs to create their current IPv6 addresses [13]. They suggest to replace the network prefix (= the 64 most significant bits) of an IPv6 address by the EPC, which only works for 64bit EPCs. The reader accessing the tag generates this IPv6 address from the EPC and transmits it to the corresponding EPCIS server. The reader stores the created IPv6 address as well. The EPCIS server holds information about the current IPv6 address of particular tags (identified by their EPC). If someone wants to retrieve data from the tag, the EPCIS server is asked for the IPv6 address and the tag can be contacted. If the reader receives a message for the particular IPv6 address, it can transmit it to the tag and send back the response to the contacting node. In 2008, Yao-Chung et al. proposed a so-called IPv6EPC Bridge Mechanism [2]. There exist various RFID networks, which are managed as EPCglobal networks. Each network is connected to the IP network via a so-called RFIPv6 gateway. Information about tags are stored in the corresponding EPCIS servers which are part of the EPCglobal network. Nodes outside this network can find information on the tag via the anycast mechanism of IPv6. The reader can identify the EPCIS address through the EPC and the correct sub network can be found via the RFIPv6 gateways, which have unique addresses as well and are derived from the EPCIS addresses. The related work so far is mainly done on EPC tags and

tries to integrate IP technology into the EPCglobal network. As modern tags do highly exceed the functionality of former EPC tags and new applications will appear, two-way end-to-end communication will be required. The integration into the Internet of Things should happen over standard IP technology (IPv6). In this way we are not limited to EPC technology but can handle also other passive RFID standards.

4. IPv6 Basics The specification of IPv6 can be found in RFC 2640 [3]. The most important change is the augmentation of the address space from 32 bits to 128 bits. Based on the most pessimistic estimates of address assignment efficiency, with this address space is predicted to provide over 1500 addresses per square foot of the earth’s surface, which certainly seems like it can serve as basis for an Internet of Things. To get a better understanding of our solution we shortly introduce the main facts of IPv6. Address structure. IPv6 addresses consist of eight 16bit blocks, each block represented by a 4-digit hexadecimal value (ABCD:14D3:0000:1F37:0000:0000:51C2:0000). The address prefix of an IPv6 address is defined as the leading bits and can have a variable length. Depending on the prefix, different types of addresses are defined, e.g. if the address prefix is 128 bits long, the address defines exactly one IPv6 address for a particular device. For global unicast addresses the prefix is fixed to 64-bits which separates the address into a network and a host portion. The 64-bit network portion consists of a network and a subnet identifier. The last 64-bit of an IP address, the host part, form the interface identifier which is unique for each network interface. Thus, one interface identifier can be part of multiple IPv6 addresses which are bound to the same network interface with different prefixes. This fact simplifies the concept of multi-homing. Three types of addresses are defined in IPv6: unicast, multicast and anycast addresses. Unicast addresses are used in point-to-point communication, one address identifies exactly one destination. With a multicast address more than one destinations can be addressed in parallel. A group of IPv6 nodes can share the same multicast address. This is also true for anycast addresses, but an anycast packet is in the first step only sent to one node (e.g. the next reachable) out of the whole group. Afterwards, the packet is delivered to the other members of the group. The concept of anycast addresses can be useful also for mobile networks. Packet Format. An IPv6 packet consists of a fixed-size header followed by multiple optional extensions headers and the data portion. The basic IPv6 header has a fixed

size of 40 bytes (including version, traffic class, flow label, payload length, next header, hop limit, and source and destination address). This is only two times the length of a minimal IPv4 header, although the address fields need 24 bytes more. This fixed-size basic header can be augmented by so-called extension headers, if necessary. Mobile IPv6 (MIPv6). The IPv6 protocol provides concepts to handle mobile nodes. These are nodes which are able to move in the IP network, they can join different subnets over time. In mobile IPv6 (MIPv6) two mobile nodes can establish a point-to-point communication without the intervention of another server. Communication between a fixed node and a mobile node works over a so-called Home Agent, which is a router with MIPv6 capabilities. A mobile node has a home subnet, where the Home Agent is located. The Home Agent always knows the current location of the mobile node. To provide the MIPv6 functionality, a mobile node has to be identified by a EUI64 address (Extended Unique Identifier). This address consist of 64 bits and is composed from the MAC (Media Access Control) address of the mobile node. The MAC address represents a physical LAN address and consists of a Company ID (24 bits) and a Manufacturer ID (24 bits). To convert the MAC address into the EUI-64 format, the Company ID and the Manufacturer ID are separated by two bytes (0xFF and 0xFE). The resulting address is 64 bits long. To compose a 128-bit IPv6 address, the first 64 bits of the address are filled with the subnet prefix. In that way, a mobile node with the same MAC address will always be mapped to the same home IPv6 address (using the home subnet prefix as the first 64 bits). Figure 2 shows the structure of a MIPv6 address. The whole process is called stateless address (auto)configuration and specified in RFC 4862[15] and 4861[12]. 64 bits ... Subnet Prefix

24 bits

16 bits FFh FEh

24 bits

Manufact. ID Company ID 24 bits 24 bits MAC Address

Figure 2. MIPv6 Address Structure As the concept of handling mobile nodes can be also very useful for RFID tags, we shortly describe this concept. If the mobile node leaves the home subnet, the following steps are carried out: • Discovery of new subnet: the mobile node must realize, that it moved to another subnet. This is done with the Neighbor-Discovery-Protocol: each MIPv6capable router sends a Router Advertisement message periodically, which contains the prefix of the subnet.

If the mobile node receives subsequently two different prefixes, it knows that the subnet has changed. • Generation of Care-of Address: the mobile node has to generate a new IP address to indicate where it is currently located. It has to send this address to its Home Agent. The new address is called Care-of Address (CoA) and is generated from the subnet prefix and the EUI-64 address of the mobile node. The mobile node has also to take care, that its address is unique in the current subnet. This functionality is offered by IPv6 with the Duplicate Address Detection (DAD). • Discovery of Home Agent address (if necessary): the address of the Home Agent can be manually configured for each mobile node, but if the Home Agent address changes, the IPv6 protocol also provides the possibility to discover the Home Agent address again (with Home Agent Discovery Request and Home Agent Address Discovery Response). • Setup of Security Association (optional): IPSec can be used to secure the communication between mobile node and Home Agent. Before the CoA is sent, both partners have to agree on the security algorithms used. This is called Security Association. • Home Agent Binding: the mobile node sends its CoA to the Home Agent. The Home Agent stores the new CoA in its Binding Cache. In the Binding Cache all Home Addresses are assigned to the current Care-of Addresses. If the Home Agent receives a packet destined for a particular Home Address, the Home Agent forwards the packet to the assigned CoA using an IPv6 tunnel. The Home Agent also broadcasts to all nodes in the home subnet, that requests for the corresponding mobile node will be relayed by the Home Agent. This is achieved by sending a Neighbor Advertisement which associates the mobile node’s IPv6 address with the Local Link address of the Home Agent. • Correspondent Node Binding (if possible): If the correspondent node is MIPv6-enabled, a point-to-point communication can be established. The mobile node sends the correspondent node its new CoA. If the correspondent node is not MIPv6-enabled, the communication can only take place over the Home Agent. If the mobile node changes the subnet, a new Care-of Address will be generated (with the new subnet prefix). The new CoA is then sent to the Home Agent, which updates its Binding Cache, and to the correspondent node (if necessary). If the mobile node returns to its home subnet, the assignment of the Home Address to CoA is deleted in the Binding Cache and the Local Link address is updated in the

home subnet. If necessary the correspondent node binding is reset to the Home Address.

5. Passive RFID Technology in the IoT As we stated in section 4, we propose concepts from MIPv6 to integrate passive RFID tag into the IoT. These tags can be accessed directly and can thus provide their information to any Corresponding Node (CN) or can also be fed with data. This will be an enabling technology for many future applications. The RFID tags will be treated as mobile nodes. The difference is, that the tags will not implement the IPv6 protocol by themselves but use the readers as a “translators” to the IPv6 network. There are some requirements, that have to be fulfilled to establish our passive-RFID enhanced IoT: • There exists a Home Agent (according to MIPv6), which manages the tags and stores their current location. This Home Agent will relay all IPv6 packets for the corresponding tag. • Each tag holds an unique IPv6 address. • The readers act as IPv6 routers for the tags and manage the communication between tags and the IoT. They also translate the IPv6 packets into RFID standard communication frames and vice versa. • Optionally, there can be an online look-up service, which can be use to derive the IP of a tag from its UID. Home Agent. For each IPv6-enabled tag exists a socalled Home Agent, which manages all assigned tags. When a tag is issued or newly assigned, the Home Agent creates a new item in a database, where all assigned tags are registered with their UIDs and their Home Addresses. The Home Address consist of the subnet-prefix of the Home Agent and the tag identifier (= the 64 least-significant bits of the IP address), which uniquely identifies the tag at the Home Agent site. If a tag enters a reader field, a Care-Of Address (CoA) is created, which is the IP address where the tag can currently be reached. It consist of the subnet prefix of the reader and the tag identifier. This CoA is also stored in the Home Agent’s database to be able to relay the communication for the tag to the correct location. In principle, communication with an IPv6-enabled tag works like communication via MIPv6. The CN wants to send an IPv6 packet to a particular tag. Therefore, it has to know the Home Address of the tag. If the CN does not know it anyway, it has to know at least the UID of the tag. With this information, the IP address of the tag can be found by an online look-up service, which works similar to DNS in IP technology. For our scenario, we suppose, that the

tag manager wants to contact an assigned tag. Therefore he does not only provide the Home-Agent service but is also the CN and the IP address of the tag is known. Therefore, an online look-up service is not required for our applications.

re s

po ns e

RFID request 4 RFID Tag

RFID response

2

5

3

Header Manager # 8 bits 28 bits

Obj. Class 24 bits

Serial # 36 bits

Reader

Figure 3. Communication Principle Figure 3 shows how the communication with an IPv6enabled tag will be established. The CN sends the packet via an IPv6 network (1). First the packet is sent to the Home Agent as the IP address starts with the subnet prefix of the Home Agent. From the IP address (=Home Address) the Home Agent can derive the UID and the CoA. Then the IPv6 packet is forwarded to the CoA(also via an IPv6 network) (2). The CoA refers to the subnet of the RFID reader, where the tag is currently present. The reader receives the IPv6 packet and looks up in its routing table which UID is related to the received IPv6 destination address. The payload of the packet is translated into an RFID request for the tag and sent via RF to the tag (3). The tag answers with an RFID response (4). The response has to be translated into an IPv6 packet. This packet is either sent back to the Home Agent (5) which relays the packet to the CN (6) or sent to the CN directly with the CoA as source address (7). Depending on the CN (if it is MIPv6-capable or not), further connection can be established directly with the reader or via the Home Agent. Addressing Tags. The first approach to find IPv6 addresses for tags is the mapping from the UIDs to an IPv6 address, i.e. the bits from the UID are used to form the IP address. The advantage of this approach would be, that no extra memory space is needed on the tags and that Corresponding Nodes only need the UID of a tag to derive the IP address. As different passive RFID standards exist (e.g. [9], [10], [8]), there is no common UID structure for tags. Even within standards, there are different types of UIDs with dif-

Figure 4. Structure of GID-96 Identifier An IPv6 address consists of 128 bits, which means we have to map some of the 96 bits from the EPC to an IPv6 address. In section 4 we described the structure of an IPv6 address: it consists of 64 bits to identify the subnet and of 64 bits to identify the mobile node itself. The GIC-96 identifier consist of some bits to identify the company, which manages the tags (General Manager Number), and some bits to identify the type of item (Object Class) and the item itself (Serial Number). Thus, the General Manager Number can be used for the subnet prefix of the Home Agent and the Object Class and Serial Number should be used for the tag identifier of the IPv6 address. In figure 5, the size of the required IPv6-address fields are compared with the information gained from the 96-bit tag identifier. Subnet Prefix (64 bits) Tag Identifier (64 bits) Manager # Obj. Class Serial # 36 bits 28 bits 24 bits 36 bits

4 bits

IP v6

IPv6 response

7

IPv6 request

Corresponding Node Home Agent IPv6 request 1 6 IPv6 response

ferent structures. This means, that a general concept to map tag UIDs to IPv6 addresses will not work. In the following, we will give an example how mapping could work for a GID-96 identifier of EPC tags: A GID-96 identifier consists of 96 bits, which are arranged in header, serial number, an object class, and a manager number. Figure 4 shows the structure of a GID-96 identifier. The header consists of 8 bits. It is followed by a 28-bit General Manager Number. This number is a unique identifier for the manager of this object (corresponds to the Home Agent), which is responsible for the assignment of the following fields (serial number and object class). The Object Class is encoded as a 24-bit value. This value must be unique within the General Manager domain and identifies the object type. The 36-bit Serial Number is unique within an object class and identifies a particular entity of an object.

Figure 5. Mapping of GID-96 to MIPv6 The General Manager Number holds only 28 bits and the subnet is decoded with 64 bits, therefore 36 bits for the subnet-prefix are missing. A direct mapping could be done at the reader site (e.g. padding), but this would reduce the address space of the Home Agents to 28 bits. Another problem occurs if the subnet prefix is derived directly from the UID. We consider the tags to change their manager during lifetime. If the Home Agent address is coded in the UID it cannot be changed in case of an ownership transfer. As the 64 most-significant bits of the IPv6 address (tag identifier) should define the tag, the tag specific parts of the

Look-Up Service. If the IP address is unrelated to the UID of a tag and the CN does not know the IP address of the tag, it cannot derive it from the UID. In this case, a look-up service can help. The look-up service can map registered tag UIDs to their current Home Addresses. When a tag is issued, the Home Agent registers the tag at the look-up service with its UID and the new MIPv6 address. If the Home Agent of a tag changes, the entry at the look-up server is modified by the previous Home Agent. The modification of the data stored on the look-up server should only be done by authenticated Home Agents. The look-up service should work similar to DNS in an IP network. Readers as Routers. Readers communicate with the tags via RFID protocols and should be able to receive, process and send IPv6 packets. Readers are in general connected to a computer in order to control the reader and process the data gained from it. Also reader applications are controlled by the computer. As most of the computers are connected to the Internet, we assume that in the future Internet (of Things), these computers are able to handle IPv6 packets. We see the reader and the connected computer as one entity and use the term ”reader“ to refer to this entity. So we define that readers are able to handle IPv6 packets. The reader must act as a router for the tags in its field. The reader continuously polls its environment for new tags. This is a standard functionality of an RFID reader. If a new tag enters the reader’s field, the UID is recognized and further processed. In our case, the tag indicates (e.g. with a flag in the inventory response) that it is IPv6-enabled. If this is

the case, the reader obtains the IP address of the tag and creates a new CoA: The 64 least-significant bits of the address should be the same as for the IPv6 address of the tag. The 64 most-significant bits are filled with the subnet prefix of the reader. The reader uses the original subnet prefix of the tag address as destination address to send the new CoA to the Home Agent. Figure 6 shows the updating process. Reader

Home Agent

5 Subnet Part of prefix IP CoA Inventory 1 2

UID get IP

RFID Tag

4

6

UID CoA

UID could be used to fill up this part of the address. In our case, these parts are the Object Class and Serial Number. They consist of 60 bits, i.e. 4 bits are left. These 4 bits can be padded without reducing the address space, because at the Home Agent site, the Object Class together with the Serial Number must identify one item uniquely. If the Home Agent only issues 60-bit identifiers, no more than 260 items can be issued anyway. But an ownership transfer can be a problem also for the tag specific part of the IP address. The Tag Identifier is unique within the Home Agent domain, but this is not guaranteed for a new Home Agent domain. As we described above, there are some problems if the mobile IP address of an RFID tag is derived from its UID, therefore we propose another solution: when a tag is issued, the Home Agent creates a unique new Home Address for the tag. This IP address is stored on the tag and can be read out by a custom command. If the owner (or manager) of a tag changes, a new IP address, which is unique in the new domain, is stored on the tag. This solution needs more memory space and a little more time (for the request to get the tags’ IP) but has the advantage that it is a more general solution which works for all RFID standards.

IP

3 Reader

Figure 6. Address updating for MIPv6 tags In the figure, the reader sends an inventory request (1), which is responded with the UID of the tag (2). The tag has indicated via a flag, that is IPv6-enabled, therefore the reader sends a custom command (getIP) (3) and receives the IP address of the tag (4). The reader creates the new CoA for the tag (5) and sends it together with the UID to the Home Agent (6). The IP address of the Home Agent is derived from the tags’ IP address. The Home Agent updates its database with the new CoA of the tag. The reader itself will add the tags’ CoA in a ”routing table“. In this table, also the IP address of the Home Agent and the RFID communication standard for the tag will be stored. One further advantage of using the MIPv6 concept is the possible use of anycast addresses. The Home-Agent service for RFID tags can be distributed over various servers which have anycast addresses, i.e. if there is a IPv6 packet for an RFID tag, the first Home Agent which receives the packet can forward it. So, the Home Agent service is also available if one ore more servers are down. If there is address updating, the Home Agents forward the updating information, until all servers are up to date. The reader has to act as translator from IPv6 to RFID standard communication. In the simplest case, the reader can extract the data content from an IPv6 packet and sends it to the tag corresponding to the destination IP address. In this case, the CN has to act as a remote reader and chooses the correct RFID protocol to talk to the tag. The CN has to create the correct RFID requests and wraps it into an IPv6 packet to send it via the Internet. The reader extracts the data and relays the RFID frames to the tag. Another approach is, that a public command suite can be created and

7. Security Considerations One of the main topics when building an Internet of Things is security. As we have seen in the traditional Internet, applications are not successful unless they provide

Corresponding Node 1

Home Agent

read challenge 6 7 response data 12 2

read req. 3 4 challenge

RFID Tag

response 9 10 data

5

data

8 response

IPv6 functionality for passive RFID technology does not come for free. In this section we summarize the new requirements for RFID components in order to integrate them into a future Internet of Things. We assume mobile tags which change the reader field from time to time, but stay in the same reader field for a certain time. We do not consider high-velocity applications as primary application area. RFID tags do not require too much additional functionality. They need extra memory to store the IP address (128 bits). Two custom commands will have to be implemented (getIP and changeIP for transfer of ownership). Alternatively, this can also be done by a read and write command at a specified location in the memory. The execution of a protocol will take some more time than a standard RFID protocol, but timing is not considered as primary problem. The real complexity is shifted to the reader. The reader has to provide router functionality of an IPv6 router. Special functions which the reader has to provide are the translation of the commands (IPv6 packets to RFID commands and vice versa) and the communication flow control between the CN and a particular tag. This functionality is completely new and will require some further investigation. The implementation of router and translator functions on the reader site should be no problem as we assume, that a reader has enough hardware resources available to handle these new requirements.

challenge

6. Requirements for RFID Components

an appropriate level of security. We suppose that this rule will also be true for the Internet of Things. For securing an IPv6 communication, well-known approaches exist: IPSec is a protocol that provides authentication and confidentiality for an IP communication [11]. For the connection between IPv6 nodes (Home Agent, Corresponding Node (CN), reader) no additional security services have to be provided, as they already exist. But the communication line between Corresponding Node and IPv6enabled tag is not secured, because the security depends on the behavior of the reader, which controls the IPv6 communication with the Corresponding Node. The tag cannot trust the reader, therefore a new security layer for this communication has to be implemented. For the applications which we have in mind (change of tag status, polling of tag information), the CN should authenticate itself against the tag before being able to access the tag’s data. Also encryption of the tag information sent over the IP network should be provided. Passive RFID tags can already be cryptographically enhanced, they can already perform symmetric and asymmetric encryption algorithms (e.g. [5], [6], [7], [1]). Authentication can be done using a challenge-response protocol between tag and CN and confidentiality can be provided by encrypting the tag responses. Privacy for the tags is not considered in this paper, as we think that if a tag should be addressable within an IP network it must reveal its identity.

read

the CN can send reader commands via IPv6 packets. The reader will then translate it into the correct RFID frame for the destination tag, send it to the tag, and send back the response as an IPv6 packet to the CN. The reader remembers the IP address a request came from, to send the corresponding response back to the CN, i.e. that the reader also stores the last IPv6 packet received for any tag in its field. If a response from the tag arrives, the source address of the stored packet is used as destination address for the IPv6 response. In our scenario, the tag does not initialize an IPv6 communication, therefore it is always a previous IPv6 packet with the address of the CN available. Nevertheless, there will be applications, where the tag wants to start the IPv6 communication (e.g. the tag has to report some actions to a server). In that case, the functionality of the tag must be extended to be able to indicate the destination address of an IPv6 packet, but this case is out of scope of our paper.

11

Reader

Figure 7. Secure Connection for IPv6 Tags In figure 7 a secured communication between CN and tag is shown. In this case, the CN wants to get some data from the tag. The read request from the CN is sent to the Home Agent which relays the message to the Care-Of Address of the tag. The reader receives the message and translates it into an RFID frame which it sends to the corresponding tag. The tag response indicates, that it wants an authentication from the CN and sends a challenge back to the reader. The

reader translates the tag response into an IPv6 packet and returns it to the CN. The CN encrypts the challenge with its private key and sends the response back to the tag (same procedure as before). The tag checks the response and, if successful, it encrypts the requested data and sends it back to the CN. This mechanism is only a basic concept and still suffers from some insufficiencies, e.g. also the tag should authenticate itself against the CN. Another point to consider is, that the tag cannot be sure, that the CN does not change between two requests (= session hijacking). This problem does not exist in ”traditional“ RFID technology because the reader polling the data is physically present. In our scenario the CN is only remotely connected. For reading this is not that problem, because an unauthorized CN is not able to process the encrypted tag response. For writing, other security protocols have to be considered, e.g. only encrypted requests are handled by the tag. Another solution for the problem is the usage of IPSec, i.e. that session keys are used and the reader can control if the CN changes. Then, the tag has to trust the reader and indicate that the IP communication should use IPSec. Anyway, the reader or the CN can decide to use IPSec for the communication or not. This section only shows some basic considerations about a security layer for IPv6-enabled RFID tags, but there are many points left for further investigation.

8. Conclusion In this paper we provided a concept to integrate passive RFID technology into the Internet of Things. Many new applications will be possible if RFID tags can be accessed via the Internet. We looked at concepts from mobile IPv6 technology and came to the conclusion, that these concepts also work for passive RFID tags. We elaborated a system consisting of a Home Agent(which manages tag information), RFID readers (which act as routers and translators), IPv6enabled tags holding IPv6 addresses, and a optional online look-up service. The overhead to create IPv6-enabled tags is minimal. Most of the complexity of the system is shifted to the readers, which have in general enough resources available to manage this challenge. The particular implementation of the reader software managing is one major point in the future. Security is another important topic for a RFIDenhanced Internet of Things. In the last section, we gave some starting points for a security discussion in this scenario. For providing secure communication in our concept, some more functionality is required also on the tag, but, all in all, for many applications the additional benefit does exceed the overhead. There are many open questions left for future research. With this paper we hope to give an impulse via IPv6-enabled passive RFID devices.

References [1] H. Bock, M. Braun, M. Dichtl, E. Hess, J. Heyszl, W. Kargl, H. Koroschetz, B. Meyer, and H. Seuschek. A Milestone Towards RFID Products Offering Asymmetric Authentication Based on Elliptic Curve Cryptography. Invited talk at RFIDsec 2008, July 2008. [2] L. Y.-S. Chang Yao-Chung, Chen Jiann-Liang and W. ShiMing. RFIPv6 - A Novel IPv6-EPC Bridge Mechanism. In Proceedings of the IEEE International Conference on Consumer Electronics, Januar 2008. [3] S. Deering and A. Hiden. RFC 2460: Internet Protocol, Version 6 (IPv6) Specification, December 1998. [4] D. W. Engels. Comparison of the Electronic Product Code Identification Scheme & the Internet Protocol Address Identification Scheme, June 2002. [5] M. Feldhofer, S. Dominikus, and J. Wolkerstorfer. Strong Authentication for RFID Systems using the AES Algorithm. In M. Joye and J.-J. Quisquater, editors, Cryptographic Hardware and Embedded Systems – CHES 2004, 6th International Workshop, Cambridge, MA, USA, August 11-13, 2004, Proceedings, volume 3156 of Lecture Notes in Computer Science, pages 357–370. Springer, August 2004. [6] M. Feldhofer, J. Wolkerstorfer, and V. Rijmen. AES Implementation on a Grain of Sand. IEE Proceedings on Information Security, 152(1):13–20, October 2005. [7] D. Hein, J. Wolkerstorfer, , and N. Felber. ECC is Ready for RFID - A Proof in Silicon. In Workshop on RFID Security 2008 (RFIDsec08), July 2008. [8] International Organisation for Standardization (ISO). ISO/IEC 18092: Information technology - Telecommunications and information exchange between systems - Near Field Communication - Interface and Protocol, April 2004. [9] International Organization for Standardization (ISO). ISO/IEC 18000-3: Information Technology AIDC Techniques — RFID for Item Management – Part 3: Parameters for air interface communications at 13.56 MHz, March 2004. [10] International Organization for Standardization (ISO). ISO/IEC 18000-6: Information Technology AIDC Techniques — RFID for Item Management – Part 6: Parameters for air interface communications at 860-960 MHz, 2004. [11] S. Kent and K. Seo. RFC 4301: Security Architecture for the Internet Protocol. RFC 4301 (Proposed Standard), Dec 2005. [12] T. Narten, E. Nordmark, W. Simpson, and H. Soliman. Neighbor Discovery for IP version 6 (IPv6). RFC 4861 (Draft Standard), Sept. 2007. [13] L. Sang-Do, S. Myung-Ki, and K. Hyoung-Jun. EPC vs. IPv6 mapping mechanism. In The 9th International Conference on Advanced Communication Technology, volume 2, pages 1243–1245, February 2007. [14] S. Sarma, D. L. Brock, and K. Ashton. White Paper: The Networked Physical World. MIT-AUTOID-WH-001.pdf, October 2000. [15] S. Thomson, T. Narten, and T. Jinmei. IPv6 Stateless Address Autoconfiguration. RFC 4862 (Draft Standard), Sept. 2007.