A Security Analysis of NFC Implementation in the Mobile Proximity Payments Environment

(1)

A Series of Whitepapers on NFC security - Part 1

A Security Analysis of NFC Implementation in the

Mobile Proximity Payments Environment

Security Task Force (STF)

Version 2.0

Published by Mobey Forum - June 2013

Copyright © 2013 Mobey Forum

(2)

Copyright © 2013 Mobey Forum

All rights reserved. Reproduction by any method or unauthorised circulation is strictly

prohibited, and is a violation of international copyright law.

(3)

Security Task Force (STF)

Chair

Mario Maawad “la Caixa”

Contributors

Matias Seppovaara Nordea

Alexander Luijt UL

Zafar Kazmi “la Caixa”

Niall O'Donoghue Trusted Computing Group / Nokia

Natalí Melgarejo GMV

Ira McDonald Trusted Computing Group / Samsung Electronics

Douglas Kinloch Metaforic

Ville Sointu Tieto

Keywords

application developers, card cloning, card skimming, contactless, denial of service, encryption, data insertion, data modification, eavesdropping, ghost and leech attack, man in the middle, mobile payment application, mobile financial services, near field communication (NFC), NFC enabled mobile devices, phishing, physical layer, proximity payment system environment, risks, secure channel, secure element (SE), secure management, security, service in payment card, tags, triggers, threats, untrusted, verification, vulnerabilities

(4)

List of Abbreviations

Term Description

AI Application Issuer

APDU Application Protocol Data Unit

CA Certificate Authority

CDA Combined Data Authentication

CDMA Code Division Multiple Access

CVC Card Verification Value

DDA Dynamic Data authentication

IC Integrated Circuit

ISD Issuer Security Domain

OS Operating System

OTA Over The Air

PAN Primary Account Number

PKI Public Key Infrastructure

POS Point of Sale

SD Secure Digital

SDA Static Data Authentication

SE Secure Element

SIM Subscriber Identity Module

SP Service Provider

SSD Supplemental Security Domain

SSL Secure Socket Layer

TLS Transport Layer Security

TSM Trusted Service Manager

USIM Universal Subscriber Identity Module Table 1. Abbreviations used in the paper

(6)

1. Executive Summary

The mobile device aims to replace our bulky physical leather wallets in the near future. A number of countries around the globe are already involved in various mobile wallet and mobile payment related initiatives based on near field communication (NFC) technology. The new services have created many opportunities for new business models, but they also bring new security risks and threats.

This document presents an overview of the current security trends related to the mobile

payments market. It outlines NFC technology related threats and vulnerabilities, and explains how these could affect the entire contactless payment ecosystem.

Chapter three of the paper summarises the vulnerabilities and threats in NFC mobile services and offers a description of the risks NFC functionalities face today and are likely to face in the future. Chapter four describes the countermeasures recommended to manage these vulnerabilities and threats. Stakeholders within the NFC ecosystem need to take these recommendations into account to ensure that end users have the best possible service that works in a secure manner. Chapter five concludes that for a successful mobile payments landscape, all stakeholders in the ecosystem need to work together to ensure secure and efficient NFC services. The final chapter summarises the recommendations for developing secure NFC services.

(7)

2. Introduction

There is concrete evidence that criminals are already trying to compromise mobile devices for financial gain, and these attacks will undoubtedly become more sophisticated over time. At the same time, current security strategies are not keeping up with the rapid changes in the mobile financial services (MFS) environment.

This year will see yet more banking clients opt for mobile banking, mobile payments and other MFS. The growing threat of cybercrime related to mobile devices requires the industry to

establish a deeper understanding of current and future threats, vulnerabilities and weaknesses in the mobile environment.

Intelligence gathering and awareness of future threats are important if the countermeasures needed to enhance the security of the stakeholders and related technologies within the MFS ecosystem are to be appropriately deployed.

The application examples of NFC technology presented in this paper are not limited to payments, but can also be deployed to home banking, ticketing and loyalty programs, to name a few.

(8)

3. Security Trends in NFC Enabled Mobile Devices

In order to effectively develop a set of precautionary recommendations that could enhance the security of the NFC payment environment, it is necessary to outline and analyse the existing vulnerabilities and threats within the NFC based payment ecosystem.

