Cloudlets Authentication in NFC-based Mobile ...

Cloudlets Authentication in NFC-based Mobile Computing Samia Bouzefrane CEDRIC Lab Conservatoire National des Arts et Métiers - CNAM Paris, France [email protected]

Amira F. Benkara Mostefa Computer Science Department University of Science and Technology Mohamed Boudiaf, Oran, Algeria [email protected]

Abstract— The availability of NFC capabilities on smartphones has facilitated the development of a large number of related applications. Some of these applications may be resourceintensive tasks; and Cloudlets-based mobile computing are a good candidate to offload computation while being free of WAN delays, jitter, congestion, and failures. In this context, new use cases dedicated to NFC applications based on cloudlets are presented and a security protocol is proposed to authenticate the cloudlets by the mobile devices. The secure element of the mobile device is a trust environment used to store sensitive data and to perform cryptographic calculations. Index Terms—mobile computing, secure element, NFC, cloudlets, authentication.

I. INTRODUCTION According to Cisco [1], “about 36 percent of worldwide mobile service revenues come from data; by 2016, it will increase to 46 percent. Similarly, the 1.3 exabytes per month of mobile data traffic generated today is expected to increase eight-fold by 2016”. Mobile devices will more and more deal with heavy computation tasks because principally of the huge size of data that will be more and more manipulated. Besides the growing of data exchanged, these last years NFC services are becoming reality through the deployment of applications in many countries [2] such as: mobile payment, epassports, e-ticketing, mobile wallet (called Suretap in Canada or Orange Cash in France to deploy on 2014). While the use of secure element is common in mobile NFC applications, it is vulnerable to security-related issues that arise from the use of untrusted cloudlets for storage and to process applications. The contribution of this paper is to propose a security protocol, in the context of NFC platforms, to authenticate cloudlets before soliciting them to offload computation. Section 2 recalls the architecture of NFC platforms. Section 3 describes the different architectures that may implement a Mobile Cloud Computing model while focusing on the cloudlets architecture. Section 4 gives some motivations to the combination of NFC and cloudlet concepts through some scenarios. Section 5 details the authentication solution proposed to authenticate cloudlets. Section 6 concludes the paper with some perspectives.

Fatiha Houacine, Hervé Cagnon CEDRIC Lab Conservatoire National des Arts et Métiers - CNAM Paris, France [email protected] [email protected] II. NFC PLATFORMS

The growing availability of smart phones equipped with NFC functionality is boosting developers’ interest in the design and the development of NFC applications. For example, in France, AFSCM association [3] has gathered many companies from industry to specify the necessary steps to develop and deploy NFC applications called Cityzi applications. These specifications allow the promotion of the contactless domain and guarantee the interoperability through the use of distinct mobile network operators. In the following, we describe the different entities involved in an NFC application. A. Secure Element A smartcard is a tamper resistant micro-controller [4] whose security is enforced by multiple software and hardware countermeasures. A secure element (SE) is a smart card embedded in a mobile phone, able to store sensitive data such as PIN code and security keys and perform internal computation such as cryptographic processing when needed by the terminal (phone). The SE is generally a Java Card platform composed of a Java Card Virtual Machine (JCVM), a Java Card API and a Java Card Runtime Environment (JCRE). JCRE implements the Java Card mechanisms that are intrinsic to the smart cards such as transaction management. When the SE is a SIM card, it is enriched with Java Card packages that allow interaction with the Mobile Network Operator (MNO) such as sending SMS, generating a phone call, etc. In addition, Java Card platforms are designed in respect to Global Platform specifications [5]. In other terms, each Java Card platform is composed of isolated E²PROM areas called security domains (SD). A SD is assigned to one service provider (SP) and may contain one or several applications belonging to the same SP. Each Java Card application is composed of one or several Java Card applets, generally called Cardlets. In the remainder of this paper, we focus on a SIMcentric approach that involves the contribution of MNO when designing NFC-based mobile applications. B. NFC-Enabled Mobile Applications As in Fig.1, each NFC device has a NFC controller that allows a contactless communication with respect to three modes: Read/write mode: the application running on the mobile device is able to read and write data on RFID tags

-

-

