Contactless Mobile Payment Architecture Overview 2010062808363068

2008, 2009, 2010 EMVCo, LLC (EMVCo). All rights reserved. Any and all uses of the EMV Specifications (Materials) shall be permitted only pursuant to the terms and conditions of the license agreement between the user and EMVCo found at http://www.emvco.com/specifications.cfm.

EMVCo Contactless Mobile Payment Contactless Mobile Payment Architecture Overview Version 1.0 June 2010

http://www.emvco.com/specifications.cfm

Contactless Mobile Payment Architecture Overview

2008,2009 EMVCo, LLC (EMVCo). All rights reserved. Page ii

Contents 1 Scope 1

1.1 Audience 1 2 References 2

2.1 EMV Documents 2 2.2 External References 2

3 Definitions 3 4 Abbreviations and Terminology 5

4.1 Abbreviations 5 5 Contactless Mobile Payments 7 6 Architecture 8

6.1 System Architecture 8 6.2 Architectural Zones 10

6.2.1 Definition of Architectural Zones 10 6.2.2 EMVCo Role 12

6.3 Handset Physical Architecture 13 6.4 Secure Element Architecture 14

7 Application Choice 16 8 Provisioning and personalisation. 19 9 Parameter update and counter reset 20 10 Security 22

10.1 Contactless Mobile Payment Security 22 10.1.1 Differences from single issuer controlled contactless payment devices 22 10.1.2 Impacts on Security Architecture 23 10.1.3 Remote Personalization 24

10.2 Security Policy and Requirements 24 10.3 High-level Policy 24 10.4 Security Objectives 25

10.4.1 Assumptions 25 10.4.2 Main Objectives 25

11 Summary 26


2008,2009 EMVCo, LLC (EMVCo). All rights reserved. Page 1

1 Scope

EMVCo is in the process of addressing issues surrounding the installation and use of EMV based contactless mobile payment applications on mobile devices, in particular mobile handsets. The areas of focus have been identified in two white papers, The Role and Scope of EMVCo in Standardising the Mobile Payments Infrastructure [ROLE] and EMV Mobile Contactless Payment Technical Issues and Position Paper [TECH]. EMVCo is focussing on contactless mobile payment where a mobile device takes the role of a card in a transaction. The current work does not address the use of a mobile device as a payment terminal, nor the use of a mobile device for remote payment. This document provides an architectural overview and framework for the work that EMVCo is undertaking in the area of mobile contactless payment. This document does not seek to define implementation details or roles and responsibilities for deployment, but to provide an overall context for the detailed work that EMVCo is doing in each of these areas.

1.1 Audience This document is intended for all interested stakeholders in the mobile payment ecosystem including but not limited to:

Payment Industry participants Mobile payment solution developers Mobile payment service providers Mobile handset suppliers Contactless mobile payment component suppliers Other standards bodies focused on standardising different parts of the

mobile payment infrastructure



2 References

The following documents are referenced in this document. The latest version shall apply unless a publication date is explicitly stated.

2.1 EMV Documents EMV documents are available on the EMVCo Website: http://www.emvco.com/specifications.cfm. [TECH] EMV Mobile Contactless Payment Technical Issues and Position

Paper [ROLE] The Role and Scope of EMVCo in Standardising the Mobile

Payments Infrastructure [CCPS] EMV Contactless Communication Protocol Specification

2.2 External References [102588] ETSI TS 102 588, Technical Specification

Smart Cards; Application invocation Application Programming Interface (API) by a UICC webserver for Java Card platform

[14443] ISO/IEC Identification cards Contactless integrated circuit(s) cards Proximity cards 2001

[18092] ISO/IEC 18092 Information technology Telecommunications and information exchange between systems Near Field Communication Interface and Protocol (NFCIP-1)

[7816] ISO/IEC 7816-4 Identification cards Integrated circuit cards Part 4: Organization, security and commands for interchange

[GPCS] GlobalPlatform, Card Specification, Version 2.2, March 2006

