0% found this document useful (0 votes)

316 views42 pages

EMVCo Software Based Mobile Payment Security Requirements - V1.0 - 20161213 - 20161213093622436

This document provides guidelines for securing mobile payment applications that do not use a secure element. It defines requirements in three areas: application design best practices over the lifecycle, architecture for secure components and interfaces, and specific security requirements. The goals are to protect payment credentials and transactions from attackers and threats. Requirements address secure communication channels, platform security, device attestation, credential storage, and updating mechanisms. The document aims to provide a baseline level of security for software-based mobile payment applications.

Uploaded by

Dagoberto Vega

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

316 views42 pages

EMVCo Software Based Mobile Payment Security Requirements - V1.0 - 20161213 - 20161213093622436

Uploaded by

Dagoberto Vega

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 42

EMV®

Mobile Payment

Software-based Mobile Payment Security

Requirements

Version 1.0
December 2016

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted
only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a
registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Mobile Payment
Software-based Mobile Payment Security Requirements v1.0 Page 2 / 42

Legal Notice
The EMV® Specifications are provided “AS IS” without warranties of any kind, and EMVCo
neither assumes nor accepts any liability for any errors or omissions contained in these
Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-
INFRINGEMENT, AS TO THESE SPECIFICATIONS.

EMVCo makes no representations or warranties with respect to intellectual property rights of

any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to
determine whether any implementation of the EMV Specifications may violate, infringe, or
otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other
intellectual property rights of third parties, and thus any person who implements any part of
the EMV Specifications should consult an intellectual property attorney before any such
implementation.

Without limiting the foregoing, the Specifications may provide for the use of public key
encryption and other technology, which may be the subject matter of patents in several
countries. Any party seeking to implement these Specifications is solely responsible for
determining whether its activities require a license to any such technology, including for
patents on public key encryption technology. EMVCo shall not be liable under any theory for
any party’s infringement of any intellectual property rights in connection with the EMV
Specifications.

Version History
Version Date Description
V1.0 December 2016 First publication.
This document provides security guidance and
defines generic security requirements for
applications and interfaces involved in payment
transactions that do not involve a Secure Element.

Contents
Version History ................................................................................................................... 3
1 Introduction ................................................................................................................... 7
1.1 Objective ................................................................................................................ 7
1.2 Target Audience ..................................................................................................... 8
1.3 Scope ..................................................................................................................... 8
1.4 Abbreviations.......................................................................................................... 8
1.5 Terminology.......................................................................................................... 10
1.6 Related Documentation ........................................................................................ 14
2 Software-based Mobile Payments .............................................................................. 15
2.1 Mobile Application ................................................................................................ 15
2.1.1 Software Development Kit ......................................................................... 15
2.1.2 Software Library ........................................................................................ 16
2.2 Credential Manager .............................................................................................. 16
2.3 Credential Storage................................................................................................ 16
2.4 Consumer Device Platform ................................................................................... 18
2.4.1 Basic Platform ........................................................................................... 18
2.4.2 Enhanced Platform ................................................................................... 19
2.5 System Overview ................................................................................................. 20
3 Mobile Application Life Cycle and Best Practices .................................................... 21
3.1 Application Design and Development ................................................................... 22
3.1.1 Secure Communication Channels ............................................................. 22
3.1.2 Platform Security....................................................................................... 23
3.1.3 Device Attestation ..................................................................................... 23
3.2 Mobile Application Download and Installation ....................................................... 24
3.3 User Enrolment .................................................................................................... 24
3.4 Provisioning and Credential Issuance ................................................................... 24
3.5 Card Credential Replenishment ............................................................................ 25
3.6 Monitoring and Reporting Information ................................................................... 25
3.7 Mobile Application Security and Management ...................................................... 26
3.7.1 Application and Platform Update Mechanism ............................................ 26
3.8 Application Removal ............................................................................................. 26
4 Mobile Application Security Architecture .................................................................. 27
4.1 Architecture of the Mobile Application ................................................................... 27
4.1.1 Types of Mobile Application Components ................................................. 27

4.1.2 Interface Endpoints ................................................................................... 28

4.2 Mobile Application Security Model ........................................................................ 29
4.2.1 Security Objective ..................................................................................... 29
4.2.2 Attacker Goal ............................................................................................ 29
4.2.3 Payment Threats....................................................................................... 29
4.2.4 Scenarios .................................................................................................. 30
4.2.5 Threat Model ............................................................................................. 30
4.2.6 Attacks ...................................................................................................... 31
4.3 Assurance Level and Rating ................................................................................. 33
4.4 Mobile Application Assets ..................................................................................... 34
5 Mobile Application Security Requirements ............................................................... 36
5.1 MA-SEC-REQ-1: Security Guidance and Usage Instructions ............................... 36
5.2 MA-SEC-REQ-2: Asset Protection........................................................................ 37
5.3 MA-SEC-REQ-3: Mobile Application Protection .................................................... 38
5.4 MA-SEC-REQ-4: Authentication–Identification and Verification ............................ 39
5.5 MA-SEC-REQ-5: Consumer Authentication .......................................................... 39
5.6 MA-SEC-REQ-6: Reporting .................................................................................. 40
5.7 MA-SEC-REQ-7: Cryptographic Keys, Methods, and Random Numbers .............. 41
5.8 MA-SEC-REQ-8: Secure Mobile Application Design and Development ................ 42

Tables
Table 1.1: Abbreviations ...................................................................................................... 8
Table 1.2: Definitions ......................................................................................................... 10
Table 1.3: Related Documentation ..................................................................................... 14
Table 4.1: Attacks on the Mobile Application ...................................................................... 31
Table 4.2: Mobile Application Assets.................................................................................. 35

Figures
Figure 2.1: Provisioning of Software Card Credentials ....................................................... 17
Figure 2.2: Basic Mobile Payment System Overview (Example) ........................................ 18
Figure 2.3: Enhanced Mobile Payment System Overview (Example) ................................. 19
Figure 3.1: Mobile Application Life Cycle Model ................................................................. 21

1 Introduction
The payment industry has concentrated its efforts for several years on leveraging the existing
chip-based ecosystem and processes, where security models are well known and defined.
With the deployment of mobile consumer devices and the opportunity for easier deployments,
the payment industry is interested in a trust model that does not rely on the use of a Secure
Element (SE) to store and process payment transactions. This new model comes with its
challenges and requires, in particular, specific attention to the security aspect of such designs
and implementations.
There are many different available architectures to implement software-based payment
applications. Such applications can be installed, for example, in a Rich Execution Environment
(REE) or in a Trusted Execution Environment (TEE). The architecture choice has an impact
on the final security level of the payment product.
This document aims to establish a common security understanding around using a Consumer
Device (such as a mobile phone) for payment without involvement of a Secure Element (SE).
Note that an SE could still be used for other purposes.
This document does not focus on any specific type of payment; rather it:
 Provides an overview of the system architecture, both for the issuance of Software
Cards and for payment transactions using Software Cards. It also defines the various
roles involved in issuance of, and transactions with, Software Cards.
 Describes various models of management for the Mobile Application and for the
Software Cards and the Mobile Application life cycle.
An architecture reference model, including terminology and a list of roles involved in such
payment transactions, is described in a separate EMVCo document [Architecture].

1.1 Objective
This document provides security guidance and defines generic security requirements for
applications and interfaces involved in payment transactions that do not involve a Secure
Element.
Functional requirements are out of scope.

1.2 Target Audience

This document is intended for use by Payment System staff, architects and developers of
software-based payment solutions, Consumer Device architects, payment service and token
service providers, security laboratories, and Issuers of software-based payment products.

1.3 Scope
The scope of this document is the mobile application as it could be downloaded, installed,
provisioned, and used on any type of device and for any software-based payment services
(e.g. proximity payment and remote payment).
The concepts explained in this document apply for all types of Operating Systems (OS), as
well as all known Consumer Device architectures (including the use of multiple devices such
as wearables connected to a mobile phone). It includes also platforms where TEE, TPM,
and/or SE are available for hardware support.
This document does not address MPOS and 3DS security requirements; however the majority
of the security requirements might equally apply. While the final wording of the security
requirements might differ, the intent and control objectives will be addressed in future versions.

