Apple Pay, EMV and Tokenization

Update (2014-10-19). The discussion of tokenization in this post is based on an interpretation of the EMV Tokenisation specification that I now think is not the intended one. See the white paper Interpreting the EMV Tokenisation Specification for an alternative interpretation.

Update (2014/09/24). Apple Pay must be using the EMV contactless specifications, which are a substantial departure from the EMV 4.3 specifications. PLEASE SEE THIS MORE RECENT POST.

After reading Apple’s press release on Apple Pay, I naively believed that Apple had invented a new protocol for credit and debit card payments. In my previous post I speculated on how Apple Pay might be using the device account number, one-time unique number and dynamic security code mentioned in the press release. But in a comment, Brendon Wilson pointed out that Apple Pay must be using standard EMV with Tokenization, since it uses existing contactless terminals, as shown in a demonstration that he sent a link to. I agree, and after spending some time looking at the EMV specifications, I believe that the device account number, one-time unique number and dynamic security code of the press release are fanciful names for standard data items in the specifications.

I’ve seen a Bank Innovation blog post that tries to explain how Apple Pay works in terms of EMV and Tokenization. But that post is inconsistent, saying sometimes that the terminal generates a transaction-specific cryptogram, and other times that the cryptogram is already stored in the iPhone when the consumer walks up to a checkout counter.

One way of explaining how EMV-plus-Tokenization works is to consider the evolution from magnetic strip cards to cards with EMV chips and then tokenization.

Magnetic strip transactions

In a magnetic strip transaction, the terminal reads the credit or debit card number (a.k.a. as the Primary Account Number, or PAN) and the expiration date from the card and assembles a transaction authorization request that contains the card number and expiration data in addition to other data, including the transaction amount. The terminal sends the request to the acquiring bank, which forwards it to the issuing bank through a payment network such as VISA or MasterCard. If appropriate, the issuer returns an approval code, which reaches the merchant via the payment network and the acquiring bank.

At the end of the day, the merchant sends a batch of approval codes to the acquiring bank for clearing. The acquiring bank forwards each approval code to the appropriate issuing bank via the payment network and credits the merchant account after the issuing bank accepts the charge and the transaction amount is received by the acquiring bank from the issuing bank.

EMV transactions

When an EMV chip is used instead of a magnetic strip, the transaction process changes as follows. The terminal sends transaction data including the transaction amount to the chip in the card, which returns a response indicating whether the transaction is to be rejected, accepted offline, or processed online by submitting it to the issuer for approval.

(In the context of EMV, an “online transaction” is an in-store transaction that is approved by the issuing bank reached over some network. To avoid confusion, I will use the term “web transaction” or “web payment” to refer to a transaction where the user enters credit card data into a web form.)

The chip’s response includes a cryptogram. Confusingly, the term cryptogram has two different meanings in the EMV specifications. Formally, a cryptogram is a symmetric signature, which takes the form of a message authentication code (MAC) calculated with a key shared between the chip and the issuing bank. (Strictly speaking, each MAC is computed with a different key derived from a permanent shared key and a transaction counter.) But informally, the term cryptogram is also used to refer to a message containing the MAC, such as the response from the chip to the terminal, and a cryptogram is said to be of a particular type, indicated by an acronym such as AAC, TC, ARQC or ARPC, determined by a Cryptogram Information Data byte included in the message.

To indicate that the transaction is to be accepted offline, the chip sends the terminal a Transaction Certificate (TC) cryptogram, while to indicate that an authorization request is to be sent to the issuer, the chip sends the terminal an Authorization Request Cryptogram (ARQC). In both cases the MAC is computed on data that includes the transaction amount and other transaction data as well as terminal and application data. However, the card number and expiration date are not included in the MAC computation.

If it receives an ARQC cryptogram, the terminal sends an authorization request including the cryptogram (i.e. the MAC) to the acquiring bank, which forwards it to the issuing bank via the payment network. The issuer responds with a message that follows the same route back to the merchant and includes an Authorization Response Cryptogram (ARPC), signed with the same key as the ARQC cryptogram. The terminal forwards the ARPC cryptogram to the chip, which sends back a TC cryptogram.

Whether the transaction is authorized offline or online, the merchant includes the TC cryptogram received from the chip in the funding request that it sends to the acquiring bank at clearing time. The TC plays the role played by the approval code in magnetic strip processing. It is forwarded by the acquiring bank to the issuer via the payment network.

Tokenized transactions

Tokenization replaces the credit or debit card number and expiration date with numeric codes of same length, called a payment token and a token expiry date respectively. Separate ranges of numeric codes are allocated so that no payment token can be confused with a card number. A Token Service Provider maintains the mapping between card numbers coupled with their expiration dates and payment tokens coupled with their expiration dates.

Reliance on the token service provider means that tokenization can only be used for online transactions. [Update. As explained in Shaun’s comment, there is no reason why offline transactions cannot use tokenization.] Only the issuer and the payment network see the true card number and expiration date. The acquiring bank, the merchant and the user’s device (which may be a card with a chip, or a mobile device) only see the payment token and expiration date. Back-and-forth translation between card data and token data is effected by the token service provider upon request by the payment network. Translation does not invalidate cryptograms, because cryptograms do not include the card number and expiration date.

At transaction time, the authorization request with the ARQC cryptogram includes token data as it travels from the user’s device to the merchant’s terminal, the acquiring bank, and the payment network. The payment network sends a “de-tokenization” request to the token service provider. The token service provider returns the card data, which the payment network adds to the request before forwarding it to the issuer bank. The response from the issuer bank, which carries the ARPC cryptogram, includes card data but no token data. The response goes first to the payment network, which replaces the card data with token data obtained from the token service provider, before sending the response along to the acquiring bank, the merchant, and the user’s device.

