2009 Third International Conference on Digital Society

Near Field Communication Network Services

Jorma Ylinen, Mikko Koskela, Lari Iso-Anttila and Pekka Loula Tampere University of Technology/Pori Pohjoisranta 11 28100 PORI Finland { jorma.ylinen, mikko.koskela, lari.iso-anttila, pekka.loula }@tut.fi Abstract
Near Field Communication (NFC) provides means to close-range contactless identification and communication for mobile phones and other devices alike. NFC is a new technology but it is maturing fast as it is being standardized. The first NFC services have mostly been simple applications but with the expansion of NFC technology and its application areas there is an urgent need to move from stand-alone applications to operator driven service creation and delivery model. In this paper we present a new NFC gateway protocol for network driven services. It is designed to allow network based service creation and delivery for operators and lightweight applications for end users. We also demonstrate and evaluate our implementation of the proposed NFC gateway protocol. powered by the means of inductive coupling in the reading process on behalf of the initiating reader device. The transmission distance is dictated by the size of the reader antenna and it is in practice in the range of few centimeters. Typical Near Field Communication (NFC) service is a standalone application on mobile phone. These applications usually just read Radio Frequency Identification (RFID) tags and are related to daily life issues such as healthcare services. When touching a tag with a reader, the NFC device reads the data stored on the tag, and initiates the appropriate action after the user's confirmation. Usually the data is sent to a background system for further processing. NFC application can, for example, open a Web page, call a favorite number, or send an SMS. Small items such as Web links can also be shared by touching another NFC device. NFC services can also be used to read business card information and save this information to mobile phone contact database. NFC based services are rapidly expanding in different areas, although commercial services are yet few and far between. Almost all hitherto and proposed NFC services are heavily terminal dependent. These terminal driven NFC services are large applications that hoard a lot of terminal resources and pose strict requirements to running environment. Most often these applications are made with mobile Java (J2ME) which might cause slowness and reliability issues. One major problem for terminal driven NFC services is the service delivery process. Application must be downloaded and installed on every phone before the service can be used for the first time. This can be a tedious process and it might even turn away potential customers from the operators point of view. This is why a new network driven service model is needed for NFC applications.

1. Introduction
Recent years have seen an expansion in the use of Radio Frequency Identification (RFID) in industrial sector helping to streamline logistic processes in particular. Near Field Communication (NFC) is a spinoff of RFID with an aim to bring contactless communication for everyday use. NFC is a radio frequency interface intended for interactions between tags and electronic devices in very close proximity. In addition to its primary purpose of use, i.e. contactless identification, NFC also enables payment and ticketing applications and data exchange. The most prominent target device to act as an NFC reader seems to be a mobile phone, although currently NFC is also spreading towards other kinds of electronic appliances and uses, such as automatic pairing and configuration of computer peripherals. NFC is a radio communication technology operating in the open 13.56 MHz frequency band with 106-424 kbps data transfer speeds. The passive tags are
978-0-7695-3526-5/09 $25.00 2009 IEEE DOI 10.1109/ICDS.2009.43 89

Network driven NFC services allow mobile applications to be more lightweight and less complex when compared to their terminal driven counterparts. Using the network driven service model, the complex logic of NFC services can be carried out at network and only the results have to be returned back to mobile device. This paper is structured as follows. Section 2 discusses our research motivation and related work. Section 3 presents our proposal for NFC gateway protocol as an enabler for network driven NFC services. We then go further to discuss protocol security. Section 4 describes our gateway protocol implementation. We open discussion and contemplate on future work in section 5. Section 6 finally concludes the paper.

It has to be straightened out before full-scale commercial services are to be launched.

3. NFC network services

Network driven Near Field Communication services allow mobile phone to utilize network and server resources, which allow NFC services to work as real time. Moreover, this model allows network service operator to decide what services are offered with certain NFC tags. We first describe our proposal for a new NFC gateway service protocol in detail and then go on to discuss the security considerations in communication between client application and NFC gateway. Security issues related to NFC interface itself are out of scope for this paper. They are thoroughly discussed for example in [9]. RFID security issues in general are listed in [10].

2. Motivation and related work

Standardization of NFC is being carried out by Ecma International, ISO, ETSI and NFC Forum. The most important standards for NFC are ECMA-340 (NFCIP-1) [1] and ECMA-352 (NFCIP-2) [2]. Former specifies the RF signal interface and transport protocol including initialization and collision avoidance for wireless communication between closely coupled devices which communicate at data rates of 106, 212, and 424 kbps. Latter specification defines a mechanism to detect and select one communication mode out of ECMA-340 (NFC mode), ISO/IEC 14443 (proximity mode), and ISO/IEC 15693 (vicinity mode), which all operate at 13.56 MHz frequency band but use different protocols. NFC Forum aims for interoperability and compatibility with NFC devices and services. It has released specifications for a common data format (NDEF) [3], standard record types (RTD) [4], record types for plain text [5] and URIs [6] for NFCcompliant devices and tags. Academic research on NFC is yet scarce and biased towards limited and case-specific technical issues. On the other hand, there have been some studies towards more general purpose frameworks involving NFC. For example, [7] present a framework for integrating NFC and rich web applications. The framework accommodates the network side to NFC services but leans very heavily on terminal capacity. A framework for mobile interaction with the Internet of Things has also been suggested in which real world objects are linked to web services described using OWL-S semantic markup language [8]. Operator-scale NFC service creation and delivery have neither been studied nor standardized by anyone.