3.1. Vulnerabilities

3.1.1. Untrusted Communication Channel

There are no controls set up in the communication layer between the NFC device and the point of sale (POS). It is not possible for both devices to be authenticated in a non-reliable communication channel; leaving the path clear for an identity hijacking in case the NFC device or the POS is replaced.

If a POS is replaced, then the confidentiality is compromised, allowing the attacker to obtain card data such as the primary account number (PAN), the expiration date, the cryptogram and the name of the cardholder if the card should contain it.

3.1.2. Denial of Service in the Physical Layer of Communication

A denial of service can be obtained by sending data at the same frequency as the NFC

communication channel. In this case, communication between the POS and the contactless device will be compromised and the communication channel will be disabled. The issue here is that the interference signal must be stronger than the signal used by the POS in the NFC communication.

3.1.3. Denial of Service in Payment Cards

Each card has an internal transaction counter. If the card limit is exceeded, the card is disabled. There is also a safety mechanism that disables the card after three incorrect attempts to enter the personal identification number (PIN) offline. An attacker could impersonate a POS enabling them to interact with the card causing denial of service or exceed the limit of failed transactions or PIN attempts.

3.1.4. No Encryption in Communications

Within current NFC based payment implementations, there is no encryption protocol being used in the communication between the POS and the contactless payment NFC device. This can enable

(9)

captured can include the PAN, expiry date, cryptogram and cardholder’s name.

It is relevant to state that although this data can be successfully captured and the confidentiality could be compromised as a result of this, it is very difficult to carry out a fraudulent payment using this information, for the following reasons:

 A magnetic stripe CVC is required to make card payments (in the majority of cases); this CVC is printed on the magnetic stripe and not transmitted.

 To perform fraudulent payments over the internet, the CVC2 (also known as CVV2) is needed, which is printed on the back of the card and is not transmitted. Today, most internet sites require the CVC2 code to be entered before a transaction can be made, however, there are still some internet sites which do not request this information from their customers.

 It is necessary to recalculate the cryptogram to perform a fraudulent transaction by altering the data. In order to do this, the card key must be known and this key is not actually transmitted during the transaction process.

3.2. Threats

3.2.1. Ghost and Leech Attack

In this attack, the ghost acts as a card and the leech as a reader. The hacker’s reader or ‘leech’ transmits the card credentials to fake radio frequency identification (RFID) card. The ghost and leech attack does not need to modify or manipulate the contents of the communications between the reader and the payment card; this attack only needs to relay the communications in a black box manner. In this case, cryptography won’t defend the data security against this attack2 because the attack does not interfere with either the input or output of transaction

authentication. It has been proved that the attack deployment is possible and costs are within the expected returns of fraud.

3.2.2. Eavesdropping

NFC technology uses radio frequency (RF) as the link to communicate. Hence an attacker with the appropriate antenna can receive the signal that is transmitted between NFC devices. The main issue here is the close proximity of the devices and the attacker to enable them to successfully eavesdrop. Stealing data using this attack depends on specific parameters, such as the RF field characteristic of the given sender, the attacker’s antenna, the quality of the attacker’s receiver

1

Some experiments have achieved this conclusion using the Proxmark3

2 “Keep Your Enemies Close: Distance Bounding Against Smartcard Relay Attacks” Saar Drimer and Steven J. Murdoch Computer Laboratory, University of Cambridge

(10)

eavesdrop on communicating NFC devices, there should be no doubt that NFC communication needs to be combined with some kind of security protocol.

Figure 1: Ghost and Leech Attack as a Relay attack. Innocent customer, Alice pays a short amount of money by entering her PIN into an untrusted terminal operated by Bob. Meanwhile, Carol uses a fake card in the trusted terminal at Dave’s store. The result is that Alice is paying for Carol’s diamond without knowing it. (Source: From the paper “Keep Your Enemies Close: Distance Bounding Against Smartcard Relay Attacks”. Permission to use image from Saar Dimer.)

3.2.3. Data Modification

The attack allows the data to be received by the reader device, but is manipulated. Data

