EMV is four protocols chained together — and formal verification still finds gaps

contact@corebaseit.com (Vincent Bevia) — Thu, 06 Aug 2026 13:00:00 +0200

EMV is often treated as a solved security problem. Billions of cards, decades of deployment, and strong cryptography create the impression that the protocol is fundamentally sound once the crypto primitives are correct.

A 2021 IEEE Symposium on Security and Privacy paper from ETH Zurich pushes against that assumption. Basin, Sasse, and Toro-Pozo formally modeled the EMV specification — more than 2,000 pages across contact and contactless books — in the Tamarin prover and asked a different question from the usual penetration-test framing: does the protocol guarantee the authentication properties it is assumed to provide?

Their answer is nuanced. Cryptography was not the weak link. Several configurations leave security-critical decisions unauthenticated. Some of those gaps are old; some were newly exposed by exhaustive symbolic analysis; one Visa contactless gap was demonstrated on live terminals.

This post walks through that result for POS architects: the four-phase structure of an EMV exchange, what the model actually proved, where Visa and Mastercard diverge, and what “bind the business decision to the cryptogram” means in practice. The EMV mechanics below follow POINT OF SALE ARCHITECTURE (the book), Chapter 3; the attack and proof claims are from the paper unless marked as interpretation.

Claims to keep separate

Confirmed by the paper (and, where noted, by lab tests):

EMV transactions can be partitioned into four phases: initialization, Offline Data Authentication (ODA), cardholder verification (CVM), and transaction authorization.
Tamarin analysis of 40 contact and contactless configurations rediscovered known flaws and found new logical ones.
Visa contactless Card Transaction Qualifiers (CTQ, tag 9F6C) are not authenticated to the terminal or the issuer. A man-in-the-middle can clear the online-PIN-required bit and assert CDCVM, allowing high-value contactless payments without the cardholder PIN. Demonstrated with a proof-of-concept Android app on real terminals (authors’ own cards; goods paid for).
Under SDA or DDA, the Application Cryptogram (AC) is not authenticated to the terminal. An offline-approved transaction can present a modified cryptogram that the terminal accepts; the issuer rejects it later in clearing. The authors did not test this on live terminals for ethical reasons.
For contact EMV, Combined Data Authentication (CDA) with online PIN (and some CDA/no-PIN online paths) satisfied all three evaluated authentication properties. Mastercard contactless CDA configurations satisfied them; several common Visa contactless configurations did not.

Interpretation (mine, not the paper’s conclusion):

The architectural takeaway for modern stacks — API gateways, tokenization, attestation, fraud AI — is the same binding problem: a decision that changes liability or CVM must be integrity-protected with the transaction it steers.

Security is not only encryption

Payment engineering often measures security by cryptographic inventory: AES, RSA or ECC, Secure Elements, HSMs. EMV already has those. Chapter 3 of the book treats EMV as a mutual-authentication framework over the ICC, the terminal kernel, and the EMVCo specification — not as a single algorithm.

The harder question is whether every field that changes transaction behavior is covered by a signature or MAC that the relying party can check. A single unprotected qualifier can undo an otherwise sound cryptogram design.

EMV as four protocols

Basin et al. divide an EMV transaction into four phases. The book expands the same handshake into five operational stages (application selection, initialization, data acquisition, CVM, authorization). The paper’s “initialization” collapses selection, GPO, and record reading; ODA is then treated as its own protocol. Both views are useful.

The combined flow below maps those phases onto the terminal and card decision path: session setup, offline processing (ODA through terminal action analysis), the first GENERATE AC, then online completion when ARQC is returned.