3.1 Service protocol

NFC gateway protocol is an application level protocol designed for communication between mobile phone and NFC gateway. Its sole purpose is to enable network driven NFC services. Since NFC gateway protocol operates on mobile environment short on processing and memory resources, it must be lightweight. CPU power and memory restrictions are the main reasons why we have chosen to use binary protocol instead of XML-based protocol. The header load of a binary protocol is notably smaller than the header load of an XML-based protocol. NFC gateway protocol is light and it is based on request response technique, i.e. mobile phone sends a service request and server side confirms that the requested service is either available or unavailable. NFC gateway decides what to do after it has received mobile identification and NFC tag identification from the client. Request protocol, represented in Figure 1, is made up of header and identification fields. Header field is constructed of Payload type, Major version, Minor Version and Length fields. These fields determine the type of the message, its version and length in bits.

90

Figure 1. NFC gateway request protocol Sender ID and NFC Tag ID fields compose the Identification field. The Sender ID field identifies the sending party, whereas the NFC Tag ID carries the canonical identification number (CID) of the read tag itself. These two ID fields are used for service selection by the NFC gateway. The length of the Header field is 32 bits. Header field divides into 8 bits for Payload type, 4 bits for Major and Minor Version each and 16 bits for Length. Identification field has 32 bits for Sender ID and 64 bits for NFC Tag ID. Maximum sizes of 64 bits for NFC Tag ID and 32 bits for Sender identification information are well enough.

might be used to provide endpoint authentication and communication privacy. The time interval between two sequential connections to a NFC gateway might be even days. That is why the same socket connection cannot be used. One of main objectives of designing NFC gateway protocol was to provide lightweight and quickly responsive software. TLS negotiation can turn out to be a rather tedious process particularly in case the mobile application has to make a new TLS negotiation every time when it connects to a server. This will eventually slow down the application as well. Figure 3 illustrates a proposal for NFC gateway key negotiation process. Our suggestion is to use TLS only when the first connection to a gateway is established and additionally every time when the getaway requires it. If the TLS connection is successfully established, the client receives a new session ID and a private key. These two keys are then used in the future to identify the user and to encrypt the message with a symmetric algorithm such as the Advanced Encryption Standard (AES).

Figure 2. NFC gateway response protocol Response protocol on the other half is made up only of a header field. Like the request protocol, it also consists of Payload, Major version, Minor Version, Flags and Length. Length field is not currently in use but is reserved for future use. Response protocol is depicted in Figure 2. Payload, Major Version, and Minor Version fields are same as in request protocol. Flags field is a bit field and it contains result of request status. This field is also used to request more information to NFC gateway service. Length field contains only the size of the response message.

Figure 3. NFC gateway key negotiation. After the successful TLS negotiation, Login function is called. Login has a Sender ID as a parameter. Client receives new values of Session ID and Private key calling Startsession function. These two variables can be used in the future to provide secured connection between the client and the NFC gateway. Client can disconnect the TLS connection after it has received a new key pair. In Figure 4, a new secured gateway request protocol structure is illustrated. The green area of protocol is

3.2 Protocol security

During the development of NFC gateway protocol a non-secured protocol was used. However there are some security considerations that must be discussed. First of all, the information transferred between a mobile application and an NFC gateway server contains private information. This information should always be encrypted. Transport Layer Security (TLS)

91

encrypted with symmetric algorithm such as AES. 128 bits is the block size of AES thus padding field is needed to make plaintext length divisible by 128. Sender ID is removed from secured request protocol because it is redundant information. During the key negotiation (Figure 3) Session Key is related to a Sender ID.

single contact identifier. Contact addresses have different priorities depending on the situation. Normally user has to change contact priorities manually which can become laborious or user may even forget to carry out these updates. We have sought to improve the procedure by attaching RFID tags to different communication devices. In our implementation, we have used RFID tags to tell the service where we want our incoming calls to be routed. A tag can be attached for example to a workplace desk, a car dashboard and a home door. The tag can be read by an NFC client. The client then sends the service request message to the NFC gateway, which knows the locations of each and every RFID tag. As the NFC gateway receives the sender ID and RFID tag ID information, it will know where to route all incoming phone calls for that user. Our implementation is illustrated in Figure 5.