[HCI] ETSI TS 102 622, Smart Cards; UICC Contactless Front-end (CLF) interface; Host Controller Interface (HCI)

[SWP] ETSI TS 102 613, Smart Cards; UICC-CLF Interface; Physical and Data Link Layer Characteristics.

Overview of EMVCo Mobile Payments Standardisation Activities


3 Definitions

The following terms are used in this specification. AAUI Application Activation User Interface A user

interface application on the mobile device enabling the user to set a contactless mobile payment application to be active, and which configures the mobile device to enable this.

Confirmation Code A code or password entered into a mobile device in order to confirm that a user wishes to perform a contactless mobile payment transaction.

Contactless Mobile Payment

Integration of EMV based contactless payment technology in mobile devices.

Contactless Mobile Payment Application

An application which is hosted in a secure element which performs information exchange and processing needed to perform a contactless mobile payment transaction.

Contactless Module A module within a mobile device providing a contactless interface compatible with EMV Contactless Communication Protocol Specification [CCPS].

Contactless Payment Terminal

A contactless reader conforming to EMV Contactless Communication Protocol Specification [CCPS] and compliant with EMV specifications related to the use of the PPSE that is capable of conducting a payment transaction with a Contactless Mobile Payment Application.

EMV EMV is a global standard for credit and debit payment cards based on chip card technology

EMVCo EMVCo manages, maintains and enhances the EMV Integrated Circuit Card Specifications for chip-based payment cards and acceptance devices, including point of sale (POS) terminals and ATMs. EMVCo also establishes and administers testing and approval processes to evaluate compliance with the EMV Specifications. EMVCo is currently owned by American Express, JCB, MasterCard and Visa.


Page 4 2008,2009 EMVCo, LLC (EMVCo). All rights reserved. June 2010

Handset A type of mobile device, specifically a mobile phone handset.

Man Machine Interface

Alternative term for a user interface

Mobile Device A portable electronic device with contactless and wide area communication capabilities. Mobile devices include mobile phones and other consumer electronic devices such as suitably equipped PDA

Mobile Handset A handset.

Near Field Communications

A short range contactless proximity technology based on ISO/IEC 18092, which provides for ISO/IEC 14443 compatible communications

SECM Secure Element Contactless Management A scheme employed by a Secure Element to manage the contactless applications thereon. The scheme could vary depending on the Secure Element implementation

Secure Element A tamper resistant module, capable of hosting applications in a secure manner

SIM Subscriber Identity Module An application on a UICC for management of mobile telephony authentication and functionality.

SWP Single Wire Protocol the electrical and protocol interface for connecting a UICC to a contactless module. Defined by ETSI TS 102 613 [SWP]

UICC Universal Integrated Circuit Card the physical integrated circuit card which hosts the USIM and other applications

User Interface Input and output components on a mobile device, for example, display, keyboard and touch screen.



4 Abbreviations and Terminology

4.1 Abbreviations 7816 Physical smartcard interface based on ISO/IEC 7816

AAUI Application Activation User Interface

ADF Application Definition File

AID Application Identifier

APDU Application Protocol Data Unit

CMP Contactless Mobile Payment

CRS Contactless Registry Service

ETSI European Telecommunication Standards Institute

GP GlobalPlatform

GSMA GSM Association an association of GSM operators

HCI Host Controller Interface, defined by ETSI TS 102 622

I2C Inter-Integrated Circuit two wire serial bus for communication between internal components

MMC MultiMediaCard

MMI Man-Machine Interface

NCI NFC Controller Interface

NFC Near Field Communications

OTA Over the Air

PAN Primary Account Number

PDA Personal Digital Assistant

PIN Personal Identification Number

PPSE Proximity Payment System Environment

S2C SigIn-SigOut-Connection two wire serial interface for connecting secure devices

2008,2009 EMVCo, LLC (EMVCo). All rights reserved. June 2010

SCP Smart Card Platform (working group of ETSI focussed on the UICC)

SCWS Smart Card Web Server

SD Secure Digital memory card

SE Secure Element

SECM Secure Element Contactless Management

