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.
Comments
11 responses to “Apple Pay Must Be Using the Mag-Stripe Mode of the EMV Contactless Specifications”
Another detailed write up. I see that Mastercard in EMV Book mentions “on device cardholder verification (ODCV)” and I have seen references to “consumer devicer cardholder verification” from Visa. This should solve issues where the terminal asks you for a PIN as well.
As you mention I’m not to sure how well ODCV will work in practice while still staying in the contactless field. Entering a PIN while still maintaning a NFC contact sounds difficult.
What I have been after is what changes does a POS Terminal supplier need to make to support this? In NZ we have many contactless POS terminals and I’d like to know if there is development work required. I guess we will wait till the first deployment to see exactly what tags go across.
Lastly, I’m thinking that Apple’s call that you can remain ‘anoyomous’ while using this, is nonsense. I’m expecting the token to stay constant and even if that changes I would expect the ICC Public Key Certificate to be constant. So the merchant will still be able to accumulate sale information. How to map this identifier to a real person will become the next step.
Even if these NFC values did consistently change, I’d expect we would see POS terminals with Wifi or Bluetooth that spring into life when the reader is activated and look for the MAC of very near devices.
I have been interested in this as I liked to
Somehow your comment got truncated. I’d love to see the end of the sentence 🙂
Actually my fault 🙂 . I was editing it and forgot to remove the line. It was meant to say that I have been interested in this as I want to see the flow to find out what it means for our instore POS Terminal devices.
It does read like a nice teaser though 🙂
From what I understand, the architecture will support both EMV Card Emulation (with the full symmetric AND asymmetric signatures) as well as the MagStripe (MSD) mode from the outset – as you point out, when the terminal initiates the data exchange, it shares information with the card – this can include what applications and modes it supports and, subsequently the ApplePay solution will present back the required data. TBH with the looming EMV upgrade in the US (while not mandated by the schemes, they are implementing a liability shift which will heavily incentivise all the participants to upgrade) this point will be somewhat moot within 12-24m as all the contactless terminals will likely be upgraded to EMV.
The “dynamic codes” referred to are (depending on the profile used) a combination of the dCVV (CVC3), the CDA signature and the ARQC /ARPC/TC – all of these fields could be described as ‘dynamic’ and one-time use, while the token is indeed “static” but will differ depending on type of card selected as the merchant/acquirer still needs to know whether they are processing a debit vs credit transaction as well as the scheme of the “card” as these are using for routing decisions and interchange reconciliations. My understanding is that the TSPs will work with First Data (on behalf of Apple) to provision the tokens onto the Secure Element which has been pre-loaded with the relevant scheme applications/applets.
I also believe Apple is using your “Option 2” as tokenisation has been built to support a wide variety of use cases and therefore the token vault has to capable of mapping multiple tokens (from multiple token requestors) to the same PAN. Indeed as the Token services evolve to support HCE and other use cases, they will likley support “dynamic” (limited by time, domain, device, etc) tokens as well as the more static implementation of ApplePay
Regarding the phone transaction logs not reflecting declines – you are partially correct, as it will not reflect authorisation declines from the issuer, but it will reflect declines resulting from the terminal-device logic flow (incorrect consumer verification, failed card authentication, etc). However, there is a potential subsequent step available in these types of NFC implementations whereby the a combination of the Issuer/Token Service Provider can remotely ‘sync’ a correct transaction history to the device using a secure gateway and connection to the device. Again, exactly how this is implemented in ApplePay is as yet unclear, but I have heard from credible contacts in the banks that they are doing something like this.
The scheme rule definitions of On Device Consumer Verification (or CD CVM in the Visa language) are not prescriptive that it must be a PIN – it can be numeric, alphanumeric, pattern-based, etc. In the ApplePay case, Touch ID is acting as the CDCVM and Apple have implmented the logic that translates the +ve/-ve response from their Secure Enclave (where the fingerprint template is stored) into the relevant data field for the transaction. The PIN-based implementations I have seen previously used to allow 2 different user experiences – one where the consumer pre-enters a PIN (though this causes some issues re non-repudiation as it is done before they can validate the transaction amount) and one where the user is required to do 2 “taps”. My guess (though I can’t be sure) is that ApplePay is doing the latter, but the TouchID response is so near instant and the user will likely be already pressing the home button when presenting the phone so that the 2 “taps” are not distinguishable. We will see once they get into the wild!
As to the security of TouchID, very few verification methods are foolproof, hence the schemes have extensive rules around liabilities and chargebacks. Under an EMV transaction, the issuer is liable for the fraud, not the merchant, so you can be sure that the schemes and the banks will have reviewed Touch ID (and whatever is being used for the watch) in fairly extensive detail before granting permission for this solution. In addition, one of the benefits of these type of solutions is that the token can be remotely blocked or killed over the air (Apple are implementing this through Find my iPhone) such that even if a device is stolen, a consumer can block the payment functionality before the fingerpint is cloned, etc as well as alerting their issuer such that the transaction would be declined (as today).
To shaun’s question regarding updates required to the terminal/merchant/processor, the EMVCo tokenisation framework is a good starting point for understanding the changes to data fields and the introduction of new data fields. In the US, the schemes mandated support for these changes by October 2014, so I would expect similar mandates and instructions to follow for other countries as the use of tokenisation spreads.
HTH
Thanks a lot for your very informative comment.
Regarding whether two taps are needed. I’ve looked again at the TechCrunch Apple Pay demo. The customer brings the phone within range of a contactless terminal. There is no tapping, the phone remains several inches away. When the phone enters the NFC field, the payment software is activated and shows a picture of the default credit card, then the customers touches the fingerprint sensor to make the payment. If desired, the customer is able to select a different credit card before touching the sensor. All that happens while the phone remains within the NFC range. So there does not seem to be a need for two distinct interactions. Of course this is because only one touch is needed to pay. As Shaun points out in his comment, it would be difficult to enter a PIN while the phone is within range.
Regarding the security of Touch ID, I have to disagree with you on that. Sure, a responsible user may be able to stop payments before a thief who has stolen the phone has made too many purchases, so a liable issuing bank may tolerate the risk. But I wouldn’t be surprised if issuing banks put a limit on the value of transactions that can be made with Apple Pay. After all, I believe contactless payments were intended for fast low-value transactions when they were introduced a decade ago.
Regarding your response to Shaun’s question, I believe you are referring to the liability shift that will occur in the US in October 2015, and the “October 2014” you mention is a typo; but I don’t think the liability shift mandates tokenization. Please correct me if I’m wrong.
Thanks Francisco – couple of clarifications below.
Re the 2 ‘taps’ issue – when I was describing a ‘tap’, I was referring to an exchange of data between the terminal and handset within the NFC field rather than a physical interaction per se. My hypothesis is that in the Techcrunch example, there are still 2 ‘taps’ but the efficiency and speed of the hardware/software integration by Apple and the fact that the user is likely already holding the TouchID renders this practically invisible…ie when the phone first enters the NFC field (“Tap 1”), the terminal transmits its request (merchant ID, amount, AIDs/methodologies supported, etc) and the phone is activated and requests TouchID (and card selection if required); the consumer verifies the details on screen and performs TouchID and card selection; the phone then returns the relevant information (Token PAN, dCVV, ARQC/TC, CDCVM response, etc) to the terminal (“Tap 2”).
It is entirely possible that the card selection and CDCVM (TouchID or PIN) step could be done outside the RFID field, but Apple are choosing to educate the consumers to stay in the field for simplicity and speed (it is notable that Apple have architected their NFC antenna differently to others and prioritised speed and TouchID is noticeably quicker in iPhone6/6+ and iOS8)
In my description of the single tap scenario in my first post, the card selection and CDCVM step are done before the phone even enters the NFC field (and before the txn amount, etc is shown on the phone screen) and ‘Taps’ 1 and 2 above are then completed in one data exchange between terminal and phone.
As to TouchID, my understanding is that there will be no transaction limit, though I am sure Issuer risk-decisioning systems will be watching carefully in the early weeks/months!!
Contactless was always designed for all value transactions, however, for high-speed, low-value contactless transactions the schemes/banks have implemented limits as those transactions have NO customer verification, only card authentication (ie just tap and go), hence the need for the transaction value and frequency limits.
There is no convenient, secure (foolproof) consumer verification method for mobile, but TouchID is markedly more secure than most other alternatives (despite its flaws) and forms just one layer of security protections in use within ApplePay. I interested to know if you are aware of something potentially better…
Re the mandate, the October 2014 reference was a mandate for processors (ie not overtly public) to support the additional fields/data in the EMVCo tokenisation framework in preparation for ApplePay (though it was never mentioned by name) – this was separate from the broader EMV mandate that implements the liability shift from October 2015.
Thank you very much for the clarifications.
You ask whether I know of something better than TouchID. I do! First, a 4-digit PIN is more secure than TouchID because it is a secret, whereas the user’s fingerprint is not, since you can find it on the phone itself. The user’s fingerprint is like a password on a yellow sticker stuck on the phone.
You may argue that a 4-digit PIN won’t resist a brute-force offline guessing attack by an adversary who captures the phone, but such an attack can be prevented. Apple could prevent it by verifying the PIN within the same secure element where the payment credentials are stored, against a hash of the PIN (or the PIN itself) stored in the secure element, which presumably provides some physical tamper resistance. The attack can also be prevented in phones without a secure element by encrypting the payment credentials under a key entrusted to a key storage service and retrieved upon authentication of the device to the service using a credential regenerated on demand from the PIN and a protocredential. The protocredential is such that all PINs produce well-formed device authentication credentials, making it impossible to test guesses of the PIN in an offline attack. We refer to this technique as virtual tamper resistance technique.
You may also argue that a PIN entered before the transaction does not provide non-repudiation while a PIN entered during the transaction requires the customer to bring the phone into the NFC field twice, or to keep it in the field while entering the PIN. But that’s just because NFC is the wrong technology for in-store payments with a mobile phone. Bluetooth does not have that problem, and can provide a strong form of non-repudiation by having the customer enter the PIN after seeing the balance and transaction details, and seeing them on the user’s own device rather than a device controlled by the merchant. The same benefits can be achieved by making an Internet payment with a web app or a native app while in the store. In the same TechCrunch demo of Apple Pay that I referenced above, the Apple store and Panera transactions may be Internet or Bluetooth transactions using native apps.
Second, if you want to use biometrics, there are modalities such as iris scan or retinal scan that are more of a secret than a fingerprint. At least an iris scan or retinal scan is not found on the exterior of the phone itself. When using such modalities you need more biometric privacy protection than storing a template in a Trusted Execution Environment (TEE), such as Apple’s Secure Enclave, that does not claim to provide physical tamper resistance. But there are techniques for consistently generating a “biometric key” from varying by genuine biometric samples, together with helper data that reveals no biometric information. Our virtual tamper resistance can make use of such a biometric key instead of a PIN, with the helper data included in the protocredential.
Third, although I cannot blame Apple for not knowing this :-), we have recently invented a different technique that provides strong security specifically for in-store payments. I can’t discuss it now in a public forum because we have not filed a patent application yet. Usually we file in the US only, which allows us to publish up to one year before filing, but this invention may deserve an international filing.
You can get some technical info from the developer documentation on Apple’s web site. The main document is this: https://developer.apple.com/apple-pay/Getting-Started-with-Apple-Pay.pdf but the details are in the PassKit documentation here: https://developer.apple.com/library/IOs/documentation/UserExperience/Reference/PassKit_Framework/index.html Also of particular interest is https://developer.apple.com/library/IOs/documentation/PassKit/Reference/PaymentTokenJSON/PaymentTokenJSON.html#//apple_ref/doc/uid/TP40014929
This documentation pertains to use of ApplePay within apps that process transactions using some sort of web services interface via the Internet rather than POS terminals, but I’m guessing that the POS terminal interaction is basically the same since both will have to interface with the same acquirer services.
Thanks for the suggestion to look at the Apple Pay developer documentation, and for the links. It turns out that Apple Pay relies primarily on the 3-D Secure protocol for Internet payments, although it may also use EMV. Unfortunately there are no details in the documentation on how EMV is used. I’ve looked in some detail at the documentation and at the information I’ve been able to find on 3-D Secure and I’ve written a new blog post explaining what I’ve found out.
[…] customers, and even then only some: there is only one Chip and PIN specification, but there are seven specifications for contactless cards, and only the MasterCard variant includes this defence. It’s not perfect, but it makes pragmatic […]
[…] customers, and even then only some: there is only one Chip and PIN specification, but there are seven specifications for contactless cards, and only the MasterCard variant includes this defence. It’s not perfect, but it makes pragmatic […]