1.4 Abbreviations
The following abbreviations are used in this document.

Table 1.1: Abbreviations

Abbreviation Description
API Application Programming Interface

ATC Application Transaction Counter

BLE Bluetooth Low Energy

C Confidentiality

CDCVM Consumer Device Cardholder Verification Method

CVM Cardholder Verification Method

DBI Dynamic Binary Instrumentation

GP GlobalPlatform

Abbreviation Description
HCE Host Card Emulation

I Integrity

I+ Integrity with the addition of accountability/authentication

ID&V Identification and Verification

MPOS Mobile POS

NFC Near Field Communication

OEM Original Equipment Manufacturer

OSSAP OWASP Software Security Assurance Process

OTA Over-The-Air

OWASP Open Web Application Security Project

PAN Primary Account Number

PCI SSC Payment Card Industry Security Standards Council

PII Personally Identifiable Information

PIN Personal Identification Number

POS Point Of Sale (device)

PTC PIN Try Counter

REE Rich Execution Environment

SDK Software Development Kit

SDLC Software Development Life Cycle

SE Secure Element

TA Trusted Application

TEE Trusted Execution Environment

TPM Trusted Platform Module

1.5 Terminology
The following terms are used in this document:

Table 1.2: Definitions

Term Description

Acquirer An entity that has a commercial relationship with the Merchant and
with the Payment System and processes payment transactions on
behalf of the Merchant.

API Application Program Interface (API) is a set of routines, protocols,

and tools for building software applications.

Basic Platform A Consumer Device platform that does not provide verifiable
hardware security for protection of the Software Card security
assets.

Card A card is used here as a generic term for the payment application
linked to an account by virtue of its PAN or Token.

CVM Cardholder Verification Method or CVM is the method that is used

to check that the valid cardholder is using the card. CVM examples
are signature, online PIN and offline PIN.

CDCVM Consumer Device Cardholder Verification Method is a form of

consumer authentication performed on a Consumer Device.
Verification of the CDCVM is used as a way to verify whether the
person presenting the Consumer Device is a legitimate user of the
device. CDCVM examples are numeric passcode, a pattern (e.g.
used for Android device unlock) or a biometric authentication (e.g.
fingerprint, iris, facial).

Code lifting Transferring executable code to another system while retaining the
functionality without the need to fully reverse engineer it.

Consumer The user of Software Card credentials used for payment

transaction.

Consumer Device The device, typically a mobile phone or a tablet, which hosts the
Mobile Application used for payment by the consumer.

Term Description
Credential Manager The entity that manages the credentials to be provisioned to the
Software Card(s) used by the Mobile Application. The Credential
Manager has the capability to establish a secure communication
with the Mobile Application for the provisioning and management of
Software Cards.

Credential Provider The entity that generates the credentials for the Software Card.

Credentials Set of data elements constituting a Software Card. These data

elements are used to conduct a transaction using the Software
Card.

Device Attestation The device attestation is a mechanism that allows a Consumer

Device to present evidence to the requesting party about the
integrity of its security model.

Device Binding Using device information or hardware features such that it is hard or
impossible to operate software on a different device or platform on
a different device or platform.

Enhanced Platform A Consumer Device platform that provides verifiable hardware

security for protection of the Software Card security assets.

Information Binding Using unique device information such that it is hard to operate the
software elsewhere without obtaining this information from the
device.

Issuer The entity that issues Software Cards to the Consumer.

Library A library provides one specific function (e.g. crypto library). A

library consists of pre-written code, classes, procedures, scripts,
configuration data and more. All of the available functions within a
software library can be called/used within the program body without
defining them explicitly.

Merchant An entity that sells goods or services to the Consumer and is

equipped to process a Software Card payment transaction.

Term Description
Mobile Application The application that hosts Software Cards on board the Consumer
Device. The Mobile Application may be downloaded from an
application store or may come pre-loaded in the Consumer Device.
In its most complex form, it may store several Software Cards from
various Issuers and Payment Systems, and enables the Consumer
to manage them and transact with them. For example, a Payment
Card Manager as described in [Payment Card Management]

Mobile Application The entity responsible for installing and managing the Mobile
Provider Application on the Consumer Device.

Obfuscation Hiding information about program state, execution flow, and data
streams to make it hard to understand the meaning and
functionality. Includes obfuscation of:
 Data
 Key
 Code / program

OWASP The Open Web Application Security Project (OWASP) is a

worldwide not-for-profit charitable organization focused on
improving the security of software.
http://www.owasp.org

Payment System An entity that has a commercial relationship with the Issuer and
with the Acquirer. The Payment System specifies Software Cards
and Mobile Application(s). It may provide a Software Development
Kit (SDK) that can be integrated into a Mobile Application to
facilitate the deployment of Software Cards.

Rooting Rooting is the process by which a user of a Consumer Device

attains privileged control or root access to run privileged
commands. Rooting is often performed with the goal of overcoming
limitations that carriers and hardware manufacturers put on some
devices.

SDK A Software Developer's Kit (SDK) is a set of software development

tools that allows for the creation of a mobile application. In
particular, an SDK can be one or more application programming
interfaces (API’s) in the form of some libraries to interface to a
particular programming language or to include sophisticated
hardware that can communicate with a particular embedded
system.

Term Description
The card credentials used for Software-based Mobile Payments
Software Card
stored inside the Mobile Application. For example, a contactless
Payment Application as described in [Payment Card Management]

TA A Trusted Application is authorized software that can be securely

executed inside the Trusted Execution Environment (TEE) that
exports security related functionality to Client Applications outside
of the TEE.

TEE A Trusted Execution Environment provides security features such

as isolated execution environment for Trusted Applications. It
protects security assets from general software attacks, defines
safeguards as to data and functions that a program can access,
and resists a set of defined threats.

Token Service An entity that provides a Token Service comprised of the Token
Provider Vault and related processing.

White-Box Crypto One-way transformation of a keyed-cryptographic function to

prevent exposing the key and/or to avoid reverse engineering of the
keyed function (decrypt versus encrypt).

1.6 Related Documentation

Table 1.3: Related Documentation

Reference Document

[HCE Position] EMVCo – Position paper on the Impact of Host Card Emulation
(HCE) on Contactless Mobile Payments

[EMV Contactless] EMVCo – EMV Contactless Specification – Books A-D

[Tokenisation] EMVCo – EMV Payment Tokenisation Specification Technical

Framework

[Payment Card EMVCo – EMV Contactless Mobile Payment – Payment Card

Management] Management Whitepaper

[Architecture] EMVCo – EMV Software-based Mobile Payment, Architecture

[GP TEE Arch] GlobalPlatform – TEE System Architecture

[GP TEE PP] GlobalPlatform – TEE Protection Profile

[GP TEE WP] GlobalPlatform – TEE White Paper: The Trusted Execution
Environment: Delivering Enhanced Security at a Lower Cost to
the Mobile Market

[GP TEE UI API] GlobalPlatform TEE UI API Spec. v1.0

[TPM] Trusted Computing Group, TPM Main Specification

http://www.trustedcomputinggroup.org/resources/tpm_main_specif
ication

2 Software-based Mobile Payments

The term software-based Mobile Payments is used to identify payment transactions where the
Consumer Device is a mobile device such as a mobile phone. Commercially available software
protection solutions must be used to provide the required software security controls and
protections.

2.1 Mobile Application

The big advantage of software-based Mobile Payments is that it provides a way to offer
services without the need to use a hardware-based Secure Element. Hence, there is no
dependency on SE providers and less need to work in partnership with other parties (such as
mobile operators or handset manufacturers). It also provides more flexibility to integrate Issuer
payment programmes with their other mobile customer services.
This current document only describes requirements for a mobile application as an end-user
product that is deployment ready. However, software-only mobile applications are most of the
time based on a Software Development Kit (SDK). A SDK provides all the generic mobile
application payment functionality (e.g. interface with the NFC controller and the Credential
manager), meets most of the security requirements, and can make use of commercially
available software libraries (e.g., attestation, white-box crypto or obfuscation functionality).

