A Secure Application Invocation Mechanism in Mobile ...

2012 IEEE International Conference on Consumer Electronics (ICCE)

1569491173

 A Secure Application Invocation Mechanism in Mobile Phones for Near Field Communication Kwanghoon CHOI1, Jaekwon KIM1, Member, IEEE, and Seog PARK2 1 Yonsei University at Wonju, 2Sogang University Abstract—This paper proposes an access control based, secure Near Field Communication in mobile phones. We make NFC tags hold codes of which the execution can make use of mobile services securely under user defined policies.

I. INTRODUCTION NFC (Near Field Communication) is a short range wireless RFID technology that supports a close-coupled device communication. When two parties come near at distances of a few centimeters, some transaction automatically starts. One party becomes inactive behaving as an NFC tag while the other party reads information from the tag to start an appropriate action. NFC offers very convenient mobile experiences. For example, a man-about-town can get information by touching Smart Posters, a photographer can print photos from his or her camera by holding it close to the printer, and even a nontechnician can set up wireless home office with a touch. The NFC forum (www.nfc-forum.org) defined the format and the rules for exchanging data structures through NFC, which is called the NFC Data Exchange Format (NDEF). NDEF records consist of application-specific data structures along with type information. An NDEF message is formed by one or multiple records. There is a set of well-known standard NDEF record type definitions such as Text Record Type, URI Record Type, and Smart Poster Record Type. For example, in a human-readable form, “T” “Hello World” is a text record, “U” “tel:+35891234567” is a URI record, and “Sp” “U” “http://www.nfc-forum.org” “act” “Launch browser” “T” “Hello, world” “(in en-US)” is a Smart Poster record, respectively. To support various application-specific peer interactions, the NFC forum also defined Generic Record Type [5] to provide a common framework for describing arbitrary actions. For example, three NDEF records “Target” “Property Manager”, “Action” “Set”, and “Data” “Silent Mode” “ON” are intended to turn off the volume of mobile phone. The NDEF message handling architecture is shown in Figure 1. On receiving an NDEF message, the software stack analyzes the structure to extract one or more records from the message. It then dispatches the records to the registered RTD (Record Type Definition) handlers by their type information. This research was supported by Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education, Science and Technology (2011-0009225).

978-1-4577-0231-0/12/$26.00©2012 IEEE

The NFC software architecture together with NFC Record Type Definition offers a programmable framework for peer interactions among NFC mobile phones. When two NFCenabled phones come close, an NDEF message flows from one to the other to invoke some application on the receiver to initiate a service. This kind of easy connection of NFC opens up many opportunities for mobile phones to be used to enhance physical encounters.

Figure 1: NFC Record Handling Architecture [12] However, the current practice of NFC-enabled mobile phones poses several security problems. First, the received NDEF messages must be assumed insecure and untrusted. They would cause to make a phone call not permitted or to access your phone book unnoticed. Second, there is no authentication mechanism to associate an NDEF message with an application to handle it in a mobile phone. We may have several handlers for one record type. Third, the meaning of a generic record is application-specific. It would cause interoperability problems as well. Mulliner demonstrated a number of attacks against NFCenabled mobile phone, including Smart Poster URI spoofing that can direct a user’s mobile phone to a premium rate phone number charging high fees [1]. Roland and Langer proposed digital signatures for NDEF records, which will provide authenticity and integrity of NDEF data [2]. Dodson, Bojinov, and Lam analyzed a lot of potential mobile scenarios integrated with NFC to discuss security resolution for attachments to transactions and virtual tokens for replacing physical real-world tokens [3]. This paper proposes a language-based technique that uses active codes rather than passive data for NDEF messages, and we address the discussed security issues by using an existing access control mechanism to protect mobile resources from harmful actions by the codes in untrusted NDEF messages. We solve the first problem by adopting the access control mechanism, and we solve the second and third problems by using the rigorous programming language semantics. This is a

737

new approach to NFC security as far as we know. We will explain the design and implementation of our proposal.

mechanism [6] where users can define arbitrary access control policies. Depending on user’s policy, the interpreter will make a decision whether or not it permits service requests. Figure 2 describes the architecture of an implementation of our proposal. III. EVALUATION