Figure 4. Secured NFC gateway request protocol. The sequence number is a counter. NFC gateway must ignore all the packets having smaller sequence number than the biggest one received so far. It will prevent third party from recording the packets and sending them again to the NFC gateway The session ID field locates inside and outside of the encrypted packet. The NFC gateway must check that the session ID inside the encrypted packet is the same as the session ID outside of the encrypted packet. This practice will prevent tampering of the Session ID and it will provide the packet integrity.

4. NFC gateway service implementation

We have implemented our proposed NFC gateway service protocol with Telephone Number Mapping (ENUM) environment. ENUM is a suite of protocols developed by the Internet Engineering Task Force's (IETF's) Telephone Number Mapping Working Group. ENUM defines a Domain Name System (DNS) based architecture and protocols for mapping a standard E.164 telephone number to a Uniform Resource Identifier (URI) used to contact a resource associated with that number [11]. New communication techniques, such as instant messaging and VoIP (Voice over IP) have introduced new ways to communicate. This has brought users many contact addresses and new devices. ENUM wraps users various contact information behind a Figure 5. NFC gateway service architecture We have used Nokia 5140i mobile phone with NFC reader shell as a terminal device in our implementation. A small Java MIDlet application (J2ME) running on a mobile phone acts as a client. The client reads a NFC tag and then creates a network connection in order to send ENUM update request to NFC gateway. ENUM update request contains NFC tag identification and Sender identification. NFC gateway checks received sender identification and RFID tag identification and if the RFID tag is allocated to the sender, the NFC gateway generates a new ENUM update request and sends the update to the

92

ENUM server. The NFC gateway knows what to do after it has verified Sender ID and NFC tag ID. In our solution the NFC gateway generates an update request directing incoming calls to a VoIPclient, a desk phone, a mobile phone or a voicemail.

5. Discussion and future work

When considering operator-scale NFC service creation and delivery it is obvious that several different services must be able to live on server at the same time. Need for multiple coexistent services calls for standardized service description language. As a future work item we are considering a NFC network service description language, which connects services to ID-domains. This means that as a certain ID is received on the server a related service will then be delivered. Functionality depends on the ID and its domain and might require additional information or approval from the client. Mobile payment can be used as an example scenario. In the payment process a customer might be asked for a password. The protocol has to be able to deliver a request for password inquiry to client and carry back this password information to server. This is a prerequisite for the approval of the payment. We have chosen a binary as opposed to a popular XML format for our proposed protocol. We argue that binary protocol is more lightweight and therefore more suitable for mobile environment with mixed types of terminals. XML might provide more flexibility and expandability but those issues have not yet been relevant to us.

and prospects. We have also successfully implemented the protocol in ENUM environment as a proof-ofconcept. NFC gateway service protocol provides service operators a convenient and flexible way to deliver and administer services for their customers. Assigning services to certain tags and certain customers is straightforward.

7. References
[1] Near Field Communication Interface and Protocol, ECMA-340 NFCIP-1, 2nd edition, Dec 2004. [2] Near Field Communication Interface and Protocol -2, ECMA-352 NFCIP-2, Dec 2003. [3] NFC Data Exchange Format, NFC Forum Technical Specification, NDEF 1.0, July 2006. [4] NFC Record Type Definition, NFC Forum Technical Specification, RTD 1.0, July 2006. [5] Text Record Type Definition, NFC Forum Technical Specification, RTD-Text 1.0, July 2006. [6] URI Record Type Definition, NFC Forum Technical Specification, RTD-URI 1.0, July 2006. [7] M. Koskela, J. Ylinen and P. Loula, A Framework for Integration of Radio Frequency Identification and Rich Internet Applications, in Proc. 29th International Conference on Information Technology Interfaces, Cavtat, Dubrovnik, Croatia, 2007, pp. 691-695. [8] E. Rukzio, M. Paolucci, M. Wagner, H.H. Berndt, J. Hamard and A. Schmidt, Mobile Service Interaction with the Web of Things, in Proc. 13th International Conference on Telecommunications, Funchal, Madeira island, Portugal, 2006. [9] E. Haselsteiner and K. Breitfu, Security in Near Field Communication (NFC), in Workshop on RFID Security, Graz, Austria, 2006. [10] H. Knospe and H. Pohl, RFID security, Information Security Technical Report, 9(4), 2004, 39-50. [11] J. Klensin, Ed. The History and Context of Telephone Number Mapping (ENUM), IETF RFC 3245, March 2002.

6. Conclusion
There is a steadily growing demand for mobile contactless communication services on a global scale. NFC seems to be the most prominent candidate for contactless communication technology on a mobile phone. Different kinds of NFC applications and frameworks have already been suggested and piloted by academic and commercial actors. Until now, there has been a distinct lack of research on operator-scale NFC service creation and delivery. In this paper we have proposed a new gateway service protocol for Near Field Communication network services and discussed related security issues

93