🛡️ EMV and card security

The EMV standard

EMV (Europay, Mastercard, Visa; now managed by EMVCo, owned in equal shares by six schemes) is the global standard for chip payment cards. Its core idea is to replace the static magnetic stripe data, which can be copied endlessly, with a dynamic cryptographic exchange between the chip, the terminal, and the issuer that makes every transaction unique and impossible to forge. France rolled out chip cards across the board before other markets, and fraud on in-person payments there has become marginal.

An EMV contact transaction runs through standardized steps: application selection (choosing the AID, such as A0000000421010 for CB), reading the card data, offline data authentication (SDA/DDA/CDA), cardholder verification (CVM), and terminal risk management (floor limits, random selection). The last step is cryptogram generation (GENERATE AC), which carries the chip’s decision: request online authorization (ARQC), approve offline (TC), or decline (AAC).

ARQC and ARPC: the cryptographic core

The ARQC (Authorization Request Cryptogram) is a MAC the chip computes with a session key, derived from the card’s master key, which is itself derived from the issuer master key. The calculation covers the critical transaction data: amount, currency, date, ATC counter, the terminal’s unpredictable number (UN), verification results (TVR), and more. The issuer, which holds the same keys, recomputes the ARQC. If the two values match, the transaction came from the genuine card and its data was not altered in transit. The issuer then responds with an ARPC, a response cryptogram that the card verifies in turn. Each side thus authenticates the other.

9F26 08 A1B2C3D4E5F60718   ARQC (8 bytes) - the cryptogram itself
9F27 01 80                  CID: 80 = ARQC (online authorization request)
9F36 02 014A                ATC: chip transaction counter (= 330)
95   05 0000008000          TVR: terminal check results
9F37 04 1A2B3C4D            UN: terminal unpredictable number (anti-replay)
9F02 06 000000012550        authorized amount: 125.50
5F2A 02 0978                currency: EUR
9A   03 260711              transaction date: 2026-07-11
9F10 12 0110A00003220000... IAD: issuer discretionary data (CVR...)
82   02 3900                AIP: card capabilities (DDA, CDA...)

CVM: verifying the cardholder

The CVM (Cardholder Verification Method) is the method used in a given transaction to verify that the person presenting the card is its legitimate holder. The card carries a CVM list, ranked by preference and subject to conditions (amount, terminal type). The terminal runs the first applicable method it supports.

• The CVM list is signed within the offline authentication data: a fraudster cannot quietly downgrade it on a properly verified DDA/CDA card.
• The verification result is recorded in the CVR/TVR and reaches the issuer in the IAD; an issuer can decline a no-CVM transaction above its own thresholds.
• In France, three wrong PINs in a row block the chip (response code 75); the card keeps the counter, and the issuer resets it.

SDA, DDA, CDA: authenticating the card offline

Offline data authentication (ODA) verifies that the card is genuine without contacting the issuer. It underpins offline transactions (in-flight, tolls, below authorization floor limits) and fast contactless payments. The standard includes three generations, and the first is no longer allowed for new card issuance.

The chain of trust rests on a three-tier PKI. The public keys of the schemes’ certificate authorities (CAs) are loaded into terminals; they certify issuer public keys, which in turn certify card public keys. Revoking CA keys, through rotations scheduled by EMVCo, is a recurring task for acquirers and for companies that maintain POS terminal fleets.

Contactless: kernels and mobile tokenization

The kernel is the terminal software that runs the EMV contactless exchange with the card. Historically, each scheme specified its own. The standard has eight kernels, which makes POS terminal certification complex. A French terminal must carry several and pick the right one based on the card’s AID. EMVCo has published Kernel 8, a generic, next-generation kernel (elliptic-curve cryptography, secure channel) meant to gradually replace the proprietary kernels.

Mobile payments (Apple Pay, Google Pay) add network tokenization on top of contactless. The real PAN is replaced by a DPAN, a device token stored in the Secure Element or via HCE. Every payment generates a dynamic cryptogram, and neither the merchant nor its PSP ever sees the original card number.

PCI DSS: protecting card data

PCI DSS (Payment Card Industry Data Security Standard) is the security standard the schemes contractually impose on anyone who stores, processes, or transmits card data. Version 4.0.1 is in force, and its future-dated requirements have applied since March 2025. Twelve requirements (firewalls, encryption, access management, logging, testing, policies, and more) break down into hundreds of controls, with validation levels scaled to volume.

• Reduce scope before securing it: PSP iframe/redirect + tokenization ⇒ SAQ A instead of SAQ D; it is the most cost-effective architecture decision you can make.
• PCI DSS v4 tightens e-commerce requirements: inventory and integrity of payment page scripts (requirements 6.4.3 and 11.6.1), a direct response to Magecart attacks.
• Compliance is annual and ongoing: after an incident, the acquirer can hold an expired AOC against the merchant.

End-to-end encryption, skimming, and countermeasures

Between the chip and the back office, card data passes through links that can be attacked: the read head, terminal memory, the store network, and servers. P2PE/E2EE (point-to-point encryption) encrypts the PAN as soon as it is read, inside the terminal’s secure module (SRED). Only the processor holds the decryption key. An attacker who compromises the POS system or the network sees only ciphertext, and the merchant’s PCI scope shrinks dramatically (SAQ P2PE).