SWP Single Wire Protocol, defined by ETSI TS 102 613

UI User Interface

UICC Universal Integrated Circuit Card



5 Contactless Mobile Payments

Contactless payment functionality has been mainly deployed in the form of ID-1 form factor cards. However, as contactless payment acceptance is not constrained to a particular physical shape, and as cardholder convenience may benefit from the integration of contactless payment in devices other than cards, alternative contactless-enabled devices have been developed, for instance key fobs or mobile handsets. Mobile devices, in particular mobile handsets, are especially suitable devices for hosting contactless payment functionality, since: The targeted mobile devices are communication devices supporting a

proximity wireless interface (in addition to a wide area communication interface) compatible with the EMVCo Contactless Communication Protocol Specification [CCPS]. Hence they may conveniently implement contactless payment transaction protocols, and can also offer additional useful functionalities like over-the-air personalization or software update.

They are programmable devices featuring a built-in display and keyboard, which may be used for functions like confirmation code entry or activation/deactivation of the payment functionality.

Their personal nature makes them particularly suitable for performing security functions, e.g. confirmation code entry, as they are less likely to be vulnerable to techniques like physical tampering.

They typically offer embedded secure storage and processing units, such as the UICC cards used by some mobile telephony technologies, or other kinds of embedded secure modules.

Their widespread ownership and use is of great help in solving the cost and distribution issues traditionally associated with any mass rollout of new application-specific tokens or hardware devices, e.g., smart cards and smart card readers.

Their relatively modest cost and their pervasive nature make them very attractive to consumers.

Throughout this document, integration of contactless payment technology based on EMV specifications in mobile devices is referred to as Contactless Mobile Payment (CMP).


6 Architecture

6.1 System Architecture The system architecture which is considered of interest to EMVCo is illustrated in Figure 1.

Mobile Device User

Interface

Application Environment

Secure Element

Secure Element

Secure Element

Contactless module (NFC Controller)

Router

Payment system network

Payment application


Personalisation and provisioning

server

Update Server

Wide area modem

Payment application

issuer

Personalisation backend

Figure 1 Contactless Mobile Payment System Architecture



The CMP capable mobile device has a number of logical components1

An application environment in which applications may be loaded and run. This is the default execution environment of the mobile device and hosts most of the consumer visible applications. The application environment may host user interface applications which allow for communication between a contactless mobile payment application and the user.

, including:

A user interface (UI), also known as a Man-Machine Interface (MMI). The UI, e.g. a display area and key pad, displays necessary information and provides the input mechanism for user selection and payment functions.

One or more secure elements. A secure element hosts one or more EMV based contactless mobile payment applications, and may also host other non-EMV contactless applications;

A contactless module (or NFC Controller), which provides contactless capabilities based on the EMV Contactless Communication Protocol [CCPS]2. The contactless module is also responsible for routing contactless communications between the antenna and one of the secure elements or the application host processor in the mobile device3

A wide area modem.

4 which provides network connectivity for both the application environment, and for provisioning and personalization of payment application onto a Secure Element5

In order to conduct a payment transaction, the contactless mobile payment application interacts with a contactless payment (point of sale) terminal, which is connected into the payment system network (typically via an acquirer). The payment system network is responsible for authorization, clearing and settlement.

.

1 The components described in this section are logical components, and do not necessarily have a one-to-one correspondence with physical components. 2 Note that the contactless module may support contactless protocols other than just CCPS, for example, it may support MiFare, FeliCa or NFC [18092]. 3 Where a mobile device supports only a single secure element, or allows only one secure element to be active at a time, the routing capability may operate as a switch, rather than having dynamic routing capability. 4 For a mobile handset, the wide area modem is typically a cellular modem, but the wide area modem includes WiFi or other local area network interfaces which are connected via a gateway to a wide area network. 5 Note that while Figure 3 shows a direct connection between the secure element and the wide area modem this may be implemented through the mobile device OS, or via an application which acts as a relay between the SE and the wide area modem.


