Blog article
See all stories »

Tokenization is not enough: The role of on-device software for secure mobile payments

HCE cloud-based mobile payments have opened a new chapter in the industry's thinking around security of card data on-device and the risk management associated with it. 

The lack of secure element hardware storage on-device 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.

But is tokenization alone enough?

Traditionally, tokenization means one-time use data. If one-time use card data is provisioned to the phone then the security risk of the data in open is restricted to that transaction only. However, as per EMVCo specification on tokenization, the definition of token is alternate PAN, which is not the same as one-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. The main security it provides is that a hacker cannot use the stolen card data online or other channels.

Furthermore, having cryptographic keys and functions in the phone database leaves critical payment data vulnerable to attacks.

Two aspects become critical for consideration in thinking about cloud payment deployment based on HCE and tokenization. They are dynamic issuance and on-device security and management.

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.
 
On-device management is the ability to dynamically monitor various threshold parameters that govern the policy of making a transaction and performing account replenishment. For example, a bank may decide to replenish account parameters if the device is used to transact at a location that is 250 miles away from where the account data was initially issued. In this case, the digital issuance system is resetting the threshold parameters and replenishing the limited-use key. This is an example of how location data can be used to dynamically manage account parameters for cloud payment deployments.

On-device security is the implementation of software-based secure element to protect card data and cryptographic keys and functions. In addition, application integrity must be maintained to resist modification of the application by hackers. Various techniques must be employed to protect application integrity including white-box cryptography.

At the end of the day, secure mobile payments, especially leveraging cloud-based HCE, will only be possible by leveraging all the available tools for security. That will include network-based tokenization and dynamic issuance and management as well as robust on-device software and device fingerprinting. The sooner we understand that and start having a holistic approach to mobile payments security the sooner mobile payments will migrate from early adopters to the majority of the population.

8547

Comments: (1)

A Finextra member
A Finextra member 13 March, 2015, 16:54Be the first to give this comment the thumbs up 0 likes

Marcelo De Lima, thanks for an interesting post that raises an important question. I take your point that Tokenisation may be necessary, but is it sufficient?

I would add that in all this there is a danger I foresee in terms of the two key stakeholders, the consumers and merchants still feeling in control.

Today as a consumer I've developed simple strategies to cope with dangers I know I'm exposed to. Assuming all that you've described, plus a host of other areas that we've yet to encounter get put in place, we'd need to ensure that both consumers and merchants can still employ simple ways by which they feel protected, especially when attacks (of the kind we still can't foresee) take place. Unfortunately it's likely the most vulnerable will find it more difficult to figure all this out, while fraudsters will stay right on top of the end-to-end changes as they're implemented.

Now hiring