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.
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.
press release on Apple Pay, I naively believed that Apple had
invented a new protocol for credit and debit card payments. In
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
that he sent a link to. I agree, and after spending some time looking
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.
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
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.
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
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.
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
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
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
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,
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
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
blog post on Apple Watch that was also referenced by
Brendon Wilson in his
comment. (Thank you, Brendon!)