The story
While researching on possible mobile payment methods for a project, I had this thought stuck in my mind, “Why can’t I just clone my credit cards and store a virtual copy of it on my phone?”. That seemed pretty straight-forward; I would just need to record and replay the exact same near-field communication (NFC) signal emitting from my (contactless-enabled) credit card. So, as with any new idea I tapped in to the near limitless wealth of knowledge powered by the culmination of mankind’s technology advances in the palm of my hands — I Googled for answers.
As it turns out — not surprisingly, it isn’t as simple as copy-pasting my card number or mimicking a radio signal. I quickly realise it is not possible because of various limitations in part due to the EMV protocol implementation. Some of the more interesting facts/limitation I found include:
- EMV-Contactless cards only emit signal when triggered by Point-of-Sale (POS) terminals (the processor in EMV cards are powered wirelessly through induction)
- Only a legitimate POS merchant with an authorised acquirer bank can communicate with the EMV-chip and create the transaction
- Each “reply” by the EMV chip, even when everything above checks out, can only be used once and is tied to the specific transaction
Coupled with various other strategy and algorithms employed by the EMV standard and banks, which are ever-evolving to combat fraud, it seems like an eternal uphill battle.
It led me to ponder about those fancy mobile payment we hear about; Apple Pay, Samsung Pay or the other similar payment methods out there.
First, let’s dive under the hood to understand the implementation of the various mobile payment methods
I shall start my path on Google to search for answers again.
Payment methods such as Apple pay & Google pay have working partnerships with major banks and card network that allow them to essentially re-create a symbolic link of the card itself.
What this means is that the card stored in the phone is a virtual “copy” of the original but by all intents and purposes is a totally unrelated card. When the merchant tries to process the transaction on the virtual card, the network (Visa, Mastercard, etc) identifies the virtual card, find out the actual card number represented by that card and forwards it to the issuing entity; usually the customer’s card issuing bank. If everything checks out, the flow reverses with the issuing entity responding with transaction approval until the merchant receives the payment complete message.
Whoa, that is more complicated than I initially imagined; but I’m not giving up.
I shall dig deeper.
How do the big guys do it?
Apple handles this by storing a tokenised copy of the data representing the stored credit card in the secure element chip which can only be decrypted by the card’s payment network. Apple’s servers does not store any card number nor have access to any card data.
For more details, Apple has a pretty detailed article on the security and privacy of Apple pay here
For Android pay, Google had to come up with an alternate solution since the hardware is not as tightly coupled as iPhone & iOS and not all devices will contain a secure element chip. Google introduced the solution in Android 4.4 called Host Card Emulation (HCE). A simple way to think of it is that the secure chip is now on the cloud in Google’s servers. The Android device will store a limited set of tokens generated by the Google’s servers and will then transmit it using NFC to POS terminals when needed; essentially emulating the card without storing any card-related information.
One key difference in this approach is that the card information is therefore no longer stored on the device as opposed to Apple’s device hardware only implementation.
*It is unclear at this stage if Google stores only tokenised card data or actual card data in their servers but in this article we assume only tokenised card data are stored on Google’s servers
More details on Google’s implementation can be found here
This makes Google’s implementation slightly less secure and private but it does provide numerous benefits — mainly scalability and lower cost which in turn to drive up adoption which make perfect sense considering Android’s business structure.
From the complex payment flow involving different mobile operating systems, manufacturers, banks & payment networks it seem near impossible to simply replicate what the big tech companies have done.
But..it can’t really be the case right?
Time to dig deeper.
Okay, so how exactly?
To start off, adding any credit or debit card to the mobile wallet service will encrypt the card information, and only the wallet service provider can decrypt, before sending it securely to the mobile wallet service provider’s server(Apple, Google, Samsung etc). It then triggers a request to the payment network for a tokenised data that represents the card. This is the only time the actual card number in its encrypted form ever gets sent from the device.
The payment network, issuing banks and any bank authorised service provider, all plays a part in tokenising the card. Specifically, the payment network which acts as the Token Service Provider (TSP) provides a token & a token key to the issuing bank. In some cases, an authorised third party can act as the TSP instead. The issuing bank will then tags a credit verification value (cvv) key to the data and forwards it to the mobile wallet service provider. The mobile wallet service provider will then store the information in the secure element chip(in Apple’s case), or on a secure server (in Google’s case).
So, at this point we have already established that no actual card numbers are stored on the device and our hopes and dreams of are utterly destroyed.
Darn it! But… Could we somehow store the tokenise card and use it ourselves then?
Maybe, if I could somehow go further…
Let’s take a look at how the tokenised card is actually used.
Remember the 3 things we got from the payment network and stored in secure element? The token, which is basically your tokenised card aka virtual card, the token key, which generates a cryptogram based on data such as the token, token key, transaction value etc (just think of it as a unique one-time password you get in SMS messages), and the cvv key, which generates a dynamic cvv number(the 3 digit number you find behind most credit cards)
Those information get sent via NFC using a contactless payment protocol to the merchant’s payment terminal which forwards it to the payment network. Each entity that issued the tokens verifies the data accordingly and determines if the transaction is valid. The TSP then verifies that the cryptogram is valid and de-tokenise the virtual card — matching the virtual card with the actual card number, and forwards the actual card number with the dynamic cvv to the issuing bank. The issuing bank in turn verifies the dynamic cvv and authorises the transaction. The authorisation flows in reverse back to the merchant’s payment device and the transaction is completed.
There are a few key security features to note. Just like the regular EMV-Contactless chip, the signal sent by the NFC from the mobile device is only valid for a one-time usage. The cryptogram ensures that the same data can’t be charged twice and the transaction value or any other related value are intact. And at this point the dynamic cvv is just defense in depth’s icing on the cake.
Well then. Now that I’ve gotten to bottom of it, maybe it’s time to accept that it can’t be done — at least for now.
While there is no such thing as perfect security but it will take a whole lot more work to crack at this.