2.1.1 Software Development Kit

The developer of an SDK for a payment Mobile Application focusses on the common functional
and security requirements that can be used by many Mobile Applications. A validated SDK
comes with a developer security guidance document which clearly describes how the SDK
can be securely integrated into a Mobile Application. This allows a Mobile Application
developer to focus on the integration of the SDK into their application without requiring them
to be knowledgeable of every facet of the security, functions and interfaces needed to
implement a fully functional, secure application.
Security testing of the final mobile application will be limited to a security evaluation that the
SDK security guidance has been properly implemented (this includes outstanding mobile
application requirements not covered by the SDK). This SDK approach will yield compliant
products while drastically reducing the amount of development and testing time of the final
mobile application resulting in time and cost savings. Also in case of a security issue, the SDK
products that might have an issue can be quickly identified and updated.
The SDK requirements are a subset of the Mobile Application (MA) requirements, as some
requirements might not apply to a SDK and can therefore be excluded.

2.1.2 Software Library

A software library provides a specific function (e.g. crypto library or device attestation) and can
be open source or commercially available. A library consists of pre-written code, classes,
procedures, scripts, configuration data and more. A Mobile Application or SDK can use these
available functions within a software library without redefining them. Software libraries that
provide security services will be especially beneficial when their security has been previously
evaluated and does not have to be re-evaluated during a Mobile Application evaluation.

2.2 Credential Manager

The Credential Manager has the capability to establish secure communication with the Mobile
Application for the provisioning and management of Software Cards. Depending on the model
used for the management of the Mobile Application and Software Cards, the Credential
Manager may be any of several entities, such as an Issuer, a Token Service Provider, a Wallet
Service Provider, or another Mobile Application Provider. Besides the security requirements
described in this document, the security of Software Card implementations relies on the
Credential Manager having strong security controls.

2.3 Credential Storage

In software-based Mobile Payments, card credentials may be stored in an application located
in the Rich Execution Environment (REE) or in the Trusted Execution Environment (TEE) of
the Consumer Device, as applicable. The Consumer Device REE is considered to be
untrustworthy and subject to arbitrary compromise. A TEE is considered to be more
trustworthy but not yet to a level commensurate with an SE. In addition to providing secure
storage and processing, a TEE can also provide trusted user interfaces for entering and
displaying information [GP TEE UI API].
Security assets may also be split. For example, cryptographic keys may be stored in the TEE
whilst non-sensitive parts of the card credentials may be stored in the REE. The card
credentials in such an application, even when split, are referred to as a Software Card.

Figure 2.1: Provisioning of Software Card Credentials

Credential
Manager

Secure
communication

MyBank C
MyBank B
Mobile MyBank A1234 5678 9012
Software 3456
1234 5678 9012 3456 12/17
LEE M. CARDHOLDER

Application Cards
1234 5678 9012 3456 12/17
LEE M. CARDHOLDER
12/17
LEE M. CARDHOLDER

Consumer Device

In Figure 2.1, the Credential Manager is the entity which provisions the Software Card
credentials to the mobile application. The Mobile Application is the entity which hosts the
Software Card. A secure connection must be provided to ensure that the software card
credentials are protected end-to-end regardless of the deployment model. See the Mobile
Payment architecture document [Architecture] for a more detailed description.

2.4 Consumer Device Platform

The Consumer Device platform can be software only and untrusted (i.e. Basic Platform; see
Figure 2.2) or can have some level of trust due to added security functionality and hardware
support (i.e. Enhanced Platform; see Figure 2.3).

2.4.1 Basic Platform

The Mobile Application runs on a Consumer Device platform. This platform should be
considered untrusted and may even be insecure (for example, if the device has been rooted).
It is noted that being rooted does not mean being insecure. Being rooted is a threat if the root
privileges are used to monitor or circumvent security measures used by the Mobile Application
to protect the assets.
Software Card solutions that depend purely on software security are based on a model that
does not rely on verifiable hardware security for protection of the security assets. The software
model forces the developer to create a solution that provides cryptographic services and
protects those services against attack. Therefore, the Mobile Application should implement
countermeasures (e.g. white-box crypto, obfuscation and binary protection) to enhance its
security and protect sensitive information and security assets.

Figure 2.2: Basic Mobile Payment System Overview (Example)

App
App Store Download
Enrolment / Management
Payment Credential download

Interface
Issuance Authorization
Non-payment System System
functionality

Payment
Assets

App
N
Mandatory F Reader Acquirer
Operating System
C
Optional Consumer Device Platform

2.4.2 Enhanced Platform

The Mobile Application, or parts of it, can also be implemented as a Trusted Application (TA)
in the Trusted Execution Environment (TEE) of the Consumer Device. The TEE is a separate
execution environment that runs alongside the REE and hosts trusted services offered to that
REE. The TEE can provide security features such as:
 hardware-based isolation or dedicated security core
 hardware root of trust
 trusted boot process
 hardware unique key embedded in the application processor and accessible by
trusted OS only
 hardware-based resources and peripherals for access control (e.g. fingerprint
sensor)
Trusted Applications are given controlled access to security resources and services via the
TEE Internal APIs. Because of its hardware protection, cryptographic root of trust, Consumer
Device authentication, and possibly consumer authentication services, the TEE allows for
secure remote management and update, as well as secure communication via protected
channels; it may also simplify the protection of Mobile Applications, avoiding the need for
white-box crypto. As with Secure Elements, use of the TEE implies working in partnership with
other parties (such as mobile operators or device manufacturers) that control access to the
TEE.
See the GlobalPlatform TEE white paper [GP TEE WP] for more details. Other options for
hardware security enhancements can be provided by a Trusted Platform Module (TPM) or
even embedded Secure Elements.

Figure 2.3: Enhanced Mobile Payment System Overview (Example)

App
App Store Download
Enrolment / Management
Payment Credential download

Interface
Issuance Authorization
Non-payment System System
functionality

Payment
Assets

TA or TEE App
N
Mandatory F Reader Acquirer
Operating System
C
Optional Consumer Device Platform

2.5 System Overview

Any Software-based Mobile Payment solution is comprised of several components. See the
EMVCo architecture document [Architecture] for a more detailed description. The following
focuses not on the system architecture components, but on the security functionality of the
different components.
The Mobile Application once built and tested has to be distributed to Consumer Device. It
could be pre-installed on the Consumer Device via the Original Equipment Manufacturer
(OEM) and third parties. More likely, the application will be downloaded or updated by the
user via a trusted application store or an Issuer’s web site (e.g. OTA to device).
The Mobile Application resides on a basic or enhanced platform in Consumer Device. For a
payment to take place, a valid set of card credentials needs to be present (via enrolment and
provisioning) within a Mobile Application. To manage risk effectively, these card credentials
may need to be replenished on a periodic basis.
The Credential Manager provides card configuration data that can be used to provision
cards on a Mobile Application for Software Card payments, including the initial set of
Software Card parameters deployed to the Mobile Application. It also replenishes dynamic
credential data, according to credential manager preferences. And finally, it manages the life
cycle of a Software Card (e.g. suspend, resume and remove) as determined or triggered by
either the cardholder or the Issuer.
Issuer host systems are the existing authorisation/authentication/risk management systems
that an Issuer currently uses for authorising and authenticating transactions. These
components are therefore not new, but will typically need to be modified and/or enhanced to
adequately support cloud-based payments. This Issuer host system plays an important role
in its analysis of transaction data to maintain the security of the Software Card.
The acquirer is the organisation that is responsible for signing up the merchant and acquiring
the transaction. No changes are required to the acquirer systems in order to support
Software Card payments.

3 Mobile Application Life Cycle and Best