according to an NFC Data Exchange Format defined by NFC forum [6]. Since 2010, Google proposed an API to implement this mode. Peer to peer mode: called Android Beam in Android platforms, this mode allows a tap of NFC devices together to exchange data between them. Emulation card: unlike the other modes, the emulation card mode involves the use of a SE and allows communication between the mobile and a contactless reader. In case SE is a SIM card (see Fig.1), a Single Wire Protocol (SWP) connects the SIM card with the NFC controller to perform the communication with the contactless smartcard reader infrastructure.

service operator in Cityzi projects. To design a Cityzi application, the service operator has to develop: - A cardlet, stored on the SIM card of his client, it contains all the sensitive data of the Cityzi application. - A mobile application, stored on the Cityzi device, to serve as a Human Machine Interface and to allow the end user to interact with the Cityzi services. - An NFC platform of the service operator that allows access to the remote cardlet once the cardlet is installed via OTA platform of the MNO. The NFC platform can be managed internally by the service operator or by an external partner like the TSM. Whatever the case, the SP needs to establish a contract with the MNO to have access to a security domain of the SIM card. III. MOBILE CLOUD COMPUTING ARCHITECTURES

Fig. 1. NFC mobile device

In a SIM-centric solution, the mobile is assimilated to the SIM card. The contactless terminal sends APDU commands to the SIM card through the NFC controller. In addition to these NFC modes, there is a usual functioning in the mobile phones with or without NFC capabilities, to interact internally with the SIM card through APDU protocol. C. Mobile Network Operator (MNO) Each SIM card embedded in a mobile phone is provided by a MNO. Before the introduction of NFC technology, the security domains of a Java SIM card were used and managed solely by the MNO. However, with the growing of NFC mobile development, trust entities that are independent from the MNO such as TSM (Trusted Service Manager) have access to the SIM card to install applications. In France, AFSCM association [3] proposes a development and deployment process of NFC platforms by allowing each SP to establish a contract with a MNO to have access to the SDs of the SIM card. This is a great step forward in the field of NFC because it opens the SIM platform to other service providers while guaranteeing security. In Cityzi1 platforms for example, the MNO makes available to the SP a secure memory space on the SIM card, and sets up a system to download and block OTA applications, while offering a customer support service. D. Service Provider (SP) The SP is in charge of the design of the application. It offers services to the end user. The service provider is called 1

http://www.Cityzi.fr/

To highlight the motivation for mobile cloud computing, different architectures in the literature [7, 8, 9, 10, 11] have been defined to cater to different use cases in mobile cloud computing. The major benefit of cloud computing for mobile devices is to enable running applications between resourceconstrained devices and Internet-based Clouds. Hence, resource-constrained devices can outsource computation/communication/resource intensive operations to the cloud. Mobile cloud applications based on mobile cloud collaboration may deploy their components into different places including local smart phone, virtual machines in cloud and cloudlets. The principal motivation of offloading is to achieve less execution time and less energy consumption within mobile devices. In the following, we describe the possible architectures for mobile cloud computing. A. Cloud computing with mobile devices Commonly, mobile cloud computing means to prolong the capabilities of storage/computation-limited devices, and to provide seamless access to data/application on a remote resource rich server from anywhere. The network connectivity from the device to the cloud server needs to be optimized to ensure the quality of service and seamless handover. B. Virtual cloud computing provider Another approach [12] is to build up a cloud with peer-topeer connected mobile devices for data storage and processing so that mobile devices are resource providers of a virtual cloud. Through Hyrax platform, the author in [13] demonstrates the possibility of building a cloud with mobile devices such as Android smartphones to provide basic functions and services. C. Cloudlets as Intermediate Offload Elements Similar to the concept of hotspots, the cloudlet concept proposed by Satyanarayanan [14] is another approach to mobile cloud computing. Cloudlet approach is an alternative solution to remote cloud server which would present latency and bandwidth issues. Indeed, a cloudlet is viewed as a multicore computer installed in the public infrastructure with connectivity to remote cloud servers. Hence, the cloudlet is

