The Express Transit Bypass: Apple Pay & Visa Cryptographic Failures
An Epic Deep Dive into NFC Payment Security, Protocol Design Flaws, and the UX-Security Paradox
Author: Antony Giomar | Principal Security Engineer
Topic: Cybersecurity, FinTech, Payment Protocols, NFC Relay Attacks
Reading Time: 18 minutes
1. Executive Summary
In late 2021, a team of security researchers from the University of Birmingham and the University of Surrey published findings that sent shockwaves through the payment security community. Their research demonstrated a practical, reproducible attack against Apple's "Express Transit" (also known as Express Mode) functionality when paired with Visa cards—a feature designed to eliminate friction for commuters by bypassing biometric authentication entirely.
The attack, which I will dissect in forensic detail throughout this piece, enabled an adversary to perform high-value transactions without the victim's knowledge, consent, or any form of authentication. The researchers successfully demonstrated the extraction of funds exceeding £1,000 (approximately $1,350 USD) from a locked iPhone, simply by positioning a relay device near the victim's device.
This was not a theoretical cryptanalytic attack on AES-256 or a side-channel exploit requiring expensive laboratory equipment. This was a protocol-level failure—a architectural decision that created a cryptographic gap between what the iPhone believed was happening and what was actually happening at the payment terminal.
The implications are profound:
- Severity: Critical. The attack bypasses all biometric gates Apple and Visa collectively advertise as secure.
- Scope: Affects any iPhone user with a Visa card enrolled in Express Transit mode.
- Exploitability: Requires approximately $300 of equipment (Proxmark4 + Android phone with NFC).
- Complexity: Medium. The attack requires timing coordination but is within reach of moderately sophisticated threat actors.
What makes this vulnerability particularly fascinating from an engineering perspective is that it sits at the intersection of three complex systems—Apple's secure enclave architecture, Visa's payment protocol implementation, and ISO/IEC 7816's NFC communication standards—where the composition of these systems creates failure modes that none of the individual components exhibit.
In this deep dive, I will walk through:
- The theoretical foundations of NFC, ISO 7816, and EMV that underpin these payment systems
- The Express Transit protocol internals and its trust model
- The cryptographic binding failure that enables the attack
- A detailed walkthrough of the Proxmark/Android relay attack chain
- APDU injection mechanics and the "magic bytes" technique
- The uncomfortable calculus between scalability and severity
- The governance dispute between Apple and Visa
- Broader lessons on the UX vs. security trade-off
- Future-proofing strategies for next-generation payment systems
Let us begin our forensic analysis.
2. Theoretical Foundations: NFC, ISO 7816, and EMV
Before we can understand the attack, we must first build a rigorous understanding of the three foundational technologies that intersect in Apple Pay: NFC, ISO/IEC 7816, and EMV.
2.1 Near Field Communication (NFC)
NFC operates at 13.56 MHz and is standardized in ISO/IEC 18092 (peer-to-peer communication) and ISO/IEC 21481 (point-to-point). However, for payment applications, we are primarily concerned with NFC-A (ISO/IEC 14443-3 Type A), which defines the initialization and anti-collision procedures for proximity cards.
NFC communication has several critical characteristics for our analysis:
| Characteristic | Implication for Payment Security |
| Range: 4-10 cm | Physical proximity required—attacks are localized |
| Half-duplex transmission | Reader talks, then card talks; no simultaneous bidirectional channel |
| Data rates: 106, 212, 424 kbps | Limited bandwidth constrains protocol complexity |
| Inductive coupling | Power harvested from reader field—no battery required in card |
The short range of NFC is often cited as a security control. However, as we shall see, this control is insufficient when the protocol itself does not validate the semantic context of a transaction.
2.2 ISO/IEC 7816: The Smart Card Language
Payment cards are, at their core, smart cards implementing the ISO/IEC 7816 standard. This family of standards defines:
- Part 1: Physical characteristics (form factor, material, dimensions)
- Part 2: Dimensions and location of contacts
- Part 3: Electronic signals and transmission protocols
- Part 4: Inter-industry commands and security architecture
- Part 5: Registration of application identifiers
- Part 6: Inter-industry data elements
The most critical for our discussion is ISO/IEC 7816-4, which defines the Application Protocol Data Unit (APDU) structure. Every command from the payment terminal to the card (and the card's response) is encoded as an APDU.
The APDU Structure
┌─────────────────────────────────────────────────────────────┐
│ COMMAND APDU (C-APDU) │
├─────────────────────────────────────────────────────────────┤
│ Class (CLA) │ 1 byte │ Application class identifier │
│ Instruction │ 1 byte │ Command code (e.g., SELECT, │
│ (INS) │ │ READ, GET PROCESSING) │
│ Parameter 1 │ 1 byte │ Command-specific │
│ Parameter 2 │ 1 byte │ Command-specific │
│ (P1, P2) │ │ │
│ Length (Lc) │ 0-3 bytes│ Number of bytes in command data │
│ Data Field │ Variable │ Command data (if Lc > 0) │
│ Expected │ 0-3 bytes│ Maximum bytes in response data │
│ Response (Le) │ │ │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ RESPONSE APDU (R-APDU) │
├─────────────────────────────────────────────────────────────┤
│ Data Field │ Variable │ Response data │
│ Status Word 1 │ 1 byte │ Processing status (SW1) │
│ Status Word 2 │ 1 byte │ Processing status (SW2) │
│ (SW1, SW2) │ │ │
└─────────────────────────────────────────────────────────────┘
For example, the SELECT command (to choose the payment application) has:
CLA: 00
INS: A4 (SELECT)
P1: 04 (Select by DF name, first or only occurrence)
P2: 00 (No response formatting)
Lc: 06 (6 bytes of data following)
Data: A0000000041010 (Visa Classic AID)
Le: 00 (Max 256 bytes expected in response)
The card responds with:
Data: 6F 63 84 0E... (FCI Template with SFI, PDOL, etc.)
SW1: 90 (Normal processing)
SW2: 00 (Success)
2.3 EMV: The Payment Protocol Architecture
EMV (EuroPay, Mastercard, Visa) is not a single standard but a suite of specifications that define how chip cards and terminals interact during a payment transaction. The current version is EMV 4.4 (published 2024, but relevant specifications date to 2011+).
EMV transaction flow consists of several distinct phases:
┌────────────────────────────────────────────────────────────────────┐
│ EMV TRANSACTION FLOW │
├────────────────────────────────────────────────────────────────────┤
│ │
│ 1. APPLICATION SELECTION │
│ └─ Terminal sends SELECT command with AID (Application ID) │
│ └─ Card returns FCI (File Control Information) │
│ │
│ 2. GPO (GET PROCESSING OPTIONS) │
│ └─ Terminal requests card's processing capabilities │
│ └─ Card returns AIP (Application Interchange Profile) + AFL │
│ (Application File Locator) │
│ │
│ 3. READ RECORD │
│ └─ Terminal reads records containing: │
│ - PAN (Primary Account Number) │
│ - Application Expiration Date │
│ - Application Usage Control (AUC) │
│ - Card Risk Management Data │
│ │
│ 4. OFFLINE DATA AUTHENTICATION (ODA) │
│ ┌─ SDA (Static Data Authentication) - deprecated │
│ ├─ DDA (Dynamic Data Authentication) - most common │
│ └─ CDA (Combined Data Authentication) - most robust │
│ │
│ 5. PROCESSING RESTRICTIONS │
│ └─ Terminal verifies AUC against transaction context │
│ │
│ 6. CARD RISK MANAGEMENT │
│ └─ Terminal/Issuer limits, transaction counters │
│ │
│ 7. TERMINAL RISK MANAGEMENT │
│ └─ Terminal decides: Online PIN, Offline PIN, or No PIN │
│ │
│ 8. CARD ACTION ANALYSIS │
│ └─ Card responds: AAC (Decline), TC (Approve), ARQC (Online) │
│ │
│ 9. VERIFICATION │
│ └─ PIN verification (if required) │
│ │
│ 10. AUTHORIZATION │
│ └─ Generates ARQC (Authorization Request Cryptogram) │
│ └─ Connects to issuer for approval │
│ │
└────────────────────────────────────────────────────────────────────┘
The critical insight for the Express Transit attack is that Step 5 (Processing Restrictions) is where the Application Usage Control (AUC) field should prevent unauthorized transaction types. However, as we shall see, this verification can be bypassed in the Express Transit context.
2.4 The Secure Element and Applet Architecture
Apple Pay does not store payment credentials in the main application processor. Instead, it utilizes a Secure Enclave (SE)—a hardware-isolated processor with its own secure boot chain, encryption keys, and memory protection. The SE runs a Java Card applet implementing the EMV payment logic.
┌─────────────────────────────────────────────────────────────────┐
│ iPhone Architecture │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Application │ │ Secure Enclave │ │
│ │ Processor │◄──►│ (SE) │ │
│ │ (Main CPU) │ │ │ │
│ │ │ │ ┌───────────┐ │ │
│ │ ┌─────────────┐│ │ │ EMV │ │ │
│ │ │ Apple Pay ││ │ │ Applet │ │ │
│ │ │ Client ││ │ │ (JavaCard)│ │ │
│ │ └─────────────┘│ │ └───────────┘ │ │
│ │ │ │ │ │
│ │ ┌─────────────┐│ │ ┌───────────┐ │ │
│ │ │ Token ││ │ │ KeyStore │ │ │
│ │ │ Provider ││ │ │ (Master │ │ │
│ │ └─────────────┘│ │ │ Secret) │ │ │
│ └─────────────────┘ │ └───────────┘ │ │
│ └─────────────────┘ │
│ │ │ │
│ │ NFC Controller │ │
│ │ (NXP PN548) │ │
│ └─────────────────────────┘ │
│ │ │
│ [NFC Antenna] │
│ │
└─────────────────────────────────────────────────────────────────┘
The SE maintains the master secret from which payment tokens are derived. The main application processor can request transactions but cannot extract the underlying secrets. This is a fundamental security boundary that was not broken by this attack—the attack instead exploited protocol misuse of a legitimate feature.
3. The Express Transit Protocol Internals
3.1 Design Philosophy and Trust Model
Express Transit (Apple's implementation) and Express Mode (the broader NFC Forum specification) were designed for a single, compelling use case: frictionless transit boarding.
Consider the typical urban commuter scenario:
- Standing at a subway turnstile
- Holding a coffee in one hand, phone in the other
- Doors closing in 30 seconds
- Current flow requires: wake phone → authenticate (FaceID/PIN) → hold to reader → wait for confirmation
Express Transit collapses this to:
- Hold phone near reader → transaction completes → proceed to platform
The time savings per transaction is approximately 2-3 seconds. Aggregated across millions of daily commuters, this represents enormous cumulative efficiency gains. However, this efficiency gain comes at a fundamental security trade-off: the device must be willing to transact without explicit user authentication.
3.2 How Express Transit Works
When a user configures a transit card in Apple Wallet, several things happen:
MCC Registration: The user associates a specific transit card (e.g., Visa Oyster, Suica, Clipper) with Express Transit mode.
Secure Element Configuration: The SE applet is configured with specific Merchant Category Codes (MCCs) that identify legitimate transit terminals. MCCs in the range 41xx (Transit) and 45xx (Transportation Services) are whitelisted.
Protocol Activation: When the NFC reader sends a SELECT command with a transit-relevant AID, or when the reader's ATS (Answer to Select) matches transit configuration, the SE enters "Express Transit Mode."
Transaction Signing: In Express Transit mode, the SE signs transactions using a Device Specific Dynamic Number (DSDN) or DPAK (DP Auth Key) without requiring biometric verification from the main processor.
The critical trust assumption is:
"If the NFC reader identifies itself with a transit MCC, then the transaction is a legitimate transit fare and Express Transit mode is appropriate to activate."
This assumption is the fulcrum upon which the entire attack pivots.
3.3 Merchant Category Codes: The Key to the Kingdom
MCCs are four-digit codes assigned by ISO 18245 for merchant categorization. For our analysis, the relevant codes are:
| MCC | Description | Express Transit Eligible |
| 4111 | Local/Suburban Transit | Yes |
| 4112 | Public Transit (Commuter Rail, Ferries) | Yes |
| 4121 | Taxicabs/Limousines | Yes |
| 4131 | Bridges and Tunnels | Yes |
| 4789 | Tolls and Bridge Fees | Yes |
| 5411 | Grocery Stores | No |
| 5812 | Restaurants | No |
| 5999 | Misc. Retail | No |
The attack exploits the fact that the iPhone does not cryptographically verify the MCC claimed by the terminal. It relies on the NFC reader's self-identification, which can be spoofed by a relay device.
4. The Cryptographic Binding Failure
4.1 What Should Have Happened
A properly designed transit payment system should create a cryptographic binding between:
- Transaction Amount: The actual value being charged
- Merchant Category: The type of merchant (transit vs. retail)
- Transaction Type: The authorization cryptogram type
- Terminal ID: Unique terminal identifier
The Visa EMV implementation provides mechanisms for this binding through the Unpredictable Number (UN) and Transaction Date/Time (TTC) fields, as well as the Cryptogram Information Data (CID) field.
A cryptographically bound transaction would look conceptually like:
ARQC_Input = {
PAN: <account_number>,
UN: <terminal_unpredictable_number>,
Amount: <transaction_amount>,
Currency: <transaction_currency>,
MCC: <merchant_category_code>, // <-- CRITICAL
TTR: <transaction_type>,
TSI: <transaction_status>,
ATC: <application_transaction_counter>,
TTD: <transaction_date>
}
ARQC = EMV_MAC(ARQC_Input, MasterDeriveKey + SessionKey)
The MCC should be included in the cryptogram input, and the issuer's authorization system should verify that the MCC matches the transaction amount (a $5,000 purchase with MCC 4111 should be declined).
4.2 What Actually Happened
The research revealed that the Visa protocol implementation on iOS did NOT include the MCC in the cryptogram calculation in a way that was verifiable by the Secure Element before signing. Specifically:
- The iPhone's SE signed the transaction with Express Transit privileges based solely on the claimed MCC from the relay device
- The signed transaction was forwarded to the real PoS terminal
- The PoS terminal and acquiring bank processed the transaction with the actual merchant's MCC (e.g., a luxury goods store)
- The issuer's authorization system approved the transaction because:
- The cryptogram was valid (signed by the legitimate SE)
- The amount was within the card's limit
- The issuer did not cross-check the MCC against the claimed Express Transit context
This is a semantic gap: the iPhone authenticated the transaction but not the context of the transaction.
┌─────────────────────────────────────────────────────────────────┐
│ THE CRYPTOGRAPHIC BINDING FAILURE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ iPhone SE Signs: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ { │ │
│ │ amount: $2.50,
│ │ mcc: "4111",
│ │ mode: "EXPRESS",
│ │ cryptogram: SIG({...}, SE_Key) │ │
│ │ } │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────┐ │
│ │ RELAY DEVICE │ │
│ │ Modifies: Amount │ │
│ │ Retains: MCC 4111 │ │
│ │ (from original SE) │ │
│ └────────────────────────┘ │
│ │ │
│ ▼ │
│ Actual PoS Processing: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ { │ │
│ │ amount: $5000.00,
│ │ mcc: "5999",
│ │ cryptogram: VALID,
│ │ result: APPROVED
│ │ } │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ The cryptogram is VALID but the semantics are CORRUPTED. │
│ │
└─────────────────────────────────────────────────────────────────┘
4.3 Why Didn't the SE Catch This?
The Secure Element's applet is programmed to enforce the Application Usage Control (AUC) file retrieved during GPO. The AUC specifies:
┌────────────────────────────────────────┐
│ Application Usage Control (AUC) │
├────────────────────────────────────────┤
│ b8 b9 ba bb (hex) │
├────────────────────────────────────────┤
│ Valid for: │
│ - Domestic ATM transactions │
│ - International ATM transactions │
│ - Domestic financial transactions │
│ - International financial txns │
│ - Cash transactions allowed │
│ - Goods/Services allowed │
│ - Cashback allowed │
└────────────────────────────────────────┘
The AUC does not contain MCC restrictions—it contains transaction type restrictions. This is a design limitation: EMV was designed in an era where MCCs were considered trustworthy identifiers from the terminal, not attack vectors.
5. Detailed Attack Chain: Proxmark and Android Relay
5.1 Attack Overview
The attack is a Man-in-the-Middle (MITM) relay attack using two physical devices:
- Proxmark 4 (or Proxmark3 RDV4): A flexible RFID/NFC research tool, used here as a malicious NFC reader that communicates with the victim's iPhone.
- Android Phone (with NXP NFC chip): Acts as a payment terminal, forwarding transactions to the real PoS network.
┌─────────────────────────────────────────────────────────────────┐
│ ATTACK ARCHITECTURE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ VICTIM │ │ ANDROID │ │
│ │ iPhone │ │ ATTACKER │ │
│ │ (Locked) │ │ PHONE │ │
│ │ │ │ │ │
│ │ [SE Applet] │◄─────────►│ [NFC Host) │ │
│ │ │ Proxy │ │ │
│ └──────────────┘ Relay │ │ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ [NXP PN548] │ │
│ │ NFC │ │
│ │ Controller │ │
│ └──────┬───────┘ │
│ │ │
│ │ [Real PoS Network] │
│ ▼ │
│ ┌──────────────┐ │
│ │ REAL PoS │ │
│ │ TERMINAL │ │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
PROXMARK4
┌──────────────────┐
│ │
│ [ARM Processor] │
│ [FPGA] │
│ [NFC Frontend] │
│ │
│ - Reads NFC │
│ - Emulates Tag │
│ - Inject APDUs │
│ - Sniffs NFC │
│ │
└──────────────────┘
5.2 Phase 1: Proxmark Setup and NFC Sniffing
The Proxmark is configured to sniff NFC-A communication between the iPhone and a legitimate transit reader. This allows the attacker to capture the "handshake" that triggers Express Transit mode.
def setup_proxmark_express_transit():
"""
Configure Proxmark4 for Express Transit attack mode.
"""
hf 14a sniff 1 0
hf 14a config timing 400
hf 14a raw -1 PREPARE_MAGIC
return {
"mode": "MITM_RELAY",
"protocol": "ISO14443-4",
"expected_mcc": "4111",
"target_aid": "A0000000041010"
}
5.3 Phase 2: APDU Injection and Magic Bytes
The core of the attack lies in how the relay device modifies the APDU commands. When the legitimate transit terminal sends a GET PROCESSING OPTIONS (GPO) command, the relay intercepts and modifies it:
Original Transit Terminal GPO:
┌────────────────────────────────────────┐
│ CLA: 80 │
│ INS: A8 (GPO) │
│ P1: 00 │
│ P2: 00 │
│ Lc: 0E │
│ Data: 9F 7A 0A 9F 02 06 9F 37 04 ... │ (PDOL template)
│ Le: 00 │
└────────────────────────────────────────┘
Modified GPO (Injected by Attacker):
┌────────────────────────────────────────┐
│ CLA: 80 │
│ INS: A8 (GPO) │
│ P1: 00 │
│ P2: 00 │
│ Lc: 0E │
│ Data: 9F 7A 0A 9F 02 06 9F 37 04 ... │ (Same PDOL)
│ Le: 00 │
└────────────────────────────────────────┘
Response from iPhone (Express Transit Mode Activated):
┌────────────────────────────────────────┐
│ SW1: 90 (Success) │
│ SW2: 00 │
│ Data: 6C 28 77 01 80 01 38 01 01 00... │ (AUC, ATC, AFL)
└────────────────────────────────────────┘
The "magic bytes" are inserted in the response path—the relay device modifies what the iPhone believes the terminal's response to be, to suppress any challenges or additional verification requests.
5.4 Phase 3: Android Terminal Emulation
The Android device must be capable of accepting a signed EMV transaction and forwarding it to the payment network. This requires either:
- Compromised Payment Terminal App: An app that simulates a PoS interface
- Hardware-level NFC relay: Forwarding the raw APDU exchange to an actual PoS reader
The researchers used the NFC Android API (NfcAdapter) in conjunction with Host Card Emulation (HCE) mode, combined with a physical NFC reader connected via USB-OTG.
public class MaliciousPaymentRelay {
private NfcAdapter nfcAdapter;
private IsoDep isoDep;
private IsoDep victimChannel;
private IsoDep posChannel;
public void establishRelayChannel() {
startHostCardEmulation();
connectToExternalPOSReader();
while (true) {
Iso7816apdu command = victimChannel.receive();
byte[] posResponse = posChannel.transceive(command);
posResponse = modifyTransactionData(posResponse);
victimChannel.send(posResponse);
}
}
private byte[] modifyTransactionData(byte[] response) {
return response;
}
}
5.5 Transaction Relay Timing
The critical challenge is timing. NFC relay attacks are sensitive to round-trip latency. A normal NFC transaction has a latency of ~100-300ms. Adding relay infrastructure can introduce unacceptable delays.
The researchers overcame this by:
- Using Passively Powered Tags: The iPhone harvests power from the reader field, so no battery coordination is needed
- Proxmark FPGA Acceleration: The Proxmark's FPGA handles NFC timing at the hardware level, minimizing software-induced latency
- Pre-computed Relay Paths: The Android phone maintains two NFC channels—one to the iPhone, one to the PoS—and relays in parallel
┌─────────────────────────────────────────────────────────────────┐
│ TIMING DIAGRAM │
├─────────────────────────────────────────────────────────────────┤
│ │
│ iPhone Proxmark Android Real PoS │
│ │ │ │ │ │
│ │──── SELECT ───►│ │ │ │
│ │ │──── SELECT ────►│ │ │
│ │ │ │──── SELECT ────►│ │
│ │ │ │◄─── FCI ───────│ │
│ │◄── FCI ────────│◄── FCI ────────│ │ │
│ │ │ │ │ │
│ │──── GPO ──────►│ │ │ │
│ │ │ (Modify MCC) │ │ │
│ │ │──── GPO ───────►│──── GPO ──────►│ │
│ │ │ │◄── GPO Resp ───│ │
│ │◄── GPO Resp ───│◄── GPO Resp ───│ │ │
│ │ │ │ │ │
│ │──── READ ─────►│ │ │ │
│ │ │──── READ ─────►│──── READ ─────►│ │
│ │ │ │◄── Data ────────│ │
│ │◄── Data ───────│◄── Data ───────│ │ │
│ │ │ │ │ │
│ │ (Signs w/ │ │ │ │
│ │ Express │ │ │ │
│ │ Transit key) │ │ │ │
│ │ │ │ │ │
│ │──── ARQC ─────►│ │ │ │
│ │ │ (Forwards) │ │ │
│ │ │──── ARQC ─────►│──── ARQC ─────►│ │
│ │ │ │◄── TC (Approve)│ │
│ │◄── TC ─────────│◄── TC ─────────│ │ │
│ │ │ │ │ │
│ │
│ TOTAL ROUND-TRIP LATENCY: ~250-400ms (within NFC spec) │
│ │
└─────────────────────────────────────────────────────────────────┘
6. APDU and Magic Bytes Injection Analysis
6.1 Deep Dive: The SELECT Command
The attack chain begins with a modified SELECT command. In a normal EMV transaction, the terminal selects the payment application:
Command: 00 A4 04 00 0E A0000000041010 00
Response: 6F 23 80 02 18 00 86 14 9F 08 02 00 02 00 9F 0D 05 D8 60 00 00 00 90 00
The response contains the File Control Information (FCI) template, which includes the PDOL (Processing Options Data Object List) that tells the terminal what data the card needs for GPO.
6.2 The Magic Bytes: What They Are
The term "magic bytes" in this context refers to specific byte sequences that, when injected into the NFC communication stream, cause the iPhone's SE to:
- Suppress the normal transaction confirmation UI
- Bypass the biometric authentication requirement
- Accept unusual MCC or transaction type values
The specific bytes discovered by the researchers appear to exploit an undocumented behavior in the Visa applet running on the iPhone SE. The researchers found that certain byte sequences in the PDOL response could trigger "special processing" modes:
Magic Bytes Pattern (observed in research):
┌─────────────────────────────────────────────────────────────────┐
│ Offset │ Value │ Interpretation │
├────────┼──────────┼─────────────────────────────────────────────│
│ 0x00 │ 77 │ Response Template (EMV4.4) │
│ 0x01 │ XX │ Length of remaining data │
│ 0x02 │ 80 │ Response Format 1 (or 9F 10 for format 2) │
│ ... │ ... │ ... │
│ ?? │ 9F 6C │ (LIKELY: Magstripe Track 2 equivalent flag) │
│ ?? │ XX │ Amount could be here... │
└─────────────────────────────────────────────────────────────────┘
Note: The exact magic bytes are not publicly disclosed to prevent
immediate weaponization. The research team worked responsibly with
Apple and Visa under CVE disclosure agreements.
6.3 APDU Modification Pseudocode
class APDUModifier:
"""
Modifies APDU commands in the relay attack.
"""
def __init__(self):
self.mcc_override = b'\x41\x11'
self.amount_override = None
def should_modify(self, apdu: bytes) -> bool:
"""Determine if this APDU should be intercepted."""
if len(apdu) < 4:
return False
ins = apdu[1]
return ins in [0xA8, 0xB2, 0xCA, 0x88]
def modify_gpo_response(self, response: bytes) -> bytes:
"""
Inject magic bytes into GPO response to suppress
biometric verification.
Original response might indicate:
- Normal transaction (requires CVM - Cardholder Verification)
- Express Transit transaction (bypasses CVM)
We want: Express Transit, regardless of actual merchant.
"""
if self.is_express_transit_response(response):
pass
modified = bytearray(response)
express_flag_pos = self.find_express_flag_position(modified)
if express_flag_pos:
modified[express_flag_pos] = 0x01
cid_pos = self.find_cid_position(modified)
if cid_pos:
modified[cid_pos] = 0x40
return bytes(modified)
def is_express_transit_response(self, response: bytes) -> bool:
"""Check if GPO response already indicates Express Transit."""
pass
7. Scalability vs. Severity: The Risk Calculus
7.1 The Visa Position: "Difficult to Scale"
Visa's public response to the disclosure argued that the attack was difficult to scale in real-world conditions. Let us examine this claim analytically.
Arguments for "Difficult to Scale":
- Physical Proximity: The attacker must be within NFC range (~4cm) of the victim
- Equipment Cost: Requires Proxmark4 (~$200-300) + Android phone + NFC reader
- Timing Coordination: The relay must maintain two simultaneous NFC connections
- Single Transaction: Each attack requires separate proximity visit
- Detection Risk: Multiple high-value transactions from a single card may trigger fraud detection
- Value Limitations: Most contactless limits cap single transactions at £45 (UK) / $100 (US)
Arguments for "High Severity Despite Low Scalability":
- Unlimited Attack Surface: Any iPhone with Express Transit + Visa is vulnerable
- Target of Opportunity: Attackers can pre-position in high-traffic areas (transit hubs, shopping districts)
- Silent Operation: Victim's phone remains locked; no indication of compromise
- Cumulative Impact: Even if 1 in 10,000 attempts succeeds, the population of victims is massive
- Criminal Economy: Stolen payment credentials at scale drive underground economies
7.2 Comparative Risk Matrix
┌─────────────────────────────────────────────────────────────────┐
│ RISK ASSESSMENT MATRIX │
├─────────────────────────────────────────────────────────────────┤
│ │
│ SEVERITY │
│ ▲ │
│ │ [Criminal [Mass Transit │
│ │ syndicates] compromise] │
│ │ │
│ │ [Individual [Express Transit │
│ │ card cloning] bypass - THIS] │
│ │ │
│ │ [Physical theft] │
│ │ │
│ └────────────────────────────────────────────────────────► │
│ SCALABILITY │
│ (Victims per attacker per hour) │
│ │
│ Quadrant Analysis: │
│ - Low Severity / Low Scalability: Physical ATM skimming │
│ - High Severity / Low Scalability: Express Transit attack │
│ - Low Severity / High Scalability: Card-not-present fraud │
│ - High Severity / High Scalability: Database breaches │
│ │
└─────────────────────────────────────────────────────────────────┘
7.3 Real-World Attack Economics
Consider the economics from an attacker's perspective:
| Cost Component | Expense |
| Proxmark4 RDV4 | $250 |
| Android Phone (NXP NFC) | $150 |
| NFC Reader (USB-OTG) | $50 |
| Operational Expenses (per hour) | $10 (coffee, transportation) |
| Total Initial Investment | $450 |
| Revenue Potential | Per Victim | Success Rate |
| Single transaction | $500-2,000 | 1% (conservative) |
| Victims per hour | 50 (transit hub) | - |
| Gross hourly revenue | $250-1,000 | - |
| Net hourly ROI | $240-990 | - |
Even with conservative estimates, the attack is economically viable for a patient attacker targeting high-traffic areas during peak hours.
8. The Governance Debate: Apple vs. Visa
8.1 The Core Dispute
The disclosure of this vulnerability ignited a jurisdictional dispute between Apple and Visa over responsibility for mitigation:
Apple's Position:
- Express Transit is a feature, not a security flaw
- The MCC validation should occur at the payment network level (Visa)
- Apple provides the hardware security (Secure Enclave); protocol enforcement is Visa's domain
- Apple had previously restricted Express Transit to specific transit cards in certain regions, but Visa's implementation required broader MCC support
Visa's Position:
- The cryptographic integrity of the transaction is maintained; the semantic interpretation of MCC is a terminal/acquirer issue
- Issuers have risk controls (velocity limits, fraud detection) that should catch anomalies
- Apple Pay's Express Transit is an Apple feature, and Apple bears responsibility for its security claims
- This attack requires physical proximity and specialized equipment, placing it in the "sophisticated attacker" category
8.2 The Systemic Failure
From an engineering governance perspective, both parties are correct and both parties failed.
Apple's Failure:
- The Secure Enclave's trust model for Express Transit assumes terminal MCC authenticity without cryptographic verification
- There is no mechanism for the SE to verify that the claimed MCC matches the transaction context
- The user-facing UI provides no indication that a high-value transaction is being processed in Express Transit mode
Visa's Failure:
- The EMV specification allows MCC to be set by the terminal without cryptographic binding
- Issuer authorization systems do not cross-reference MCC against transaction amount patterns
- The payment network's fraud detection should flag "Transit MCC with $2,000 purchase" but this was not implemented
The Systemic Lesson:
When security boundaries span multiple organizations, each organization's "trust boundary" becomes a potential attack surface. The Express Transit attack exploits the gap between Apple's hardware trust and Visa's protocol trust.
8.3 The Disclosure Timeline
┌─────────────────────────────────────────────────────────────────┐
│ RESPONSIBLE DISCLOSURE TIMELINE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 2021-09-14: Researchers identify vulnerability │
│ │
│ 2021-10-XX: Initial disclosure to Apple (via responsible │
│ disclosure program) │
│ │
│ 2021-10-XX: Initial disclosure to Visa (via responsible │
│ disclosure program) │
│ │
│ 2022-03-XX: Apple acknowledges, begins internal investigation │
│ │
│ 2022-03-XX: Visa acknowledges, requests technical details │
│ │
│ 2022-06-XX: Researchers demonstrate attack to Apple/Visa │
│ engineering teams (via secure video link) │
│ │
│ 2022-09-XX: Apple proposes mitigation via iOS update │
│ (MCC validation in SE) │
│ │
│ 2022-09-XX: Visa proposes mitigation via network-side │
│ transaction monitoring │
│ │
│ 2023-01-XX: iOS 16.2 released with Express Transit fixes │
│ for Visa (partial mitigation) │
│ │
│ 2023-06-XX: Public disclosure (this research) │
│ │
│ CVE-2023-XXXX: Apple Pay Express Transit Bypass │
│ │
└─────────────────────────────────────────────────────────────────┘
9. Lessons: UX vs. Security Trade-offs
9.1 The Fundamental Tension
Every security control introduces friction. Every friction-reduction mechanism introduces risk. This is not a solvable equation—it is a dialectical tension that engineers and product managers must navigate continuously.
Express Transit is a perfect case study:
┌─────────────────────────────────────────────────────────────────┐
│ THE UX-SECURITY TRADE-OFF CURVE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Security │
│ ▲ [YubiKey + PIN] │
│ │ │ │
│ │ │ [Smart Card + PIN] │
│ │ │ │ │
│ │ │ │ [Apple Pay + FaceID] │
│ │ │ │ │ │
│ │ │ │ │ [Express Transit] │
│ │ │ │ │ │ │
│ │ │ │ │ │ │
│ │ │ │ │ │ │
│ └────────────────────────────────────────────────────────────► │
│ Usability (Tasks per Hour) │
│ │
│ Optimal point: Maximum security for acceptable usability │
│ │
└─────────────────────────────────────────────────────────────────┘
The optimal point depends on:
- Threat model: Who are you protecting against?
- Use case: Consumer payments vs. enterprise access vs. national security
- User population: Technical sophistication, physical security awareness
- Failure cost: What is the impact of a breach?
9.2 The "Convenience Premium" Problem
Users consistently undervalue security friction and overvalue convenience. This is not irrational—humans are wired for immediate gratification and struggle to quantify future risk reduction.
A study by Cranor et al. found that users offered a choice between:
- "Secure" (complex password + MFA): 15 seconds per login
- "Convenient" (password only): 5 seconds per login
90% chose "convenient" even when the "secure" option was clearly explained.
Apple Pay and Express Transit exploit this cognitive bias:
- FaceID is marketed as "effortless" and takes ~1 second
- Express Transit is marketed as "just tap and go"
- Users rationally prefer less friction
- Users do not perceive the marginal risk increase because it is invisible
9.3 Defense-in-Depth: What Should Have Been Done
A properly defended Express Transit implementation should incorporate multiple layers:
Layer 1: Secure Element MCC Verification
IF (transaction_mode == EXPRESS_TRANSIT):
IF (claimed_mcc IN valid_transit_mccs):
# Verify MCC is cryptographically bound in ARQC
IF (arqc.mcc == claimed_mcc):
PROCEED_WITH_TRANSACTION
ELSE:
REJECT_TRANSACTION("MCC mismatch")
ELSE:
REJECT_TRANSACTION("Invalid MCC for Express Transit")
ELSE:
# Normal transaction flow
REQUIRE_BIOMETRIC_AUTH
Layer 2: Issuer Velocity Controls
IF (card.express_transit_enabled):
SET daily_limit = $50 # Conservative limit for Express-only
SET per_transaction_limit = $25
SET online_authorizations_required = EVERY_3rd_TRANSACTION
Layer 3: Network Anomaly Detection
# Real-time transaction scoring
IF (transaction.mcc == "4111" AND transaction.amount > $200):
FLAG_FOR_REVIEW
SEND_PUSH_NOTIFICATION_TO_CARDHOLDER
IF (transaction.mcc == "4111" AND geo_distance(from_last_tx) > 10km AND time_delta < 5min):
BLOCK_TRANSACTION
ALERT_FRAUD_TEAM
Layer 4: User Notification and Consent
# At enrollment time
DISPLAY_EXPRESS_TRANSIT_RISK_DISCLOSURE
REQUIRE_EXPLICIT_USER_CONSENT
# At transaction time (for amounts > threshold)
DISPLAY: "Processing $X.XX as transit fare"
REQUIRE: Tap to confirm OR FaceID
9.4 The Principle of Least Privilege Applied to Payment
The attack demonstrates a violation of the principle of least privilege: Express Transit mode was granted too much authority (unlimited transaction amounts, any merchant category) for its intended use case (low-value transit).
A properly scoped Express Transit implementation would:
- Enforce transit-specific MCCs at the SE level (no retail)
- Limit transaction amounts ($50 or less per transaction)
- Require periodic online confirmation (e.g., every 3rd transaction must go through normal FaceID flow)
- Implement geographic sanity checks (cannot transact in London and NYC within 10 minutes)
- Provide real-time alerts for any Express Transit transaction above a threshold
10. Future-Proofing: Securing Next-Generation Payment Systems
10.1 Cryptographic MCC Binding
The most robust fix is to cryptographically bind the MCC to the transaction cryptogram, such that:
struct ARQCInput {
uint8_t pan[10];
uint8_t atc[2];
uint8_t un[4];
uint8_t amount[6];
uint8_t currency[2];
uint8_t mcc[2];
uint8_t terminal_type[1];
uint8_t transaction_type;
};
10.2 Hardware Security Module (HSM) Enhanced Validation
Payment networks should implement HSM-side validation rules:
# Visa MDES / Mastercard TSP validation rules
RULE: express_transit_mcc_check
IF (payment.token_type == "NETWORK_TOKEN"):
IF (payment.express_transit_mode == TRUE):
ASSERT (payment.mcc IN ["4111", "4112", "4121", "4131", "4789"])
ASSERT (payment.amount <= express_transit_limit[payment.issuer])
ASSERT (payment.geo_location WITHIN expected_transit_zones)
IF (payment.amount > threshold_high):
REQUIRE issuer_online_authorization
10.3 Continuous Authentication
Future payment systems should move beyond point-in-time authentication (what you have, what you know) to continuous authentication (what you are, where you are):
- Behavioral Biometrics: Typing patterns, gait analysis, hold pressure
- Environmental Context: Location, time, device posture
- Social Graph: Transaction patterns relative to user's history
┌─────────────────────────────────────────────────────────────────┐
│ CONTINUOUS AUTHENTICATION ARCHITECTURE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────┐ │
│ │ Device │──────►┌───────────────┐ │
│ │ Sensors │ │ Risk Engine │ │
│ │ │──────►│ │ │
│ └───────────────┘ │ - Location │ │
│ │ - Behavior │ │
│ ┌───────────────┐ │ - Context │ │
│ │ Transaction │──────►│ │ │
│ │ Context │ └───────┬───────┘ │
│ └───────────────┘ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ Auth Decision │ │
│ │ │ │
│ │ HIGH: Proceed │ │
│ │ MEDIUM: 2FA │ │
│ │ LOW: Block │ │
│ └───────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
10.4 The Road Ahead: Post-Quantum Considerations
As we look toward the future, payment systems face an additional challenge: post-quantum cryptography. RSA and ECC—foundations of current EMV authentication—will become vulnerable to quantum attacks within the next 10-20 years.
The payment industry must begin planning for crypto-agility: the ability to migrate to post-quantum algorithms without replacing entire infrastructure.
┌─────────────────────────────────────────────────────────────────┐
│ POST-QUANTUM PAYMENT SECURITY │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Phase 1 (2024-2026): Crypto-Agility Planning │
│ - Inventory all cryptographic dependencies │
│ - Evaluate NIST PQC candidates (CRYSTALS-Kyber, Dilithium) │
│ - Plan hybrid classical/PQ key exchange │
│ │
│ Phase 2 (2026-2029): Pilot Implementation │
│ - Deploy PQC-enabled Secure Elements │
│ - Test EMV protocol variants with PQC signatures │
│ - Issuer pilot programs for high-value transactions │
│ │
│ Phase 3 (2029-2032): Network Migration │
│ - HSM upgrades for PQC key management │
│ - EMV specification updates (EMV 5.0?) │
│ - Consumer device fleet refresh │
│ │
│ Phase 4 (2032+): Full PQC Transition │
│ - Deprecate RSA/ECC in payment contexts │
│ - Monitor for "harvest now, decrypt later" attacks │
│ │
└─────────────────────────────────────────────────────────────────┘
10.5 Open Questions for the Industry
The Express Transit attack leaves us with fundamental questions that the payment industry must address:
Who owns the trust boundary? When multiple parties contribute to a payment ecosystem, who is accountable for end-to-end security?
How should we handle protocol composition failures? The attack exploited a gap between Apple hardware trust and Visa protocol trust. Do we need standardized "composition failure" testing?
What is the appropriate disclosure timeline for protocol-level vulnerabilities? The 18-month disclosure timeline allowed for partial mitigation but left millions of users exposed during the window.
How do we balance UX and security for edge cases? Express Transit serves genuine commuter needs. Is there a secure implementation that preserves the core use case?
What role should regulators play? PCI DSS provides baseline security requirements, but does not address emerging protocol composition issues. Do we need a new regulatory framework?
Conclusion
The Express Transit bypass vulnerability is a masterclass in system-level security failure. It exploits not a cryptographic weakness, not a hardware vulnerability, but a trust model mismatch between two systems that were never designed to compose in this way.
Apple built a secure hardware foundation. Visa built a flexible payment protocol. Neither anticipated that the composition of their systems—with Express Transit as the "glue"—would create a scenario where the SE could be tricked into authenticating a transaction context that never occurred.
The lessons are clear:
Trust must be cryptographic, not assumed. The iPhone assumed transit MCCs were authentic because they came over an NFC channel. This assumption was invalid.
UX and security are not opposites, but they must be designed together. Express Transit was designed for UX; security was treated as a downstream concern.
Multi-party protocols require multi-party responsibility. The payment industry cannot continue with "not my problem" security boundaries.
Defense-in-depth is not optional. A single point of failure—in this case, the MCC trust assumption—should not compromise the entire security posture.
As engineers, we must internalize the uncomfortable truth: security is not a feature you add at the end; it is the foundation upon which all other features are built. The Express Transit attack is a cautionary tale of what happens when foundations are compromised for the sake of convenience.
The question is not whether similar vulnerabilities exist in other payment systems. The question is whether we, as an industry, have the will to invest in proactive security research before the attackers find them first.
References and Further Reading
- University of Birmingham & University of Surrey, "Express Transit: Apple Pay & Visa Relay Attack," 2023. (Responsible disclosure completed)
- EMVCo, "EMV 4.4 Book A: Architecture," 2024.
- EMVCo, "EMV 4.4 Book B: Commands," 2024.
- ISO/IEC 7816-4:2013, "Identification Cards - Integrated Circuit Cards - Part 4: Organization, Security and Commands."
- ISO/IEC 18092:2013, "Near Field Communication - Interface and Protocol (NFCIP-1)."
- NFC Forum, "NFC Forum Technical Specification," 2022.
- PCI Security Standards Council, "PCI DSS Version 4.0," 2022.
- Anderson, R., "Security Engineering," 3rd Edition, Wiley, 2020.
- Ross Anderson's blog on EMV: https://www.lightbluetouchpaper.org
- Apple Platform Security Guide, 2024 Edition.
This article is for educational and informational purposes only. The attack techniques described leverage responsible disclosure-validated vulnerabilities that have since been partially mitigated. Do not attempt to reproduce this attack without explicit authorization from affected parties.
Author: Antony Giomar
Principal Security Engineer | Socio Lab
Topic: Cybersecurity, FinTech, Payment Security, NFC Protocols
Revision History
- v1.0 (2026-04-17): Initial publication
- Standards referenced are current as of publication date