Practices
This chapter summarizes considerations that must be taken into account when designing,
building, and deploying a secure Mobile Application. Software solutions can be strengthened
by using a multi-layered and dynamic security model (e.g. no single point of failure). By
reinforcement of the weak areas, we can ensure that the combination is strong. Hence, one
should take a broad, systemic view – rather than focussing purely on how to secure the
software components in isolation. This is especially important for solutions that rely on
Consumer Device platforms that do not provide verifiable hardware security (Basic Platforms)
for protection of the Software Card security assets.
Figure 3.1 provides an example of a Mobile Application life cycle model. It highlights the
different phases that must be considered when designing a Mobile Application solution. This
chapter provides best practices for the different stages in the Mobile Application life cycle as
well as other security relevant aspects in the payment ecosystem.

Figure 3.1: Mobile Application Life Cycle Model

App
Application Design and
Removal
Development

App Download Software Card

Management
Card Removal /
Blocking

App Update Production

State
Payment
User Capable
Enrolment
Reader
Payment
Credential
Software Issuance
Card
Provisioning

3.1 Application Design and Development

Mobile Applications and their relying components (e.g. SDK and Libraries) must be designed
and developed based on a software development life cycle methodology. This includes
security best practices such as outlined in the OWASP Software Security Assurance Process
(OSSAP). Following such processes will reduce the possibility of requirement oversights,
design flaws, implementation bugs, and deployment configuration mistakes. There are several
other methodologies that could be referenced but the intent is to ensure security practices are
consistently applied to the Mobile Application and other components of the payment solution.
Moreover, one must take full account of evolving and anticipated industry standards, and draw
upon communities (e.g. OWASP) that are focused on the security of Mobile Applications. As
software security standards evolve rapidly and best practices change quickly, it is important
to ensure that the latest set of best practices are followed and to use the most recent
generation of secure technologies.
Specific design and development security requirements include the following:
 The Mobile Application must be designed and built following security best practices.
 Developers must perform a threat and vulnerability assessment and identify early in
the development cycle the security requirements for the Mobile Application and how
sensitive payment assets and security functions must be protected.
 Developers must ensure that the application is developed in controlled development
environments conforming to industry best practices.
 Developers must conduct design reviews of the security architecture with business
and technical resources.
 Developers must conduct code analysis and secure code reviews.
 Developers must conduct functional, security, and penetration testing early and often
within the integration, validation, and production stages of the product life cycle.
 To ensure the security enforcing features do not impact the functional requirements
of the Mobile Application, all security measures must be in place and operational
during approvals testing.

3.1.1 Secure Communication Channels

No matter how securely data is stored while at rest, it can still be at risk whilst in transit, so it
must be protected accordingly. All communications from the consumer’s device to a Credential
Manager (or other cloud-based systems) must apply end-to-end protection to ensure that
sensitive information is protected at the required security level and not being exposed to a
lower level of security. This will also ensure that security assets are not available in an
unprotected format in any of the systems that route the communication between the endpoints
and thereby mitigates the risk of man-in-the-middle attacks on third parties through which
sensitive information passes.

3.1.2 Platform Security

More often than not, the security of the Mobile Application relies on the security functionality
provided by the platform of the Consumer Device. Although it is not always possible to secure
this platform, it is often possible to verify its integrity and status, or to authenticate the
environment. Ideally the Mobile Application, or its relying Software Card system components,
should be able to monitor the platform it is running on, detect any abnormalities (e.g. reporting)
that may arise in a compromised device, and act accordingly.
Rooting is the process by which users of Consumer Devices attain privileged control within
the device platform (the process is also known as jail-breaking). Unauthorized users (e.g.
hackers or remote attackers) will use these elevated privileges to gain further access to the
device for different purposes. It should be noted that, when a consumer roots a device, they
can do this for a legitimate purpose and do not necessarily intend to attack the Mobile
Application. In fact, users will generally root a device for completely benign purposes (such as
having more flexibility in customising the Operating System). That said, a rooted device does
open the door to numerous attack vectors or vulnerabilities, and one should consider carefully
whether to allow the Mobile Application to operate in these circumstances. This might require
additional root detection controls and risk mitigation strategies.

3.1.3 Device Attestation

The security of the Software Card solution cannot rely solely on the security of the Mobile
Application. It also relies on the security status of the Consumer Device and the server-side
controls. Server-side controls might be able to detect a Software Card or device compromise
either by transactional data analysis (e.g. monitoring and fraud detection) or by information
explicitly provided by the device (e.g., device attestation).
The device attestation is a mechanism that allows a Consumer Device to present fresh
evidence to the server-side about the integrity of its security model. However, such an
attestation does not necessarily provide reliable information on whether the Consumer Device
is rooted. For it to work, the underlying attestation mechanism should be trustworthy and the
evidence be securely conveyed to the server-side. As a Consumer Device runs in a potentially
hostile environment, it may not be clear how this security functionality can be preserved, how
the mechanism will respond to new attacks or be securely updated.
Device Attestation and Monitoring are important aspects of a Software Card multi-layered
security design. They also highlight the difference between traditional chip card security
evaluations, where the chip card rating does not include these attestation mechanisms and
server-side controls.
Once a device attestation mechanism is compromised, the server-side cannot rely on this
information. Hence, transactional data analysis, by monitoring and fraud detection, is another
important security layer in the Software Card multi-layered security design.

3.2 Mobile Application Download and Installation

The Mobile Application, once built and tested, has to be distributed to a Consumer Device. It
could be pre-installed on device via OEMs and third parties. More than likely the application
will be distributed via a trusted application store or a trusted web site (OTA to device). One
must consider the following:
 Make the Mobile Application available through recognized sources (e.g. the Google
Play App store or the Issuer’s web site).
 Download and install only on Consumer Devices that support the functionality
necessary for the intended payment service and application to properly operate.
 Perform application and device integrity checks prior to Mobile Application installation
on the Consumer Device (e.g., via signature verification and device attestation).
 Have a verifiable audit trail of the Mobile Application installation process.

3.3 User Enrolment

User enrolment enables the cardholder to request the registration of their Software Card. It is
an important life cycle event, normally conducted remotely (e.g. OTA), at the time a consumer
wishes to enrol a payment card to the Mobile Application. Some Identification and Verification
(ID&V) considerations that need to be taken into account are:
 There must be defined and established Identification and Verification (ID&V)
requirements to be used during the user enrolment process.
 The user enrolment process must verify through remote device attestation whether
the device is in a trusted state before releasing protected data to or storing private
information on the Consumer Device.

3.4 Provisioning and Credential Issuance

Following enrolment, provisioning and credential issuance is defined as the configuration of
the Software Card within the Mobile Application to be ready for use, including an initial set of
card credentials and possibly device risk parameters.
The greatest risks are likely to relate to the cardholder registration and provisioning processes.
One will need to ensure that credentials are installed in and tightly bound to the right device,
and that the process is not vulnerable to reverse engineering. The following must be
considered:
 Once a user has successfully enrolled, the Software Card credentials must be
securely provided to the Mobile Application.

 The card credential elements provisioned must be determined by the configuration

parameters supported by a given payment system, the Mobile Application model
used, and regional/Issuer needs.
 Once user enrolment and account provisioning are completed, the Mobile Application
should be ready to conduct payments immediately.

3.5 Card Credential Replenishment

Card credential replenishment initiates replenishment requests, and processes new sets of
card credentials and possibly device risk parameters. The day-to-day operation of Software
Card payments will revolve around the on-going management and periodic replenishment of
card credentials, which determine whether it is possible for payments to take place, and
therefore perform a critical risk management function. As with traditional card-based
payments, the risks relating to lost and stolen devices can generally be mitigated though a
robust cardholder verification method (CVM); however, even in the event of a compromised
CVM, the following can limit fraud.
 The Mobile Application must connect to the cloud-based system to obtain payment
credentials such as keys, tokens, parameters.
 The Mobile Application must allow the credential manager to refresh/update the card
data elements on subsequent connections to the cloud-based system.
If the old device is being disposed of, then card replenishment must invalidate all data bound
to the old device and repeat provisioning and credential issuance on the alternate device.

3.6 Monitoring and Reporting Information

