Beyond Tokenization Ensuring secure mobile payments using dynamic issuance with on-device security and management

W H I T E PA P E R

2

Introduction

Cloud-based payments powered by tokenization

represent a paradigm shift in the way the payments

industry enables secure payments and manages risk

across multiple mobile platforms and access points.

Top industry players see major opportunities presented

by new flexible implementations of mobile payments.

The most notable of these is Host Card Emulation (HCE),

which not reliant on scarce and controlled resources of

security hardware on smartphones. However, the new

avenues open for cloud and software-based mobile

payments are not without risk.

The lack of secure element hardware storage in the handset

creates the need for strong software based solutions to

mitigate the risk of storing sensitive card data on phone

memory. Tokenization has emerged as one of the most

important solutions for enabling secure cloud-based

payments. By replacing something of high value, the secure

Personal Account Number (PAN), with something of lower

value, the limited-time use card data or “token,” tokenization

protects the original PAN number from misuse.

The issue is that tokenization alone is not enough to enable

secure mobile payments. Per EMVCo’s specification on

tokenization, a token is defined as an alternate PAN, which

is not the same as strict limited-time use data. Consequently,

tokenization specifications being implemented in commercial

services today provision tokens to phones with extended

active life spans - opening the window for potential fraud.

Hence the role of tokenization in cloud-based payment

security for proximity payment has lesser importance than

it is often given.

“ Tokenization specifications being implemented in commercial services today provision tokens to phones with extended active life spans - opening the window for potential fraud. ”

Bottom line: Tokens issued to phone memory must be

protected by robust on-device software and dynamic

management of card data by network-based software.

This white paper presents important security considerations

for card issuers intending to provision cloud-based payment

credentials to mobile devices. Sequent sees the provisioning

of cloud-based payment credentials to mobile devices in

three distinct parts: tokenization, dynamic issuance, and

on-device security and management.

3

Service providers are generally familiar with the aspects

of card issuance and personalization. Card issuance and

personalization for SE-based and HCE-based issuance

have much in common. The key difference being that

the former is static while the latter is dynamic in nature.

Dynamic issuance requires dynamic management of the

card and account data in addition to tokenization. The

dynamic management of mobile issuance coupled with

on-device security and management is what ensures the

security of tokens sent to mobile devices.

Here are some of the issues that arise with HCE cloud-based mobile payments:

• How is the user device authenticated?

• How is data secured on the device?

• How is the integrity of the application ensured?

• How is the card data secured in transit to the

mobile app?

• How is the user experience managed when

multiple applications are registered as payment

in Android apps?

• Who manages the seamless payment experience

for the consumer who is unaware where card data

is stored or if data network is available or not?

• Who provides active account management

policies that govern the usage of card data

on device?

• Who provides active monitoring of the card data

(e.g. tracking geolocation) for purposes of active

account management?

Making sure that mobile cards are safe to use is a

primary concern of bank risk management departments.

They need to continually evaluate the security

“management” aspect of the card data. How secure

is the card data? When was it last replenished? What

has changed since then? As stated earlier, it is a

misperception that tokenization alone provides the

necessary security and risk management that banks

need. Who ensures that the card data is not spoofed

from one device and replayed on another device? In

truth, a token is not enough to replace the security of

a secure element.

What happens after the service is active on the device

receives less attention although it is of equal or greater

importance. After all, consumers care little about how

the card is provisioned to their mobile wallet. But they

do care about how convenient and safe it is to use a

card. This paper describes in detail the distribution and

management challenges that need to be addressed for

successful rollout of cloud-based mobile payments.

“ Tokens issued to phone memory must be protected by robust on-device software and dynamic management of card data by network based software. ”

4

To understand where the issues lay, let us take a look at how cloud-based payments are currently deployed.

The high-level components of a cloud-based payment solution are tokenization (alternate PAN), digital issuance, app management, and an on-device HCE client. The tokenization system provides the token vault, token generation, and token validation services. The digital issuance system manages the cloud-based card account, associated keys, and provides business logic for card data provisioning and replenishment. The app management system is responsible for managing millions of mobile endpoints and acts as a conduit for secure card data to the device. The HCE client software protects the card data on-device.

For a complete security solution, the following functions are critical:

• Application integrity. The application must be protected so it cannot be manipulated by a hacker.

• Authentication of device, user, and service.

• Securing card data and cryptographic functions. Card data, the keys and the cryptographic functions must be protected so they cannot be stolen and replayed from another device.

