Contactless Mobile Payment Architecture Overview 2010062808363068

EMVCo
Contactless Mobile Payment
Contactless Mobile Payment Architecture

Overview
Version 1.0
June 2010
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.
Contactless Mobile Payment Architecture Overview
Contents
1
Scope
1.1
Audience
References
2.1
2.2
1
2
EMV Documents
External References
2
2
Definitions
Abbreviations and Terminology
4.1
Abbreviations
Contactless Mobile Payments
Architecture
6.1
System Architecture
6.2
Architectural Zones
6.2.1
Definition of Architectural Zones
6.2.2
EMVCo Role
6.3
Handset Physical Architecture
6.4
Secure Element Architecture
8
10
10
12
13
14
Application Choice
16
Provisioning and personalisation.
19
Parameter update and counter reset
20
10
Security
22
10.1 Contactless Mobile Payment Security

10.1.1 Differences from single issuer controlled contactless payment
devices 22
10.1.2 Impacts on Security Architecture
10.1.3 Remote Personalization
10.2 Security Policy and Requirements
10.3 High-level Policy
10.4 Security Objectives
10.4.1 Assumptions
10.4.2 Main Objectives
11
Summary
2008,2009 EMVCo, LLC (EMVCo). All rights reserved.
22
23
24
24
24
25
25
25
26
Page ii
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
Page 1
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
The Role and Scope of EMVCo in Standardising the Mobile
Payments Infrastructure
EMV Contactless Communication Protocol Specification
[ROLE]
[CCPS]
2.2
External References
[102588]
[14443]
[18092]
[7816]
[GPCS]
[HCI]
[SWP]
ETSI TS 102 588, Technical Specification

Smart Cards; Application invocation Application Programming
Interface (API) by a UICC webserver for Java Card platform
ISO/IEC Identification cards Contactless integrated circuit(s)
cards Proximity cards 2001
ISO/IEC 18092 Information technology Telecommunications
and information exchange between systems Near Field
Communication Interface and Protocol (NFCIP-1)
ISO/IEC 7816-4 Identification cards Integrated circuit cards
Part 4: Organization, security and commands for interchange
GlobalPlatform, Card Specification, Version 2.2, March 2006
ETSI TS 102 622, Smart Cards; UICC Contactless Front-end
(CLF) interface; Host Controller Interface (HCI)
ETSI TS 102 613, Smart Cards; UICC-CLF Interface; Physical
and Data Link Layer Characteristics.
Page 2
Overview of EMVCo Mobile Payments Standardisation Activities
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 3
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.
Page 4
June 2010
4
4.1
Abbreviations and Terminology

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
Page 5
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
Page 6
June 2010
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).
Page 7
Architecture
6.1
System Architecture
The system architecture which is considered of interest to EMVCo is illustrated

in Figure 1.
Personalisation
backend
Mobile Device
Personalisation
and provisioning
server
User
Interface
Wide area
modem
Application
Environment
Update
Server
Payment
application
Payment
application
issuer
Secure
Element
Secure
Element
Secure
Element
Router
Contactless module
(NFC Controller)
Contactless
Payment
Terminal
Payment
system
network
Figure 1 Contactless Mobile Payment System Architecture
Page 8
June 2010
The CMP capable mobile device has a number of logical components 1, including:
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.
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 device 3.
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 Element 5.
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.
Note that the contactless module may support contactless protocols other than just
CCPS, for example, it may support MiFare, FeliCa or NFC [18092].
2
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.
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.
4
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.
Page 9
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
6.2.1
Architectural Zones
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.
Page 10
June 2010
Personalisation
backend
D
Mobile Device
Personalisation
and provisioning
server
User
Interface
Wide area
modem
Application
Environment
ASecure
Update
Server
Element
Secure
Element
Secure
Element
Payment
application
issuer
Router
Contactless module
(NFC Controller)
C
F Contactless
Payment
Terminal
Payment
system
network
Figure 2 Architectural Zones

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
Page 11
organisations
A
The Secure Element
EMVCo, ETSI SCP,

GlobalPlatform, GSMA
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
The component (antenna) which

implements the analogue part of the EMV
contactless interface.
EMVCo, NFC Forum
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
The contactless payment application
Payment systems
The payment terminal.
EMVCo, Payment
systems
The provisioning and personalisation

