In an earlier post I raised concerns about the security of Apple Pay based on the scant information provided in Apple’s press release. In a comment on that post, Brendon Wilson pointed out that Apple Pay must be using standard EMV with Tokenization rather than a new payment protocol, because it works with existing terminals. After looking in some detail at the EMV specifications, I tried to explain in my last post how Apple Pay could be implemented without departing from the specifications. As part of that explanation, I conjectured that an Apple Pay device may be using both a symmetric signature verified by the issuer and an asymmetric signature verified by the merchant’s terminal. That would eliminate one of the security concerns in my original post. In his comment, Brendon also referred to a MacRumors blog post that provided new details on how Apple Pay is used with Apple Watch. In this post I’d like to recap my remaining concerns on the security of Apple Pay for in-store transactions. (I don’t have enough information yet to discuss web transactions.)
The security design of Apple Pay is secret. This is a weakness in and of itself. Submitting security designs to public scrutiny has been a standard best practice for decades. Without public scrutiny, security flaws will not be caught by friendly researchers, but may be found by adversaries who have enough to gain from reverse-engineering the design and exploiting the flaws that they find.
Insecurity of Touch ID
When Apple Pay is used on the iPhone, the user has to authenticate to the phone for each transaction. This is a good thing, but authentication relies on Touch ID, which only provides security against casual attackers.
Shortly after the introduction of Touch ID, it was shown that it is possible to lift a fingerprint from the iPhone itself, use the fingerprint to make fake skin reproducing the fingerprint ridges, place the fake skin on a finger, and use the finger with the fake skin to authenticate with Touch ID. Three different techniques for making the fake skin were reported, two of them here, a third one here.
Relay attacks against Apple Pay on Apple Watch
Apple’s press release touts the security provided by Touch ID, but adds that Apple Pay will also work with Apple Watch without explaining how the customer will authenticate to Apple Watch, which does not have a fingerprint sensor, and can be used with the iPhone 5 and 5c, which do not have fingerprint sensors either.
A MacRumors blog post explains that the user will authenticate with a PIN, and remain authenticated while the watch detects continuing skin contact using sensors on the back of the watch. The user has to reenter the PIN after contact is interrupted.
A PIN is more secure than Touch ID as long as either the watch or a chip within the watch provide sufficient tamper resistance to protect the hash of the PIN which may be used to verify the hash. (If an adversary who captures the watch is able to extract the hash, then he or she can easily crack the PIN by a brute-force offline attack.) But the scheme described by MacRumors is vulnerable to a relay attack.
A relay attack involves two attackers, a first attacker located near a merchant’s contactless terminal, and a second attacker located near an unwitting customer, whom we shall refer to as the victim. The first attacker has an NFC device that interacts with the terminal, and the second attacker has an NFC device that interacts with the victim’s contactless card or mobile device, masquerading as a terminal. The attackers’ devices communicate with each other using a fast link, relaying data between the terminal and the victim’s device. The first attacker can thus make a purchase and have it charged to the victim’s card or device. The attack does not work if a customer has to authenticate by performing some action such as entering a PIN or touching a sensor, but it works if all a customer needs to do is put his or her device within NFC reach of the terminal, as is the case for Apple Pay on Apple Watch.
A relay attack was demonstrated by Gerhard Hancke in 2005, who claimed it was an easy attack against ISO 14443A cards and terminals. More recently, a different kind of relay attack was demonstrated by Michael Roland against Google Wallet. In Roland’s attack, the second attacker was replaced with malware running on the victim’s Android phone. Google countered the attack by restricting access from the main operating system of the phone to the NFC chip containing the payment credentials. (It would be interesting to check if Host Card Emulation happens to reenable the attack.) Google’s countermeasure, however, only prevents the attacker-plus-malware attack, not the two-attacker attack.
Lack of customer ID verification
Tokenization means that merchants will not be able to verify the identity of their customers. This is good for customer privacy, but leaves merchants defenseless against criminals who steal phones and defeat Touch ID, and against relay attacks on Apple Watch. Millions of smart phones are stolen every year in the US alone, and once Touch ID can be used for payments, criminal organizations will no doubt perfect the Touch ID hacking techniques originally developed by researchers.
3 thoughts on “Security Weaknesses of Apple Pay for In-Store Transactions”
Does anyone know, how touch id is exeactely used for the EMV payment?
As far as I know, there is no fingerprint option in EMV.
Does the fingerprint activate a pre entered and cached pin?
As I explain in the next post, I now believe that Apple Pay follows the EMV Contactless Specifications, which are a substantial departure from the EMV 4.3 specifications. The contactless specifications make a distinction between transactions made with a mobile phone and transactions made with a card. In transactions made with a phone, the point-of-sale (POS) may delegate customer verification to the phone. For MasterCard transactions, this is explained in Section 3.8 of book C-2. The phone indicates to the POS that customer verification has succeeded by setting bit b5 of Byte 2 of the POS Cardholder Interaction Information data object, described in Section A.1.116 of book C-2. Bit b5 is labeled “Offline PIN verification successful”, but there is no reason why the phone cannot use a fingerprint for authentication instead of a PIN.
Paypass does not support offline pin, which is verified on the secure element.
But there is a “on device cardholder verification” where the secure element is not involved.
I therefore suppose that the touch id verification is performed according to the latter (like the pin by google wallet).