used by the mobile device to offload its workload while ensuring low delay and high bandwidth. Simanta et al. in [15] proposed an example of implementation of the concept of cloudlets with the objective of enhancing processing and conserving battery power in the mobile devices notably in hostile environments where networks are unreliable. The key feature of the architecture is that offload elements are stateless. Communication between the cloudlet and the cloud core is done only during setup and provisioning. Once the cloudlet is provisioned, it works in a disconnection mode with the core and in a connection mode with the mobile device. When a mobile device is connected to a cloudlet, an application overlay is offloaded from the mobile device to the cloudlet. An application overlay represents the difference between a base VM with only an operating system installed and the same VM with the application installed. The cloudlet may host multiple VMs. An overlay is associated to one application and is calculated through a VM synthesis process as in the following: Firstly, the Base VM is composed of a VM disk image file (such as Windows) and is provided by the core. It is saved to the cloudlet that runs a VM manager. Secondly, the VM manager starts the Base VM and installs the application. The obtained VM is shut down and a copy of this VM is saved as the complete VM disk image. Thirdly, the application overlay is obtained by performing a binary diff between the complete VM disk image and the Base VM disk. The Base VM is then deployed to the cloudlets and the corresponding application overlays are carried by the mobile devices. Consequently, the mobile app can locate a nearby cloudlet and offload its overlay to run it on the cloudlet without any configuration. Basically, the cloudlet host is a physical machine that hosts: 1) a discovery service that broadcasts the cloudlet IP address and port; 2) the Base VM Image to make VM synthesis; and 3) the Cloudlet Server that handles the Complete Base VM launched by the VM manager. On the other hand, the Mobile Client is a mobile device that hosts the Cloudlet Client app that discovers cloudlets and uploads application overlays to the cloudlet. IV. COMPUTATION-INTENSIVE NFC MOBILE APPLICATIONS Niroshinie et al. in [7] discuss different application domains, from literature, that are suitable to mobile cloud computing, such as image processing [14], natural language processing [12], crowd computing [16], sharing GPS/Internet data [12, 13], Sensor data applications [13], Multimedia search [14], etc. As an image-processing based scenario, the authors in [14] have used an application called an optical character recognition (OCR) to extract words from images using mobile devices. This application can be used by a foreign traveler to translate the extracted words into a known language. Another scenario is given in [12] where a tourist visits a museum in South Korea. He sees an interesting exhibit, takes a picture of the text in

Korean and launches an OCR app on his phone to get the translation of the text into English. Marinelli [13] proposes to share GPS/Internet data in order to decrease the cost and delay. In fact, it is more efficient to share data among a group of mobile devices that are near each other, through local-area or peer-to-peer networks. Another use case described by [12] is that: instead of downloading a P2P file from the internet over an expensive interface (GPRS, UMTS, LTE etc), a mobile user scans using Bluetooth for a nearby device which has downloaded the needed file and retrieve it in the vicinity. Since most mobile phones are equipped with sensors (light sensor, GPS, accelerometer, microphone, thermometer, compass and clock), the phones can behave as service providers by sensing data from the environment that are synthesized within a Cloud. Mobile devices store many types of multimedia content such as videos, photos, and music which can be shared by other users. Hence, multimedia files can be searched in the contents of nearby mobile devices [14]. These data can be used by applications for traffic reporting, sensor maps, etc. All these application examples from different domains show the suitability of the Cloud in mobile computing while the resource provider depends on the architecture. In a remotecloud server architecture, the cloud provides resources to the mobile devices through the internet. To bypass latency and bandwidth issues, the cloudlet based architecture is proposed to enable mobile device benefit from the cloudlet resources. In the vicinity, a virtual resource cloud made up of mobile devices may be used as resource providers. Regarding mobile devices, the NFC controller is viewed as an additional sensor with the ability of reading and sharing data at a distance less than 10 cm from the data source. According to the preceding scenarios and NFC modes, we can imagine: R/W NFC mode: Reading a RFID tag of a smart poster for example to access via an URL data hosted on a cloud with respect to remote-cloud server architecture. P2P NFC mode: Sharing data files (images, video, etc.) by taping mobile devices together instead of getting these data from the cloud, to reduce the bandwidth consuming. In the image processing example of [14], the image of mobile device A can be shared with a device B to benefit from the OCR application installed on device B. Many devices may form a virtual resource cloud. Emulation card NFC mode: The typical application used in this case is the mobile payment where purchasing an eservice needs the authentication of the user and the confidentiality and integrity of the banking transaction. These security properties are guaranteed thanks to the secure element that is assimilated with the mobile device to launch security procedures when accessing via a contacless reader to a remote cloud server. To motivate the use of cloudlets, in the following subsections, we describe two use cases that can be based on cloudlets rather than on a cloud-server approach.