modification is not as simple to achieve as it strongly depends on the amplitude modulation of the signal and the signal encoding. The attacker needs to change pauses into signals and as an effect, the reader receives modified signals. If the data being transmitted is encrypted, then the modified signals will result in a corrupted message, because the attacker cannot choose to alter the signals to change the meaning of the message.

3.2.4. Denial of Service

The only purpose of this type of attack is to interrupt the communication between NFC devices. The attack is relatively simple to achieve with the appropriate hardware but difficult to prevent.3

3.2.5. Phishing

By replacing a tag on an NFC based smart poster, an attacker can deceive and force the user to visit websites with the same look and feel, but those sites are actually fake and malicious. For

3 Gauthier Van Damme, Karel Wouters. Katholieke Universiteit Leuven, Belgium. Practical Experiences with NFC security on Mobile phones. http://www.cosic.esat.kuleuven.be/publications/article-1288.pdf

(11)

Copyright © 2013 Mobey Forum A Security Analysis of the NFC Implementation 8 / 22 instance, in the case of an NFC poster, which enables customers to acquire a bus ticket by sending an SMS, it is simple for an attacker to alter the telephone number so that users are directed to a premium rate number instead. Users may not pay too much attention to the numbet and may end up paying a much higher amount as a result. Errors or deficiencies in the user's mobile device graphic user interface (GUI) could also be used to trick the user into visting an incorrect website or contacting a premium number.

This situation can be even more serious if the GUI is mixed with user information and the information provided by the NFC tag. A simple attack is to create a smart poster with a URL that directs the user to download malware unknowingly.

If a supermarket uses NFC tags, a criminal could replace the tag of a product with a similar but cheaper tag4. Other tags can be used for the Wi-Fi setup (for printer or internet access, etc.) or to provide configuration parameters and keys stored in an NFC tag. If the contents of the tag have been modified or replaced by a malicious label, visitors may not have a connection or could be connecting to a malicious access point, believing that they are connected to the correct network. In the final scenario, all network traffic can be easily intercepted if the communications do not use strong end-to-end security (SSL or TLS).

3.2.6. Man in the Middle

As NFC devices can detect jamming or changes in the signal because they can detect collisions, a man in the middle attack is not possible at the communication layer due to collision detection5.

3.2.7. Card Cloning and Skimming

Card cloning and skimming are two prominent attacks on contactless systems that are often the subject of practical research. The skimmer is a hidden electronic device that intercepts the card data and tries to collect its information. A skimmer may allow an active relay attack by

eavesdropping and altering messages. This attack is also called a wedge attack, which has been demonstrated in the ‘Chip and PIN is Broken’6 paper. This study demonstrates how to successfully steal cards without knowing the PIN.

EMV® (a global standard for credit and debit payment cards based on chip card technology) cards are the most commonly used, especially in Europe; there is therefore a lot of research regarding EMV data authentication. Depending on the chip technology, three methods are available:

 Static Data Authentication (SDA)

 Dynamic Data Authentication (DDA)

 Combined Data Authentication (CDA).

4

M.R. Rieback, B. Crispo, and A.S. Tanenbaum, “The evolution of RFID security. Pervasive Computing IEEE”, IEEE, 5(1):6269, Jan.-March 2006.

5

Ernst Haselsteiner and Klemens Breitfu, “Security in near field communication (NFC), en Workshop on RFID Security, RFIDSec 06. Philips Semiconductors”, July 2006.

6

“Chip and Pin is Broken” Steven J. Murdoch, Saar Drimer, Ross Anderson, Mike Bond, University of Cambridge 2010

(12)

Copyright © 2013 Mobey Forum A Security Analysis of the NFC Implementation 9 / 22 In 2011, Visa and MasterCard mandated that all EMV cards must use DDA. SDA cards can be cloned and used without a PIN for offline transactions only. DDA card clones are ineffective for offline and online transactions, however a valid DDA card can be used to pass offline

authentication and perform fake offline transactions (not tied to authentication). CDA is designed to protect against this attack but it should still be possible for the skimmer to force usage as an SDA card.

3.2.8. Mobile Payment Application Development Risks