• Securing communication to the device. Although this can be implemented between the digital issuance system and the on-device middleware, it is not the job of digital issuance to manage the device endpoints and the security requirements associated with them.

• Capture on-device telemetry data that are essential for risk management for cloud-payment. The system would notify the digital issuance system when there is change in the device, geolocation, and mobile phone number.

Cloud-based Payment Solution Overview

Figure 1 shows a system view of the overall cloud-based payment solution.

Authentication

Securecommunication

Device & appmanagement

Eventmanagement

Banking App

On-Device SW

Bank digital walletor mBanking app

App Management

On-Device Management Dynamic ManagementDigital Issuance

Key management

Account datamanagement

Active accountmanagement

Card lifecyclemanagement

Token generation

Token validation

Token vault

Token Service Provider

Issuance

Manages applicationsecurity, device and app

authentication, registration,and device/app lifecycle

On-device software that manages security of

bank cards, generates transaction data,

including cryptogram

5

TokenizationSecond aspect is the replacement of the PAN with a token; a

process known as tokenization. The digital issuance system

requests the token from the token service provider (TSP)

and sends it to the phone during issuance. As part of the

issuance process, the TSP’s function is relatively small. It

needs to validate the requestor (digital issuance system)

and perform relevant ID&V (identification and validation)

checks. The TSP plays a bigger role in transaction processing

where it must validate the token and map it back to the

PAN for every transaction.

Tokenization has become the primary topic in HCE security

discussions but it is actually only one part of the security

in HCE payments. Tokenization as implemented is not

about restricting the lifetime or usage count of the token.

Tokenization obscures the card data elements that are

susceptible to compromise (PAN and its expiry date) from

the weakest points in the payment processing ecosystem

by using alternate data elements (alternate PAN and its

expiry date) and restricting usage to specific domains

such as eCommerce payment or NFC payment. The great

strength of HCE cloud payments is linked to dynamic data,

while the nature of security provided by tokenization is

static. In a world of connected and always on devices,

static security is not enough. Security needs to be dynamic

and continuously validated.

Digital IssuanceThere are two aspects to issuance of cloud-based credentials.

The first is the card data (track 1 and track 2 data) and

the associated keys. Digital issuance is responsible for

communicating with bank systems to receive card data

and keys, and preparing data based on the required format.

It is also responsible for managing the lifecycle of the card

data on device, which includes add, delete, suspend, and

resume actions. Just like SE-based issuance, issuance in

a cloud-based payment system must interface with bank

systems, prepare card data for the device, and manage

keys that need to be sent to the phone. It is important to

note that there is no significant difference in data preparation

between card data prepared for SE-based issuance versus

HCE-based issuance. The additional role that HCE-based

digital issuance systems play is active account management.

6

Application Management SystemWhile the digital issuance system is responsible for prepping card data and requesting tokens from the TSP, it is the responsibility of the application management system to handle distribution to devices. The app management system manages the last mile; ensuring device and user authentication, securing communications with the devices, and finally sending the sensitive card data.

In terms of secure distribution of sensitive data, there are two sources of trust – the user and the backend. The security architecture must assume that this channel is fundamentally unsecured. The trust established for the on-device software is temporarily in nature. Since a mobile device is fundamentally unsecure, this trust has to be rotated regularly. It is the responsibility of the app management platform to manage this trust along with the associated business rules for distribution. This can become increasingly complex if multiple payment apps coexist on the same device.

On-device Software: Secure Storage and MoreThe future of mobile payments demands that on-device

software take on even more roles. Legacy risk management

systems are not designed to handle dynamic, contextual

data from connected devices. The right on-device software

should be adaptable to a variety of security solutions. It

should also be extensible to new solutions such as HCE

or other hybrid approaches.

On-device software must:

• Accommodate all secure storage methods: SE, TEE, and HCE

• Protect card data, keys and cryptographic functions

• Resist modification by hackers so that no harmful code can be injected in the application

• Be the single point of trust between cards, mobile apps and backend systems

• Extend existing authentication and authorization to potentially multiple HCE apps

• Provide an abstraction layer to manage new capabilities and future security layers without interfering with the user experience

• Support all payment networks

When account parameters are provisioned to the device, the

limited-use key allows a number of payment transactions

according to the device threshold parameters such as

transaction count and time-to-live value. If the data is not

secured properly, it is possible to use the data to perform

transactions for the remaining transaction count on an

unauthorized device. The on-device software should prevent

this type of fraud by first verifying the app, and then optionally

the user and device, before initiating the payment transaction.

7

