The Need for Integration in NFC Mobile Payments

Journal of Information Assurance and Security. ISSN 1554-1010 Volume 9 (2014) pp. 051-061 © MIR Labs, www.mirlabs.net/jias/index.html

The Need for Integration in NFC Mobile Payments Pardis Pourghomi1, Muhammad Qasim Saeed2, Gheorghita Ghinea3 1Department

of Computer Science, Brunel University London, Uxbridge, Middlesex, United Kingdom [email protected]

2Information

Security Group (ISG), Royal Holloway, University of London, Egham, United Kingdom [email protected]

3Department

of Computer Science, Brunel University London, Uxbridge, Middlesex, United Kingdom [email protected]

Abstract: Near Field Communication (NFC) is a short range wireless technology that provides contactless transmission of data between devices. With an NFC-enabled device, users can exchange information from one device to another and make payments using their NFC devices as means of their identity. Since the main players such as service providers and secure element issuers have crucial roles in a multi-application mobile environment similar to NFC, managing such an environment has become very challenging. One of the technologies which potentially ensure secure and flexible NFC transactions is cloud computing that offers wide range of advantages compare to using secure element as a single entity in an NFC device. This approach provides a comprehensive leadership of the cloud provider towards managing and controlling customer’s information where it allows the phone’s secure element to deal with authentication mechanisms rather than storing and managing confidential transaction data. In this paper, we further discuss the previously proposed NFC Cloud Wallet model and present a new insight that defines an integrated framework based on a reliable relationship between the merchant and the mobile network operator. We then carry out an analysis of such relationship to explore different scenarios that arise from this approach. Keywords: Near Field Communication, Security, Mobile transaction, Cloud, GSM authentication.

I. Introduction The popularity of the Internet and other high-speed data networks in combination with the attractiveness of smart phones have increased the interest of companies to invest in the idea of mobile wallet [1][2]. CWI Amsterdam was one of the first companies in Europe which carried out two distinct projects to combine digital cash and mobile telephones. The first project investigated mobile device authentication, while the other was based on Chaum’s online digital payment protocol [3]. The aim of both projects was to use Global

System for Mobile Communication (GSM) [4] to act as an electronic wallet for payers in order to connect to the bank and payee. Subsequently, this idea was extended to a different scheme, which was part of the European CAFÉ e-commerce project [2]. The goal of this extended work was to propose the concept of wallets with observers [3] in order to enable credentials and off-line digital cash to utilise in commercial settings. Although the results of the European CAFÉ project never implemented in combination with cellular networks, nevertheless, electronic wallet technology was developed as an outcome of this project. The developed electronic wallet technology had the potential to perform the transactions based on a short-range infrared link that could directly connect to wallets held by individuals as well as connecting to compliant cash registers. However, the transaction could also be performed over the Internet to other SPs. During the off-line transaction, an observer that is trusted by the credential issuer protects the credential issuer interests. The observer also uses the credentials on behalf of the issuer and controls copying of the credentials. An off-line transaction is carried out when the payer (credential holder) and the payee (credential verifier) are not connected to any supplementary services. In this scenario, the service is trusted by the payer. While the result of European CAFÉ project did not demonstrate the ability of electronic wallets to perform transactions in combination with GSM networks, it was a significant step towards improving the mobile wallet technology. Valista [5] as an alternative company, follows the mobile wallet approach and introduces a new service which supports secure payments, user identity verification and personalization. Their system works based on a provider-centric model in which a hosted server such as Identity Provider (IdP) acts as a

Dynamic Publishers, Inc., USA

52

Pourghomi et al.

central database for storing customers’ wallet information and can be accessed from the user’s mobile device. Valista wallet service meets the requirements of main security standards such as Visa Mobile 3-D Secure and MasterCard’s Secure Payment Application (SPA). The fast acceptance of second generation mobile communication systems made an enormous influence on increasing the essence of mobile identity services which led to the rapid development of mobile commerce (mcommerce) services [6][4].The two main factors that have a direct effect on the growth of m-commerce services are usability and trust. Therefore, several approaches have been proposed in order to enhance usability in mobile devices [7]. On the other hand, confidentiality, integrity, user control and minimal disclosure of the sensitive data are the key issues in the perception of trust on mobile devices. GSM-based IdM [4] is one approach that uses SIM and the GSM infrastructure as the fundamental platform. This approach has several benefits; however, the number of managed identity attributes is very restricted since they are only related to the GSM infrastructure and the SIM hardware. As defined in [8], an NFC payment ecosystem consists of the entities required to provide all necessary elements – from a mobile handset, to a network operator, to a point of sale terminal, to a TSM to provision the card to the phone, to a processing network to acquire and settle the transactions – that would ultimately allow a consumer to make a payment using NFC enabled phone. In an NFC payment ecosystem, the Secure element (SE) as a single entity that acts as a controlling party is unable to carry out remote operations. In other words, current card issuance models cannot support dynamic post issuance personalization process [9]. The remote operations include installation and loading of new applications in an external party, creation of security domains for an external party, activation and personalization of the applications that are loaded on the SE for an external party [10]. This is because service providers:  