According to the Open Web Application Security Project (OWASP), mobile applications in general need to take into account the following risks when installing onto the mobile operating system (OS)7.

 Insecure data storage

 Weak server side controls

 Insufficient transport layer protection

 Client side injection

 Poor authorisation and authentication

 Improper session handling

 Security decisions via untrusted inputs

 Side channel data leakage

 Broken cryptography

 Sensitive information disclosure

3.2.9. Access to the Secure Element

There are various ways of accessing the secure element (SE)8. Although some of these methods use sophisticated access control capabilities, the common flaw is their confidence in the security of the mobile OS to perform access control enforcement. In all cases, the SE relies on the OS or application processor's access control decisions. In this case, the application only needs to pass the security checks performed by the mobile OS to exchange messages with the SE.

This is a very important issue considering that there is a trend to exploit different mobile device platforms in order to gain root access to the OS. If this is possible, many security checks can be bypassed and the SE compromised.

Basically, the SE is as secure as a regular contactless smartcard, as the two have the same security features: secure storage, secure execution environment, hardware-based cryptography and certified high security standard. To enable access to the data and services in the SE, an application programming interface (API) between the applications on the phone and the SE is needed. There

7

OWASP Mobile Security Project https://www.owasp.org/index.php/OWASP_Mobile_Security_Project

8_{M. Roland, J. Langer, and J. Scharinger: Practical Attack Scenarios on Secure Element-enabled Mobile}

Devices. In Proceedings of the Fourth International Workshop on Near Field Communication (NFC 2012), pp. 19-24, Helsinki, Finland, Mar. 2012

(13)

which enables access to the NFC chip.

If the mobile phone does not support Java, the mobile device manufacturer and / or OS issuer must offer an API to access the SE and NFC chip.

In all cases, APIs are a way of access control, which is always enforced by the OS on the

application processor. The API ultimately trusts the OSs access control and the underlying mobile hardware.

This makes the API vulnerable in front of malicious software with privilege escalation exploits9. Even the end user can be a threat if he jail breaks the mobile phone, bypasses major security measures intentionally or unintentionally, or installs non-qualified applications.

3.2.10. Automatic Actions in Mobiles Triggered by NFC Tags

Smart posters include a field called ‘action’, which allows the attacker to take any action they want with commands through the NFC connection. Examples of these actions are:

 Modifying a contact from the agenda of the mobile phone.

 Making calls and sending text messages.

 Starting Bluetooth connections and sending data.

 Allowing the user to open a malicious URL. For this, there are Android exploits contaminating the user’s mobile phone with malware.

Here is a practical example of how an NFC enabled phone can be used for criminal purposes: When the criminal is aware of a forthcoming meeting, pre-programmed tags can be glued under the table. When a participant places their phone on the table, it reads the tag, opens a call to a pre-programmed number and enables the receiving end to hear the conversation in the room.

9

For Android OS, some examples are: mempodroid, Levitator, zergRush, GingerBreak, ZimperLich, KillingInTheName, RageAgainstTheCage, Exploid

(14)

4. Recommendations for Enhancing the Security

4.1. Eavesdropping

The wireless nature of NFC technology makes it impossible to protect against eavesdropping without the use of encryption. Although data transmitted in passive mode is significantly more difficult to be eavesdropped, this is not sufficient for most applications to transmit sensitive data. The only solution to this attack is to set up a secure channel as descbired in section 4.6 of this paper.

4.2. Data Corruption

NFC devices can be protected from data corruption as they are able to verify the signal status while they are transmitting data, therefore enabling the NFC device to detect the attack. The power needed to corrupt the data is also significantly higher than the power, which can be detected by the NFC device.

4.3. Data Modification

Protection against data modification can be achieved in various ways; in this case the following two methods are preferred.

1. Option one: The NFC device checks the RF field while sending. This means the sender could continuously check for such an attack and could stop the data transmission when an attack is detected.

2. Option two (and probably the better solution): develop a secure channel, as described in section 3.6 of this paper.

4.4. Data Insertion

There are three possible countermeasures.

1. Option one: The answering device answers with no delay. In this case the attacker cannot be faster than the correct device and can only be as fast as the correct device. If two devices answer at the same time, no correct data is received.

