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

Transcription

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

2 Introduction Cloud-based payments powered by tokenization represent a paradigm shift in the way the payments industry enables secure payments and manages risk 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. 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. 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. 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. Tokenization specifications being implemented in commercial services today provision tokens to phones with extended active life spans - opening the window for potential fraud. 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. 2

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 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. 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? Tokens issued to phone memory must be protected by robust on-device software and dynamic management of card data by network based software. 3

4 Cloud-based Payment Solution Overview 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. On-Device Management 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. Dynamic Management Digital Issuance Bank digital wallet or mbanking app App Management Account data management Key management Banking App On-Device SW Authentication Secure communication Device & app management Event management Active account management Card lifecycle management Token Service Provider Issuance On-device software that manages security of bank cards, generates transaction data, including cryptogram Manages application security, device and app authentication, registration, and device/app lifecycle Token vault Token generation Token validation Figure 1 shows a system view of the overall cloud-based payment solution. 4

5 Digital Issuance There 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 Tokenization Second 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. 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. 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. 5

6 Application Management System While 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. 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 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. When account parameters are provisioned to the device, the On-device Software: Secure Storage and More The 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 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. should also be extensible to new solutions such as HCE or other hybrid approaches. 6

7 Device Level Security 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 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. device or a different device with the stolen credentials. 7

8 Dynamic Management of Account Data is Key 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). 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 asking 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. 8

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 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. 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. 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 The app management platform has an important role in payments use cases. 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. 9

10 Digital Issuance and Dynamic Management Managing card profiles The 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. Managing account lifecycle One 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. 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 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. changes to all onboarded devices. 10

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. 11

12 User Experience and Credential Distribution 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. 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. 12

13 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. 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. On-device security 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-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. 13

14 Risk management Sequent 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 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. Allow banks to define policies that determine replenishment rules Annotate transaction data with device details to help authorization system verify device fingerprint 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. Dynamic issuance and management Sequent 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 Modular configuration Sequent 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. 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. 14

15 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. Sequent Software Inc. contactus@sequent.com