Can only decide whether or not to use their applications that is due to their lack of control over the SE Cannot control other applications that are stored on the same SE. May not have the permission to contact the SE or have the opportunity to get to know their customer personally.

At present, many restrictions and unknown constrains have created problems for the operations of Service Providers (SPs) and Secure Element Issuers (SEIs) in the mobile NFC world. Those restrictions have presented a new approach for business cooperation in which collaboration is essential between unknown parties, and none of the parties are able to influence the service environment substantially. Therefore, technical solution and a clear framework are required in order to define constant procedures for ecosystem players. These constant procedures improve the interaction of business partners while

it makes the negotiation and description of each interaction unnecessary. It also provides easy management and deployment of applications for unknown business partners. The NFC ecosystem will not succeed without having such an approach which results in unacceptable business framework that does not provide satisfactory services for clients. Technical standards and fundamental interoperability at the basics are essential to be achieved for industries working with NFC technology so as to establish a positive cooperation in the service environment. Interoperability is also missing in the complex application level of the service environment which has resulted in the slow adoption of NFC technology within societies. Current service applications do not provide a unique solution for the ecosystem and consequently the service environment does not meet the right conditions [10]. The current situation is that, many independent business players are making decisions based on their own benefits which may not be acceptable by other business players. A. Our Contribution Our goal is to provide a concept for an NFC ecosystem that is technically feasible, is accepted by all parties involved and thus provides a business case for each player in this ecosystem. The purpose of this paper is to introduce a new cloud-based NFC framework that is the extension of our previously proposed NFC Cloud Wallet model. We then describe the transaction process that is based on the trusted relationship between the vendor and the Mobile Network operator (MNO) and discuss a new framework that improves trust in Mobile Payment ecosystem. Furthermore, an analysis of such framework is carried out to investigate the potential limitations of this approach. The rest of this paper is structured as follows. Section II highlights different components of NFC cell phones. Section III gives a comprehensive overview of the SE lifecycle within the NFC ecosystem. Section IV discusses the role of cloud in NFC transactions and determines the benefits of cloud-based NFC transaction approach. Section V addresses the security issues of such approach. Section VI evaluates the previously proposed NFC Cloud Wallet Model. Section V proposes a new approach to NFC Cloud Wallet model centred on the trusted relationship between the vendor and the MNO. Section VI describes a number of scenarios created on our assumptions in order to further analyse the new approach. A security analysis is then carried out to investigate the potential weaknesses of our approach. Finally, Section VII presents the conclusion. The conference version of this paper is published in [11].

II. NFC Over Cell Phones The integration of NFC with cellular technology resulted in a sharp rise in its utility. The leading mobile phone manufacturers such as Samsung, Nokia, HTC, and Sony are integrating NFC in most of their devices. An NFC equipped cell phone can act as a Radio Frequency Identification (RFID)

The Need for Integration in NFC Mobile Payments reader to read from or write to a tag. Additionally, two cells phones can share data in a peer-to-peer mode or a cell phone can act as a tag (card emulation mode) which is read by any compatible reader. NFC architecture on a mobile phone consists of the following components [12]:  NFC Antenna. This is responsible for the physical connection of the cell phone to another RF reader, NFC device or RF tag.  NFC Controller. This converts analogue to digital or vice-versa for transmission and receiving through the NFC antenna. Additionally, it controls all processes related to the NFC in a cell phone.  Secure Element. In card emulation mode, an SE is used to store sensitive data. The SE is a combination of hardware, software, interfaces and protocols that enable secure data storage and application execution. The cell phone equipped with SE can be used for services requiring a high level of security such as payment application, ticketing, etc. The SE can be in a form of removable (SIM, external memory card) or non-removable (embedded in hardware) component within the cell phone or it can be in a cloud providing all the necessary services.  Host Controller. The Host Controller interacts with the NFC Controller and in some cases, with the SE as well (for instance, to top-up credit in the Secure Element over the air).

53 The security of the NFC technology is provided by a component called security controller. This component is in the form of a SE which is a tamper-resistant secure memory location, for example a smart card. SE acts as a platform within a mobile device or a cloud environment which specify a multi-application architecture and it consists of hardware, software, protocols and interfaces [13]. Regardless of SE’s location (either in a mobile device or a cloud environment), in the context of NFC transactions, SE provides protection storage for transaction assets such as keys, transaction application code and transaction data. According to [14], Universal Integrated Circuit Card (UICC) is the most flexible and reliable components to act as an SE within the NFC architecture. UICC is capable of running multiple applications which can be issued by multiple application issuers while it provides the same security as a smartcard. Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS) networks are supported by UICC and it is complaint with all smartcard standards. In the following sections of this paper, we discuss the ways in which cloud computing changes the use of SE in an NFC transactions by using the UICC as an authentication component. In this case, the cloud provides the main SE (virtual SE) that keeps the sensitive transaction information and UICC is only used for authentication with vendor’s terminal while providing temporary storage to store the authentication assets. A. Lifecycle The processes for application issuance and the way smartcards used to be managed by service providers are changed since the introduction of SEs. In practical terms, this means that service providers do not necessarily have to initialize and personalize smartcards before issuing it for NFC handsets. The rest of this section describes the lifecycle of SE within an NFC phone [15].