At clearing time, the merchant sends token data along with the TC cryptogram to the acquiring bank, which forwards them to the payment network. The payment network asks the token service provider to de-tokenize the data, then forwards the card data and the TC cryptogram to the issuing bank.

The tokenization spec allows the role of token service provider to be played by the issuing bank, the payment network, or a party that plays no other role in transaction processing. According to the Bank Innovation post, it is the payment network that plays the token service provider role in Apple Pay.

The tokenization spec mentions a token cryptogram. This cryptogram is different from the others, and does not replace any of the others. Its purpose is to help the token service provider decide whether it is OK to respond to a de-tokenization request and reveal card data. It is computed with a symmetric key derived from data shared between the user’s device and the token service provider. It is sent along with a transaction authorization request from the user’s device to the merchant’s terminal, the acquiring bank and the payment network, which includes it in the de-tokenization request to the token service provider.

According to the EMV specs, the token cryptogram may also be forwarded by the payment network to the issuer, which can take it into account when deciding whether to authorize the transaction. However, the issuer cannot verify the authenticity of the token cryptogram, since it is signed with a key that the issuer does not have.

Offline data authentication

Now I need to go back to the pre-tokenization EMV specs and describe the concept of offline data authentication, which refers to the direct authentication by the terminal of data sent by the card, as part of an offline or online transaction. The EMV specifications require cards that can perform offline transactions to support offline data authentication, while such support is optional for cards that only perform online transactions. Offline data authentication takes place when both the card and the terminal support it.

Offline data authentication comes in three flavors, called SDA, DDA, and CDA.

In Static Data Authentication (SDA), the card provides the terminal with an asymmetric signature on static card data. The signature is computed once and for all by the issuer when the card is issued and stored in the card. The issuer has an RSA key pair. The private key is used to compute the signature, and the public key is included in a certificate issued by a certificate authority (CA) to the card-issuing bank . The issuer’s certificate is also stored in the card and sent to the terminal along with the signature. (The issuer’s private key is not stored in the card, of course.) The terminal uses the public key in the certificate to verify the signature, and the public key of the CA, which it is configured with, to verify the CA’s signature in the issuer’s certificate. Notice that the card does not have a key pair.

In Dynamic Data Authentication (DDA), the card has its own key pair, which is stored in the card when the card is issued. (Cryptographic best practice calls for a key pair to be generated within the cryptographic module where it will be used, but card firmware may not have key-pair generation functionality.) The card provides the terminal with an asymmetric signature computed with the card’s private key on data including a transaction-specific random challenge sent by the terminal. The card sends the signature to the terminal together with a certificate for the card’s public key signed by the issuer and backed by the issuer’s certificate, which the card also sends to the terminal.

In Combined DDA / Application Cryptogram Generation (CDA), the data signed by the card additionally includes the cryptogram that the card sends to the terminal.
[Update: The data that is signed also includes transaction data. Transaction data is thus signed twice, with a symmetric signature (the cryptogram) and an asymmetric signature. The CDA asymmetric signature provides non-repudiation, although non-repudiation is not discussed in the EMV specfications.]

Offline data authentication in a tokenized transaction

The tokenization spec does not mention offline data authentication. Recall that tokenized transactions are necessarily online transactions, and the EMV spec does not require cards that only perform online transactions to support offline data authentication.

However, nothing prevents the use of offline data authentication in a tokenized online transaction. In a non-tokenized transaction, the asymmetric signature in any of the three flavors of offline data authentication is computed on data that includes the card number and expiration date. In a tokenized transaction, it will be computed on data that includes instead the payment token and token expiry date.

Explaining the Apple press release terminology

Based on the above, the terms in the Apple press release can be understood as follows:

Device account number. The press release says:

When you add a credit or debit card with Apple Pay, the actual card numbers are not stored on the device nor on Apple servers. Instead, a unique Device Account Number is assigned, encrypted and securely stored in the Secure Element on your iPhone or Apple Watch.

Clearly, the device account number must be what the Tokenization spec calls the payment token.

One-time unique number. The press release also says:

Each transaction is authorized with a one-time unique number using your Device Account Number …

The one-time unique number must be the ARQC cryptogram that is sent to the issuer as part of an authorization request.

Dynamic security code. The press release goes on to say:

… and instead of using the security code from the back of your card, Apple Pay creates a dynamic security code to securely validate each transaction.

This is puzzling, since the card’s security code is not used for in-store transactions, is not encoded in a magnetic strip, and is not stored in an EMV chip. It is only used for payments by phone or web payments. So nothing can be used instead of the security code for in-store transactions.

I conjecture that the term dynamic security code has been invented by an imaginative security-marketing guru to refer to an asymmetric CDA signature sent by the user’s device to the merchant’s terminal. We have seen above that CDA is not precluded by the EMV spec for online transaction. It would make sense for Apple Pay devices to provide CDA to merchant terminals, because that would increase security and could be useful to merchants. A merchant could use a CDA signature as evidence when contesting a chargeback, because an asymmetric signature provides non-repudiation. The signature would be on data including the payment token rather than the card number, but in a repudiation dispute the token service provider could supply the card number.

If Apple Pay devices implement CDA signatures, and if all terminals used with Apple Pay make use of them, then the concerns about the use of symmetric instead of asymmetric signatures that I raised in the previous post are eliminated. But other security concerns remain. In the next post I will restate those remaining concerns, taking into account new information in a MacRumors blog post on Apple Watch that was also referenced by Brendon Wilson in his comment. (Thank you, Brendon!)