Once the Mobile Application has been designed and built, it is important to develop monitoring
and reporting functionality. This will enable relevant data to be retrieved and reported to control
servers at specific points in the operation of the Mobile Application. The intelligent use of such
data has several benefits, including:
 Early detection of malware on Consumer Devices: A control server can collect the
type of information that, when used intelligently, will help to establish the nature and
size of an attack on any given portfolio, thereby limiting the potential damage.
 Improvements in fraud detection: Fraud detection systems can draw on a more
comprehensive set of data, and will therefore become more adept in identifying
potentially fraudulent transactions.
 Enhancing the user experience: This level of data can help back-end systems to
make better-informed decisions on transaction authentication and authorisation,
thereby reducing the need for repeated or intrusive consumer verification.

If ever a compromise is detected, one will need to ensure appropriate action is taken.
Depending on the severity of the compromise, this could include a range of measures – from
suspension of the payment capability and contacting the cardholder, through full deactivation
of the Mobile Application and the deletion of all Software Card credentials.

3.7 Mobile Application Security and Management

From the outset, one should accept that the Mobile Application will be targeted by attackers –
possibly through malware, or reverse engineering, or opportunism, or attempts to infiltrate
relying websites or back-end systems. It is important to protect the Mobile Application against
any unauthorised modification or updates and to ensure that it can verify its own integrity at
least at runtime.
As the Mobile Application is downloaded and installed on a potentially hostile device, it is
highly likely that any unauthorized application modification or update is the result of either
malware or a malicious user. The Mobile Application should not only be able to resist such
attacks, but should also be able to report them to the appropriate relying system or to act
appropriately (stop execution).

3.7.1 Application and Platform Update Mechanism

Mobile Application updates are used to add new functionality or correct bugs. Sometimes it
may be necessary to deploy an application or platform update to fix known security issues. In
this case, and especially when a critical security vulnerability has been detected, it is important
to have the ability to force an update – either automatically or by requiring the user to download
and install the latest version of the Mobile Application.
Mobile Applications for managing Software Card products and the platforms on which the
Mobile Application is installed will be frequently updated in the field after deployment.
Therefore, it is important that:
 the Mobile Application has a secure update mechanism
 the platform has a secure update mechanism
The update mechanism must incorporate good version control, roll back prevention, as well
as protection of the credential data. The Mobile Application might depend on the underlying
platform to securely implement this functionality.
Once a Mobile Application has been installed or updated, it is unusual (although not unheard
of) for consumers to conduct a user-initiated roll-back to an earlier version of the application.

3.8 Application Removal

If a user does not want to use the Mobile Application any longer, the Software Card credentials
must be securely deleted before removal of the Mobile Application.

4 Mobile Application Security Architecture

This chapter provides an overview of the Mobile Application security architecture. It introduces
the Mobile Application security model including a description of the assets to be protected by
the Mobile Application.

4.1 Architecture of the Mobile Application

Depending upon implementation, the functionality of the Mobile Application can be distributed
over a number of components. These components may be contained within the Consumer
Device, but some components may be external; for example, a mobile phone used with a
wearable accessory such as a watch.
In addition to provisioning and authorisation functions necessary to manage the risk inherent
in Software Card payments, there are also server-side components that contribute to Mobile
Application security functionality; for example, detection of compromise of a device either by
information explicitly provided by the device (e.g., via device attestation) or by transactional
data analysis (e.g. by monitoring and fraud detection).
There must be a clear specification of the protection required for each of the assets within the
device and any associated external components. The level of protection required will depend
on the lifetime of those assets and their sensitivity. The lifetime or sensitivity must be reduced
(for example, by enhancing back-end server functionality providing additional detection for
compromised devices), or the assets must be moved to a more secure location such as within
a TEE. Additionally mobile application protection must be applied (for example, white-box
crypto, obfuscation, and binary protection), to augment the risk protection provided by the
platform and server-side components.

4.1.1 Types of Mobile Application Components

The assurance provided by the Mobile Application will vary according to the architecture of
the Mobile Application and the way in which it uses its components. For example, Mobile
Application asset processing and storage may be wholly performed by an application
executing in the REE. Alternatively the Mobile Application may be distributed over components
that use functionality provided by a TEE and REE and further supported by hardware
components such as a TPM or SE.
A specification of the Mobile Application architecture is important for evaluating the security
afforded to assets by the implementation as they flow between components. A component
may have some level of pre-existing assurance. Even so, it may have some limitations on the
assurance it can provide.

4.1.2 Interface Endpoints

Assets will flow between components of the Mobile Application using available component
interfaces. These interfaces may be internal or external to the Consumer Device and might
have security support. For example, a Mobile Application payment processing component may
be installed on a wearable accessory and provisioned from a Mobile Application component
on the Consumer Device using Bluetooth Low Energy (BLE). This BLE connection must be
securely configured.
Mobile Application assets are transmitted over an interface between endpoints. An endpoint
may be external to the Mobile Application; for example, the NFC Controller or the Credential
Provider cloud [Architecture]. An endpoint may also be integrated in the Mobile Application
and could be a component that provides the required security services for the transmitted
assets; for example, a TEE. The transmission of assets over interfaces between endpoints
must not conflict with the required security services of the endpoints.

4.2 Mobile Application Security Model

4.2.1 Security Objective

The objective of the Mobile Application security model is to ensure that the Mobile Application
provides required security functions to protect the Mobile Application assets identified below,
by providing an attack surface that is uneconomic for an attacker to penetrate. However, it is
recognized that an attacker may have other objectives (e.g. self-promotion, nation-state
attack, or to discredit the product) to spend a lot more resources to break the system than is
warranted by the direct financial fraud payback.

4.2.2 Attacker Goal

The presumed goal of an attacker is to compromise Mobile Application assets on the
Consumer Device to perform unauthorized payments, for financial gain, publicity, or other
reasons (e.g. denial-of-service). Attacker capabilities, classes and models are out of scope.

4.2.3 Payment Threats

The primary payment threats are the following:
 The successful deployment of a scalable attack (especially one that can infect and
spread to multiple Consumer Devices) which proceeds undetected (for a period of
time) and delivers active assets from compromised devices to unauthorized devices.
 An attack which enables an unauthorized party to perform fraudulent payments via
remote access to legitimate devices that have been compromised.
 Mobile Application cloning where a single compromised Consumer Device duplicates
(clones) its assets to unauthorized devices or where data is selectively duplicated so
that multiple (partial) clones may all transact without detection.
 A denial-of-service attack that would prevent a consumer from making a payment.
 Unauthorized payments made with ‘lost and stolen’ devices.

4.2.4 Scenarios
Two scenarios are considered where an attacker tries to compromise Mobile Application
assets, or identify and exploit vulnerabilities:
 The attacker gains remote access to the Consumer Device through manipulation of
one or more available logical interfaces.
In this scenario the security objective is to reduce the risk of scalable logical attacks
on the Mobile Application that achieve the attacker’s goal.
 The attacker gains local access to the device through manipulation or eavesdropping
of available physical or logical interfaces, or by physical tampering.
Physical attacks are typically not scalable but if it is possible to use the Mobile
Application by straightforward physical means following the attack then any ‘lost and
stolen’ prevention mechanism – such as device lock and/or consumer authentication
requirements for payment – are no longer effective.

4.2.5 Threat Model

An attacker might try to compromise the Mobile Application assets in the different phases of
the Mobile Application’s life cycle with different windows of opportunity; for example, during
enrolment, provisioning, card credential replenishment, payment, and Mobile Application
update.
For each stage of the life cycle, the threat model considers two phases: identification and
exploitation. In the identification phase, the attacker tries to develop a successful attack. The
exploitation phase corresponds to the effort required to repeat the identified attack on a limited
or large scale.
In the identification phase, physical and logical analysis can be considered to identify potential
attack paths. However, in the end the most important consideration is whether the attack can
be easily exploited, and especially whether it is scalable.

4.2.6 Attacks
To compromise the inherent security of the Mobile Application, an attacker is likely to attempt
one of the attacks listed below.

Table 4.1: Attacks on the Mobile Application

Attack Description Attack Path