Figure 1. NFC architecture over cell phone [12] Out of these components, the Security Element is the most crucial so we will discuss this component in detail.

III. Secure Element (SE)

The Initialization of an SE can be completed by different SEIs such as credit card companies, MNO, financial institution and retailers. The SEI can also act as a platform provider. If the SE does not contain any applications when issued that means there is no platform manager assigned to that SE. A platform manager cannot deal with SE applications without having different certifications (i.e. Visa PayWave certification). These certifications are provided by the Service Provider (SP). In most cases, the assignment of platform managers is dependent on the installation of the first application. Any party that installs the first application on the SE will be assigned as a first platform manager. However, the SE can also be managed by other application issuers. The SE can be issued by preinstalled applications that can be provided by SP which means, the SE is already under the control of SP as its platform manager. The Activation process takes place when the SE is inserted into the phone. The SE then sings in to the NFC controller and

54 NFC controller sends a confirmation message to the platform manager in order to inform the platform manager of the successful insertion of the SE in the phone. The platform manager then sends a confirmation message to the mobile phone in order to activate the SE. The platform manager is the only party that has the authority to hold the SE keys for data configuration purposes. NFC controller identifier is also stored in the SE to inform the SE in case if it was inserted into another phone. During phase 1 of the Applications Upload process, the SP (in this case also the application issuer) contacts the MNO that is the only party who is responsible for the Mobile Station International ISDN Number (MSISDN). The only way to classify the external party for an Over-The-Air (OTA) transaction with the NFC phone is the MSISDN. In phase 2, MNO forwards the SP’s request to the platform manager(s) that is in charge of the SE. If there is no SE in the phone, the MNO will inform the SP regarding this issue. In this case application upload process terminates. However, if the platform manager is positive with the request, it will send an offer directly to the SP to upload its application. In the next phase, SP selects one platform manager amongst others (if more than one platform manager exists) to load its data to the security domain area which is under the control of the same platform manager. The application data passes through a secure channel to reach the security domain for application personalization purposes. If the handset is logged in to the network, the SP has no difficulties in terms of alteration and deletion of data stored in the security domain. Having security domains ensures the privacy of each security domain in a way that different SPs will only have access to their own space within a specific security domain. The Deactivation procedures are also managed by the platform manager where it can deactivate the SE (OTA in the case of theft) or loss. If the SE is installed in a new device, then the activation process should be renewed and the platform manager is the only party that should confirm the activation process to enable the SE to be used for contactless transactions. The above description is dependent on the multi-host interface implementation that is not standardized yet. Accordingly, a control instance is required in order to control the SEs within the handset. Currently, there is only one control instance for the whole phone and not individual control instances for individual SEs. The control instance is responsible for establishing a direct communication between the NFC controller and the SIM through the Single Wire Protocol (SWP) [16]. It also deals with the communication between the NFC phone and MNO and routes the communication. While an SE only act as a tamper-resistant data container, this communication channel is required to establish data channels and also to send short messages.

IV. Cloud-based NFC Solution

Pourghomi et al.

Although using an SE as the main secure component in an NFC mobile phone had been a good start for development of this technology, nonetheless, once it got to the real stage of its global implementation, the ecosystem players faced many problems. We believe bringing the cloud infrastructure to the NFC business will assist to overcome many of the current complications [14]. A cloud-based approach offers several advantages over the use of an SE as a single secure component in terms of managing sensitive data for an NFC transaction. However, according to the speed of the present generation mobile data services, it seems an NFC cloud-based approach needs a few more years to become commercially feasible. The NFC cloud-based approach introduces a new method of storing, managing and accessing sensitive transaction data by storing data in the cloud rather than the mobile phone. When a transaction is carried out, the required data is pulled out from a remote virtual SE which is stored within the cloud environment and pushed into the NFC phone SE in an encrypted format. The NFC phone SE provides temporary storage and authentication assets for the transaction to take place. After reaching the SE in an NFC phone, data are again pulled out from the handset and reach vendor terminal. In general, the communication between the cloud provider and the vendor terminal is established through the NFC phone. In the rest of this section we describe a number of fundamental advantages that this approach provides over the existing solutions: The storage capacity of the SE should be large enough to store user applications with unknown sizes. If the users wish to add more applications to their NFC phone, this would raise some limitations for the existing solution since each SE support certain storage capacity. The other issue with the SE is that companies should meet the requirements of organisations such as EMVco [17] to provide high level security in order to store cards data. This approach makes the SE expensive for the companies, while the cloud-based approach reduces this cost. In the NFC cloud-based approach, the phone SE can only be responsible for user/device authentication and not for storing data. This solution increases the cost efficiency compare to the current costs that SE makes for a company. Moreover, the NFC controller chips will be smaller and cheaper as they would not have to support all functionalities. Furthermore, the concept of the SE can be completely avoided by replacing it with the concept of a trusted zone that can be created within the processor of a mobile phone. The NFC cloud-based approach also makes the business simpler for companies with the integration of SE card provisioning. It would be much easier for businesses to implement NFC services without having to perform card provisioning for every single SE. An NFC phone user will be able to access unlimited number of applications as they are stored within a cloud secure server and not in a physical SE. In terms of flexibility, all users would be able to access their