A. Smart Poster scenario based on Cloudlets NFC Forum [6] has defined NFC Smart Posters as objects in or on which readable NFC tags are placed. An NFC Smart Poster can be a poster, billboard, magazine page, a statue of a movie character, etc. The common factor is an NFC tag that has an NDEF message stored in it and is attached or embedded in the desired medium. This small tag with information is read when an NFC mobile device is held close to it. Examples of read information: a web address for buying sports tickets, a timetable displayed at a bus stop, etc. Smart Posters are attractive to retailers, transport agencies, health care providers, and any entity that has information to share. They can be created by advertising agencies or in-house departments that develop communications materials. We can consider the scenario of [12], where a foreign tourist is visiting the museum of South Korea. If an RFID tag is attached to the exhibit, he can read the tag with his mobile phone to get additional information from a remote server. The information can come in many forms as required by the NDEF message: text, images, video, audio, etc. In this scenario, if the information related to the exhibit is in Korean, the tourist can offload this information to a cloudlet in order - to get the translation of the text information or - to extract the text from the image using OCR application on the cloudlet if the information is an image (see Fig 2).

Fig. 2. Example of a Smart Poster using a cloudlet

B. P2P scenario based on Cloudlets Assume that there are two friends Robert and Pascal from France that are visiting the museum of South Korea. Robert has a Client-Cloudlet app installed on his mobile phone while this is not the case of Pascal. As they have all together NFC mobile phones, if Pascal is interested in a especial exhibit, he can get the corresponding information by reading the tag attached to the exhibit. But, if he needs translation into French, he has to share the collected information with Robert (see Fig. 3). Robert will launch a cloudlet discovery, offload the overlay and the data on the selected cloudlet to process these data. The resulting translation will be shared with Pascal thanks to a peer to peer communication.

V. AUTHENTICATION OF CLOUDLETS In this article, we are interested in scenarios like those described in the preceding section. These secenarios are based on NFC mobile applications that demand intensive computing resources. To save energy and avoid long WAN latencies, the mobile device offloads its workload to a local cloudlet with connectivity to the remote cloud servers as defined by Satyanarayanan [14]. The objective of such elastic applications is to dynamically leverage cloudlet computing for resourceconstrained mobile devices.

Fig. 3. P2P scenario using a cloudlet

The major issue in this context is that the cloudlet is not a trust entity in comparison with the cloud that can provide a Security As A Service, and the mobile that is endowed with a secure element. In the following subsections, we propose a solution to authenticate cloudlets by NFC mobile devices. The authentication of a cloudlet is required before migrating heavy computational tasks from the mobile device to the cloudlet. In [18], the authors propose a security model for elastic applications made up of ‘weblets’ that can be migrated to and from a cloud to a mobile device. In particular, they introduce the authentication and secure session management needed for secure communication between weblets and multiple instantiation concurrently. In [19], the author considers NFC platforms where the end user needs to access to services on the Cloud using his NFC mobile phone. In this authentication solution, the SP manages the user Id and generates a digital token. The SP delegates to a TSM the delivery of user credentials in the user mobile phone through OTA capability to communicate with the SE embedded in the mobile phone. Hence, when the user requests access to the Cloud, the SP has only to compare its digital token with the one provided by the SE. In [20], the authors present an elegant solution for authentication called Smart OpenID to allow access to a SP through the internet. Their solution is an enhancement of OpenID by moving part of the OpenID authentication server functionality to the smart card of the user’s device. They introduce: 1) a trust third party called OPSF that shares a secret key with the SIM card of the user, and 2) an entity called OP that runs on the mobile device to validate authentication based on the user credentials received from OPSF and those generated by the SIM card.