2. Option two: Use the answering device to listen to the channel between the opening of the channel and the start of the transmission. The device can then detect an attacker attempting to insert data.

(15)

4.5. Man in the Middle

As already said in section 3.2.6, it is practically impossible to undertake a man in the middle attack on an NFC communication channel. As a countermeasure an active-passive communication mode can be used, so that the RF field is continuously generated by one of the valid parties. The

recommendation is to maintain one of the NFC devices generating the RF field and actively listen to detect any disturbances caused by a potential attacker.

4.6. Secure Channel for NFC

To protect against eavesdropping and data modification attacks the best solution is to establish a secure channel between the NFC devices. A standard key protocol such as Diffie-Hellman should be sufficient to implement it. As man in the middle attacks are not really a problem, the

unauthenticated version of Diffie-Hellman is sufficient.

4.7. Use Tags Signed by Legitimate Entities

The user should remember that NFC tags could be associated with malicious actions. Devices that emit these tags should be signing to ensure the user identity and avoid attacks, such as phishing or man in the middle. The importance of this action relies on the fact that a single tag can trigger various functions, such as using malicious code, making calls or modifying contacts.

As with all new technology, a variety of security threats exists and should be dealt with in

different ways. Digital signatures can offer one way of validating the originator of the tag content. A public key solution with some sort of public key infrastructure (PKI) and a standardised format for signature records on the tags can offer a flexible solution supporting signed tags from different providers.

Furthermore, it is possible to process signatures and certificates on mobile devices and signature records can be added to NFC tags. The choice of signature algorithm will, however, influence the signature verification time and the amount of available space on the tag.

4.8. Cancel Automatic Actions Associated to Tags

Currently, almost all NFC enabled mobile devices come with the NFC functionality already

enabled. Thus, the device is ready for any NFC enabled device trying to connect and communicate with it. It may be better to disable the automatic function and allow the user to decide whether to download a tag or not. The user will then be aware of the services activated and be conscious of what it implies.

(16)

4.9. Verification of Mobile Applications

Applications using / accessing NFC functions should be verified by the entity making the distribution. The check should include best practices recommended by the OWASP and the applications including payment functions should follow the PCI DSS requirements.

4.10. Applications and Firmware Updates

It is clear that software or firmware updates are designed to provide improvements over previous versions and enhance device performance. These updates may also resolve bugs or security leaks found in previous versions. Managed updates of different applications on mobile devices could therefore protect against different threats.

(17)

5. Conclusions

The NFC world is moving forward with new and exciting solutions for consumers. As with all new technologies, NFC offers new functionalities, but also brings with it new and unknown threats. A successful mobile payment world will be one that is developed by all stakeholders working together to create secure and efficient NFC services. Key actors from the industry including hardware manufacturers (mobile handsets, UICCs, NFC chips, etc), software and application providers (OS developers, application developers, etc), mobile network operators (MNOs) and the merchants will have to gather their energies to provide the end user with the appropriate path to a secure mobile world.

The list below summarises the recommendations for secure NFC mobile payments:

 The business model is changing from ‘issuer centric’ to ‘user centric’, meaning that the user will be the one choosing which applications to install where. Although the

technology already enables this, the industry needs to ensure that business models allow the required level of security needed for highly sensitive applications such as mobile banking.

 MNOs and service providers need to follow best practices set out by standard associations to manage the critical data in the NFC application deployment (configuration, installation and management).

 Industry standards provide good guidelines for NFC mobile service deployment, but more case studies are needed to understand new trends. For example, the creation of the consumer centric business model will bring changes and create new roles and features.

 The OS developers will have to work together with mobile manufacturers to develop better ways of access control to avoid malware intrusion into the SE or the trusted execution environment (TEE).

 Wireless technology is always sensitive to sniffing and eavesdropping. NFC payments need to take this into account when sending the user’s financial data wirelessly. Data encryption must be a requirement in this situation.

 Application developers always have to be concerned about security in their applications. The controlled access offered by the OS is a big plus to maintaining the critical financial data saved from mal-intentioned software.

 More authentication factors need to be developed beyond the usual PIN for mobile payments and banking applications. Hackers will figure out new ways of forcing payments if authentication is reduced to only one factor.