system.
EMVCo, GSMA,
Payment systems
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.
Page 12
June 2010
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.
Page 13
ISO 7816
interface
with
baseband
Removable
card, e.g.
SD/MMC
cards
M
e
m
Handset
Connection
to Secure
Element
(e.g. SWP,
ISO7816,
S2C etc)
UICC Card
SE
Contactless
Module
(NFC
Controller)
Cntl
Communication link
between the UICC and
contactless module (e.g.
SWP, HCI)
SE
Contactless
antenna
SD/MMC
Interface
Baseband
and
Application
Processor
Communication link
between the
Application processor
and the contactless
module, (e.g. NCI)
Phone processor to run

interface applications
Figure 3 Handset physical architecture

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:
Page 14
June 2010
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.
Secure Element
App
App
App
SECM
Device interface
Antenna interface
Figure 4 Secure Element Logical Architecture
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 SECM 6 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.
6 The Contactless Registry Service (CRS) defined by GlobalPlatform is one example of an

SECM.
Page 15
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.
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.
Page 16
June 2010
A user may choose to activate 7 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).
Secure Element
Application
Application
Activation
ActivationUser
User
Interface
Interface
SECM
App
App
Secure Element
SECM
PPSE
Routing
Table
Router
App
App
Secure Element
SECM
App
App
Contactless module
(NFC Controller)
Figure 5 Application Choice Logical Architecture
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.
Page 17
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 vary 8.
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.
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.
8
9 Note that the PPSE is a shared application which will be used by all CMP applications
on the mobile device.
Page 18
June 2010
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 6 10. Provisioning and personalisation is
in zone G.
Personalisation
backend
Mobile Device
Personalisation
and provisioning
server
User
Interface
Wide area
modem
Application
Environment
Secure
Element
Secure
Element
Secure
Element
Router
Contactless module
(NFC Controller)
Figure 6 Provisioning and Personalisation
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.
Page 19
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.
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.
Page 20
June 2010
Mobile Device
User
Interface
Wide area
modem
Application
Environment
Update
Server
Payment
application
issuer
Secure
Element
Secure
Element
Secure
Element
Router
Contactless module
(NFC Controller)
Contactless
Payment
Terminal
Payment
system
network
Figure 7 Updates and Resets
Page 21
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.
Page 22
June 2010
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.
Page 23
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-theair, 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 cardspecific 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.
Page 24
June 2010
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
Page 25
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.
<< END OF DOCUMENT >>>
Page 26
June 2010

Contactless Mobile Payment Architecture Overview 2010062808363068

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Contactless Mobile Payment Architecture Overview 2010062808363068

Diunggah oleh

Hak Cipta:

Format Tersedia

EMVCo

Contactless Mobile Payment

Contactless Mobile Payment Architecture

Contactless Mobile Payment Architecture Overview

Abbreviations and Terminology

Contactless Mobile Payments

Provisioning and personalisation.

Parameter update and counter reset

10.1 Contactless Mobile Payment Security

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

Contactless Mobile Payment Architecture Overview

EMVCo is in the process of addressing issues surrounding the installation and

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

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

Contactless Mobile Payment Architecture Overview

EMV documents are available on the EMVCo Website:

EMV Mobile Contactless Payment Technical Issues and Position

ETSI TS 102 588, Technical Specification

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

Overview of EMVCo Mobile Payments Standardisation Activities

The following terms are used in this specification.

Application Activation User Interface A user

A code or password entered into a mobile device in

Integration of EMV based contactless payment

An application which is hosted in a secure element

A module within a mobile device providing a

A contactless reader conforming to EMV Contactless

EMV is a global standard for credit and debit

EMVCo manages, maintains and enhances the EMV

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

Contactless Mobile Payment Architecture Overview

A type of mobile device, specifically a mobile phone

Alternative term for a user interface

A portable electronic device with contactless and wide

A short range contactless proximity technology based

Secure Element Contactless Management A scheme

A tamper resistant module, capable of hosting

Subscriber Identity Module An application on a

Single Wire Protocol the electrical and protocol

Universal Integrated Circuit Card the physical

Input and output components on a mobile device, for

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

Contactless Mobile Payment Architecture Overview

Abbreviations and Terminology

Physical smartcard interface based on ISO/IEC 7816

Application Activation User Interface

Application Definition File

Application Protocol Data Unit

Contactless Mobile Payment

Contactless Registry Service

European Telecommunication Standards Institute

GSM Association an association of GSM operators

Host Controller Interface, defined by ETSI TS 102 622

Inter-Integrated Circuit two wire serial bus for

NFC Controller Interface

Near Field Communications

Over the Air

Primary Account Number