55

The Need for Integration in NFC Mobile Payments applications from their devices (e.g. phones, tablets or laptops) since the applications are stored in a cloud environment. Additionally, fraud detection would be instant as the system fully runs in an online mode. Since all the information is stored in a cloud, mobile wallet is not needed; thus, in order to change their mobile wallet information users can easily use the virtual SE to access the information they require online via a web browser. This approach also improves SPs services as they are no longer required to develop different applications for different types of mobile phones. This approach reduces the risk of third parties getting unauthorised access while the phone is being shipped to a new user or for repairing purposes. This is because there is no SE with stored user confidential information in the NFC phone as this information is stored in a cloud environment and not in the handset itself. The cloud-based transaction method provides the card-present payment, since the SE is stored in the NFC handset and deals with the authentication between the handset and the vendor terminal. This solution enables the NFC phone to link to multiple virtual SEs (stored in the cloud) which allow any user to access his/her own SE in order to modify the information (e.g. to add/delete applications). The acceptance of the NFC cloud-based transaction method is dependent on being able to implement strong authentication mechanisms as well as conducting transactions quickly enough to increase the performance. The processing times are far quicker in this approach because the main SE is stored in a cloud where there is more computing power available in contrast with stored SE in a mobile device. However, more time is required for data request to reach the cloud server and return back to the vendor terminal. To summarise, NFC cloud-based solution offer infinite computing services and extensive capabilities in terms of storage, networking of shared devices and computing. The solution provides broad capabilities to enable the use of different platforms bringing the user access into ubiquitous computing. Different virtual and physical needs of clients makes the NFC a flexible technology, therefore, the system should have the ability to provide a desired infrastructure in order to make the consumers capable of effectively managing their resources. As mentioned previously, our aim is to discuss the use of NFC in mobile payments therefore we concentrate on the previously proposed NFC Cloud Wallet to present an alternative approach based on this model.

V. Security in Cloud-based NFC Transaction This section highlights the vulnerabilities of NFC cloud payments and addresses possible exploits from Cyber-attacks. B. Wireless Threats One of the most common attacks on a public wireless network (e.g. NFC) is a classical Man-In-The-Middle attack, where Alice and Bob are joined by unwanted Eve who pretends to

Alice to be Bob and pretends to Bob to be Alice. Configuring a computer to impersonate a legitimate access point for a public wireless hot spot, such as a coffee shop or an airport first-class lounge, allows client connections to be attracted and sensitive data captured from unsuspected patrons [18].

Figure 2. The lifecycle of a mobile ticket [19] 1. The tickets are requested to be issued by a cloud service. 2. A user purchases a ticket from his mobile device. 3. Verification of the ticket. 4. Admittance to the venue

The computer may route traffic onto the legitimate access point while continuing to monitor communications. Since it provides gateway services and DNS settings to connecting clients, mapping authentic domain name of certain Web sites, such as a bank or financial institution, to the IP number of a malicious website is also a possibility. Also, in a similar fashion, it is possible to set up a cellular base station to pose as a legitimate one but it would be more difficult [20] [21]. The connectivity potential demanded by users from their smartphones mean that they are filled with radio interfaces. These include Bluetooth, NFC, WiFi, 2G/GSM, 3G/UMTS and General packet radio service (GPRS) technologies. The smartphone is able to use, for example, 3G service for data exchange with the internet - then hand over the data circuit to WiFi should it sense a valid network available. Some telecommunications providers (Orange UK) permit a direct handover of all 3G services to WiFi using a built-in Smartphone Orange WiFi App. The attack security surface area of vulnerabilities in each individual interface of the smartphone is becoming defined and research is starting into the handover between interfaces [22], for example: as the smartphone handsover from 3G/UMTS to WiFi during typically a transit from outside a building - where 3G may have the better quality as a service - then upon entering inside of the building, WiFi will take over as carrying the data packets. This exposes a new vulnerability surface at the point of actual handover. One way to tackle the generalized security risks in the mobile cloud is to ensure that appropriate modern cryptography could be used in mobile terminal devices to protect the user data so that cloud carriers only see encrypted data. Apparently, cloud providers are not yet interested in implementing such systems. Could a high level authority seek to impose the regulations to require cloud suppliers to implement encryption on the client and not collect unencrypted data from humans. This would

56

Pourghomi et al.

solve some of the growing wireless attacks such as the compromise of A5/1 crypto algorithm in the GSM system which is reaching its deployed end of life. C. Citizen’s Threats During the procedure of purchasing, storing and using the ticket, the mobile device user may find himself under following threats [23]. 1) Attacks while Purchasing and Using the Ticket    