1 Bypass mobile Gain privileged access A malware infection uses a published
platform (e.g. OS) to Mobile Application exploit or zero-day attack targeted at a
security controls processing and specific platform vulnerability which can
assets. be used to escalate privilege.

2 Reverse engineer Recover sensitive Native code disassembly

Mobile Application source code and
Java code de-compilation
source code extract sensitive
Mobile Application Code structure analysis
assets. Asset extraction

3 Modify Mobile Alter behaviour of Code is modified or malicious code

Application code Mobile Application. injected, for example to present false
information to the user.

4 Exploit interfaces Abuse the interfaces Masquerade as a legitimate payment

between between the application in the REE interacting with a
components components that trusted application in the TEE.
make up the payment
Compromise the results of consumer
application.
authentication thereby fooling the mobile
application into believing that CDCVM
has been performed.
Compromise HCE functionality to relay
transactions to a remote endpoint.

5 Extract assets in Recover assets from The application is executed under

runtime an application running debugger, emulator or dynamic binary
under the attacker instrumentation (DBI). The attacker
control. intercepts plaintext assets at the time
they are processed in memory.

Attack Description Attack Path

6 Modify mobile Manipulate critical The application is executed under
application code mobile application debugger, emulator or dynamic binary
flow functionality. instrumentation (DBI). The attacker
injects malicious code that alters the
logic of the application in order to
perform fraudulent payments directly on
device, facilitate recovery of assets for
off-device attacks, suppress reporting to
backend, etc.

4.3 Assurance Level and Rating

To protect against brand and reputation damage – as well as financial loss – one must ensure
that:
 There are no viable scalable logical attacks where the cost of attack is lower than the
expected returns.
 Physical attacks would take a sufficiently long time to exploit such that the cardholder is
likely to have reported the device as lost or stolen and/or has its Software Card
credentials deactivated before the attack can be successful.
The risk model for software-based mobile payments is different from the traditional chip-based
payment model. In contrast to chip card solutions, the security of the overall solution heavily
relies on the effectiveness of the server-side components and back-end system in replenishing
card credentials and detecting potential compromise of the Mobile Application and/or device
integrity either from information provided directly by the Mobile Application, device attestation
or inferred from transactional analysis. In current rating systems this information is not always
considered.
A complicating factor in establishing an assurance level or an attack rating is how to establish
risk values of the various security assets. The well-known chip-card categories for primary and
secondary assets are not very useful for software-based mobile payment solutions. For
example, the impact of stealing short-term payment keys, code lifting (i.e. breaking device
binding), or stealing authentication data is different from exposure of unique card keys or
manipulation of a PIN Try Counter (PTC) for card products. In the end, it is important to know
not only whether a fraudulent payment can be made with the attack, but also what are the
additional risks related to privacy, identity theft, and brand promise.
Software attacks are inherently easy to repeat. Hence, the attack effort needed is mainly in
the identification phase, which complicates the rating model for software solutions. Current
rating methods do not take into account Issuer risk management in the back-end system;
instead the rating relies solely on the robustness of the payment device itself.
The current approach toward rating software-only solutions is based on understanding the
risks these solutions introduce and managing those risks to an acceptable level. An industry
acceptable assurance level for protection of Software Card solutions has not been established
and/or agreed upon yet.

4.4 Mobile Application Assets

Identified Payment System assets are required to be protected within the payment ecosystem.
In addition to requirements imposed by payment systems, the required protection for some
assets may be determined by national regulation; for example, personally identifiable
information (PII). PCI SSC also specifies requirements for protection of sensitive data
(cardholder data and sensitive authentication data) and cryptographic keys used to protect
cardholder data.
Static (long-lived) assets require higher assurance than dynamic or ephemeral (short-lived)
assets due to their persistence in the Consumer Device. However, note that attacks on short-
lived or ephemeral assets could be more viable for an attacker than one on a master key that
might be blocked by a counter after a few unsuccessful transactions.
The following table identifies the Mobile Application assets that must be protected to an
industry-acceptable assurance level. Assets must be categorised as requiring one or more
security services: Confidentiality (C), Integrity (I), and Integrity with the addition of
accountability/authentication (I+). The vendor might additionally claim other security services
(e.g. confidentially for binary code protection).

Table 4.2: Mobile Application Assets

Asset C/I+ Description

1 Assets used during payment These are the card profiles and
processing: associated mobile payment application
level cryptographic keys, IVs, seed
 Card Profiles I values, and other EMV parameters that
participate in the generation of
 Payment System public keys I cryptograms used for confidentiality or
and Issuer public keys authenticity.

 Private and secret payment C/I

keys or payment session keys If the use of the symmetric payment keys
and related parameters (static also verifies cardholder presence (CVM)
and dynamic) then “+” is added to this categorisation.

 Risk management data I+ Risk management data (e.g. Application

Transaction Counter (ATC), device risk
parameters).

2 Assets and sensitive information C/I+ These include private and secret
cryptographic keys and related
 cryptographic keys and related
parameters used for remote management
parameters (static and
and personalisation of the Mobile
dynamic)
Application.
 used for communications
Public keys do not require confidentiality,
processing and to secure
nor do the parameters used for validation
transport to the Mobile
of pinned certificates.
Application

3 Cardholder data or card image C The cardholder may be required to enter

data PII or cardholder data (for example, PAN
and expiry date) into the Consumer
Device (manually or as a captured image)
– for example, during registration.

4 Consumer authentication I+ This is the result of Device Unlock or

CDCVM processing or consumer
intent/consent passed to the Mobile
Application.

5 Source code / binary I This is the Mobile Application code. The

vendor might additionally claim
confidentially.

5 Mobile Application Security Requirements

This chapter provides the minimum security requirements for a Mobile Application.

5.1 MA-SEC-REQ-1: Security Guidance and Usage

Instructions
Control Objective: Document the protection of the Mobile Application security assets and
their dependencies. Note that the “user” here is not the cardholder; it is the system integrator,
Issuer, Payment System, and/or security evaluator.

No. Requirement

1.1 The Mobile Application must have a user (security) guidance document defining how to use
the Mobile Application in a secure manner.
1.2 The user guidance document must state how the Mobile Application can be securely installed
and updated including default settings.
1.3 The user guidance document must list all security assets. For each security asset it must state
the required protection (C/I/I+).
1.4 The user guidance document must indicate which devices – including platform versions (e.g.
OS, TEE, and TPM) – are supported.

5.2 MA-SEC-REQ-2: Asset Protection

Control Objective: Protect the Mobile Application security assets to meet the minimum
required security objective.

No. Requirement

2.1 All security assets in the Mobile Application must be protected (C/I/I+) commensurate with
their status (ephemeral, short-lived, or long-lived) as indicated in the security objectives for
the Mobile Application.

2.2 Confidential data must be securely removed from the device when no longer needed.
2.3 Sensitive data (both while stored and while in transit) must be protected as necessary for its
stated security requirements.
Each Mobile Application component that reads an asset from another Mobile Application
component must maintain the confidentiality (“C”) requirement specified for that asset.
The communications of the asset between the components must also maintain the
confidentiality (“C”) requirements specified for that asset.
2.4 Sensitive data used during processing (e.g. to compute a cryptogram) must be protected as
necessary for its stated security requirements.
Each Mobile Application component that will use an asset within its own processing or
provide it to another Mobile Application component must ensure that its I/I+ requirements
are maintained as specified for that asset.
The communications of the asset between the components must also maintain the I/I+
requirements specified for that asset.
2.5 The security mechanisms used by the Mobile Application to protect the assets must be
evaluated. If the mechanisms rely on the security of an underlying component (such as a TEE,
white-box crypto, and obfuscation) then the security of the underlying component must also
be evaluated and, where appropriate, certified.
2.6 If the assurance of the Mobile Application relies on security functionality provided by a
component, that component must provide demonstrable assurance for that functionality
based on how the component is integrated into the Consumer Device and not on an
evaluation of the isolated component.

5.3 MA-SEC-REQ-3: Mobile Application Protection

Control Objective: Protect the Mobile Application against unauthorized modification and
usage. Ensure that the Mobile Application runs the latest approved version and can be
securely updated.