flowchart TD
subgraph SETUP["Session setup"]
direction TB
ACT["Card activation
ATR and PPS, or field detect"]
SEL["Application selection
PPSE / PSE, candidate list, AID"]
GPO["Get processing options
PDOL in; AIP and AFL out"]
RR["Read record loop
CDOL1, CDOL2, CVM list, certificates"]
ACT --> SEL --> GPO --> RR
end
subgraph OFF["Offline processing"]
direction TB
ODA["Offline data authentication
CDA or DDA; sets TVR bits"]
PR["Processing restrictions
AUC, version, dates → TVR"]
CVM["Cardholder verification
CVM list loop → CVM results"]
TRM["Terminal risk management
Floor limit, velocity → TVR"]
TAA["Terminal action analysis
TVR against TAC and IAC"]
ODA --> PR --> CVM --> TRM --> TAA
end
subgraph CARD["Card decision"]
direction TB
GEN1["First generate AC
CDOL1 data"]
CRM["Card risk management
Card may only downgrade"]
GEN1 --> CRM
end
subgraph ONL["Online and completion"]
direction TB
ONLINE["Online authorisation
ARQC and IAD in field 55"]
ISSUER["Issuer processing
Checks ARQC, returns ARPC"]
NOGO["Unable to go online
Default action codes apply"]
S71["Issuer scripts, template 71"]
GEN2["Second generate AC
CDOL2 plus issuer auth data"]
ONLINE --> ISSUER --> S71 --> GEN2
ONLINE --> NOGO --> GEN2
end
APPROVE["Approved
Final TC"]
DECLINE["Declined
Final AAC"]
RR --> ODA
TAA -->|"Request TC, ARQC or AAC"| GEN1
CRM -->|TC| APPROVE
CRM -->|AAC| DECLINE
CRM -->|ARQC| ONLINE
GEN2 -->|TC| APPROVE
GEN2 -->|AAC| DECLINE
classDef purple fill:#EEEDFE,stroke:#534AB7,color:#3C3489
classDef amber fill:#FAEEDA,stroke:#BA7517,color:#633806
classDef blue fill:#E6F1FB,stroke:#185FA5,color:#0C447C
classDef green fill:#EAF3DE,stroke:#639922,color:#27500A
classDef red fill:#FCEBEB,stroke:#A32D2D,color:#791F1F
classDef gray fill:#F1EFE8,stroke:#5F5E5A,color:#444441
class ACT,SEL,GPO,RR,ODA,PR,CVM,TRM,S71 purple
class TAA,ONLINE amber
class GEN1,GEN2,ISSUER blue
class CRM purple
class NOGO gray
class APPROVE green
class DECLINE red

Click diagram to expand

Initialization — The terminal and card agree on an application (AID). The card returns capabilities and locator data, including the Application Interchange Profile (AIP, tag 82) and Application File Locator (AFL, tag 94). Contactless kernels also exchange scheme-specific qualifiers such as Terminal Transaction Qualifiers (TTQ, tag 9F66) and, for Visa, CTQ.
Offline Data Authentication (ODA) — The terminal validates card authenticity via the CAPK → issuer certificate → ICC certificate chain, then verifies SDA, DDA, or CDA depending on AIP and terminal capabilities. Chapter 3 ranks them SDA (static signature; weakest), DDA (challenge-response), CDA (dynamic signature bound to the Application Cryptogram). ODA establishes card authenticity; it does not by itself approve the transaction.
Cardholder verification (CVM) — Online PIN, offline PIN, signature, CDCVM, or no CVM, selected from the intersection of card rules, terminal capabilities, and amount limits.
Transaction authorization — Offline decline (AAC), offline approval (TC), or online authorization (ARQC → issuer ARPC → final TC/AAC). See Online vs Offline EMV Transactions and ARQC, TC, and AAC: A Field Guide to EMV Application Cryptograms.

Each phase feeds the next. A field that steers CVM or authorization without cryptographic binding becomes a protocol gap, not an implementation bug.

Offline processing is where several of those binding failures sit. ODA, processing restrictions, CVM, and terminal risk management only write TVR bits; terminal action analysis is the single place that turns those bits into a request for TC, ARQC, or AAC:

flowchart TD
ODA["Offline data authentication
CDA or DDA; sets TVR bits"]
PR["Processing restrictions
AUC, version, dates → TVR"]
CVM["Cardholder verification
CVM list loop → CVM results"]
TRM["Terminal risk management
Floor limit, velocity → TVR"]
TAA["Terminal action analysis
TVR against TAC and IAC"]
RTC["Request TC
No action code match"]
RARQC["Request ARQC
Online match"]
RAAC["Request AAC
Denial match"]
ODA --> PR --> CVM --> TRM --> TAA
TAA --> RTC
TAA --> RARQC
TAA --> RAAC
classDef purple fill:#EEEDFE,stroke:#534AB7,color:#3C3489
classDef amber fill:#FAEEDA,stroke:#BA7517,color:#633806
classDef gray fill:#F1EFE8,stroke:#5F5E5A,color:#444441
class ODA,PR,CVM,TRM purple
class TAA amber
class RTC,RARQC,RAAC gray

Click diagram to expand

What they verified

The authors modeled contact EMV and Visa/Mastercard contactless EMV in Tamarin, including concurrent sessions and an active Dolev-Yao adversary on the card–terminal channel. The bank–terminal channel was treated as secure.

Rather than asking whether a particular kernel implementation can be broken, they asked whether the protocol configurations guarantee:

Bank accepts — A transaction the terminal accepts should not be declined by the issuer solely because the Application Cryptogram is wrong.
Authentication to the terminal — When the terminal commits to a transaction, the card (and, where applicable, the bank) agree on that transaction (injective agreement).
Authentication to the bank — When the bank accepts, card and terminal agree on the authenticated transaction data.

That is a stronger evaluation bar than penetration testing alone. It also rediscovers older results (for example Murdoch et al.’s offline PIN bypass) as special cases of the same missing authentication pattern.

The Visa contactless CTQ gap

The finding that drew the most attention was Visa contactless CVM steering.

In a Visa contactless exchange, the card’s response to GET PROCESSING OPTIONS carries CTQ. CTQ tells the terminal which CVM path to take. The model showed that CTQ is authenticated neither to the terminal nor to the bank.

An attacker in the middle can therefore rewrite CTQ so that:

online PIN appears unnecessary, and
CDCVM appears to have already succeeded on the consumer device.

The practical result, demonstrated on real POS terminals with the authors’ Android relay/MITM app: a stolen Visa contactless card can complete purchases above the CVM-required limit without the victim’s PIN. The paper notes the same pattern may apply to Discover (Kernel 6) and UnionPay (Kernel 7); those were not tested.

This is the binding failure in concrete form. The cryptogram machinery can still run. The CVM decision that should have gated high-value acceptance was never integrity-protected.

Mastercard contactless configurations that use CDA verified cleanly under the same properties. That is a scheme-configuration result from the model, not a claim that Mastercard deployments are immune to every class of attack.

Offline approval and an unauthenticated cryptogram

A second class of gap appears in offline authorization under SDA or DDA.

After terminal action analysis, the first GENERATE AC carries CDOL1 data (amount, TVR, unpredictable number, and related fields). Card risk management may only downgrade the requested cryptogram — never raise it — so a TC request can become ARQC or AAC, but an AAC request cannot become a TC:

flowchart TD
GEN1["First generate AC
CDOL1: amount, TVR, unpredictable number"]
CRM["Card risk management
Card may only downgrade, never raise"]
TC["TC returned
Approve offline"]
ARQC["ARQC returned
Go online"]
AAC["AAC returned
Decline"]
GEN1 --> CRM
CRM --> TC
CRM --> ARQC
CRM --> AAC
classDef blue fill:#E6F1FB,stroke:#185FA5,color:#0C447C
classDef purple fill:#EEEDFE,stroke:#534AB7,color:#3C3489
classDef green fill:#EAF3DE,stroke:#639922,color:#27500A
classDef amber fill:#FAEEDA,stroke:#BA7517,color:#633806
classDef red fill:#FCEBEB,stroke:#A32D2D,color:#791F1F
class GEN1 blue
class CRM purple
class TC green
class ARQC amber
class AAC red

Click diagram to expand

The Application Cryptogram is a MAC under a key shared by card and issuer. The terminal does not hold that key, so it cannot independently verify the AC. With CDA, the Signed Dynamic Application Data (SDAD) binds CID, the cryptogram, transaction data, and the terminal’s unpredictable number, giving the terminal a public-key check. With SDA or DDA alone, that binding is absent.

The model therefore allows an adversary to modify the cryptogram on an offline-approved path. The terminal can still accept; the issuer later detects the bad AC in clearing, after goods or services may already have been delivered. The paper treats this as a protocol-design issue for those ODA modes. It was not demonstrated on live terminals.

Only the ARQC branch continues to online authorisation and a second GENERATE AC. Issuer scripts (template 71 before, template 72 after) and the unable-to-go-online path still settle through that second cryptogram:

flowchart TD
ONLINE["Online authorisation
ARQC and IAD sent in field 55"]
ISSUER["Issuer processing
Checks ARQC, returns ARPC"]
OFFLINE["Unable to go online
Default action codes apply"]
S71["Issuer scripts, template 71
Run before the second generate AC"]
GEN2["Second generate AC
CDOL2 plus issuer authentication data"]
S72["Issuer scripts, template 72
Run after the second generate AC"]
TC2["TC returned
Approved"]
AAC2["AAC returned
Declined"]
ONLINE --> ISSUER
ONLINE --> OFFLINE
ISSUER --> S71 --> GEN2
OFFLINE --> GEN2
GEN2 --> TC2
GEN2 --> AAC2
TC2 --> S72
AAC2 --> S72
classDef amber fill:#FAEEDA,stroke:#BA7517,color:#633806
classDef blue fill:#E6F1FB,stroke:#185FA5,color:#0C447C
classDef purple fill:#EEEDFE,stroke:#534AB7,color:#3C3489
classDef green fill:#EAF3DE,stroke:#639922,color:#27500A
classDef red fill:#FCEBEB,stroke:#A32D2D,color:#791F1F
classDef gray fill:#F1EFE8,stroke:#5F5E5A,color:#444441
class ONLINE amber
class ISSUER,GEN2 blue
class OFFLINE gray
class S71,S72 purple
class TC2 green
class AAC2 red

Click diagram to expand

For architects, the operational point matches Chapter 3 and Online vs Offline EMV: offline approval transfers risk to local rules and deferred issuer verification. If the terminal cannot authenticate the AC, “offline approved” is not the same as “issuer will honor.”

Which configurations held

The useful output of the paper is not only the attacks. It is the configuration table of what does satisfy the three properties.

Contact EMV. CDA is the ODA mode that consistently closed the gaps the model cared about. Configurations combining CDA with online PIN (and some CDA paths without PIN for online-capable runs) verified. SDA and DDA paths left AC authentication to the terminal broken, and offline-PIN paths reproduced the known CVM disagreement / PIN-bypass pattern.

Contactless. Mastercard CDA configurations (including common online-PIN and no-PIN low-value cases in the paper’s table) satisfied all evaluated properties. Visa’s only fully verified contactless line in their table was a less common DDA-for-online (high-value) setup with SDAD verification. The authors’ live-terminal sampling did not observe that Visa configuration in the field.

Their proposed Visa mitigations are mostly terminal-side (TTQ bits and mandatory SDAD checks) so cards in circulation need not be reissued. Whether networks and acquirers deployed those mitigations after 2021 is outside the paper’s scope and should be checked against current scheme contactless rules for each market.

What this means for payment system design

The paper is less about scoring Visa against Mastercard than about a design rule that survives outside EMV kernels.

Modern platforms add API gateways, tokenization, device attestation, Secure Elements, fraud models, and PCI controls. Those layers can be implemented carefully and still fail the same way EMV failed in the CTQ case: a business or risk decision influences acceptance, but that decision is not cryptographically bound to the transaction evidence the issuer or merchant later relies on.

Formal verification does not replace Level 2/3 testing, scheme certification, or red-team work on kernels and SoftPOS stacks. It answers a prior question: whether the protocol, under a given configuration, actually implies the authentication properties operators assume when they set floor limits, CVM limits, and offline TAC/IAC bits.

For POS and acquiring architects, that is the durable lesson. Prefer configurations that authenticate the fields that steer CVM and authorization — in EMV terms, prefer CDA (or scheme-equivalent dynamic binding) where offline or contactless CVM steering matters — and treat any unprotected qualifier that can rewrite “PIN required” or “already verified” as a first-class design defect.

References

Basin, D., Sasse, R., & Toro-Pozo, J. (2021). The EMV Standard: Break, Fix, Verify. 42nd IEEE Symposium on Security and Privacy (SP 2021). DOI: 10.1109/SP40001.2021.00037. Project site: emvrace.github.io.
Bevia, V. POINT OF SALE ARCHITECTURE, Chapter 3: EMV Principles — ODA (SDA/DDA/CDA), AIP/AFL, CVM, and cryptogram generation. corebaseit.com/my-books.
Murdoch, S. J., Drimer, S., Anderson, R., & Bond, M. (2010). Chip and PIN is Broken. IEEE Symposium on Security and Privacy — offline PIN response not authenticated (rediscovered in the 2021 model).
EMVCo. EMV Integrated Circuit Card Specifications for Payment Systems and EMV Contactless Specifications for Payment Systems — authoritative definitions of ODA methods, CVM, and cryptogram types.

Visa on Corebaseit — Design System Engineering · POS · Payments · Security

EMV is four protocols chained together — and formal verification still finds gaps

Claims to keep separate

Security is not only encryption

EMV as four protocols

What they verified

The Visa contactless CTQ gap

Offline approval and an unauthenticated cryptogram

Which configurations held

What this means for payment system design

References