A user may have his ticket stolen. Stealing the ticket of the user with or without him noticing could be possible with different types of attack: Eavesdropping on the wireless connection between the mobile device and the cloud. The attacker can get a copy of the ticket and could be able to use it before the legitimate user does. Eavesdropping on the mobile device’s screen physically or with recording equipment when it is used in a public mobile environment. Man-In-The-Middle between the mobile device and the cloud. If the attacker intercepts the connection to the cloud, he can be able to trick the user that the payment was unsuccessful while on the meantime take the ticket for his own use.

possibly hostile radio frequency threats, such as a 'fake' GSM base station. The fast spectrum-power density and protocol scan, which could occur in the background, would alert the mobile device should some suspicious activity above the local baseline be noticed such as jamming/Denial of Service. 3) Possible Countermeasures Some countermeasures can be used to reduce or in some cases eliminate the above mentioned threats. Secure connection between the user and the client is definitely a necessity when dealing with confidentiality. Moreover, it is beneficial to include mutual authentication of all parties involved in the system in order to avoid false impersonation.

VI. NFC Cloud Wallet Model This model [22] introduced the idea of using cloud computing to manage NFC payment applications which results in a flexible and secure management, personalization and ownership of the payment applications. This architecture provides easy management of multiple users and delivers personalized contents to each user. It supports intelligent profiling functions by managing customized information relevant to each user in certain environments which updates the service offers and user profiles dynamically. Depending on the MNO network reception, deployment of this service takes around one minute and deployments can be scaled to any number of users.

2) Attacks during the Verification of the Ticket The ticket is verified when the device with the mobile ticket is shown at the venue inspector system. The threats in this case are:  Unavailability of the verification system. The verification is done in the cloud in order to provide scalability and avoid losing availability of the system due to unexpected high demand in a short period of time. Using a cloud server in this case will almost eliminate the threat of having a DoS attack on the verification server.  Jamming the wireless ticket readers. If the verification system is not working, there would be no way to verify the validity of the tickets. Admittance to the venue with a complete verification of the ticket would not be possible. In such case the ticket holders would have to prove the validity of the ticket, by showing the digital receipt or some other proof of ticket purchase. However, such verification can only be done by a human inspector and may lead to many false positive or false negative results. To protect against jamming, in view of the growing threat to many radio systems, it should be possible to have the mobile device radio hardware to scan the environment for new and

The idea of this approach is that every time the customer makes a purchase the payment application which contains customer credentials is downloaded into the phone SE from the cloud and after the transaction, it is deleted from the device and the merchant will updated the cloud to keep a correct record of customer account balance. Figure 3 illustrates the steps that should be undertaken to complete the transaction process. The general execution of the model is described as follows [24][25][26]: 1) Customer scans the NFC phone on the vendor’s terminal to make a payment. 2) The payment application is downloaded into the customer’s NFC phone SE.

57

The Need for Integration in NFC Mobile Payments    

Figure 3. NFC cloud wallet

3) Vendor communicates with the cloud provider to check whether the customer has enough credit. 4) Cloud provider transfers the required information to the vendor. 5) According to the information received from the cloud, the vendor’s terminal either authorizes the transaction or rejects the customer request. 6) Vendor’s terminal communicates with the cloud to update customer balance; if customer request was authorized, the amount of purchase will be withdrawn from his account otherwise customer account will remain with the same balance. As an addition to this model, we suggest when NFC-enabled phone sends a request to its cloud provider to get permission to make a payment (step 1), the cloud provider sends an SMS requesting a PIN number to identify the user of the phone. This is how cloud provider ensures that the phone user is legitimate. Also, for verification purposes, the customer sends the PIN back to the cloud provider in the form of an SMS.

VII. Proposed Model We proposed an extension to previously proposed NFC Cloud Wallet model [24]. The major improvement is the elimination of the shared secret between the shop POS terminal and the customer MNO, a prerequisite in its earlier version described in [26] and in Chen's Protocol [27]. Therefore, the shop does not need to get itself registered with the customer MNO to perform mobile transactions [28]. This makes the Version II more flexible and it can even be used for monetary transfer between two individuals provided that the payer has registered an account with his/her MNO. Since there are multiple options applicable to this model, we designed our model based on the following assumptions [29]: 

The main SE is part of the cloud which is managed by the MNO (virtual SE).

The SE that is stored in a mobile device (phone SE) is only used for authentication purposes. SIM as SE is the best approach in this scenario (i.e. UICC). The MNO is managing the SE/SIM. Banks, etc. have secure connections with MNO. The vendor trusts the MNO.