The payment application is installed and personalised by the personalisation and provisioning server, which communicates with the secure element via the wide area network connection (typically the cellular connection of a mobile handset) via the mobile device. The personalisation and provisioning server is connected to a personalisation backend, which allows the issuer to issue the payment applications to the mobile devices. Once a contactless payment application is installed and provisioned, it may be updated via the update server. This allows, for example, the resetting of application counters and updating of parameters. The update server also communicates with the secure element (and hence the payment application) using the wide area network connection via the mobile device.

6.2 Architectural Zones

6.2.1 Definition of Architectural Zones In order to group together elements of the architecture which perform related functions, a number of zones are identified. These are illustrated in Figure 2.



The zones are defined in Table 1 along with a non-exhaustive list of global organisations that are developing specifications and other documents for Contactless Mobile Payment relevant to the zone.

Table 1 Architectural Zones

Zone Description CMP related Contributing

Mobile Device D

User Interface


Secure Element

Secure Element

Secure Element


Router




server

Update Server

Wide area modem

Payment application

issuer


Figure 2 Architectural Zones

A E

B

C

H

G

F


organisations A The Secure Element EMVCo, ETSI SCP,

GlobalPlatform, GSMA B The contactless module, which implements

the digital portion of the EMV contactless interface and is responsible for the routing of contactless information. It includes the interfaces to the contactless module from components within the mobile device, including the interface to the application processor, and the interfaces to any secure elements in the system.

EMVCo, ETSI SCP, NFC Forum

C The component (antenna) which implements the analogue part of the EMV contactless interface.

EMVCo, NFC Forum

D The baseband and application processors and other components in the mobile device (excluding the SE, contactless module and antenna) which form the mobile device.

EMVCo, GSMA

E The contactless payment application Payment systems F The payment terminal. EMVCo, Payment

systems G The provisioning and personalisation

system. EMVCo, GSMA, Payment systems

H The application update system. EMVCo, Payment systems

6.2.2 EMVCo Role There are many organisations involved in the development of the architecture and ecosystem for contactless mobile applications, a number of which are indicated in Table 1. EMVCo seeks to work with these groups to define the architecture and specifications needed to support contactless mobile payment. EMVCo will develop a number of deliverables in this space:

1. Specifications: Specifications may be developed for elements which are specific to contactless mobile payment, and which are common across the payment systems. Typically such elements will support the co-existence of CMP applications from different issuers and brands.



2. Profiles and usage guidelines: CMP applications will make use of general purpose architectural elements defined by other organisations. EMVCo will liaise with these other organisations to communicate the requirements that CMP places on such elements. EMVCo will also publish profiles and guidelines on how such elements are to be used in the context of CMP in order to promote interoperability.

3. Requirements: There are areas in which there are no existing standards, and these areas may extend beyond only contactless mobile payment. In such cases, EMVCo will gather together the requirements that contactless mobile payments place on these areas, and publish these requirements to assist the wider mobile industry in developing products and systems which are suitable for supporting contactless mobile payment.

4. Certification and type approval processes: In support of the above mentioned deliverables, EMVCo will also develop processes to determine the level of conformance of implementations to these specifications, profiles and requirements. The certification and type approval processes may make use of industry testing and conformance procedures, or where appropriate, EMVCo may develop its own processes for testing.

6.3 Handset Physical Architecture The logical mobile device architecture is shown in Figure 1. Mobile phones, or handsets as they are referred to in this document, are a key category of mobile devices for contactless mobile payment. Figure 2 provides a more detailed view of the architecture of a handset, highlighting the physical components and interconnections.


Figure 3 shows alternative options for secure elements, as discussed further in section 6.4, and the interfaces which may be used between the internal components. With respect to Figure 1, the application environment, user interface and wide area modem are implemented by the baseband and application processor.

6.4 Secure Element Architecture A secure element (SE) is a tamper resistant module, capable of hosting applications in a secure manner. The secure element provides both physical tamper resistance, and logical protection of the applications, including separation of the applications. The secure element is in Zone A. There are a number of architectural options for a secure element, including:

