Upload
trinhkhanh
View
256
Download
1
Embed Size (px)
Citation preview
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
[email protected]+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.