The virtual SE can securely store personal data such as debit and credit card information, user identification number, loyalty program data, payment applications, PINs and networking contacts, among other information. However, the phone’s SE consists of authentication data such as keys, certificates, protocols and cryptographic mechanisms. As explained in section III, SE is in the form of UICC in our model (SE part of SIM) hence the SIM only deals with the authentication of handset to MNO and handset to vendor terminal. Rather than that, the main transaction data are stored in the virtual SE. During the whole process, the MNO manages the cloud environment and it is the only party that has full access and permission to manage confidential data stored in the cloud. As the MNO is the owner of the cloud, it fully manages the SIM in terms of monitoring the GSM network and controlling cloud data. The key assumption of this framework, which makes the whole process logical in terms of its protocol design, is the trusted relationship between the vendor and the MNO. The detailed analysis of this assumption is described in section VIII. Below provides the step-by-step description of the process as illustrated in figure 4. 1) Customer selects a product; the purchase request is sent to the vendor’s terminal. 2) The vendor’s terminal displays the price. 3) If Customer agrees with the price, s/he places the NFC-enabled phone on the vending machine. 4) The NFC link is established between the vendor terminal and the NFC phone. 5) The customer requests a message from the MNO to use it to prove its legitimacy to the vendor. The customer also informs the MNO of the total price. 6) The MNO first authenticates the customer. After a successful authentication, if the MNO agrees with the price, it sends a digitally signed confirmation message to the NFC phone (the customer). 7) The mobile device then relays the same message to the vendor terminal; since the vendor’s terminal trusts the MNO, it trusts the digitally signed message. 8) The NFC phone displays enter PIN to verify its legitimacy and its ownership of the cell-phone (additional security mechanism).

58

Pourghomi et al.

9) Vendor terminal sends its banking details in an encrypted form to the NFC phone. This message can be decrypted only by the MNO. 10) The NFC phone transfers the same banking details to the MNO. 11) The MNO performs the transaction. 12) The MNO sends a signed receipt to the vendor terminal through the NFC phone.

Figure 4. MNO communicates with vendor through NFC phone

14) If the verification is successful, the product is delivered and a success message is displayed on the NFC phone. 13) The vendor’s terminal verifies the receipt.

59

The Need for Integration in NFC Mobile Payments The trusted relationship between the vendor and the MNO establishes when the MNO sends a confirmation message to the vendor through the NFC-enabled phone (steps 6 and 7). This digitally signed message confirms that the customer has enough credit for the transaction.

VIII. Analysis In this section, we carry out a scenario-based analysis from the security point of view. Since this protocol is used for monitory transactions, it must be as much secure as possible. We sketched multiple scenarios where a buyer or a seller is dishonest and then analysed their success probability. In the first scenario, we assume that a customer is dishonest and wants to purchase a product without payment. The dishonest customer can only be successful if he can successfully generate a signed receipt is step 12 of the protocol. Since this receipt is signed by the MNO, an illegitimate customer cannot generate a valid receipt. Moreover, the dishonest customer cannot replay the old receipt as the receipt contains time information. Therefore, this scenario is not successful. In another scenario, we assume that the customer is dishonest and just want to extract the banking details of a vendor. The vendor provides his banking details after it receives a signed confirmation from the MNO. The banking details are encrypted so the customer cannot decrypt and understand this message. This message can be decrypted by the MNO only who needs banking details for the transaction. Consequently, a dishonest customer is again unsuccessful. In the third scenario, the seller is dishonest and plans to extract more than the required amount from a customer. To perform this action, the seller alters the price information at transaction stage. However, the alteration is deducted in the signed receipt provided by the MNO after the transaction. This receipt is provided to both, the customer and the seller. The customer detects any alteration in the price by the seller. Thus this scenario is also not successful. In the fourth scenario, the seller is dishonest and records all the legitimate messages of a customer. He plans to replay the recorded messages to the MNO to extract money from a customer in his absence. To do this, the dishonest seller impersonates as a customer to MNO. This impersonation is detected by the MNO in the initial steps of the model where the MNO authenticates a customer before proceeding to transaction. This scenario is, again, not successful. Apart from these scenarios, there are certain principles of transaction we want to respect in designing of the protocol. These may include:

   

Non-repudiation of transaction execution messages Disclosure of relevant information on need-to-know basis New cryptographic keys for every transaction execution Different encryption and MAC keys

All transaction messages must be secure providing data confidentiality, data integrity, data freshness and data origin authentication. This can be achieved by implementing adequate cryptographic measures. Communication over the GSM link between the mobile device and the base station is encrypted as specified in the GSM standard. Otherwise, communication between different entities of the GSM network is not considered to be secure and so encryption needs to be added where appropriate. The MNO may be linked to the customer's mobile device through its own base station or through a base station of some other network. Especially in the latter case, the proposed protocol should not disclose any sensitive information to the other network. The mobile device is connected to the shop terminal over an NFC link, but note that, although the NFC link is generally regarded as secure because of its short range of operation, yet it can be eavesdropped [30] or vulnerable to relay attacks [31]. A recent study suggested that any metallic object in the vicinity of an NFC link, even a shopping trolley, can act as ‘rogue’ antenna to eavesdrop the communication [32]. The design of the protocol should be flexible and can be used for monetary transactions between two individuals. The payee acts as a shop POS terminal, and uses his own mobile phone for this. The added advantage in our proposal is that the payee does not need to register himself with the payer’s (customer’s) MNO. This eliminates dependency of both parties to be on the same mobile network for monetary transactions.