Figure 2: A Secure NFC Code Handling Architecture II. OUR PROPOSAL FOR SECURE NFC SERVICES We view NDEF messages as active codes, rather than passive data, to instruct the recipient’s mobile phones to start some action. Suppose we receive in the standard NDEF format a URI record “U” “tel:+35891234567”, which intends to make a call to the number. In our proposal, we will instead receive a piece of code as follows. Line 1: (define num (Uri.parse “tel: 35891234567”)) Line 2: (define dial (Intent. (Intent.ACTION_CALL$) num)) Line 3: (.startActivity context dial) The code above is written in Scheme, which is a small and semantically rigorous programming language [4]. On receiving the code, we directly run it using an interpreter on the recipient’s mobile phone. The first line will define a phone number. The second line will set up a request (called “Intent”) for a telephony service provided by the Android smart phone platform. The third line will make a call by sending the request to the service provider in the mobile phone. The meaning of such a code is precisely defined by the definition of Scheme [4], and it does not require any application-specific interpretation. The original NDEF URI record, however, may be interpreted differently application by application; on receiving the record, some may make a call, but other may just display the phone number. Users should be able to define and enforce their own policies on access control over mobile services requested by untrusted NFC tags. For example, making a call invoked by the NDEF URI record or by the corresponding Scheme code might not be a desirable action that the user of the recipient’s mobile phone wants to allow. We address this issue by extending a Scheme interpreter with hooks that intercept requests from codes for mobile services. For example, The above code has four places to request services: calling to a method “Uri.parse”, reading a constant “Intent.ACTION_CALL$”, creating an Intent object by “Intent.”, and calling another method “.startActivity”. Our extended interpreter checks permission on such a mobile service request by relying on a well-developed access control

We implemented the proposed idea on Google Nexus S phone supported by a server providing an access control mechanism over Android mobile services. The binary size of the Scheme interpreter extended with hooks is 43.5KB, which is small enough for running on the mobile phone. The access control policy storage contains 91 entries for Android mobile services and 157 entries for Android packages, which can be either enabled or disabled in a fine-grained way by users. We developed five sample codes, including one described in Section II. The average size of the five codes is 192bytes, which is bigger than the size of an NDEF URI record, e.g. 20~39bytes. However, stock NFC tags such as Mifare Label can hold 1K bytes, and so the increased size does not matter much. We measured time interval from discovering an NFC tag until finishing all actions invoked by the tag. It includes time taken for checking permission through the server connected in WiFi, and it includes time taken for executing the code on the interpreter. The total time is 0.565 seconds in average for the five codes (69% for communication with the server, and 31% for execution on the interpreter). We found that an NDEF URI record is processed completely in 0.01~0.005 seconds. Despite the overhead due to the communication and execution, the total time we obtained is not so high enough to do harm to user’s mobile experience with NFC. The experiment result made us believe that we achieved a flexible security mechanism on NFC under the tolerable overhead. IV. CONCLUSION In this paper, we proposed an access control based flexible security mechanism for mobile NFC applications. We demonstrated the feasibility of our proposal by using Nexus S Android phone. REFERENCES [1] [2] [3] [4] [5] [6]

738

C. Mulliner., “Vulnerability analysis and attacks on nfc-enabled mobile phone,” International Conference on Availability, Reliability and Security, p.695-700, Fukuoka, Japan, March 2009. Michael Roland and Josef Langer, “Digital Signature Records for the NFC Data Exchange Format,” 2nd International Workshop on Near Field Communication, p71-76, Monaco, April 2010. Ben Dodson, Hristo Bojinov, and Monica S. Lam, “Touch and Run with Near Field Communication (NFC),” unpublished, October 2010. William Clinger and Jonathan Rees, editors, “Revised4 Report on the Algorithmic Language Scheme,” ACM Lisp Pointers, vol. 4, no. 3, pp.155, 1991. NFC Forum, Generic control record type definition technical specification, July 2006. David F. Ferraiolo, D. Richard Kuhn, and Ramaswamy Chandramouli, Role-based Access Control. 2nd Edition, Artech Print on Demand, 2007.