Figure 3 Handset physical architecture

Handset

Baseband and

Application Processor

Contactless Module (NFC

Controller)

UICC Card

SE

SE Mem

Cntl

Communication link between the UICC and contactless module (e.g. SWP, HCI)

Contactless antenna

Phone processor to run interface applications

Removable card, e.g. SD/MMC

cards

Communication link between the Application processor and the contactless module, (e.g. NCI)

SD/MMC Interface

ISO 7816 interface

with baseband

Connection to Secure

Element (e.g. SWP,

ISO7816, S2C etc)



1. An SE which is embedded in a mobile device as an integral part of the device;

2. A removable card containing a secure area, for example a removable smart card, or a removable memory card with a secured area;

3. As part of the UICC in a handset; The logical architecture of a secure element is shown in Figure 4.

From a logical point of view, an SE has the following parts:

1. An operating system which supports the secure execution of applications and secure storage of application data. The operating system may also support the secure loading of applications.

2. A device interface which enables commands and responses to be exchanged with the mobile device. The device interface allows the mobile device to communicate with applications in the SE and the SECM.

3. An antenna interface which enables the exchange of commands and responses between an application in the SE and a contactless terminal via the contactless module of the mobile device.

4. Secure Element Contactless Management (SECM) The SECM6

6 The Contactless Registry Service (CRS) defined by GlobalPlatform is one example of an SECM.

is responsible for maintaining a list of contactless applications on the secure element, the status of the applications, and data associated with the application. The status of the application indicates if the application is available for selection on the contactless interface. Information associated with the application includes Application Definition File (ADF) Name, the application lifecycle state and the application priority.

Secure Element

SECM App App

App

Device interface

Antenna interface

Figure 4 Secure Element Logical Architecture


Although indicated as separate logical interfaces, the device and antenna interfaces may be implemented on the same physical interface. Regardless of the number of physical interfaces, applications running in the SE should be able to distinguish on which logical interface data is being exchanged, that is, whether the communication is originating from the device or the antenna. The application lifecycle state maintained by the SECM controls whether or not an application in the SE is accessible on the antenna interface. An application which has a lifecycle state indicating it is activated (represented by green in Figure 4) may be accessed on both the device and antenna interfaces. An application which has a lifecycle state indicating it is deactivated (represented by red shading in Figure 4) can only be accessed on the device interface, i.e. it is not accessible on the antenna interface.

7 Application Choice

A mobile device may host multiple contactless applications, including both contactless mobile payment applications and applications related to other service areas (such as transit or access control). Application choice is the process by which the user chooses which applications should be active at a particular time, and the priority associated with the applications. Application choice affects zones A, B and D.



A user may choose to activate7

7 An application which is activated is accessible on the antenna interface of the secure element that is, a contactless reader may select the application and interact with it. A deactivated application is not accessible on the antenna interface. It is possible to access both activated and deactivated applications on the device interface.

or deactivate particular applications, and it may be possible to have multiple applications activated at the same time. Where there are multiple applications related to a single service area, for example, payment, there must be a priority assigned to the applications in order to establish which application should be selected by a terminal. On the other hand, some contactless applications may be incompatible, and cannot be activated simultaneously. This may be because the applications require sets of contactless parameters which are incompatible, may be for business reasons, or may be due to incompatibilities in the priority mechanism (for example, applications which make use of the Proximity Payment Service Environment (PPSE) versus applications which do not).

Application Activation User Interface

Application Activation User Interface

Secure Element

SECM App

App

Secure Element

SECM App

App PPSE

Figure 5 Application Choice Logical Architecture

Secure Element

SECM App

App


Router Routing Table


The logical architecture for application selection is illustrated in Figure 5. In the figure the solid lines indicate the flow of configuration data, whilst the dashed lines indicate the flow of application data to the contactless antenna. Note that the architecture shown in Figure 5 is a logical architecture. Whilst the payment applications are hosted on a secure element, the location of the AAUI and the PPSE may vary8

There are 4 main elements: .