(18)

6. Citations & References

 GlobalPlatform Messaging Specification for Mobile NFC Services v1.0.pdf

 GlobalPlatform Specifications in the UICC Configuration v1.0

 Keep Your Enemies Close: Distance Bounding Against Smartcard Relay Attacks. Saar

Drimer and Steven J. Murdoch Computer Laboratory. University of Cambridge http://static.usenix.org/events/sec07/tech/drimer/drimer.pdf

 Chip and PIN is Broken. IEEE Symposium on Security and Privacy, 2010

http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf

 Eavesdropping Near Field Communication. Norwegian Information Security Conference,

2009 Henning Siitonen Kortvedt and Stig F. Mjølsnes Department of Telematics NTNU

 Practical Experiences with NFC security on Mobile phones. Gauthier Van Damme, Karel

Wouters. Katholieke Universiteit Leuven, Belgium.

http://www.cosic.esat.kuleuven.be/publications/article-1288.pdf

 The Evolution of RFID Security. Pervasive Computing IEEE. M.R. Rieback, B. Crispo, and

A.S. Tanenbaum. IEEE, 5(1): 6269, Jan-March 2006.

 Chip and PIN is Broken. Steven J. Murdoch, Saar Drimer, Ross Anderson, Mike Bond.

University of Cambridge, 2010

 Security of Proximity Mobile Payments. Smart Card Allliance

www.smartcardalliance.org/resources/pdf/Security_of_Proximity_Mobile_Payments.pdf

 Mifare Classic analysis in Czech Republic / Slovakia. http://www.nethemba.com/mifare-classic-slides.pdf

 Mobile Devices Security on Practical Risks of NFC Payments.

http://kas.economia.ihned.cz/gallery/2/847-06_rosa_raiffeisenbank_bezpecnost_mobilnich_zarizeni.pdf

 Applying recent secure element relay attack scenarios to the real world: Google Wallet Relay Attack at http://arxiv.org/pdf/1209.0875.pdf

 Chip and Skim: cloning EMV cards with the pre-play attack www.cl.cam.ac.uk/~rja14/Papers/unattack.pdf

 Issuer and Merchant Best Practices: Promoting Contactless Payments Usage and Acceptance.

http://legacy.nrf-arts.org/Mobile_in_Retail/Mobile_WhitePapers/Best_Practices_V8_070709.pdf

 Smart Card Alliance Contactless Payments Security Questions & Answers

www.smartcardalliance.org/pages/publications-contactless-payment-security-qa

 Practical Experiences with NFC security on Mobile phones. Gauthier Van Damme, Karel

Wouters. Katholieke Universiteit Leuven, Belgium.

www.cosic.esat.kuleuven.be/publications/article-1288.pdf

 Security in Near Field Communication - NFC Strengths and Weaknesses. Ernst

Haselsteiner and Klemens Breitfuß

 OWASP Mobile Security Project

(19)

 Practical Attack Scenarios on Secure Element-Enabled Mobile Devices. M. Roland, J.

Langer, and J. Scharinger. In Proceedings of the Fourth International Workshop on Near Field Communication (NFC 2012),

 Practical Attack Scenarios on Secure Element-enabled Mobile Devices. M. Roland, J.

Langer, and J. Scharinger. In Proceedings of the Fourth International Workshop on Near Field Communication (NFC 2012), pp. 19-24, Helsinki, Finland, Mar. 2012

 Public-Key-Based High-Speed Payment (electronic money) System Using Contactless Smart Cards. Yamamoto, H. 2001. Lecture Notes in Computer Science, vol. 2140, pp.

242-254.

 Elliptic Curve Cryptography on Smart Cards Without Coprocessors. Woodbury, A. D.,

Bailey, D. V., and Paar, C. 2001. Proceedings of the fourth working conference on smart card research and advanced applications on Smart card research and advanced

applications, pp. 71-92

 PIN Transaction Security (PTS) Point of Interaction (POI). PCI Security Standards

(20)

Appendices

List of Appendices

 Appendix 1. Roles of Different Stakeholders within the NFC Ecosystem

 Appendix 2. Mobile Features