No. Requirement

3.1 The Mobile Application must be securely installed.

3.2 The Mobile Application must be securely updated.
3.3 There must be a secure binding of the Mobile Application with the Consumer Device once
the Mobile Application is installed.
3.4 The Mobile Application must be protected against unauthorized modification and update.
3.5 The Mobile Application must have the ability to check and if required force a secure update
to its latest version.
3.6 The Mobile Application must not allow a user initiated roll-back to an earlier version that can
transact successfully, unless explicitly allowed.
3.7 The integrity of the Mobile Application must be verified at and/or during runtime.
3.8 The Mobile Application must not run on non-supported platforms and/or devices.
3.9 The Mobile Application must not run in audit, debug, or test mode.
3.10 The Mobile Application must not log sensitive data in plain (unencrypted) format.
3.11 If the Mobile Application and/or server-side detect any compromise, the Mobile Application
should have the capability to be deactivated and to securely remove all sensitive data.

5.4 MA-SEC-REQ-4: Authentication–Identification and

Verification
Control Objective: Provide strong access control measures.

No. Requirement

4.1 The Mobile Application must have a defined list of entities and interfaces it is allowed to
communicate with.
4.2 The Mobile Application must be able to securely authenticate each of the allowed entities
listed in MA_SEC-REQ-4.1.
4.3 The Mobile Application must be able to establish that the Credential Manager is authentic so
that it may trust the credentials given to it.
4.4 The Credential Manager must be able to authenticate the Mobile Application in order to be
certain that credentials are not given to an untrusted application.
4.5 A Mobile Application, or any of its components, must not disclose sensitive information when
queried by an unauthorized entity.

5.5 MA-SEC-REQ-5: Consumer Authentication

Control Objective: The Mobile Application must provide suitable consumer authentication
and verification for the purpose of the allowed verification methods.

No. Requirement

5.1 The Mobile Application must provide or integrate with approved functionality to authenticate
the consumer (e.g. numeric passcode, pattern used for device unlock, fingerprint), whenever
applicable to a transaction.
5.2 The integration of CVM functionality with the Mobile Application must ensure integrity for the
result of CVM processing and ensure authenticity of cardholder intent / consent status that is
presented to the Mobile Application.

5.6 MA-SEC-REQ-6: Reporting

Control Objective: The Mobile Application must provide reliable and secure reporting
information to the control server (e.g. back-end) without revealing sensitive information to
unauthorized entities.

No. Requirement

6.1 Account information and authentication data used for security reporting must be protected
from unauthorized disclosure and modification.
6.2 Any reporting communications, but in particular error codes, must not reveal information
that would aid an attacker in obtaining sensitive information.
6.3 If any compromises are detected, the Mobile Application must have the capability to report
to a server-side and the user / owner of the mobile device.

5.7 MA-SEC-REQ-7: Cryptographic Keys, Methods, and

Random Numbers
Control Objective: Use secure and industry accepted cryptographic protocols and methods.

No. Requirement

7.1 Industry standardized cryptographic algorithms (e.g. TDES, AES, RSA, ECC), methods, and
protocols must be used and securely configured.
7.2 Cryptographic keys must be protected (C/I/I+) as indicated in the security objectives for the
Mobile Application.
7.3 Cryptographic keys must be used only for their intended purpose.
7.4 The cryptographic key hierarchy must be defined, including the following for every key:
 cryptographic key name
 key size
 key usage (e.g. encryption, decryption, MAC, key encryption)
 key uniqueness (i.e. unique per Mobile Application or is being shared with other Mobile
Applications)
 key lifetime (e.g. ephemeral, short-lived, long-lived)
 key generation including location
 key protection
 key storage location
7.5 Random numbers (e.g. unpredictable numbers) must have sufficient entropy for the required
security level within the Mobile Application.
7.6 Data and cryptographic keys requiring encryption must be protected with cryptographic
keys bound to the Mobile Application and Consumer Device (i.e. must be device and
application bound).

5.8 MA-SEC-REQ-8: Secure Mobile Application Design

and Development
Control Objective: Develop Mobile Application at a secure site with configuration
management, version control, and secure coding practices.

No. Requirement

8.1 The Mobile Application must be developed with proper configuration and source code
control.
8.2 The Mobile Application development site must be properly protected from a physical, logical,
and organizational security perspective.
8.3 The Mobile Application must be developed with secure design and security coding practices.

