# NFC Payments PQC: ISO 14443 Direction **Source**: https://quantumsequrity.com/blog/nfc-payments-pqc **Category**: Industry & Use Cases --- [← Back to Blog](../../blog.html) Industry & Use Cases # NFC Payments PQC: ISO 14443 Direction 11 min read Tap-to-pay has changed how most of the world handles small transactions. The basic interaction is so fast that users barely notice it: hold the card or phone within a few centimeters of the terminal, wait for the beep, walk away. Behind that one-second exchange is a stack of standards that have been refined over more than two decades, with cryptographic protections that work in the harsh constraints of contactless interfaces (very short range, very limited power, very limited time). Now those cryptographic protections are facing the post-quantum migration question, and the answer is more complicated than for any other industry covered in this series. The core wireline standard is ISO/IEC 14443, which defines the radio frequency layer for proximity contactless smart cards. The payment-specific layer is the EMVCo Contactless Specification (formally the EMV Contactless Specifications for Payment Systems). The NFC Forum specifies the consumer-grade NFC technology used in phones and other devices. All three of these specifications converge in the contactless payment terminal, and all three have to evolve to support post-quantum cryptography. ## What Happens in a Tap A contactless payment transaction takes about 500 milliseconds end to end. During that time: 1. The terminal generates an electromagnetic field that powers the card 2. ISO 14443 type A or type B activation establishes a low-level radio link 3. The card or phone responds with its application identifier 4. The terminal selects the payment application (EMV) 5. Cryptographic challenge-response authenticates the card 6. Transaction data is exchanged 7. The terminal evaluates the result and approves or declines The cryptographic step is where the public-key algorithms live. EMV uses RSA for offline data authentication (verifying that the card is genuine without contacting the issuer) and ECDSA in newer specifications. The session keys for transaction data integrity are derived from the master key on the card, which is protected by the issuer's PKI. Every one of these cryptographic surfaces is potentially vulnerable to quantum attack. EMVCo has been working with the payment industry on a PQC migration roadmap since around 2022. ## ISO/IEC 14443 and Its Constraints ISO/IEC 14443 is a four-part standard: - Part 1: Physical characteristics - Part 2: Radio frequency power and signal interface - Part 3: Initialization and anticollision - Part 4: Transmission protocol It does not define cryptography. The crypto is in the application layer (EMV, government ID, transit, etc.) that runs over ISO 14443. But ISO 14443 imposes constraints that affect crypto choices: - Short range (typically 4 to 10 centimeters) - Bidirectional communication at 106 to 848 kbps - Power harvested from the terminal field (limits card compute) - Total transaction time on the order of hundreds of milliseconds For PQC, these constraints matter. ML-KEM and ML-DSA implementations exist for smart card processors but are slower than RSA or ECC operations. The bandwidth available in a 500-millisecond contactless window is roughly 50 KB at 848 kbps; in practice, useful payload is much smaller after protocol overhead. ## EMV Offline Data Authentication EMV defines several authentication mechanisms: - **SDA (Static Data Authentication)**: Card holds a static signature over its public data, signed by the issuer's RSA key. Terminal verifies the signature offline. - **DDA (Dynamic Data Authentication)**: Card has its own RSA key pair. Terminal sends a random challenge; card signs it. Terminal verifies offline. - **CDA (Combined DDA + Application Cryptogram)**: Combines DDA with the application cryptogram for unified authentication. All three use RSA today. The keys range from RSA-1024 (deprecated) to RSA-4096 (current new deployments). Quantum computers running Shor's algorithm break RSA at any size with sufficient qubits. EMVCo's PQC migration direction is to evolve these mechanisms to use ML-DSA. The challenge is that EMV chip cards have very limited storage and compute. ML-DSA-65 public keys are about 2 KB and signatures are about 3.3 KB. RSA-2048 public keys are 256 bytes and signatures are 256 bytes. The ratio is roughly 10:1. This affects card storage (multiple application instances on a single card), key management on the issuer side, and bandwidth during the transaction. For a deeper dive on EMV chip cards specifically, see [EMV chip cards PQC](emv-chip-cards-pqc.html). ## Online Transaction Authentication Most contactless transactions go online: the terminal submits the transaction data to the issuer in real time and gets an authorization decision back. The card-to-terminal-to-issuer path uses additional cryptography: - Application Cryptogram (ARQC) generated by the card using its master key - TLS connection from terminal to acquirer - Acquirer-to-issuer authorization message (often ISO 8583 over private networks or VPNs) - Issuer authorizes and returns ARPC (response cryptogram) to the card The ARQC and ARPC are symmetric (3DES or AES-CMAC), so they are quantum-resistant in the relevant sense. The TLS connection from terminal to acquirer migrates as part of the broader TLS PQC migration. The card's master key derivation from the issuer-shared secret is also symmetric. The PQC priority is therefore the offline authentication path (SDA/DDA/CDA) and the issuer's PKI that signs the cards. ## NFC Forum and Tag Authentication The NFC Forum defines the consumer NFC standards used in phones, tags, and similar devices. NFC Type 4 tags (which run a smart card-style protocol) overlap heavily with ISO 14443 and EMV. For tag authentication, NFC Forum has been adding signature support to its newer tag specifications. The Signature Record Type Definition allows NDEF (NFC Data Exchange Format) messages to be signed, with signature algorithms including ECDSA and RSA. For PQC, the NFC Forum is following the broader migration. New tag specifications are adding hooks for ML-DSA and SLH-DSA signatures. The bandwidth concern is real for low-cost passive tags, which have very limited memory; ML-DSA signatures are too large for typical tag storage. ## Tap-to-Pay on Phones Mobile payment platforms (Apple Pay, Google Pay, Samsung Pay) emulate EMV cards via the phone's NFC controller and a secure element (or in newer architectures, a Trusted Execution Environment). The cryptographic flows are similar to physical EMV cards but with some differences: - Token Service Providers (TSPs) issue payment tokens that the phone uses instead of the actual card number - Tokens have shorter lifetimes than physical card numbers - Phones can update their cryptographic configuration via OS updates The phone-based architecture is actually more amenable to PQC migration than physical cards because: - Storage is plentiful on modern phones - Compute is plentiful (Apple A-series, Snapdragon, Exynos) - Cryptographic libraries can be updated via OS patches - Tokens can be rotated to new cryptographic schemes more easily than physical cards can This means that mobile contactless payments may migrate to PQC before physical card EMV migrates. The TSPs (Visa Token Service, Mastercard Digital Enablement Service, etc.) will issue tokens with PQC-aware cryptographic profiles for compatible terminals. For more on the algorithmic background, see [ML-KEM explained](ml-kem-explained.html). ## Terminal Key Management The contactless terminal has its own cryptographic surface. Terminals store working keys for processing transactions, and those keys are loaded via a secure key injection process from the acquirer. Terminal Master Keys (TMK) protect the working keys at rest. PCI PIN Security Requirements and PCI P2PE specifications govern how terminal keys are managed. The current cryptography is AES (symmetric) with RSA-based key wrapping for the loading process. PQC migration affects the RSA wrapping and the certificate infrastructure that authenticates terminals to the key injection facility. For more on the broader terminal cryptography, see [POS systems PQC](pos-systems-pqc.html). ## Hybrid Mode for Contactless Payments Like every other PQC migration, contactless payments will go through a hybrid phase. New cards will support both classical (RSA/ECDSA) and post-quantum (ML-DSA) authentication. Terminals will negotiate based on what each card and terminal support. The negotiation is constrained by the contactless time budget. The terminal has roughly 500 milliseconds for the entire transaction. Negotiating capabilities and falling back gracefully has to fit within that budget without making the user wait. EMVCo is working on the protocol details. The current direction is to add new cryptographic profile identifiers to the EMV application data, so that the terminal can detect PQC capability during the initial application selection and adapt accordingly. For more on the hybrid approach, see [hybrid encryption](hybrid-encryption.html). ## Transit and Mass Transit Cards Transit cards (London Oyster, Tokyo Pasmo, NYC OMNY, etc.) use ISO 14443 with their own cryptographic schemes, sometimes proprietary, sometimes based on EMV. Many transit operators are migrating to "open loop" payments where users tap a regular contactless credit card or phone instead of a transit-specific card. For PQC, transit migration follows EMV migration. Open-loop systems get PQC support when EMV cards and terminals get PQC support. Closed-loop transit cards have their own migration timelines depending on the operator's PKI. ## Government ID and PKI National ID cards (Estonia eID, Belgian eID, German Personalausweis, etc.) use ISO 14443 for contactless presentation and have their own PKI for identity certificates. These PKIs typically use RSA-2048 or ECDSA P-256 today. Some governments are ahead of the payment industry on PQC. Estonia, Singapore, and a few others have announced PQC migration plans for government ID. The driver is the long lifetime of identity records: an identity certificate issued today might be queried for verification 20 years from now, well after Q-day. ## Wearables and Payment Rings A growing category of contactless payment devices are wearables: smart rings, watches, fitness bands, and similar. These devices typically tokenize cards via the same TSP infrastructure as phones, then present the tokenized card via NFC at the terminal. For PQC, wearables follow the mobile wallet migration timeline. The TSP issues tokens with PQC-aware cryptographic profiles when the wearable hardware supports it. The wearable presents the token via NFC to the terminal, and the terminal does standard EMV processing. The constraint with wearables is that they tend to have smaller secure elements with less storage than phones. This limits how many active token profiles can be loaded simultaneously and may require trade-offs between PQC certificate storage and other features. ## Loyalty, Transit, and Multi-Application Cards Many contactless cards run multiple applications: a payment application (EMV), a loyalty application, a transit application, and possibly an identity application. These coexist on the same chip, often in different applets within a Java Card runtime. For PQC, the migration is application-by-application. The EMV applet upgrades to PQC on its own timeline. The transit applet has its own timeline tied to the transit operator's PKI. Loyalty applets often follow the EMV applet's lead because they share infrastructure with the payment system. Coordinating PQC migration across all these applets within the limited storage of a single chip is a meaningful operational challenge for card issuers. The pattern emerging in the industry is to prioritize EMV PQC first, with secondary applications migrating later as their respective ecosystems become PQC-aware. ## Frequently Asked Questions **Is my contactless card vulnerable to quantum attack right now?** The card itself is not at risk in any practical sense today. Quantum computers capable of breaking RSA-2048 do not exist yet. The harvest-now-decrypt-later concern is theoretical for contactless transactions because most transactions are short and ephemeral. The bigger issue is the issuer PKI that authenticates many cards over many years. **Will I need a new card when PQC arrives?** Eventually. New cards will be issued with PQC-capable EMV applications. Existing cards continue to work with classical EMV. The migration matches the natural card replacement cycle (typically 3 to 5 years). **Does my phone support PQC for tap-to-pay?** Not yet for the EMV side. Apple Pay, Google Pay, and Samsung Pay are tracking the EMVCo PQC roadmap. As the TSPs add PQC support, the phone payment apps will follow. Realistic deployment is 2027 to 2029. **What about ATM withdrawals?** ATM withdrawals use the same EMV stack as point-of-sale, with additional protections for PIN entry. PQC migration applies similarly. The PIN itself is processed with symmetric cryptography (AES-based PIN block formats) which is quantum-resistant. **Is the 500 millisecond budget actually a problem for PQC?** For ML-DSA verification on modern smart card chips, a single signature verification takes 5 to 30 milliseconds depending on the chip. This fits in the budget but reduces headroom for other transaction work. EMVCo is evaluating optimized profiles that minimize the cryptographic work in the contactless path. ## Sources - ISO/IEC 14443, "Cards and security devices for personal identification - Contactless proximity objects", https://www.iso.org/standard/74973.html - EMVCo Contactless Specifications, https://www.emvco.com/specifications/contactless/ - NFC Forum Technical Specifications, https://nfc-forum.org/our-work/specification-releases/ - NIST FIPS 203, "Module-Lattice-Based Key-Encapsulation Mechanism Standard", https://csrc.nist.gov/pubs/fips/203/final - NIST FIPS 204, "Module-Lattice-Based Digital Signature Standard", https://csrc.nist.gov/pubs/fips/204/final - PCI PIN Security Requirements, https://www.pcisecuritystandards.org/document_library/?category=pinsecurity ## Related Articles - [What is Post-Quantum Cryptography?](what-is-post-quantum-cryptography.html) - [PQC for Financial Services](pqc-financial-services.html) - [Hybrid Encryption](hybrid-encryption.html) - [ML-KEM Explained](ml-kem-explained.html) - [Harvest Now Decrypt Later](harvest-now-decrypt-later.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)