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.
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.