More is Less: Extra Features in Contactless Payments Break Security
Tom Chothia and George Pavlides discuss how proprietary, uncoordinated features built on top of the core EMV specification by companies like Apple, Google, Square, Visa, and Mastercard lead to significant security vulnerabilities. They detail how these "black box" additions create subtle interactions and mismatches, enabling attacks that bypass authentication, allow high-value fraudulent offline transactions, and leave merchants vulnerable to significant financial loss.
The EMV contactless payment system, governed by a massive 15-book specification, is complicated by the fact that the various stakeholders—payment providers, terminal companies, smartphone companies, and banks—have independently implemented their own proprietary features. These uncoordinated, “black box” additions overload the core EMV specification, leading to subtle interactions and mismatches that create significant security vulnerabilities.
The Core EMV Protocol
The EMV protocol is a complex, multi-stage process. When a card or phone is tapped on a reader, a transaction is initiated.
- Online Transactions: The card and the bank share a unique cryptographic key. The card generates a Message Authentication Code (MAC) over the transaction data (amount, currency, date, etc.). This MAC is sent to the reader and then to the bank. The bank verifies the MAC, checks the balance, and performs fraud checks before authorizing the payment. Readers themselves are unauthenticated.
- Offline Transactions: For offline payments, the reader cannot verify the bank’s MAC. Instead, the card provides a digital signature that the reader can verify. The protocol also uses a Terminal Transaction Qualifiers (TTQ) field, which communicates a risk profile (e.g., high vs. low amount, user authenticated via Face ID) rather than a specific currency amount, to handle global currencies.
Vulnerability 1: Bypassing Locked iPhones with Apple Pay & Visa
A feature in transport systems like the London Underground allows users to tap their phones without unlocking them with Face ID or Touch ID for speed. This “transport mode” is not part of the official EMV specification.
- Reverse Engineering: By sniffing the wireless communication, it was discovered that Apple uses a proprietary handshake with “mystery bytes” (later found in a patent as “Apple Advanced Polling”) to start the payment app in a sandboxed mode, bypassing the lock screen.
- The Attack: A man-in-the-middle attack was devised. The attacker’s reader broadcasts these “magic bytes” to a locked iPhone. The attacker requests a high-value transaction (e.g., £1000) but manipulates the TTQ risk profile sent to the phone, lying that it’s a low-value transit transaction. The phone, believing it’s a legitimate transit payment, generates the payment authorization. The attacker then manipulates the phone’s response to the merchant’s reader, changing it to say that Face ID authentication was successfully performed. Since merchant readers operate online, they don’t check the offline signature (which would have revealed the lie), and the transaction is approved by the bank, which trusts the (faked) Face ID authentication.
- Disclosure: This attack remains live on iPhones configured with a Visa card for transport mode. Apple and Visa did not take responsibility, with each pointing to the other. This highlighted a critical issue: “Apple did not know how Visa’s back-end checks worked and Visa did not know how Apple transport mode worked.”
Vulnerability 2: Bypassing Square’s Offline Mobile-Only Check
Square implemented an offline terminal that, according to its business rules, was intended to accept payments only from mobile wallets (Apple Pay, Google Pay), not physical cards.
- The Bypass: The EMV spec provides no standard way to distinguish a phone from a card. It was discovered that Square used initial messages from the VAST protocol (meant for loyalty cards) to perform this check. Mobile devices respond correctly, while physical cards return an error. By acting as a man-in-the-middle, an attacker can simply use a physical card and replay a legitimate VAST response, tricking the terminal into proceeding with the transaction.
- The Attack: This bypass enabled a more severe attack on Mastercard. Mastercard’s system performs the check for cardholder verification (e.g., PIN) on its back-end server. By tricking a Mastercard card into an offline transaction with the Square terminal, the back-end check is never reached, allowing for high-value, unauthenticated offline transactions.
Vulnerability 3: Exploiting a Flawed Fix and Non-Compliance
After disclosure, Square implemented a fix based on the researchers’ recommendation. However, the new firmware introduced a different vulnerability.
- The Flawed Fix: The updated terminal began advertising a misleading TTQ flag typically used by transport terminals. Google Pay, in another proprietary decision, relied solely on this TTQ value to activate its own unauthenticated transport mode. This allowed for high-value unauthenticated transactions on locked phones using Google Pay with a Visa card.
- The Cloned Card Attack: The update also caused the terminal to stop verifying the offline digital signature (SDAD) for Visa transactions. Square stated this was a deliberate choice to support certain non-compliant US Visa cards that don’t generate a signature for that specific TTQ. This allowed the researchers to build a card emulator with sniffed Visa certificates and fake messages. Using this fabricated card, they successfully performed a £25,000 offline transaction. While this transaction was ultimately rejected when the terminal went online, the attack is still highly effective as the attacker would have already left with the goods, leaving the merchant out of pocket.
Conclusion
The primary takeaway is that the security of the EMV ecosystem is being undermined by proprietary, uncoordinated features built on top of the public specification. When stakeholders implement features in a “black box” manner without consulting others, they create unforeseen interactions that lead to critical vulnerabilities. Hiding specifications does not improve security; it obscures flaws and prevents collaborative defense. Formally verified fixes are necessary to address these complex, inter-dependent systems.