The application activation user interface: This is the element with which the user interacts to perform application selection. There may be more than one AAUI on a mobile device, however at any one time only one AAUI is active.

One or more secure elements: These host the contactless applications; The PPSE: An application on the mobile device with the primary

responsibility of indicating the user's choice of contactless payment (and possibly other service areas) applications to be used by a Contactless Payment Terminal 9

The contactless module with a router configured by a routing table. .

The Application Activation User Interface (AAUI) is the element with which the user interacts. The AAUI presents the list of available applications to the user, allowing the user to activate, deactivate and prioritise the applications. The AAUI is also responsible for detecting and resolving (possibly through interaction with the user) conflicts between applications which the user wishes to have simultaneously active. In order to be able to present the list of applications to the user, the AAUI must interact with the SECM on each of the secure elements to gather the list of available applications and their status. The AAUI is also responsible for updating the SECM if the user makes any changes to the activation state or priority of an application. Once the user has chosen the activation state and priority order of the available applications, the AAUI is responsible for populating the PPSE. The PPSE contains a list of the active contactless payment (and possibly other) applications, each with an associated priority. The AAUI is also responsible for updating the routing table so that communications sent and received through the contactless antenna are routed to the correct SE or the device host.

8 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 secure element (for example, a UICC with the AAUI implemented as a smartcard web server (SCWS) application). The PPSE could be implemented on a secure element, in the application environment of the mobile device, or even in the contactless module. 9 Note that the PPSE is a shared application which will be used by all CMP applications on the mobile device.



8 Provisioning and personalisation.

Provisioning is the process of installing a payment application on a secure element. Personalisation is the process of putting data specific to a cardholder into the application. Provisioning and personalisation may occur simultaneously or as two separate events. The architectural elements involved in provisioning and personalisation are shown in Figure 610

. Provisioning and personalisation is in zone G.

10 Note that for some types of SE it may be possible to provision and personalise the payment application before distribution of the SE. It is also possible to perform the provisioning and personalisation over the contactless interface. These options are valid, but are not the focus of the work in EMVCo.

Figure 6 Provisioning and Personalisation

Mobile Device User

Interface


Secure Element

Secure Element

Secure Element


Router


server Wide area

modem



As shown in Figure 6 the mobile device communicates with the provisioning and personalisation server via the wide area (e.g. cellular) modem. The personalisation and provisioning server is responsible for transferring the application and personalisation data to the secure element. This includes providing the necessary cryptographic material required by the secure element or application in order to allow installation or personalisation. The personalisation backend provides the connectivity to the issuer, or the issuers agent, for the initial generation of the personalisation data. It is also responsible for providing a chain of trust between the issuer and the secure element, including appropriate logging to assist in audit, repudiation and forensics.

9 Parameter update and counter reset

Payment applications often maintain a number of counters and parameters. During the course of normal operation of the application, these counters need to be reset, and parameters may need to be updated. In a contact transaction, these updates and resets are delivered to the application on the card via the point of sale terminal as the contact card is inserted in the terminal for the duration of the transaction. When the terminal goes on line for authorisation, the issuer may send back an instruction which the terminal sends to the card application, triggering the update or reset. In the case of a contactless payment application, the device hosting the contactless payment application is not necessarily in proximity with the terminal if the issuer were to send back update or reset instructions. This document focuses on the update and reset mechanisms which are specific to CMP. Other mechanisms may exist, but these are out of scope of this document.



Figure 7 Updates and Resets

Mobile Device

User Interface


Secure Element

Secure Element

Secure Element


Router

Wide area modem



Update Server

Payment application

issuer


Specific to CMP is that it can make use of the wide area network channel (typically a cellular channel) that the mobile device has available. In this case, a link is set up between the payment application and the issuer. In Figure 7 this is shown as a link via the Update server. The processing of scripts and updates may be synchronous or asynchronous with the transaction. It should be noted that the wide area network may not always be available at the time of the transaction. For this option, EMVCo will consider the mechanism by which the update server establishes a link with the contactless mobile payment application and elaborate on the elements of the issuer cloud shown in Figure 7. The update and reset system is in Zone H.