(21)

Appendix 1. Roles of Different Stakeholders within the NFC Ecosystem

The following appendix outlines the roles of major stakeholders within the NFC ecosystem considered relevant to the NFC security analysis presented in the paper.

Application Developer (AD)

The ADarchitects, designs, or builds an application code. This may include solution providers or merchants who modify or create software.

Application Provider (AP)

The AP has a direct business relationship with the customers and holds the responsibility for the mobile NFC service management in the SE and mobile phone, but does not perform operational tasks. Operational tasks are delegated to the security domain manager. The AP procures the necessary components to load a complete application (i.e. application code, application data, application keys and / or certificates and data belonging to a specific cardholder) onto a card.

Controlling Authority (CA)

The CA manages exchanges with an optional third party entity when required by the deployment model. The CA enforces the security policy in an environment with multiple stakeholders accessing the SE. Specifically, it may be used for secure security domain creation in an SE. A CA entity is mandatory when using confidential application loading and

personalisation10.

The CA keys and the certificate are loaded into the CA secure domain by the card manufacturer during UICC manufacturing.

The ‘Confidential Setup of Initial Secure Channel Keys’ requires that the CA entity must be a trusted third party to the link platform operator (an entity operating an over the air (OTA) platform, i.e. the MNO or TSM) and the entity in charge of the application personalisation (i.e. either the trusted service manager or service provider). The CA may be a certificate authority or the SIM vendor itself11.

Mobile Network Operator (MNO)

An MNO is the actual mobile network for mobile communications. An MNO maintains the mobile communication infrastructure and provisions wireless settings to mobile phones provided to consumers. It also determines both the required handset features and functions, and the service options to be provided with mobile phones sold through its channel. With UICC as a SE, an MNO also ensures the OTA connectivity between the consumer and the NFC application service provider.

10_{Chapter 11 “Confidential Setup of Initial Secure Channel Keys” of the}

UICC Configuration

11

(22)

Manager (SDM)

The SDM is responsible for a set of security domains in an SE. Depending on the privileges associated with its security domains, the SDM may have the capability to directly load, install, extradite or personalise applications on behalf of an application provider. If it does not have sufficient privileges or it does not have an OTA capability, it may request the help of another SDM to perform individual card content management operations or OTA dialogue.

Also, the SDM may be responsible for the global SE and mobile device NFC service management operations on behalf of the application provider. In this case, the SDM may need the knowledge of the global SE and mobile NFC service breakdown structure. Secure Element

Issuer (SEI)

The SEI is the entity that sources the SE, controls the SE’s secure domain keys, brands the SE and provides it to end users. The SEI can also open the SE to additional application issuers (AI).

The SEIs can be an MNO, a financial institution, a transport authority, a customer loyalty scheme owner, or even the TSM, which provides this service to the service provider. Alternatively, an SEI can be an independent organisation which wishes to empower MFS and claim a position in the new and constantly developing MFS ecosystem.

Some of the SEI’s main responsibilities are to develop the card product profile, and to choose the appropriate platform and application technologies. The SEI creates an issuer security domain inside the SE. This issuer security domain is used to perform card management operations by the security domain manager12.

Trusted Service Manager (TSM)

The TSM is the trusted party between service providers and NFC devices. The service

providers can deliver NFC mobile devices with remote management functionality through the TSM. Depending on the deployment, the TSM may have the following key functionalities:

 Issuing and managing a TEE

 Assigning trusted areas within a TEE to a specific service

 Managing keys for a TEE

 Securely downloading applications to NFC mobile phones

 Personalising applications

 Locking, unlocking and deleting applications according to requests from a user or a service provider

These functionalities can be performed by mobile network operators, service providers or third parties. All or part can be delegated by one party to another.

Even though the TSM uses the word ‘trusted’ in its name, this role is not necessarily

associated with the key management functions. In most cases this entity will not be managing keys, neither for the MNO nor the service provider.

Table 2. The Roles of Major Stakeholders within the NFC Ecosystem

12

(23)

Appendix 2. Mobile Features

1) Application Activation User Interface (AAUI)