IX. Conclusion This paper discussed the NFC ecosystem scenario where cloud computing plays a major role in the payment architecture and the MNO and vendor’s terminal have no direct communication. Thus, the merchant’s POS and the MNO communicate through the NFC phone (merchant trusts the MNO). We presented a different insight which proposed a novel integrated framework based on trusted integration of cloud-based NFC transaction players, namely the MNO, the NFC phone user and the merchant. We considered a cloud-based approach for managing sensitive data to ensure the security of NFC transactions over the use of an SE within the cloud environment as well as considering the role of SE within the NFC phone architecture. In addition, this paper provides associated issues that are essential to investigate other possible ecosystem architectures, players with their roles, different possible access controls and ownership issues in NFC ecosystem. Although this paper suggests a new payment method, but we do not recommend it for large transactions (over £50.00) to avoid security

60 limitations imposed by technology providers. In return, for the convenience, it offers customers in terms of a faster and more streamlined purchasing process. As part of future research, further potential architectures should be explored and analysed in order to finalize the most reliable architecture and design its protocol accordingly for cloudbased NFC transactions. In this paper, the idea of the proposed protocol scenario is to exchange digital transaction data. However, these protocols can be extended to support contract signing, certified digital product delivery, and certified email. Moreover, further research can be carried out to consider the possibilities of enforcing honest transaction party(s) to the proposed NFC transaction protocols which might decrease the number of exchanged messages in these protocols. Thus, enforcing honest party(s) may result in more efficient NFC transaction protocols. In addition, the origin of customers is known to merchants who ensure the identity of customers while making the payment. However, some customers may prefer to stay anonymous to merchants; therefore, for future research, anonymity can be taken into consideration towards extending the proposed scenario.

Pourghomi et al. [8] Smart Card Alliance Mobile and NFC Council. “NFC Application Ecosystems: Introduction, Peer-to-Peer, NFC Tags/Posters and Product Label Applications”, 2012. Availableat:http://www.smartcardalliance.org/resources/webin ars/nfc_app_ecosystem/20120927_NFC_Application_Ecosyst ems.pdf [9] NFC Forum, “Essentials for successful NFC Mobile Ecosystems,” October 2008 [Online]. Available: http://67.222.41.204/wpcontent/uploads/2013/12/NFC-ForumMobile-NFC-Ecosystem-White-Paper.pdf [10] K. Curran, A. Millar, and C. M. Garvey. “Near Field Communication”. In Journal of Electrical and Computer Engineering, 2(3), pp. 371–382. 2012. [11] P. Pourghomi, M.Q., Saeed and G. Ghinea. “Trusted Integration of Cloud-based NFC Transaction Players”. In Proceedings of the 9th IEEE International Conference for Information Assurance and Security (IAS). In press. [12] G. Madlmayr, J. Langer, C. Kantner, and J. Scharinger. “NFC Devices: Security and Privacy”. In Proceedings of the 3rd IEEE International Conference on Availability, Reliability and Security, ARES, Barcelona, Spain, pp. 642-647. 2008. [13] Alpár, Gergely, Lejla Batina, and Roel Verdult. "Using NFC phones for proving credentials". Measurement, Modelling, and Evaluation of Computing Systems and Dependability and Fault Tolerance. Springer Berlin Heidelberg, pp. 317-330, 2012.

References [1] S.F. Mjolsnes, & C. Rong. “Localized credentials for server assisted mobile wallet”. In Proceedings of the IEEE International Conference on Computer Networks and Mobile Computing (ICCNMC), pp. 203-208., 2001. [2] J. P. Boly, A. Bosselaers, R. Cramer, R. Michelsen, S.F. Mjolsnes, F. Muller, T.P. Pedersen, B. Pfitzmann, P. Rooij, B. Schoenmakers, S. Matthias, L. Vallee, & M. Waidner. “The ESPRIT project CAFÉ – high security digital payment systems”. In Proceedings of ESORICS, pp. 217 – 230, 1994. [3] D. Chaum. “Security without identification: transaction systems to make big brother obsolete”, ACM Journal of Communication, 28(10), pp. 1030-1044, 1985. [4] K. Rannenberg. “Identity management in mobile cellular networks and related applications”. Information Security Technical Report 9, Johann Wolfgang Goethe University Frankfurt. Elsevier. 9(1). pp. 77-85. 2004. [5] D. Henssey. “The value of the mobile wallet”. White paper, 2003. Available at: www.valista.com [6] U. Jendricke, M. Kreutzer, & A. Zugenmaier. “Mobile identity management”, Technical Report 178, Institute fur Informatik, Universitat Freiburg, 2002. [7] A. Dix, T. Rodden, N. Davies, J. Trevor, A. Friday, & K. Palfreyman. “Exploiting space and location as a design framework for interactive mobile systems”, ACM journal of Transaction on Computer Human Interaction, 7(3), pp. 285 – 321. 2000.