In the solutions of the literature such as those presented above, the access is requested to a service in a Cloud that can rely on a trust party. Unlike these solutions based on a cloudserver approach with WAN connections, the cloudlet-based approach has the role of leveraging external resources to augment the capabilities of resource-limited mobile devices connected in a WIFI range. As opposed to cloud servers, cloudlet servers are not trustworthy. The aim of this paper is to propose a security model that allows authentication of the cloudlet and its VMs that are linked to the overlays carried by the mobile device, before authorizing the migration of the mobile overlay and its data to the cloudlet. Prerequisites Before launching the authentication process of a cloudlet, we consider the following situation as in [15, 17]. We assume that each cloudlet hosts Base VMs provided by the cloud core. Each type of Base VM (Windows XP for example) can be launched by the VM manager of the cloudlet. On the other hand, the mobile device hosts distinct overlays; each specific overlay is associated to a specific intensive-computation application. Each application, hence its overlay, has a digital token that can be a key, a password, etc. If we consider that the overlays are related to NFC applications, we have the following components: - a Java Card applet, stored on the SIM card, that contains an overlay token that is shared with the TSM or the Service Operator (SO [3]); - The mobile application, stored on the mobile device, as an overlay which can be a compressed code obtained as explained in section 3 and detailed in [15]; - An NFC platform of the TSM/SO that allows access to the remote Java Card platform once the applet is installed via OTA interface of the MNO. Two public key infrastructures are respectively defined within the SIM card and the cloudlet. The SIM card as the cloudlet holds each a private key while the TSM holds the public keys of the SIM card and the cloudlet. Since we are concerned with NFC platforms, the TSM knows the public key of the SIM card. However, the public key of the cloudlet must be obtained the first time by the TSM by requesting the cloud. The sensitive data of the SIM card can be established at time of personalisation of the card or during the deployment of the NFC platform by the TSM via the MNO’s OTA capabilities.

application/overlay. The mobile device sends then an authentication request to the cloudlet with this data.

A.

B. Protocol description Before outsourcing a computing tasks, a cloudlet authentication is performed based on the following protocol as in Fig. 4: 1- First, the mobile device sends a discovery request and selects the most suitable cloudlet based on a pre-defined criteria distance, responce delay, MNO, etc. 2- Once the cloudlet is selected, the communication attributes are sent to the mobile device: the cloudlet identifier: IDcl that can be the IP address and the TCP/UDP communication port. 3- The SE (SIM card) uses its private key Kpriv_SE stored in its secure storage to sign the digital token associated to the

Fig. 4. Authentication flows

