Which Flavor of Tokenization is Used by Apple Pay

I’ve seen a lot of confusion about how Apple Pay uses tokenization. I’ve seen it stated or implied that the token is generated dynamically, that it is merchant-specific or transaction-specific, and that its purpose is to help prevent fraudulent Apple Pay transactions. None of that is true. As the Apple Pay press release says, “a unique Device Account Number is assigned, encrypted and securely stored in the Secure Element on your iPhone or Apple Watch”. That Device Account Number is the token; it is not generated dynamically, and it is not merchant-specific or transaction-specific. And as I explain below, its security purpose is other than to help prevent fraudulent Apple Pay transactions.

Some of the confusion comes from the fact that there are two very different flavors of tokenization. That those two flavors are confused is clear in a blog post by Yoni Heisler that purports to provide “an in-depth look at what’s behind” Apple Pay. Heisler’s post references documents on both flavors, not realizing that they describe different flavors that cannot possibly both be used by Apple Pay.

In the first flavor, described on page 7 of a 2012 First Data white paper referenced in Heisler’s post, the credit card number is replaced with a token in the authorization response. The token is not used until the authorization comes back. Tokenization is the second component of a security solution whose first component is encryption of credit card data from the point of capture, which can be a magnetic stripe reader, to the data center of the processor that the merchant has contracted with to process credit and debit card transactions. The processor decrypts the card data and forwards the transaction to the issuing bank for authorization (via the acquiring bank and the payment network, although this is not mentioned). When the authorization response comes back, the processor replaces the credit card number with the token before forwarding the response to the merchant. The merchant retains the token, and uses it instead of the credit card number for settlement, returns, recurring transactions, etc.

In this first flavor, the token is specific to a merchant, or perhaps even to a transaction or sequence of recurring transactions. A security breach at the merchant, other than skimming, can only reveal tokens, which cannot be used for purchases at a different merchant.

In the flavor of tokenization used by Apple Pay, on the other hand, the card number (and expiration date) is mapped to a token (and token expiration date), which is stored in the phone instead of the card number. The same token is used for all transactions and all merchants. In the course of a transaction the token travels from the phone to the merchant, to the processor if the merchant uses one, to the acquiring bank, and to the payment network (MasterCard, VISA or American Express). The payment network maps the token to the card number and forwards the authorization request with the card number to the issuer. When the authorization response comes back from the issuer, the payment network maps the card number back to the token before forwarding the response to the acquiring bank, optional processor, and merchant.

The above explanation is based on the widely held belief that Apple Pay is based on the EMV Tokenisation Specification, also referenced in Heisler’s post. The specification is a framework that admits many variations, but in all of them the token is mapped to the card number after the acquirer forwards the authorization request to the payment network, and the card number is mapped back to the token before the payment network sends the authorization response to the acquirer. Therefore the EMV tokenization standard does not cover the tokenization solution described in the First Data white paper. Why not? Simply because that solution is a private matter between the merchant and the processor. It does not involve the acquiring bank, the payment network or the issuing bank, and therefore it requires no standardization.

Since all merchants see the same token, the security of Apple Pay transactions cannot hinge on tokenization. Instead, it relies on a secret that the phone shares with the issuing bank and uses to generate the dynamic security code also mentioned in the press release, from a transaction-specific challenge received from the merchant and a transaction counter. [Update (2014-10-19). Actually, it seems that the secret is shared with the token service provider rather than with the issuer. See the white paper Interpreting the EMV Tokenisation Specification.] Use of the dynamic security code is specified in the mag-stripe mode of the EMV Contactless Specification, as I explained in an earlier post. (In that post I also pointed out that the EMV Contactless Specification also has an EMV mode, where the user’s device has a key pair certified by the issuing bank in addition to a shared secret, and I speculated that Apple Pay might also be using EMV mode now or might use in the future. A comment by Mark on that post says that it is his understanding that Apple Pay supports both modes from the outset.)

The tokenization flavor used by Apple Pay does have a security purpose, but it is not to prevent fraudulent Apple Pay transactions. It is to prevent the card number and expiration date, which could be exfiltrated from an Apple Pay transaction in the absence of tokenization, from being used in traditional online or magnetic stripe transactions that do not require a shared secret or a key pair.