This is the element with which the user interacts to perform the application selection. There may be more than one AAUI on a mobile device, however only one is active at once. Whilst the payment applications are hosted on a SE, the location of the AAUI may vary. For example, the AAUI could be implemented as an application running in the application environment of the mobile device (for example, a Java MIDlet), or it could be implemented on a SE (for example, a UICC with the AAUI implemented as a smartcard web server (SCWS) application). The proximity payment system environment could be implemented on a SE, in the application environment of the mobile device, or even in the contactless module.

2) Application Execution Environment (AEE)

Mobile device functionalities, such as voice calling, packet communication, phonebook, browser, mailer, and so on may be expanded to realise NFC mobile services, it also provides a user

interface to execute phone services interactively. All these functionalities are used and expanded to realise NFC mobile services, and as a group are termed an application execution environment (AEE). An AEE supports data storage and processor capabilities, and executes mobile phone services in a relatively secure manner, but this level of security may not be sufficient to meet the needs of all NFC service providers.

3) Trusted Execution Environment (TEE)

Some categories of NFC services, such as payment, require highly trusted environments, which are not necessarily realised by the AEE. A TEE executes security relevant NFC applications in a trusted and secure environment. The TEE can have various form factors, some of which can be removable (or replaceable), but the most important characteristic from an interactive services point of view is that the TEE has an interface to the AEE.

A TEE provides secure data storage, secure management functionalities, a secure execution environment and so on. The secure management functionality is utilised to realise OTA

downloading of applications and remote issuing or personalisation of NFC mobile services. Some of these functionalities may share parts with the AEE, but the TEE enhances security to satisfy the requirements for trusted NFC services. On the other hand, the TEE can disclose a specific interface to the AEE and give permission to access the TEE through the interface. For example, the mobile phone browser may access data stored in the TEE.

An NFC mobile device may potentially have more than one TEE. There are various reasons to provide these, including user control, different service providers requiring separate TEEs for their applications, different levels of security policies, etc.

(24)

Appendix 3. NFC Communication Protocols

There are various protocols involved in each of the layers of the open systems interconnection model between the POS and the contactless card. The following table lists the communication protocols.

ISO7816-4 An MNO is the actual mobile network for mobile communications. An MNO maintains the mobile communication infrastructure and provisions wireless settings to phones provided to consumers. It also determines both the required handset features and functions, and the service options to be provided with mobile phones sold through its channel. With UICC as a SE, an MNO also ensures the OTA connectivity between the consumer and the NFC application service provider.

ISO14443A-NFC The protocol defined by specific ISO14443 RFID communication standard at a frequency of 13.56 Mhz, defines two sub standards: A and B which differ from one another in the signal modulation methods. Variant A is commonly used in

communications using NFC technology.

EMV EMV® is a global standard for credit and debit payment cards based on chip card technology. EMVCo, owned by American Express, JCB, MasterCard, UnionPay and Visa, manages, maintains and enhances the EMV Integrated Circuit Card Specifications to ensure global interoperability of chip-based payment cards with acceptance devices including POS terminals and ATMs.

There are three security modes some of which may operate offline and online: - Static data authentication (SDA): The card does not implement any kind of

cryptography and simply authenticates using a certificate that can be verified by a CA. This mode of operation is vulnerable to replay attacks

- Dynamic data authentication (DDA): The card implements RSA encryption and private key used to encrypt a ‘cryptographic nonce’ produced by the POS. Advertise with the signed public key certificate for this to be verified by a CA.

-Combined data authentication (CDA): The card implements RSA encryption and private key used to generate a cryptogram with various data from the POS. It publics the signed public key with the certificate for this can be verified by a CA.

Table 3. NFC Communication Protocols

It should be noted that none of the afore-described protocols have encryption implemented due to the following reasons:

- ISO7816-4 standard defines only the operations.

- ISO14443A standard defines only the physical communication and security delegated to higher layers.

(25)

Copyright © 2013 Mobey Forum A Security Analysis of the NFC Implementation 22 / 22 - EMV was originally designed for communications in touch and measures were not implemented to encrypt communications.

A Security Analysis of NFC Implementation in the Mobile Proximity Payments Environment

A Series of Whitepapers on NFC security - Part 1