10 Security

This section provides an overview of the security objectives for the contactless mobile payment system, and where the security functions reside.

10.1 Contactless Mobile Payment Security

10.1.1 Differences from single issuer controlled contactless payment devices

Four main factors are likely to differentiate CMP from other contactless payment devices: The use of mobile device features and components to support the contactless

payment functionality. Part of, or all of, contactless payment functionality may be implemented using, for instance, the Secure Element, the application processor, the keyboard or the wide area communication components.

The device distribution model. Traditionally, payment tokens (typically chip cards) are personalized with security-sensitive assets before they are distributed to registered cardholders. In CMP, a potential payment token (a mobile device) will typically be in the possession of the cardholder prior to becoming an actual payment token. Generally, in the absence of a specific business model (e.g., an agreement between a card issuer and a telecom operator distributing handsets), there will be no practical way to distribute pre-personalized mobile devices or to support remote personalization of mobile devices.



The device ownership model. Unlike traditional bank cards, the mobile devices - or at least the control of their security-sensitive components - are normally not owned by a card issuer. Depending on the business model and underlying technical design constraints, ownership and control may lie with the end-consumer, a mobile network operator, the mobile device manufacturer, or a combination of these.

Multi-issuer/Multi-brand support. As a mobile device is not owned by a single card issuer, the mobile device may host CMP applications from multiple card issuers and multiple payment brands. This gives rise to the need for the user to be able to select which CMP application is to be used for a transaction, and for the CMP applications to co-exist without interfering with other applications. There is also a need for a common set of requirements on the mobile device from the brands and issuers as the device is shared between them.

10.1.2 Impacts on Security Architecture The factors listed above directly impact the CMP security architecture, as follows: The use of mobile devices may introduce new threats to the payment

application assets when compared to a chip card, because of both their physical characteristics and their logical characteristics.

Security measures should be taken to ensure an overall security level similar to the one used in classical contactless chip form factor.

The use of mobile devices may allow the implementation of new security mechanisms. For instance, one might take advantage of the mobile device keyboard to implement Confirmation Code functionality. The Confirmation Code is entered by the cardholder on the mobile device keypad and verified (typically by an embedded secure module) before enabling the contactless payment functionality for one transaction, for several transactions or for a pre-defined time.

The use of mobile devices may introduce the need for new processes. For instance, the fact that CMP is fully integrated into a mobile device may raise issues about the decommissioning of the device, e.g., when the mobile device is sold or given away. First, there could be a misperception by the cardholder of the security sensitivity of such actions. There will be a clear need for cardholder education. Second, an explicit decommissioning of the payment functionality of the mobile device should be foreseen. This would involve removing any CMP applications and associated Confirmation Codes to enable the next owner to add new CMP applications.


There is a need for a secure remote personalization mechanism, allowing the bank to securely personalize already distributed mobile devices with cardholder data. The term remote is used rather than the term over-the-air, to reflect the fact that several technical mechanisms could be used. Such mechanisms could be built upon the mobile device telecommunication channel, but also upon other channels such as Bluetooth, infrared or simply a physical link. However, for practical reasons, it is likely that the actual personalization will happen over-the-air. This mechanism is likely to rely on the establishment of some trust relationship(s) between the bank(s) and the party or parties controlling the security-sensitive components of the devices. Such a trust relationship should be built upon an agreement on the use of specific security measures, both from a technical perspective and from a procedural perspective.

10.1.3 Remote Personalization Contactless payment cards are loaded with card-specific keys generated by diversifying issuer master keys with the card Primary Account Number (PAN). Therefore, mobile devices will have to be personalized remotely with those card-specific keys, together with the other card data. Because these keys are secret keys, they have to be confidentiality-protected at all times during their lifecycle.

10.2 Security Policy and Requirements CMP, i.e., the implementation of contactless payment technology in mobile devices, is governed by the following policy, objectives and requirements. The following sections present: A high-level security policy applicable to CMP, i.e. the implementation of