Here is what is needed to protect card data

on-device:

• Obfuscation to defend against static code analysis

and reverse engineering.

• Anti-debug and anti-root guards to detect if the

application is running in debug mode or is rooted

and that disable the application when a threat

is detected.

• Checksum guards to detect static application

integrity compromise in the form of unauthorized

code change.

• Encryption of high-risk code sections and use

of dummy data to guard against intellectual

property theft.

• Use of multiple binary images of the same application

with different randomized obfuscation parameters.

• Enforcing and concealing safeguards at runtime.

• Securing sensitive data without storing the encryption

key or the user PIN.

• Securing encryption logic, the code to authenticate

the user, code to generate cryptogram, code to

activate card for payment and the code to transact

with the EMV reader using guard level encryption

key(s) hidden in the application code.

Although Host Card Emulation has made provisioning

credentials easier in a more open mobile payments ecosystem,

it has left the credentials on the device prone to various kinds

of attacks. The security provided by device operating systems

is very thin protection.

Possible threats include:

• Unauthorized access to card data and/or financial

services such as payment offered by the mobile

application.

• Theft of code and data from the application for

fraudulent use.

• Modifying application code to cause the application

to fail or behave in an unwanted way causing harm

to the brand.

The code and user credential(s) used to access the application

and use services such as payment are particularly prone to

hacking in a payment application. The attacker can gainentry

by using techniques such as replay attack after stealing user

credentials or using a wrong password but by manipulating

registers at runtime.

If the keys and/or logic involved in securing the card data are

not robust, the attacker can steal the card data and use it in

different unauthorized transaction scenarios using a stolen

device or a different device with the stolen credentials.

Device Level Security

8

The complementary objective is active and dynamic

account management to restrict the potential for fraud

within predefined limits, such as maximum usage limit or

lifetime of the dynamic data. Payment networks use this

concept in their specifications for cloud-based payment

solutions in order to mitigate the security risk posed by the

absence of a secure element. Active account management

can be extended to hybrid card storage schemes as well

where the dynamic part of card data can be stored in the

secure element and the rest in the phone memory. Due to

the dynamic nature of mobile devices and cloud-based data,

continuous management of data becomes critical.

Continuous management of card data includes:

• Evaluate risk of every transaction. This requires

additional data from the mobile device transmitted

as part of the transaction data (phone number,

device-ID).

• Trigger replenishment of account parameters.

This can be replenishment of device thresholds

and the one-time use or limited use keys (LUK).

Dynamic Management of Account Data is Key

• Capture on-device telemetry data. These data are

continuously captured as part of the mobile app

(such as location data and IP address) and are

evaluated against defined risk policies.

• One-time-use passcode. If the system detects a

change in pattern then the system may ask user

to do an out-of-band authentication such as ask-

ing user to enter one-time-use passcode.

Digital issuance is responsible for continuous management of

the account parameters and the policies that govern the usage

of the card data on the device. Application administrators are

responsible for defining various parameters and rules such as:

• Number of times the limited use key (LUK) can be

used for transactions

• Time-to-live value of the key on device

• Limits on transaction amount

• Domestic versus international usage limitation

• Optional telemetry rules such as limiting usage

of the card data within 100 mile radius.

9

The digital issuance platform and processing host are

responsible for sensing when a risk parameter reaches a

threshold limit and then initiating replenishment. The digital

issuance platform is responsible for notifying the authorization

host so that the host has all the data needed to authorize

a transaction. Since the bank authorization system sees

the authorization transaction data, it plays a role in the risk

assessment. If it detects anomaly or sees high risk then it

would trigger replenishment of limited-use-keys on the

device by notifying the digital issuance platform. Bank

administrators should be able to configure policies that

govern the behavior of the credential and the transaction.

From a policy administration console, administrators should

be able to manage the device, risk, and account parameters.

The app management platform has an important role in

dynamic management including authentication of the device,

app, and user and managing communication between

on-device software and the digital issuance platform as

needed. The on-device software plays an active role in

keeping track of thresholds related to account parameters

and triggering replenishment requests when needed. In

addition, it adds value by capturing telemetry data that

can be used as threshold parameters.

Beyond minimum card network requirements, the on-device

software can apply user verification during initial registration

of the app according to existing ID&V processes implemented

by issuers. The on-device software can also require user PIN

during registration process to verify user access to secure

services such as payment transactions within a certain

timeout period. The user PIN with additional data elements

can be used to generate device and user-specific encryption

keys to protect the secure data. In addition, the on-device