[14] P. Pourghoumi and G. Ghinea. “Challenges of Managing Secure Elements within the NFC Ecosystem”. In Proceedings of the 7th IEEE International Conference for Internet Technology and Secured Transactions (ICITST), pp. 720–725. 2012. [15] G. Madlmayr, J. Langer, and J. Scharinger. “Managing an nfc ecosystem”. In Proceedings of the 7th IEEE International Conference on Mobile Business, ser. ICMB. Washington, DC, USA: IEEE Computer Society, pp. 95–101, 2008. [16] GSM Association. “Requirements For SWP NFC Handsets V4.0”. March 2011. [Online]. Available: http://www.gsma.com/mobilenfc/wpcontent/uploads/2012/03/ gsmarequirementsforswpnfchandsetsv4.pdf [17] J. Pailles, C. Gaber, V. Alimi, and M. Pasquet. “Payment and privacy: A key for the development of nfc mobile” In Proceedings of the International Symposium on Collaborative Technologies and Systems (CTS), pp. 378 –385, 2010. [18] TheShmooGroup. “Airsnarf-A Rogue APSetup Utility, Version0.2”. Available at: http://airsnarf.shmoo.com/ [19] I. Kounelis, J. Loschner, D. Shaw, & S. Scheer. “Security of service requests for cloud based m-commerce”. In Proceedings of the IEEE International Convention, pp. 14791483. 2012. [20] M. Rak, L. Liccardo, R. Aversa. “A SLA-based interface for Secure Authentication Negotiation in Cloud”. Journal of Information Assurance & Security, 7(3), pp. 137-146, 2012.

61

The Need for Integration in NFC Mobile Payments [21] U. Meyer, S. Wetze. “On the Impact of GSM Encryption and Man-in-the-Middle Attacks on the Security of Interoperating GSM/UMTS Networks”. PIMRC, pp. 28762883, 2004. [22] N. Saxena, S. C. Narendra. “Prevention of SMS against Repudiation Attack over the GSM Network”. Journal of Information Assurance & Security, 8(3), pp. 156-166, 2013. [23] T. Dougan, & K. Curran. “Man in the browser attacks”. Journal of Ambient Computing and Intelligence (IJACI), 4(1), 29-39. 2012. [24] P. Pourghoumi and G. Ghinea. “Managing NFC Payments Applications through Cloud Computing”. In Proceedings of the 7th IEEE International Conference for Internet Technology and Secured Transactions (ICITST), pp. 772–777, 2012. [25] M. F. Mubarak, J. A. Manan, S. Yahya. “A Unified Model for Security, Trust and Privacy (STP) of RFID System”. Journal of Information Assurance & Security, 7(3), pp. 119126, 2012. [26] P. Pourghomi, M. Q. Saeed, & G. Ghinea. “A proposed NFC payment application”. Journal of Advance Computer Science and Applications, 4(8), 173–181. 2013. [27] W. Chen, G. Hancke, K. Mayes, Y. Lien, and J.-H. Chiu. “NFC Mobile Transactions and Authentication Based on GSM Network”. In Proceedings of the International Workshop on Near Field Communication, pages 83-89, 2010. [28] C.G. Hocking, S. M. Furnell, N. L. Clarke, P.L. Reynolds. “Authentication aura: A distributed approach to user authentication”. Journal of Information Assurance and Security, 6(2), pp. 149-156, 2011. [29] P. Pourghomi, & G. Ghinea. “Ecosystem scenarios for cloud-based NFC payments”. In Proceedings of International Conference on Management of Emergent Digital EcoSystems, ACM. 2013. pp. 113-118. [30] G. P. Hancke. "Practical eavesdropping and skimming attacks on high-frequency RFID tokens". Journal of Computer Security 19(2): 259-288, 2011. [31] K. Markantonakis. "Practical relay attack on contactless transactions by using nfc mobile phones". In Radio Frequency Identification System Security: RFIDsec 12 (2012): 21. [32] T. W. C. Brown and T. Diakos. “On the Design of NFC Antennas for Contactless Payment Applications”. In Proceedings of the 5th IEEE European Conference on Antennas and Propagation (EUCAP), pp. 44–47, 2011.

Author Biographies First Author Dr. Pardis Pourghomi is an Information Security Analyst in UK financial services at the Coventry Building Society, Coventry, United Kingdom. He received his BSc (Hons), MSc and PhD in Information Security from University of East London (2009), Royal Holloway, University of London (2010) and Brunel University London (2014) respectively. He is an active researcher/author with publications in a number of conferences, journals and white papers. His interests include the

design of secure authentication protocols, mobile payments, communication architectures, transport ticketing security. Growing areas of interest include cyber security management: framework, standard, strategy, etc.

Second Author Mr Muhammad Qasim Saeed is BE (Avionics) and MS (Information Security) NUST, Pakistan. He is currently studying for a PhD at Information Security Group, Royal Holloway University of London. His research is focused at the security aspects of the Near Field Communication (NFC) technology.

Third Author Dr. Gheorghita (George) Ghinea is a Reader in Computing in the Department of Computer Science, at Brunel University. Dr. Ghinea's research activities lie at the confluence of Computer Science, Media and Psychology. In particular, his work focuses on the building trustworthy end-to-end systems. Dr Ghinea leads a team of 8 researchers in these areas and he has over 200 publications in his research field. He consults regularly for both public and private institutions in his areas of expertise.