Update (2014-9-15). As pointed out in the comments, it seems that Apple Pay is based on existing standards. In my next post I try to explain how it may follow the EMV specifications with Tokenization, and in the following one I update the security concerns taking into account additional information on Apple Watch.
Yesterday’s Apple announcements shed light on a surprising contrast between the attitudes of the company towards product design on one hand, and towards security on the other. Tim Cook took pride not only on the design of the Apple Watch, but also on the process of designing it, the time and effort it took, the attention to detail, and the reliance on a broad range of disciplines ranging from metallurgy to astronomy. The contrast could not be sharper with the lack of attention paid to the security of Apple Pay.
I doubt if any cryptographers were consulted on the design of Apple Pay. If they were, they should have insisted on publishing the design so that it could benefit from the scrutiny of a broad range of security experts. Submission to public scrutiny has been recognized as a best practice in the design of cryptographic protocols for many decades.
The press release on Apple Pay mentions a Device Account Number, a one-time transaction authorization number, and a dynamic security code. Since the security design is secret, it is impossible to tell for sure how these numbers and codes are used. But since no mention is made of public key cryptography, I surmise that the Device Account Number is a shared secret between the device and the credit card issuing bank, and the dynamic security code is a symmetric signature on the transaction record. If so, by using a symmetric signature instead of an asymmetric one, Apple is 36 years behind the state of the art in cryptography. By contrast, asymmetric signatures are used routinely by smartcards for in-store payments in accordance with the EMV specifications. The same techniques could be adapted for in-store or online payments with credentials stored in a mobile device.
Symmetric signatures lack non-repudiation. And if the Device Account Number is used as a symmetric key, then it may be vulnerable to insider attacks and security breaches at the issuing bank, while a private key used for asymmetric signatures would only be stored in the user’s device and would be immune to such vulnerabilities. Worse, for all we know, the Device Account Number may be made available to the merchant’s terminal; the press release says nothing to the contrary. If so, it would be vulnerable to capture by point-of-sale malware, after which it could be used online to commit fraud just like a credit card number.
A surprising aspect of Apple Pay is its dependence on Touch ID, which only provides security against casual attackers. But wait, does Apple Pay security really depend on Touch ID? Although this is not mentioned in the Apple Pay press release, it was stated at the Apple event in Cupertino that payments can be made using an Apple Watch, which itself can be used in conjunction with an iPhone 5 or 5C. Neither the Apple Watch, nor the iPhones 5 and 5C have Touch ID sensors; and use of the Touch ID sensor in an iPhone 5S, 6 or 6+ may not be required when the terminal is tapped by an Apple Watch used in conjunction with those phones. So it seems that Apple Pay does not really require user authentication.
The press release says that, “when you’re using Apple Pay … cashiers will no longer see your name, credit card number or security code, helping to reduce the potential for fraud”. This may reduce the potential for fraud against the customer, but certainly not for fraud against the merchant. And while customers have little if any liability to fraud, at least in the US, merchants are fully liable. Without knowing the customer’s name, merchants cannot verify the customer’s identity and are defenseless against a thief who steals an Apple Watch and its companion iPhone and goes shopping online, or in stores without having to show an ID.
But while Apple Pay puts merchants at risk of financial loss, it
puts users at an even greater risk. I don’t like to dramatize, but I
don’t know how else to say this. People
have been killed by smart phone thieves. Somebody wearing an
Apple Watch will be parading a valuable watch, and advertising that a
valuable smart phone is being carried along with the watch.
Furthermore, a thief who steals the watch and the phone can then go on
a shopping spree.
The press release says that “if your iPhone is lost
or stolen, you can use Find My iPhone to quickly suspend payments from
that device”; but this will be a powerful incentive for the thief to
kill the victim. If Apple does not find some other way of
discouraging theft, wearers of Apple watches will be putting their
lives at risk.
Update.
I got carried away and didn’t think it through. It’s unlikely that a
murderer will risk using the victim’s phone and watch for purchases.
Even though the merchant does not know the identity of the owner of
the mobile device, a forensic investigation will no doubt be able to
link the murder to the shopping and may allow the murderer to be
identified by surveillance cameras.
All indications are that Apple Pay is using EMV Tokenization (http://www.emvco.com/specifications.aspx?id=263) – i.e. there’s no Apple-specific magic in the payment piece here. It’s incredible similar to what is under the covers of Google Wallet.
In fact, you’ll notice that many of the merchants that were touted in the Apple Pay announcement are the same that were touted on the Google Wallet web site. Why is that? Because the terminals are the exact same. Standard Vivo or Verifone terminals, as shown in this demonstration: http://techcrunch.com/2014/09/09/heres-apple-pay-in-action/
As for Apple Watch – the lack of Touch ID is not an impediment to the security of the system (see here – essentially the user auths with a PIN when they put on the watch, instead of using Touch ID for each transaction.
Thank you for your very informative post. You’re right, Apple must be using standard EMV with Tokenization. I’ve spent some time looking at the specs, and I’ve written a follow up post where I try to explain how Apple Pay could work without departing from the specifications. I also discuss in another follow-up post the security implications of how Apple Pay works on Apple Watch according to the MacRumors post that you reference. If you have any further comments they would of course be very welcome.
Francisco,
I agree it’s incredible that a new payments system and protocol would be developed these days that did not use asymmetric cryptography to digitally sign the payment instruction composed in the cardholder’s device (smartphone or wearable or chip card) before sending that instruction to the merchant terminal. It’s pretty universal these days that a Secure Element will have a private key store and APIs for instructing the SE to sign a data object.
But I don’t see that Apple has ruled this put. Your evidence that Apple Pay is not signing the payment message is that their press release (http://www.apple.com/pr/library/2014/09/09Apple-Announces-Apple-Pay.html) makes no mention of it. But that’s a non-technical piece. It does say: “a unique Device Account Number is assigned, encrypted and securely stored in the Secure Element on your iPhone or Apple Watch“. That might mean that the unique code is signed by the issuer (as in a digital certificate) and held in the SE as a digital certificate. Such a certificate could be used to support a signed payment instruction. At least that’s the way I would do it!
I actually think the Apple Pay SE must digitally sign the data sent to the merchant. My understanding is is that the PayWave and similar NFC protocols digitally sign the data; therefore if Apple Pay works with unmodified standard NFC merchant terminals, the terminals will be expecting signed data to be received from the customer’s device. If they’re using a special symmetric key integrity check as you fear, then wouldn’t that necessitate new key management firmware in all the terminals?
Steve Wilson, Lockstep Technologies.
Thank you for your comment. I’ve looked in some detail at the EMV specifications and I think you are right: Apple Pay does produce an asymmetric signature that is verified by the terminal. It also produces a symmetric signature, that is verified by the issuing bank. If you are interested, there are more details in a follow-up post. Any further comments would of course be very welcome.