software may also need to support online PIN verification

and/or on-demand PIN verification in case of out-of-pattern

activity, if required by the issuer.

The on-device software must be authenticated to the

backend systems such as app management or issuer

mBanking systems. As it is likely that there may be multiple

payment-enabled apps on the same device, the on-device

software must be the security trust endpoint on the device

for all trusted apps. Therefore, on-device software must

perform authentication of all trusted apps on behalf of the

backend app management system.

Identifying the device is also important to both security

and service management across user devices. Multiple

parameters including MSISDN, ICCID, IMEI along with user

PIN, and temporary passcode can be used to verify this

device. Recurring verification of user, app, and device by

the on-device software is an essential step in most mobile

payments use cases.

10

Managing account lifecycleOne of the important responsibilities of digital issuance

outside of tokenization is to manage the lifecycle of cards

issued to mobile phones or eCommerce merchants.

Issuers want to prevent fraudulent card use after a device

theft and revoke a card issued to a customer who might

have violated an agreement that they had entered into

with the issuer. This applies to credentials issued to HCE,

secure element, and eCommerce merchant systems alike.

Additionally, issuers would like to delegate handling of

complex lifecycle operations such as card renewal,

device change and mobile subscription termination that

involve invoking of right set of remote card management

operations, which otherwise would require triggering less

efficient sequence of individual lifecycle operations.

In case of deployments where card issuers act as aggregators

for other issuers, efficiently managing account lifecycle

through one portal is very important. A portal that allows

administrators representing the issuers to remotely sign

in and manage the lifecycle of the credentials that they

issued is an important feature of digital issuance systems.

Managing card profilesThe necessity of using tokens and the emergence of HCE

have led to very few changes to card data and technical

issues involved in efficient provisioning. The payment industry

will leave existing payment network processes largely intact

as they expand tokenization and cloud-based payments.

With the complex details of data preparation for credential

provisioning unchanged, issuers seek data preparation for

mobile devices that is more efficient than for smart cards.

Digital issuance with real time data preparation leveraging

profiles and over the air provisioning achieves this aim.

According to payment networks, account data profile

management is a stated fundamental capability of a digital

issuance platform. The ability to manage different account

data profiles and combine them with just the individual card

specific data goes a long way in reducing data preparation

effort. Account data profiles also increase the efficiency of

card data packaging for the device with reduced traffic

between the issuer and digital issuance system. Digital

issuance systems must also easily onboard existing as well

as emerging devices. Onboarding devices means preparing

profiles and card data for different secure elements associated

to the device and managing metadata such as card art for

the various card products targeted for both SE and HCE

phones. Banks frequently introduce new card products

or revamp card art for existing products and they expect

digital issuance systems to be flexible to accommodate art

changes to all onboarded devices.

Digital Issuance and Dynamic Management

11

Risk Management

Device profiles or “fingerprints” are data that uniquely

identifies the phone to the cloud payment system. Matching

device fingerprints to authorized users helps the cloud

payments system detect fraudulent use of tokens. The

following data elements are examples of device fingerprint:

Data Integrity checks, device MSISDN, ICCID or IMEI,

User PIN and Site Key. Additional information gathering

takes advantage of the HCE client app on the phone to

collect additional data on the user, such as location, to

be used in risk assessment.

This dynamic risk management begins with limits on the

validity of tokens and includes the limited use keys (LUK)

that derive short-lived cryptograms used in cloud payment

messaging. Replenishment of the LUK is driven by thresholds,

such as time to live and number of transactions, set in the

digital issuance system. Other account data can be reset

at time of replenishment according to the risk assessment,

such as expiry and transaction thresholds. At any time,

issuers can replenish the cloud card data based on risk

assessment to re-establish an acceptable risk level.

12

Although the end user experience is the top consideration,

the experience for issuers and merchants that are being

on-boarded to the system is important as well. The on-device

software combined with the app management system must

provide a simple and convenient method of configuring

business rules for distribution, rights and permissions, ID&V,

and much more. Issuers and merchants want flexibility in

presentation technologies so that they can easily incorporate

NFC, optical codes, BLE, or other new technologies. Ideally,

these features associated with payment functionality can be

incorporated into the existing mobile apps in which issuers

and merchants have already invested heavily.

While security is essential, user experience and convenience

is the ultimate test in gaining adoption from end users. It is

crucial that the experience is optimized all the way from the

app store through the first use experience registering and

enrolling the new payment application. Encouraging recurring

use of the payment app is a top consideration with the short

life span of so many mobile apps. This includes convenient

