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.