4- Then, the cloudlet sends to the TSM the received token TOKEN(Priv_SE) combined with the cloudlet identity signed with the cloudlet private Key (H(IDcl))Kpriv_C) 5- The TSM generates a signature SIG using: - RAND a random number; - H the result of Hash function H= Hash (overlay Token, H(ID cloudlet) and RAND; - The TSM signs then the resulting H using the TSM private key Kpriv_TSM. 6- The TSM asks the MNO for a secure transmission. The TSM sends the response to MNO including the previous calculated signature and the random RAND. Note that the communication between the TSM and the MNO is done over a secured HTTPS session. 7- The MNO initiates an OTA session with the SE and sends the signature and the random RAND to the mobile secure element. 8- The SE performs verification in three steps. First, it computes the H(IDcloudlet) using its own key and the random RAND: H’ = Hash (Token, H(IDcl), RAND). Then, SE decrypts the signature using the TSM public key: (Sig)Kpub_TSM = H. Finally, the SE compares the result with the calculated H. If they match together then the cloudlet is authenticated. C. Software architecture We have defined a software architecture (see Fig. 5) that is currently under development to implement the concept of cloudlets and to integrate our security mechanism. Regarding the mobile device, we have chosen Android platforms in order to develop the mobile application. Because the SIM card is locked by the MNO, we have linked the mobile application to an external secure element that is programmed using OpenNFC tool and that interfaces with the mobile device using the Android Edition as a plugin. The Open NFC tools are an open source project sponsored by Inside Secure [21]. The SE is a Java Card platform that stores the sensitive data as defined in

our protocol. In addition, we are currently developing an applet to implement a simplified RSA algorithm. In our prototype, the overlay is simply a compressed application; the cloudlet is a VM that is accessible over WIFI from the mobile device. As shown in Fig.5, the TSM is a VM located in another network area, which integrates some security and cryptographic algorithms within a demilitarized zone. The third VM is used to simulate the OTA. It is accessible over a private VLAN by the TSM and has a direct access to the SE.

Fig. 5. Software architecture

VI. CONCLUSION By combining the cloudlet concept with NFC services, we open the door to a new mobile virtual world. We show in this work, how using cloudlets to offload intensive computation is relevant for NFC platforms, when mobile devices require the use of large processor and memory resources. The NFC platforms are useful in the context of cloudlets regarding security issues because they involve trustworthy entities (such as TSM and a secure element) that are fundamental to enable securing cloudlets. The authentication mechanism proposed here confirms that security issues in the context of cloudlets must be addressed because the cloud-server security solutions are not automatically applicable to cloudlets, even if cloudlets and cloud-server approaches implement the same vision, notably the mobile cloud computing. Currently, we are developing a prototype as a proof of concept that implements the proposed authentication protocol. We aim to complete our security model with other aspects like to guarantee the integrity of data exchanged between the mobile and the cloudlet, and to enable a secure cloudlets discovery protocol. REFERENCES [1] Henky Agusleo & Neeraj Arora, The Road to ‘Cloud Nine’ How Service Providers Can Monetize Consumer Mobile Cloud, White paper, Cisco Internet Business Solutions Group (IBSG), Feb. 2013. [2] SMART INSIGHTS WEEKLY Maganzine, 10 october 2013, Issue 13-41, 8th year. [3] AFSCM : http://www.afscm.org/

[4] Jurgensen, T.M. ET. al., Smart Cards: The Developer's Toolkit, Prentice Hall PTR, 2002,ISBN 0130937304 [5] GLOBAL PLATFORM specifications:: http://www.globalplatform.org/specifications.asp [6] NFC Forum : http://nfc-forum.org/ [7] F., Niroshinie, S. W. Loke, & W. Rahayu, "Mobile cloud computing: A survey." Future Generation Computer Systems 29.1 (2013): 84-106. [8] Xiaopeng Fan, Jiannong Cao and Haixia Mao “A Survey of Mobile Cloud Computing”, ZTE Communications, March 2011, Vol.9 No.1, pp. 8-12, ISSN 1673-5188. [9] Sweta Patel : A Survey of Mobile Cloud Computing: Architecture, Existing Work and Challenges Computer Engineering Department R.K. Uuniversity , India Volume 3, Issue 6, June 2013 ISSN: 2277 128X. [10] H. XuhuiLi and Y. Zhang, “Deploying Mobile Computation in Cloud Service,” in Proceedings of the First International Conference for Cloud Computing (CloudCom), 2009, p. 301. [11] Muhammad Shiraz, Abdullah Gani, “Mobile Cloud Computing: Critical Analysis of Application Deployment in Virtual Machines”, 2012 International Conference on Information and Computer Networks (ICICN 2012) IPCSIT vol. 27, pp.11-16, IACSIT Press, Singapore. [12] G., Huerta-Canepa, & D., Lee, "A virtual cloud computing provider for mobile devices.", in: Proceedings of the 1st ACM Workshop on Mobile Cloud Computing & Services: Social Networks and Beyond, MCS’10, ACM, New York, NY, USA, 2010, pp. 6:1–6:5. [13] E. Marinelli,“Hyrax: cloud computing on mobile devices using MapReduce,”Master thesis, Carnegie Mellon University, 2009. [14] M. Satyanarayanan, P. Bahl, R. Caceres, N. Davies, The case for VM-based cloudlets in mobile computing, IEEE Pervasive Computing 8 (2009) 14–23. [15] S. Simanta, K. Ha, G. Lewis, Ed Morris, and M. Satyanarayanan, “A Reference Architecture for Mobile Code Offload in Hostile Environments”, http://www.cs.cmu.edu/~satya/docdir/simantamobicase2012.pdf [16] N. Vallina-Rodriguez, J. Crowcroft, Erdos: achieving energy savings in mobile OS, in: Proceedings of the Sixth International Workshop on MobiArch, MobiArch’11, ACM, New York, NY, USA, 2011, pp. 37–42 [17] M. Satyanarayanan, Mobile computing: the next decade, in: Proceedings of the 1st ACM Workshop on Mobile Cloud Computing & #38; Services: Social Networks and Beyond, MCS’10, ACM, New York, NY, USA, 2010, pp. 5:1–5:6. [18] X. Zhang, J. Schiffman, S. Gibbs, A. Kunjithapatham, S. Jeong, Securing elastic applications on mobile devices for cloud computing, in: Proceedings of the 2009 ACM Workshop on Cloud Computing Security, CCSW’09, ACM, New York, NY, USA, 2009, pp. 127–134. [19] Maurizio Divona, “NFC Mobile Application as Identity Access Management enabler in the Cloud”, Chip-to-Cloud security Forum, Nice, Sept.19-20, 2012. [20] Andreas Leicher, Andreas U. Schmidt, Yogendra Shah, “Smart OpenID: A Smart Card Based OpenID Protocol”, Information Security and Privacy Research, IFIP Advances in Information and Communication Technology Volume 376, 2012, pp 75-86. [21] http://open-nfc.org/wp/home/downloads