access to payment cards with user PIN or even a default

card that is always ready with minimal navigation required

by the end user. As adoption of the payment functionality

increases, other value added services will be required for

end users. The ideal payment experience in a physical retail

environment would be seamless and potentially incorporate

payment, offers, and loyalty cards among other services.

The on-device software and app management system must

collaborate in order to manage the lifecycle of the device and

apps while maintaining as seamless of a user experience as

possible. For example, what happens when a user swaps

SIMs, changes phone number, upgrades or loses the device?

All of these scenarios are important considerations for

on-device software.

Coexistence of multiple payment apps on a single device

is inevitable. This can range between MNO apps, issuer or

mBanking apps, merchant apps, and other mobile wallets.

Where federation of card data is supported, the on-device

software must be able to manage card metadata and other

elements for a consistent user experience across multiple apps.

This needs to be accomplished without disintermediation of

the multiple parties involved. By retaining complete control

of branding and user experience, issuers, merchants, and

service providers are enabled to extend existing relationships

with customers while forging new ones with improved user

experiences and useful functionality.

User Experience and Credential Distribution

13

Distribution Sequent Wallet Management Server provides the

functionality needed to distribute card data to millions

of mobile end points. It manages the authenticity of the

devices, secures communication to the devices and

manages the lifecycle of the application on the devices.

Sequent Value

Sequent has addressed the needs of HCE-tokenization

solution holistically with particular focus on security and

risk management. Sequent brings to bear many years of

experience in deploying NFC-based payment systems in

a highly regulated market and various components that are

already commercially deployed at many tier-1 institutions.

On-device securitySequent Open Wallet Platform and Core Card Services

(CCS) secure card data and tokens on-device and

provide the best security in the industry for HCE-based

mobile payments without reliance on hardware-based

secure elements. Commercially deployed in multiple

rollouts, Sequent CCS is on-device middleware that

provides a unique patent-pending mechanism to protect

the card data on-device. CCS uses the user PIN to

generate encryption keys to protect card data without

storing the PIN on-device. The mechanism works in

the scenario where the device is not connected to the

network. In addition, it always authenticates the user and

the calling app before initiating a payment transaction.

Sequent protect the on-device application code

and the card data using:

• Patent pending local data encryption logic

• Tools and techniques to protect application integrity

including white-box cryptography

“ Sequent Open Wallet Platform and Core Card Services (CCS) secure card data and tokens on-device and provide the best security in the industry for HCE mobile payments without reliance on hardware-based secure elements. ”

14

Risk managementSequent provides multiple measures to help banks better manage risk such as:

• Monitor location data to determine if account data require replenishment

• Continuously monitor state and authenticity of device and application

• Allow banks to define policies that determine replenishment rules

• Annotate transaction data with device details to help authorization system verify device fingerprint

Dynamic issuance and managementSequent Digital Issuance Server offers a user-friendly

Account Data Profile Management system that guides the

user through a top-down sequence of configuration steps

to define the account data profiles to fit the different card

product profiles from banks. This module also has the

ability to determine the device profile and prepare the

device specific card data elements for both SE and HCE

based provisioning. The key advantage here is the easy

onboarding of existing and emerging devices.

The data preparation engine of Sequent Digital Issuance

Server provides maximum flexibility to issuers in deciding

which data elements must come from the issuer and

which data elements can be kept as a profile in the Digital

Issuance Server. This provides improved provisioning

efficiency by keeping the traffic light from banks to the

Digital Issuance Server.

Sequent Digital Issuance Server offers a portal where the

issuer customer support representatives can sign in, query

the contents of mobile phones of their customers, and

conveniently trigger lifecycle operations such as deleting

a card or blocking a card or unblocking a blocked card.

Modular configurationSequent products are built in a modular configuration to

enable integration with third-party Token Service Providers

(TSP), Trusted Service Managers (TSMs) and legacy issuance

systems already present in banks and other issuers.

15

contactus@sequent.com+1 650-419-2713

Sequent Software Inc.www.sequent.com

Why Sequent?Sequent is the world’s leading provider of digital issuance and mobile wallet platform-as-a-service

that delivers secure mobile payments and value-added services to banks, mobile operators,

merchants and access control providers. With Sequent, customers can offer wallet services open

to an ecosystem of partners and developers, while meeting the requirements of highly secure and

regulated industries. Sequent products include: Sequent Open Wallet Platform, Digital Issuance

Platform, and Trust Authority. Sequent is endorsed and used by major customers on four continents.