contactless payment functionality in mobile devices; Security objectives.

10.3 High-level Policy A number of security objectives have been identified for the components of the contactless mobile payment system. In addressing the security requirements of the SE components, the following policy applies: Any solution should ensure an overall security level similar to the one used in

classical contactless chip form factor. That is, the CMP application shall be at least as secure as the corresponding approved payment applications running on contactless chip cards in regard of its design, implementation, personalization and operation.

Conformance to security requirements is ensured by means of a security evaluation conducted under the appropriate EMVCo security evaluation program.



10.4 Security Objectives

10.4.1 Assumptions The security objectives described below rely on the following assumption: A secure element is available in the handsets. Any change in this assumption will require a review of the security objectives.

10.4.2 Main Objectives There are four main security objectives to CMP:

[SO1] Provide evidence of participation of the Secure Element in CMP transactions

[SO2] Maintain the security of the CMP application assets

[SO3] Maintain the security of the assets of other payment applications

[SO4] Provide evidence of cardholder participation in CMP transactions, when a Confirmation Code is supported

10.4.2.1 Evidence of Card Participation Evidence of card participation is provided by the contactless mobile payment application, for example by the successful validation of an EMV Application Cryptogram. These security functions largely reside in Zone E (the contactless mobile payment application), but rely on the security environment offered by the secure element in Zone A

10.4.2.2 Security of Contactless Payment Application Assets Typical assets to be protected in terms of confidentiality and integrity include: The CMP Confirmation Code, whenever applicable The CMP application cryptographic keys Security-sensitive, non-confidential data used by the CMP application, e.g.

the card PAN or application transaction counters These security functions are performed by the secure element, in Zone A and the provisioning and personalisation system, in Zone G.

10.4.2.3 Security of Assets of Other Payment Applications Typical assets to be protected in terms of confidentiality and integrity include: Confirmation codes and application keys, when shared with other payment

applications


These security functions are performed in the secure element, in Zone A, and to an extent in the mobile platform in Zone D, where sensitive information such as confirmation codes are entered.

10.4.2.4 Evidence of Cardholder Participation If a suitable Confirmation Code verification has to be successfully performed before generating contactless payment transaction data, conducting a successful transaction implies cardholder participation. The evidence of cardholder participation depends on: The evidence of card participation The Confirmation Code verification by the contactless payment Application The confidentiality of the Confirmation Code These security functions are carried out in the contactless mobile payment application (Zone E) and the mobile platform (Zone D).

11 Summary

This document has provided an architectural overview of Contactless Mobile Payment for the purposes of the work of EMVCo. The document covers the system architecture, the definition of zones within the system, and more detail on the architectures of handsets and secure elements. The document further provides the high level architectures for specific areas of interest to EMVCo, namely, Application Choice, Provisioning and Personalisation, Parameter update and counter reset, and high level security considerations. These areas will be developed further in additional EMVCo Contactless Mobile Payment documentation.

>>

ScopeAudience

ReferencesEMV DocumentsExternal References

DefinitionsAbbreviations and TerminologyAbbreviations

Contactless Mobile PaymentsArchitectureSystem ArchitectureArchitectural ZonesDefinition of Architectural ZonesEMVCo Role

Handset Physical ArchitectureSecure Element Architecture

Application ChoiceProvisioning and personalisation.Parameter update and counter resetSecurityContactless Mobile Payment SecurityDifferences from single issuer controlled contactless payment devicesImpacts on Security ArchitectureRemote Personalization

Security Policy and RequirementsHigh-level PolicySecurity ObjectivesAssumptionsMain ObjectivesEvidence of Card ParticipationSecurity of Contactless Payment Application AssetsSecurity of Assets of Other Payment ApplicationsEvidence of Cardholder Participation

Summary

Contactless Mobile Payment Architecture Overview 2010062808363068

Documents

mobile payment ecosystem

mobile devices

contactless mobile payments

contactless payment

remote payment

payment terminal

emvco role

llc emvco