Apple Pay has brought attention to the concept of tokenization by storing a payment token in the user’s mobile device instead of a card number, a.k.a. a primary account number, or PAN. The Apple Pay announcement was accompanied by an announcement of a token service provided by MasterCard and a similar announcement of another token service provided by Visa.
Tokenization is not a new concept. Token services such as the TransArmor offering of First Data have been commercially available for years. But as I explained in a previous post there are two different kinds of tokenization, an earlier kind and a new kind. The earlier kind of tokenization is a private arrangement between the merchant and a payment processor chosen by the merchant, whereby the processor replaces the PAN with a token in the authorization response, returning the token to the merchant and storing the PAN on the merchant’s behalf. In the new kind of tokenization, used by Apple Pay and provided by MasterCard, Visa, and presumably American Express, the token replaces the PAN within the user’s mobile device, and is forwarded to the acquirer and the payment network in the course of a transaction. The purpose of the earlier kind of tokenization is to allow the merchant to outsource the storage of the PAN to an entity that can store it more securely. The purpose of the new kind of tokenization is to prevent cross-channel fraud or, more specifically, to prevent an account reference sniffed from an NFC channel in the course of a cryptogram-secured transaction from being used in a traditional web-form or magnetic-stripe transaction does does not require verification of a cryptogram. The new kind of tokenization has the potential to greatly improve payment security while the payment industry transitions to a stage where all transactions require cryptogram verification.
The new kind of tokenization is described in a document entitled EMV Tokenisation Specification — Technical Framework. We have looked at the document in detail and we report our findings in a white paper. The document is, to be blunt, seriously flawed. It leaves most operational details to be specified separately in the message specifications of each of the payment networks (presumably MasterCard, Visa and American Express), and it is plagued with ambiguities, inconsistencies and downright nonsense. Nevertheless, I believe we have been able to come up with an interpretation of the document that makes sense for some of the use cases. (Other use cases cannot be made to work following the approach taken in the document.)
Here are the conclusions drawn by the white paper.
Apple Pay use case. In the use case that is probably implemented by Apple Pay for both in-store and in-app transactions, a token service provider provisions a token and a shared key to the mobile device. When it comes to making a payment, the merchant sends a cryptographic nonce to the device and the device generates a cryptogram, which is a symmetric digital signature computed with the shared key on data that includes the nonce. (A cryptographic nonce is a number that is only used once in a given context.) The merchant includes the token and the cryptogram in the authorization request, which travels via the acquirer to the payment network. The payment network asks the token service provider to validate the cryptogram on behalf of the issuer and map the token to the PAN; then it forwards to the issuer a modified authorization request that includes both the token and the PAN but not the cryptogram. The role of payment service provider can be fulfilled by the payment network itself without essentially altering the use case.
Alternative use case with end-to-end security. As an alternative, the issuer itself can play the role of token service provider and provision the token and shared key to the mobile device, just as it provisions a shared key to a chip card in a non-tokenized transaction. (The issuer may also provision a token to a chip card; the token is then stored in the chip while the PAN is embossed on the card.) In that case the payment network forwards the authorization request to the issuer without replacing the token with the PAN. The transaction flow is essentially the same as in a non-tokenized transaction. The cryptogram is validated by the issuer, preserving the end-to-end security that is lost when the cryptogram is validated by the payment network or a third party playing the role of token service provider.
Alternative to tokenization. Instead of provisioning a token to a mobile device (or a chip card), the issuer can achieve essentially the same level of security by provisioning a secondary account number and flagging it in its own database as being intended exclusively for use in EMV transactions, which require cryptogram validation.
If you have comments on the white paper, please leave them here.
There was actually an even earlier tokenization service used by both Citi and Discover, but it had to be provided by the issuer to the consumer and was only useful for online or over the phone transactions. I forget what Discover called it, but Citi called their implementation “virtual account numbers” or VANs. I forget the name of the company that actually provided the tokenization system to the issuers.
A consumer with a card account would have to log in to the issuer’s web site and request a “VAN” which, once used by a particular merchant, couldn’t be used for transactions with any other merchant. In the case of Citi’s implementation, the consumer could also choose the expiration date and a maximum total transaction limit. While the merchant tied to the VAN could charge multiple transactions within the expiration period and optional spending limit, the consumer could also manually invalidate the VAN at any time.
While it seems likely that physical storefront POS terminals would process transactions with these tokenized account numbers, a user would have the write the number to the mag stripe on a physical card and using such a card would, at the least, look very suspicious if not violate some sort of terms of service or law. But it was still quite useful for e commerce sites with dubious security that saved your card number for future transactions and might be located in countries with poor regulations and law enforcement.
Not surprisingly this service was eventually dropped by Citi and Discover because few people used it. Even though Citi, at least, had a windows client that would try to auto fill browser forms, it still required an extra user login every time a purchase was made. (The client was also Adobe Flash-based.) This is all enough extra trouble that only unusually security conscious consumers would want to bother with it.
With the rise of always-connected mobile devices, an issuer-specific payment app on a phone could implement the client part and provide more secure transactions in an automated manner without the use of EMV, but of course this relies on an Internet side channel to obtain a new tokenized account number every time and would fail when the cell network isn’t available, etc. And you still have all the issues of how to safely store authentication information for the side channel.
Someone pay to use the payment brand network service in accepting credit cards. They tell you there will be fraud, so someone has to pay again to use tokenization service provided by the payment brand XDD