Summary of "How Secure Is Tap To Pay?"

Summary — How Tap-to-Pay can be abused (technology, demo, risks, mitigations)

What happened (demo)

Researchers performed a live exploit against a locked iPhone using Tap to Pay while Marques Brownlee (MKBHD) and others observed.
Transactions from small ($5) to very large ($10,000) were shown to be approved without unlocking the phone or any user verification.
Setup and devices used:
- Proxmark NFC device to emulate/intercept the reader.
- Laptop running a Python script to modify messages.
- Burner phone to forward modified messages to the real payment terminal.
- This is a classic man-in-the-middle (MITM) relay: the proxmark and burner phone sit between the victim phone and the terminal.

How the attack works (technical steps)

Tap-to-Pay (EMV contactless) terminals and phones exchange transaction messages via NFC. Many of these messages are unencrypted for compatibility and can be intercepted and altered. Researchers inserted themselves between the phone and the reader and relayed/modified messages:

The proxmark impersonates a reader to the phone and forwards messages to the laptop.
The laptop modifies specific transaction bits and forwards them to a burner phone.
The burner phone taps the real terminal; the terminal thinks it’s talking to the phone, and the phone thinks it’s talking to the terminal.

To trick both sides the attackers falsified three specific fields (three “lies”):

Transit/offline bit — make the phone believe the reader is a transit terminal (Express Transit Mode) so the phone won’t require unlocking.
High/low value bit — flip the “high value” flag to indicate a low-value transaction so the phone won’t demand customer verification (PIN/fingerprint).
Customer verification result bit — flip the phone’s response to tell the reader the transaction was verified by the user, so the reader will accept and forward the transaction to the bank.

Why this works for some devices/cards and not others

Device differences:
- Apple iPhones (Express Transit Mode) rely on a reader‑provided label (low/high) rather than the numeric amount; this makes them susceptible to being told a transaction is low-value or transit.
- Samsung phones use the numeric amount and will reject absurd transit charges, making this attack harder on those devices.
Network/scheme differences:
- All card schemes use symmetric cryptography (card ↔ bank) to produce a transaction code checked by the bank — this is used in every transaction.
- Mastercard requires an additional asymmetric signature (card signs transaction; reader verifies) on all transactions. That asymmetric check would detect tampering and block this attack.
- Visa does not require the asymmetric card-to-reader signature in all online retail transactions (it is used in some offline/transit cases). In the exploit, the phone is tricked into sending a signature intended for transit/offline, but the real reader is online and doesn’t check that signature. That inconsistency allows the tampered messages to pass.
Practical implication:
- The exploit requires a specific combination: iPhone + Visa card placed in the transit slot (Express Transit enabled). Equipment and know-how used were sophisticated, but attackers could acquire targeting information and perform similar fraud with more accessible tools.

Cryptography explained briefly

Symmetric cryptography (card + bank): the card and bank share a secret and produce a transaction code from it; the bank verifies that code. This protects transaction integrity between card and issuer.
Asymmetric cryptography (card private key / reader public key): the card signs transaction data with a private key; the reader can verify the signature with the corresponding public key without revealing the private key. This allows the reader to detect tampering between card and terminal. Mastercard enforces such asymmetric checks more consistently, while Visa’s conditional use creates the loophole exploited.

Practical risk, scope, and history

The research group publicly disclosed this method in 2021; the flaw remains exploitable in certain real-world setups.
Visa’s stated position: large-scale exploitation is unlikely and cardholders are protected by zero-liability and dispute/refund processes.
Real impacts for victims can still be significant: stolen phones, proximity attacks (someone walking past and relaying a tap), the stress and delay of disputed refunds, and potential financial/identity consequences even if refunds are eventually issued.

Mitigations and practical guidance

Immediate user actions:

Turn off Express Transit Mode or remove/avoid placing a Visa card in the transit slot of Apple Wallet.
Monitor bank/card statements and report suspicious charges immediately so dispute/fraud processes can start.

Longer-term / industry mitigations:

Require consistent asymmetric checks between cards and readers to prevent undetected tampering.
Update protocols to protect critical bits (high/low value, transit/offline, customer verification result) from being spoofed or altered in transit.
Note: coordinating changes across devices, terminals, and card networks is complex and slow.

Additional notes

Demonstration showed approved amounts ranging from $5 up to $10,000.
The hack depends on the unencrypted, interoperable messaging required across many devices.
A sponsor/ad (Incogni — privacy/data removal service) appears in the demo video.

Main speakers / sources

Marques Brownlee (MKBHD) — victim/demonstration participant
Henry — presenter involved in the demo
Professors Ioana Boureanu and Tom Chothia — cybersecurity researchers (University of Surrey) who developed/demonstrated the hack
Apple — provided a written comment attributing the issue to Visa’s system
Visa — provided comments about likelihood, detection, and zero‑liability policy