D EMV Contactless Communication Protocol v2.1 March2011 20110406010859160
No ratings yet
D EMV Contactless Communication Protocol v2.1 March2011 20110406010859160
247 pages
EMVCo White Paper On Payment Account Reference v2.1.1 Final
No ratings yet
EMVCo White Paper On Payment Account Reference v2.1.1 Final
25 pages
7 EMVCo Level3 Framework Implementation Guidelines V 1 1 20190411
No ratings yet
7 EMVCo Level3 Framework Implementation Guidelines V 1 1 20190411
103 pages
CompTIA SY0 601
67% (3)
CompTIA SY0 601
79 pages
C 2 Kernel 2 V2.11 Final June 2023
No ratings yet
C 2 Kernel 2 V2.11 Final June 2023
458 pages
Contactless Specifications For Payment Systems: Book A
No ratings yet
Contactless Specifications For Payment Systems: Book A
57 pages
Areeba Online Payment Solutions
No ratings yet
Areeba Online Payment Solutions
14 pages
OCC Michael Hsu Comments - RA Highlights
No ratings yet
OCC Michael Hsu Comments - RA Highlights
14 pages
EMV Contactless PDF
No ratings yet
EMV Contactless PDF
111 pages
EMV Contactless Kernel PR FINAL
No ratings yet
EMV Contactless Kernel PR FINAL
2 pages
Nexo FAST: PURE Kernel
No ratings yet
Nexo FAST: PURE Kernel
35 pages
0ikL3QgQKCejxyundxQ8 CoursematerialA4-1569849373450
No ratings yet
0ikL3QgQKCejxyundxQ8 CoursematerialA4-1569849373450
82 pages
C-5 Kernel-5 v2.11
No ratings yet
C-5 Kernel-5 v2.11
126 pages
EMV Master Class: Join The Master Class! Stay Ahead of The Competition!
No ratings yet
EMV Master Class: Join The Master Class! Stay Ahead of The Competition!
2 pages
PayPass v3 TTAL2-Testing Env Nov2013
No ratings yet
PayPass v3 TTAL2-Testing Env Nov2013
63 pages
3-5-Emv L2
No ratings yet
3-5-Emv L2
6 pages
EMV v4.3 Book 3 Application Specification 20120607062110791
No ratings yet
EMV v4.3 Book 3 Application Specification 20120607062110791
230 pages
EMV v4.2 Book 1 ICC To Terminal Interface CR05
100% (1)
EMV v4.2 Book 1 ICC To Terminal Interface CR05
197 pages
book2-EMV v4.2 Book 2 Security and Key Management CR05 - 20090122094212
100% (1)
book2-EMV v4.2 Book 2 Security and Key Management CR05 - 20090122094212
176 pages
EMV SWG NH20r2a Issuer Security Guidelines For 1st Gen August2018
No ratings yet
EMV SWG NH20r2a Issuer Security Guidelines For 1st Gen August2018
78 pages
Postilion Developer External
No ratings yet
Postilion Developer External
2 pages
EMV Issuer Security Guidelines: Emvco, LLC
No ratings yet
EMV Issuer Security Guidelines: Emvco, LLC
33 pages
Emv Especifications
100% (1)
Emv Especifications
44 pages
C-1 Kernel 1 v2.6 20160512101416661
No ratings yet
C-1 Kernel 1 v2.6 20160512101416661
34 pages
C 8 Kernel 8 V1.0
No ratings yet
C 8 Kernel 8 V1.0
316 pages
csfb400 Icsf Apg hcr77d1 PDF
No ratings yet
csfb400 Icsf Apg hcr77d1 PDF
1,720 pages
VISA CEMEA Personalisation Templates Version 1.5, August 2003
No ratings yet
VISA CEMEA Personalisation Templates Version 1.5, August 2003
107 pages
Users Manual 3704697
No ratings yet
Users Manual 3704697
442 pages
Tsys Mpa With Logo 1
No ratings yet
Tsys Mpa With Logo 1
6 pages
B1 Ipayment: © 2019 Boyum Solutions A/S Boyum Solutions A/S
100% (1)
B1 Ipayment: © 2019 Boyum Solutions A/S Boyum Solutions A/S
134 pages
Personalization Data Specifications: For Debit and Credit On Chip
100% (1)
Personalization Data Specifications: For Debit and Credit On Chip
71 pages
M/Chip Functional Architecture For Debit and Credit: Applies To: Summary
No ratings yet
M/Chip Functional Architecture For Debit and Credit: Applies To: Summary
12 pages
Increasing Security and Reducing Fraud With And: EMV Chip PCI Standards
No ratings yet
Increasing Security and Reducing Fraud With And: EMV Chip PCI Standards
1 page
Emv Concepts Terminology
No ratings yet
Emv Concepts Terminology
11 pages
EMV (Chip & PIN) Protocol: Märt Bakhoff Supervised: Arnis Paršovs
No ratings yet
EMV (Chip & PIN) Protocol: Märt Bakhoff Supervised: Arnis Paršovs
41 pages
Data Protection V Data Security V Data Privacy 1629981100
No ratings yet
Data Protection V Data Security V Data Privacy 1629981100
4 pages
EMV Overview Unbranded
No ratings yet
EMV Overview Unbranded
26 pages
EMV - Understanding
No ratings yet
EMV - Understanding
3 pages
Student Coin Whitepaper
No ratings yet
Student Coin Whitepaper
28 pages
New Vulnerabilities in Public Transport Schemes For Apple Pay GPay and Samsung Pay
No ratings yet
New Vulnerabilities in Public Transport Schemes For Apple Pay GPay and Samsung Pay
34 pages
Sample ICSF EMV
No ratings yet
Sample ICSF EMV
21 pages
EMV 101 & Myths of EMV: Itai Sela Vice President B2 Payment Solutions
No ratings yet
EMV 101 & Myths of EMV: Itai Sela Vice President B2 Payment Solutions
16 pages
PCI TSP Requirements v1
No ratings yet
PCI TSP Requirements v1
92 pages
EMVCo PPSE and Application MGMT For SE v1.0-1
No ratings yet
EMVCo PPSE and Application MGMT For SE v1.0-1
67 pages
EMV Tech Report
No ratings yet
EMV Tech Report
37 pages
Sunmi KLD KeyManagement V2.101
No ratings yet
Sunmi KLD KeyManagement V2.101
7 pages
JavaCard in Smart World.v4
No ratings yet
JavaCard in Smart World.v4
38 pages
EMVCo Payment Tokenisation A Guide To Use Cases v1.0
No ratings yet
EMVCo Payment Tokenisation A Guide To Use Cases v1.0
59 pages
MC Onbehalf Key MGMT Interface Spec
100% (1)
MC Onbehalf Key MGMT Interface Spec
100 pages
Chip Card Acceptance Device Ref Guide 6 (1) .0
No ratings yet
Chip Card Acceptance Device Ref Guide 6 (1) .0
143 pages
What Is Tokenisation
No ratings yet
What Is Tokenisation
5 pages
Terminal Information To Enhance Contactless Application Selection
No ratings yet
Terminal Information To Enhance Contactless Application Selection
10 pages
Ey Tokenization of Assets Broschure Final
No ratings yet
Ey Tokenization of Assets Broschure Final
34 pages
EMV-L2 ST100 Draft
No ratings yet
EMV-L2 ST100 Draft
72 pages
Visa Chip Simplifying Implementation
No ratings yet
Visa Chip Simplifying Implementation
2 pages
PayGate PayWeb3 v1.03
No ratings yet
PayGate PayWeb3 v1.03
41 pages
L02 - Privacy and Data Privacy
No ratings yet
L02 - Privacy and Data Privacy
64 pages
Cyber Forensic Interview Questions With Answers
No ratings yet
Cyber Forensic Interview Questions With Answers
24 pages
EMV A Toz PDF
No ratings yet
EMV A Toz PDF
7 pages
EMV Frequently Asked Questions
No ratings yet
EMV Frequently Asked Questions
2 pages
EMV-SWG-NB53r4b Terminal Unpredictable Number Generation
No ratings yet
EMV-SWG-NB53r4b Terminal Unpredictable Number Generation
2 pages
17.1.115 Iso Iec 7816 9 1
No ratings yet
17.1.115 Iso Iec 7816 9 1
26 pages
Tokenization 1697136521
No ratings yet
Tokenization 1697136521
5 pages
Lessons Learned From A Salesforce - Com Implementation in Asset Management
No ratings yet
Lessons Learned From A Salesforce - Com Implementation in Asset Management
7 pages
Barnes EMV Training and Consultancy
No ratings yet
Barnes EMV Training and Consultancy
2 pages
EMVCo Kernel 8 Guidance-V1.0
No ratings yet
EMVCo Kernel 8 Guidance-V1.0
49 pages
ATG-CYBS Payment Solution
No ratings yet
ATG-CYBS Payment Solution
2 pages
Oracle Ireceivables Demo
No ratings yet
Oracle Ireceivables Demo
13 pages
Collis EMV Personal Is at Ion Validation Tool
No ratings yet
Collis EMV Personal Is at Ion Validation Tool
4 pages
Porsche Consulting
No ratings yet
Porsche Consulting
27 pages
Hedera - Ebook - Exploring The Emergin Token Economy
No ratings yet
Hedera - Ebook - Exploring The Emergin Token Economy
17 pages
Security
No ratings yet
Security
23 pages
A Architecture and General Rqmts v2 7 Final
No ratings yet
A Architecture and General Rqmts v2 7 Final
116 pages
Inteligência Artificial: Banco Central Do Brasil's Innovation Agenda
No ratings yet
Inteligência Artificial: Banco Central Do Brasil's Innovation Agenda
19 pages
Cybersecurity Strategies For Safeguarding Customer's in United States Financial Sectors
No ratings yet
Cybersecurity Strategies For Safeguarding Customer's in United States Financial Sectors
22 pages
EMVCo Kernel 8 Guidance-V1.0.1
No ratings yet
EMVCo Kernel 8 Guidance-V1.0.1
50 pages
Real Estate Tokenization Guide (2023) - PropertyClub
No ratings yet
Real Estate Tokenization Guide (2023) - PropertyClub
6 pages
TOKENF
No ratings yet
TOKENF
13 pages
Use Case Savitri
No ratings yet
Use Case Savitri
16 pages
Fime Academy Emv Contactless Specifications
No ratings yet
Fime Academy Emv Contactless Specifications
2 pages
TapToMobile Guidelines v1.0
No ratings yet
TapToMobile Guidelines v1.0
26 pages
Schmeiss Et Al. (2019) CMR - Designing Governance Mechanisms in Platform Ecosystems Addressing The Paradox of Openness Through Blockchain Technology
No ratings yet
Schmeiss Et Al. (2019) CMR - Designing Governance Mechanisms in Platform Ecosystems Addressing The Paradox of Openness Through Blockchain Technology
23 pages
E-Commerce and ERP Notes
No ratings yet
E-Commerce and ERP Notes
29 pages
EMVCo 3DS White-Paper v2.0 26-Mar-2025
No ratings yet
EMVCo 3DS White-Paper v2.0 26-Mar-2025
149 pages
E Commerce
No ratings yet
E Commerce
2 pages
Book E v1.0 June 2023
No ratings yet
Book E v1.0 June 2023
60 pages
Credit Card Skimming Review
No ratings yet
Credit Card Skimming Review
4 pages
EMV Issuer and Application Security Guidelines v3.0 1
No ratings yet
EMV Issuer and Application Security Guidelines v3.0 1
82 pages
EMV Third Edition
From Everand
EMV Third Edition
Gerardus Blokdyk
No ratings yet