USING YOUR CELLPHONE AS A WALLET…
The phone in your pocket is a camera, a torch, and a hand-held gaming console. But all these applications are simple compared to the challenge of turning your phone into a secure, contactless credit card.
Mobile payments providers face several challenges. Consumers have justified concerns about data security, and need to be persuaded mobile payments are safe. Any payment solution needs to fit into a complicated payments ecosystem with many entrenched players.
And perhaps most challenging of all, consumers have to be persuaded to change their habits. Credit cards have been around for decades. Maybe one day cards will come to seem as inconvenient as checks, but right now, people are used to them.
In this post—the first of two about mobile payments—we look at how they work. In particular, we look at how security issues are addressed when a mobile phone replicates a credit card.
Requirements for a Mobile Payments System
To accept a payment from a mobile phone, the merchant has to be able to identify the account or credit card from which to take the money. The purpose of a credit card number is to match consumers with their accounts or lines of credit.
But data breaches such as the Target hack have shown that all too often, the merchant is the weakest point in the payment system. There are too many merchants, all responsible for their own payments security, and hackers are dedicated to finding weaknesses in their systems. That creates a risk if merchants are given credit card numbers.
To encourage adoption of their new technology, mobile phone payments need to improve on traditional credit card security. They also have to solve two problems: how to safely store credit card information, and how to transmit that information in a way that is useful to merchants and banks, but useless (or nearly useless) to hackers. We can call these the storage problem and the transmission problem.
Solving the Storage Problem
Mobile payments require the storage of at least some payments information on the phone itself. If information is stored somewhere off the phone, then the payments system requires an internet connection, and processing speed is reduced. Also, the transmission of information from cloud to phone creates another potentially weak link.
Mobile payments solve this problem using what is known as a secure element on the phone. There are two main kinds of secure element.
A separate, tamper-proof chip for storing payment information. A secure chip is how Apple Pay works. It’s also why you need an iPhone 6 to use Apple Pay—older phones don’t have the secure element.
Host card emulation. Instead of storing card details physically on the phone, they are stored encrypted, in the cloud, and some form of virtual card or token is created and stored on the phone.
Solving the Transmission Problem
It’s one thing to store information securely; it’s another to be able to put it safely to use. There are several methods for safely transmitting data.
Encryption uses a key to transform useful data—like a credit card number—into useless, unreadable data. The data is only usable by a person who has possession of the encryption key. As the Target hack showed, credit card data is currently under-encrypted. PINs are protected by end-to-end encryption, but other credit card data is not.
Tokenization assigns a random number in place of a credit card number. Because they are randomly assigned, tokens cannot be “broken”—there is no code to crack. Tokens are matched to credit card numbers and stored in a secure “token vault”. If the card is compromised, only the token is stolen, and that only has limited use. Depending on the system, tokens may:
- Only work for a certain period of time
- Work only until a payment limit has been reached
- Be specific to certain merchants
- Be specific to payments on a particular device
Apple Pay, for example, uses a combination of encryption and tokenization. A single token stands for the customer’s credit card number. The token is stored on a secure chip, and is used for every transaction. However, each individual transaction is authenticated with a one-time code generated by a cryptogram, which is also stored on the phone’s secure chip. Neither Apple Pay nor Apple stores the underlying credit card number.
Virtual cards connect an actual credit or debit card to a prepaid, virtual debit card. In theory, if the virtual card is compromised, the actual card is unaffected. Google Wallet works by putting a virtual card between the user’s actual credit card and the merchant. Google Wallet also uses rotating credentials to authorize payments, which are of limited use if stolen.
Other Security Measures
An additional, key advantage of mobile payments is the ability to combine these systems with other security measures. Bioidentification, such as fingerprint ID, is one example. Dynamic risk management, such as flagging suspicious purchase attempts based on previous purchase and location patterns, is another.
The mobile payments industry is currently in a state of flux, with many systems being tested and none yet being adopted as the standard. What tokenization and virtual cards have in common is the replacement of static credentials—credit card numbers that don’t change—with dynamic credentials that do change. Given that static credentials, from credit card numbers to social security numbers, are magnets for hackers, dynamic credentials seem to be the future.
For E-Complish’s secure, encrypted, PCI-Compliant mobile payments solutions for businesses, learn more about MobilePay. For a demo of any of our payment solutions, don’t hesitate to get in touch with us.