SDA, DDA, CDA: How a Terminal Trusts a Card Offline

💡 TL;DR (Too Long; Didn't Read)

Offline data authentication in 90 seconds:

The terminal can verify a card is genuine without going online, using a chain of RSA public keys it already carries: scheme CA key → Issuer Public Key → ICC Public Key.

SDA (Static) verifies a signature over the card's static data. It proves the data is authentic — but the same signed data can be copied, so SDA is cloneable.

DDA (Dynamic) adds an on-card private key. The terminal issues a challenge; the card signs it. A clone without the private key cannot answer, so DDA defeats copying.

CDA (Combined) fuses the dynamic signature with the GENERATE AC cryptogram, so the signature also covers this transaction's cryptogram — the strongest and now-default method.

It all rests on EMV's RSA recovery function: signatures you decrypt to reveal data plus a hash, with a trailer byte BC.

There is a moment in every chip transaction, before the terminal decides anything, where it asks a question the magnetic stripe could never answer: is this card real? Not "is this account valid" — that is the issuer's job, online — but "is the plastic in my slot a genuine card and not a fabricated copy." EMV answers this with Offline Data Authentication (ODA), a public-key mechanism that lets a terminal, carrying nothing but a handful of scheme root keys, verify a card's authenticity with no network at all. There are three methods of increasing strength — SDA, DDA, and CDA — and understanding why each exists is understanding how card cloning was defeated. This follows EMVCo Book 2; I cite the structure, not the spec text, and no private key material appears here.

The certificate chain the terminal carries

ODA is a public-key trust chain, and the terminal is the verifier. It works because the terminal is pre-loaded with a small set of Certificate Authority (CA) public keys — the scheme roots, one set per payment network, identified by a Registered Application Provider Identifier (RID) and a CA Public Key Index. When a card is read, tag 8F tells the terminal which CA key index to use, and the terminal looks up the matching root it already holds.

From that root, the chain descends:

The terminal uses the CA key to verify the Issuer Public Key Certificate (tag 90), recovering the issuer's public key. Depending on the method, it then either verifies the card's Signed Static Application Data (SDA) with that issuer key, or descends one level further to recover and use the ICC public key (DDA/CDA). Trust flows down from a root the terminal already trusts — exactly like the web PKI, but with the roots baked into the terminal and the leaf being a payment card.

The RSA recovery function

All three methods rest on one primitive that EMV uses everywhere: the RSA recovery function. EMV signatures are not detached MACs; they are RSA operations you decrypt to reveal a structured block containing the signed data (or its hash) plus header and trailer bytes. When the terminal "verifies" a certificate or signature, it applies the CA/issuer/ICC public key to recover a block, then checks that the block has the right format — a header byte, the data or its representation, a SHA-1 hash over the relevant fields, and a trailer byte of BC. If the recovered block is well-formed, the hash matches the recomputed hash, and the trailer is BC, the signature is valid.

This is why "the certificate failed" in EMV usually means one of a few concrete things: the recovered trailer was not BC, the recovered hash did not match, the certificate's expiry date has passed, or the CA index pointed at a key the terminal does not hold. Each is a specific, diagnosable condition, not a vague failure.

SDA: authentic, but copyable

Static Data Authentication is the original and the weakest. The issuer, at personalization time, signs a static set of the card's data and stores the result on the card as Signed Static Application Data (tag 93). At transaction time the terminal verifies that signature up the chain: CA key verifies the issuer certificate, issuer key verifies the SSAD. Success proves the static data was genuinely signed by the issuer and has not been altered.

But notice what SDA does not prove: that the card in the slot is the original. Because the signed data is static — the same bytes every time — an attacker who reads a genuine card can copy the SSAD and all the signed data onto another card, and that copy will pass SDA verification, because the signature is over data, not over anything unique to this card or this moment. SDA authenticates the data; it cannot authenticate the card. That gap is why SDA is deprecated for anything that matters, and why the card sets an SDA-supported card can still be cloned. It set the requirement for something dynamic.

DDA: prove you hold the private key

Dynamic Data Authentication closes the cloning gap by giving the card its own RSA key pair. The public key is delivered in the ICC Public Key Certificate (tag 9F46), which the terminal verifies using the recovered issuer key — one more link in the chain. The private key never leaves the card.

Now the terminal does something SDA cannot: it issues a challenge. Via the INTERNAL AUTHENTICATE command it sends dynamic data (including an unpredictable number and terminal data specified by the DDOL), and the card signs it with its private key, returning Signed Dynamic Application Data (tag 9F4B). The terminal verifies that signature with the recovered ICC public key. Because the signature is over fresh, terminal-supplied data and requires the card's private key, a clone that copied only the public data cannot produce it — it does not hold the private key. DDA proves the card is the genuine article, not a copy. This is the mechanism that made chip cards meaningfully un-cloneable in a way the stripe never was.

CDA: bind authentication to the transaction

DDA proves the card is real, but there is a subtle gap between "the card authenticated" and "the card authenticated this transaction." A sophisticated attack could authenticate a genuine card and then tamper with the cryptogram exchange. Combined DDA/Application Cryptogram (CDA) closes it by welding the dynamic signature to the GENERATE AC step: the card's signed dynamic data now also covers the Application Cryptogram it just generated. So a single verification proves both that the card is genuine and that the cryptogram for this specific transaction is bound to that genuine card. There is no window between authenticating the card and trusting its cryptogram, because they are the same signature.

CDA is the strongest ODA method and the modern default expectation; the transaction flow requests it by adding the CDA bit to the GENERATE AC command. If you are reasoning about a current EMV deployment, assume CDA and treat SDA-only cards as legacy risk.

Battle scars

A failed certificate is a specific failure. "ODA failed" is not a mood; it is one of: expired certificate, wrong CA index (terminal lacks the key), bad trailer (BC missing), or hash mismatch. Sets the corresponding TVR bit in byte 1, and reading which bit tells you which link broke. Do not treat the whole chain as one opaque boolean.

Expired CA keys and missing indices are operational, not cryptographic. A large share of real ODA failures are logistics: a terminal that never received a new scheme CA key, or a card personalized under a CA index the terminal's key table does not include. The crypto is fine; the key management lagged. Keep the terminal CA key set current — it is the Public Key Table work that quietly keeps offline auth alive.

SDA-only is a finding, not a footnote. If your fleet still approves SDA-only cards offline for meaningful amounts, you are approving cards that can be cloned. That may be an acceptable, bounded risk for tiny offline transit fares; it is not acceptable for general retail. Know your ODA method distribution.

Where this fits

ODA is Phase 4 of the transaction flow, and its result feeds the TVR decision engine. Its strongest form, CDA, is inseparable from the ARQC it signs over. The CA and issuer keys it depends on are exactly what the gsstk Public Key Table manages.

What Actually Happens When You Dip a Chip: The EMV Transaction Flow End-to-End — where ODA runs (Phase 4).
ARQC from Scratch: Application Cryptograms Without the Black Box — the cryptogram CDA signs over.
The TVR, the TSI, and How a Terminal Decides to Decline You — where ODA failures land as bits.

Tools: manage the CA and issuer keys behind the chain with the Public Key Table; resolve 8F (CA PK Index), 90 (Issuer PK Certificate), 9F46 (ICC PK Certificate) in the EMV Tag Dictionary.

Filed under: EMV · Payment Crypto · Payments · Acquiring · Card Issuing

This article was human-architected and synthesized with AI assistance under the Daedalus (AI) persona.