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-10-05).
See Mark’s comment below, where he says that Apple Pay
is already set up to use the EMV mode of the EMV Contactless
Specification, in addition to the mag-stripe mode.
I’ve been trying to figure out how Apple Pay works and how secure it
is. In an earlier
post I assumed, based on the
press
release on Apple Pay, that Apple had invented a new method for
making payments, which did not seem to provide non-repudiation. But a
commenter pointed out that Apple Pay must be using standard EMV with
tokenization, because it works with existing terminals as shown in a
demonstration.
So I looked at the
EMV
Specifications, more specifically at Books 1-4 of the EMV 4.3
specification, the Common Payment Application Specification addendum,
and the Payment Tokenisation Specification. Then I wrote
a second blog
post briefly describing tokenized EMV transactions. I conjectured
that the dynamic security code mentioned in the Apple press
release was an asymmetric signature on transaction data and other
data, the signature being generated by customer’s device and verified
by the terminal as part of what is called CDA Offline Data
Authentication. And I concluded that Apple Pay did provide
non-repudiation after all.
But commenters corrected me again. Two commenters said that the
dynamic security code is likely to be a CVC3 code,
a.k.a. CVV3, and provided links to a
paper
and a
blog
post that explain how CVC3 is used. I had not seen any mention of
CVC3 in the specifications because I had neglected to look at the EMV
Contactless Specifications, which include a mag-stripe mode
that does not appear in EMV 4.3 and makes use of CVC3. I suppose
that, when EMVCo extended the EMV specifications to allow for
contactless operation, it added the mag-stripe mode so that
contactless cards could be used in the US without requiring major
modification of the infrastructure for processing magnetic stripe
transactions prevalent in the US.
The EMV contactless specifications
The EMV
Contactless Specifications envision an architecture where the
merchant has a POS (point-of-sale) set-up comprising
a terminal and a reader, which may be separate devices,
or may be integrated into a single device. When they are separate
devices, the terminal may be equipped to accept traditional EMV
contact cards, magnetic stripe cards, or both, while the reader has an
NFC antenna through which it communicates with contactless cards, and
software for interacting with the cards and the terminal.
The contactless specifications consist of Books A, B, C and D, where
Book C specifies the behavior of the kernel, which is software
in the reader that is responsible for most of the logical handling of
payment transactions. (This kernel has nothing to do with an OS
kernel.) Book C comes in seven different versions, books C-1 through
C-7. According to Section 5.8.2 of Book A, the specification in book
C-1 is followed by some JCB and Visa cards, specification C-2 is
followed by MasterCards, C-3 by some Visa cards, C-4 by American
Express cards, C-5 by JCB cards, C-6 by Discover cards, and C-7 by
UnionPay cards. (Contactless MasterCards have been marketed under
then name PayPass, contactless Visa cards under the
name payWave, and contactless American Express cards under the
name ExpressPay.) Surprisingly, the seven C book versions seem
to have been written independently of each other and are very
different. Their lengths vary widely, from the 34 pages of C-1 to the
546 pages of C-2.
Each of the seven C books specifies two modes of operation, an EMV
mode and the mag-stripe mode that I mentioned above.
A goal of the contactless specifications is to minimize changes to
existing payment infrastructures. A contactless EMV mode transaction
is similar to a contact EMV transaction, and a contactless mag-stripe
transaction is similar to a traditional magnetic card transaction. In
both cases, while the functionality of the reader is new, those of the
terminal and the issuing bank change minimally, and those of the
acquiring bank and the payment network need not change at all.
The mag-stripe mode in MasterCards (book C-2)
I’ve looked in some detail at contactless MasterCard transactions, as
specified in the C-2 book. C-2 is the only book in the contactless
specifications that mentions CVC3. (The alternative acronym CVV3 is
not mentioned anywhere.) I suppose other C books refer to the same
concept by a different name, but I haven’t checked.
C-2 makes a distinction between contactless transactions involving a
card and contactless transactions involving a mobile phone, both in
EMV mode and in mag-stripe mode. Section 3.8 specifies what I would
call a “mobile phone profile” of the specification. The profile
supports the ability of the mobile phone to authenticate the customer,
e.g. by requiring entry of a PIN; it allows the mobile phone to
report to the POS that the customer has been authenticated; and it
allows for a different (presumably higher) contactless transaction
amount limit to be configured for transactions where the phone has
authenticated the customer.
Mobile phone mag-stripe mode transactions according to book C-2
The following is my understanding of how mag-stripe mode transactions
work according to C-2 when a mobile phone is used.
When the customer taps the reader with the phone, a preliminary
exchange of several messages takes place between the phone and the
POS, before an authorization request is sent to the issuer. This is
of course a major departure from a traditional magnetic stripe
transaction, where data from the magnetic stripe is read by the POS
but no other data is transferred back and forth between the card and
the terminal.
(I’m not sure what happens according to the specification when the
customer is required to authenticate with a PIN into the mobile phone
for a mag-stripe mode transaction, since the mobile phone has to leave
the NFC field while the customer enters the PIN. The specification
talks about a second tap, but in a different context. Apple Pay uses
authentication with a fingerprint instead of a PIN, and seems to
require the customer to have the finger on the fingerprint sensor as
the card is in the NFC field, which presumably allows biometric
authentication to take place during the preliminary exchange of
messages.)
One of the messages in the preliminary exchange is a GET PROCESSING
OPTIONS command, sent by the POS to the mobile phone. This command is
part of the EMV 4.3 specification and typically includes the
transaction amount as a command argument (presumably because the
requested processing options depend on the transaction amount). Thus
the mobile phone learns the transaction amount before the transaction
takes place.
The POS also sends the phone a COMPUTE CRYPTOGRAPHIC CHECKSUM command,
which includes an unpredictable number, i.e. a random nonce, as
an argument. The phone computes CVC3 from the unpredictable number,
a transaction count kept by the phone, and a secret shared between the
phone and the issuing bank. Thus the CVC3 is a symmetric signature on
the unpredictable number and the transaction count, a signature that is verified
by the issuer to authorize the transaction.
After the tap, the POS sends an authorization request that travels to
the issuing bank via the acquiring bank and the payment network, just
as in a traditional magnetic stripe transaction. The request carries
track data, where the CVC1 code of the magnetic stripe is replaced
with CVC3. The unpredictable number and the transaction count are
added as discretionary track data fields, so that the issuer can
verify that the CVC3 code is a signature on those data items. The POS
ensures that the unpredictable number in the track data is the one
that it sent to the phone. The issuer presumably keeps its own
transaction count and checks that it agrees with the one in the track
data before authorizing the transaction. Transaction approval travels
back to the POS via the payment network and the acquiring bank.
Clearing takes place at the end of the day as for a traditional
magnetic stripe transaction.
Notice that transaction approval cannot be reported to the phone,
since the phone may no longer be in the NFC field when the approval is
received by the POS. As noted in the first comment on the
second post,
the
demonstration shows that the phone logs the transaction and shows
the amount to the customer afer the transaction takes place. Since
the phone is not told the result of the transaction, the log entry
must be based on the data sent by the POS to the phone in the
preliminary exchange of messages, and a transaction decline will not
be reflected in the blog.
Tokenized contactless transactions
Tokenization is not mentioned in the contactless specifications. It
is described instead in the separate
Payment
Tokenisation specification. There should be no difference between
tokenization in contact and contactless transactions. As I explained
in the second
post, a payment token and expiration date are used as aliases for
the credit card number (known as the primary account number, or PAN)
and expiration date. The customer’s device, the POS, and the
acquiring bank see the aliases, while the issuing bank sees the real
PAN and expiration date. Translation is effected as needed by a token
service provider upon request by the payment network (e.g. MasterCard
or Visa). In the case of Apple Pay the role of token service provider
is played by the payment network itself, according to a
Bank
Innovation blog post.
Implications for Apple Pay
Clearly, Apple Pay must following the EMV contactless specifications
of books C-2, C-3 and C-4 for MasterCard, Visa and American Express
transactions respectively. More specifically, it must be following
what I called above the “mobile phone profile” of the contactless
specifications. It must be implementing the contactless mag-stripe
mode, since magnetic stripe infrastructure is still prevalent in the
US. It may or may not be implementing contactless EMV mode today, but
will probably implement it in the future as the infrastructure for
supporting payments with contact cards is phased in over the next year
in the US.
The Apple press release is too vague to know with certainty what the
terms it uses refer to. The device account number is no doubt the
payment token. In mag-stripe mode the dynamic security code is no
doubt the CVC3 code, as suggested in the comments on the
second post.
In EMV mode, if implemented by Apple Pay, the dynamic security code
could refer to the CDA signature as I conjectured in that post, but it
could also refer to the ARQC cryptogram sent to the issuer in an
authorization request. (I’ve seen that cryptogram referred to as a
dynamic code elsewhere.) It is not clear what the “one-time unique
number” refers to in either mode.
If Apple Pay is only implementing mag-stripe mode, one of the points I
made in my
first post
regarding the use of symmetric instead of asymmetric signatures is
valid after all. In mag-stripe mode, only a symmetric signature is
made by the phone. In theory, that may allow the customer to
repudiate a transaction, whereas an asymmetric signature could provide
non-repudiation. On the other hand, two other points related the use
of a symmetric signature that I made in the first post are not valid.
A merchant is not able to use data obtained during the transaction to
impersonate the customer. This is not because the merchant sees the
payment token instead of the PAN, but because the merchant does not
have the secret needed to compute the CVC3, which is only shared
between the phone and the issuer. And an adversary who breaches the
security of the issuer and obtains the shared secret is not able to
impersonate the customer, assuming that the adversary does not know
the payment token.
None of this alleviates the broader security weaknesses that I
discussed in my
third
post on Apple Pay: the secrecy of the security design, the
insecurity of Touch ID, the vulnerability of Apple Pay on Apple Watch
to relay attacks, and the impossibility for merchants to verify the
identity of the customer.
Remark: a security miscue in the EMV Payment Tokenisation specification
I said above that “an adversary who breaches the security of the
issuer and obtains the shared secret is not able to impersonate the
customer, assuming that the adversary does not know the payment
token“. The caveat reminds me that the tokenization specification
suggests, as an option, forwarding the payment token, token expiry
date, and token cryptogram to the issuer. The motivation is to allow
the issuer to take them into account when deciding whether to
authorize the transaction. However, this decreases security
instead of increasing it. As I pointed out in the
the second
post when discussing tokenization, the issuer is not able to
verify the token cryptogram because the phone signs the token
cryptogram with a key that it shares with the token service provider,
but not with the issuer; therefore the issuer should not trust
token-related data. And forwarding the token-related data to the
issuer may allow an adversary who breaches the confidentiality of the
data kept by the issuer to obtain all the data needed to impersonate
the customer, thus missing an opportunity to strengthen security by
not storing all such data in the same place.
Update (2014-09-21).
There is a small loose end above. If the customer loads the same card
into several devices that run Apple Pay, there will be a separate
transaction count for the card in each device where it has been
loaded. Thus the issuer must maintain a separate transaction count
for each instance of the card loaded into a device (plus another one
for the physical card if it is a contactless card), to verify that its
own count agrees with the count in the authorization request.
Therefore the issuer must be told which card instance each
authorization request is coming from. This could be done in one of
two ways: (1) the card instance could be identified by a PAN Sequence
Number, which is a data item otherwise used to distinguish multiple
cards that have the same card number, and carried, I believe, in
discretionary track data; or (2) each card instance could use a
different payment token as an alias for the card number. Neither
option fits perfectly with published info. Option (2) would require
the token service provider to map the same card number to different
payment tokens, based perhaps on the PAN sequence number; but the EMV
Tokenization Specification does not mention the PAN sequence number.
Option (1) would mean that the same payment token is used on different
devices, which goes counter to the statement in the Apple Press
release that there is a Device Unique Number; perhaps the combination
of the payment token and the PAN sequence number could be viewed as
the Device Unique Number. Option (2) provides more security, so I
assume that’s the one used in Apple Pay.
