SDA vs DDA vs CDA: EMV Offline Data Authentication Explained

When you insert a chip card at a terminal with no internet connection, how does the terminal know the card is genuine? The answer lies in three cryptographic methods baked into every EMV chip — and understanding the differences between them is essential for anyone building or debugging payment systems.

What is Offline Data Authentication?

Offline Data Authentication (ODA) is the process by which an EMV terminal verifies that the data on a chip card is authentic — without contacting the issuer’s host. The terminal uses public key cryptography to validate that critical card data (PAN, expiry, usage restrictions) hasn’t been tampered with since the issuer personalized the chip.

ODA matters because:

• Not every terminal is online — vending machines, transit gates, in-flight POS, and markets in rural areas may lack connectivity
• Speed — offline authentication takes milliseconds vs. seconds for an online authorization
• Liability — the strength of the ODA method directly affects chargeback liability under EMV chip liability shift rules

There are three ODA methods defined by EMVCo, each progressively stronger:

See it in action: Decode the AIP tag (82) in our EMV Tag Inspector to see which ODA methods a card supports.

Also Known As…

Offline data authentication terminology varies across specifications and vendor documentation:

The PKI Foundation: How EMV Certificates Work

Before diving into SDA, DDA, and CDA, you need to understand the certificate chain that makes them all possible. EMV uses a three-level Public Key Infrastructure (PKI):

Level 1: Certificate Authority (CA)
┌─────────────────────────────────┐
│ EMVCo / Payment Brand CA        │
│ CA Public Key stored in terminal│
│ (loaded during terminal config) │
└────────────┬────────────────────┘
             │ signs
             ▼
Level 2: Issuer
┌─────────────────────────────────┐
│ Issuer Public Key Certificate   │
│ Tag 90 (stored on card chip)    │
│ Signed by CA Private Key        │
└────────────┬────────────────────┘
             │ signs
             ▼
Level 3: ICC (Card)
┌─────────────────────────────────┐
│ ICC Public Key Certificate      │
│ Tag 9F46 (stored on card chip)  │
│ Signed by Issuer Private Key    │
│ (DDA and CDA only)              │
└─────────────────────────────────┘

The terminal verifies this chain from top to bottom:

1. Terminal has the CA Public Key (pre-loaded by the payment brand)
2. Terminal recovers the Issuer Public Key from the Issuer Certificate (tag 90) using the CA Public Key
3. Terminal recovers the ICC Public Key from the ICC Certificate (tag 9F46) using the Issuer Public Key — but only for DDA and CDA

This chain ensures that every key traces back to a trusted root — the payment brand’s Certificate Authority.

Key EMV Tags in the PKI Chain

Look up any tag: Search our Reference Database for full EMV tag descriptions, or paste raw TLV data into the EMV Tag Inspector.

How SDA Works

Static Data Authentication is the simplest and oldest ODA method. The issuer signs a fixed block of card data during personalization, and the terminal verifies that signature at the point of sale.

SDA Step-by-Step

Card Personalization (at issuer):
┌──────────────────────────────────────┐
│ 1. Issuer selects critical data      │
│    (PAN, expiry, restrictions, etc.) │
│ 2. Issuer hashes the data           │
│ 3. Issuer signs hash with           │
│    Issuer Private Key               │
│ 4. Signature stored as tag 93       │
│    (Signed Static Application Data) │
└──────────────────────────────────────┘

Transaction (at terminal):
┌──────────────────────────────────────┐
│ 1. Terminal reads tag 8F             │
│    (CA Public Key Index)             │
│ 2. Terminal recovers Issuer PK       │
│    from tag 90 using CA PK           │
│ 3. Terminal verifies tag 93          │
│    using recovered Issuer PK         │
│ 4. If signature valid → SDA passed   │
│    If invalid → set TVR bit 7 byte 1 │
└──────────────────────────────────────┘

What SDA Proves

The Fatal Flaw: Cloning

Because the signature in tag 93 is static — identical for every transaction — an attacker who intercepts the card’s data can create a clone that produces the exact same signature. The terminal cannot distinguish the original card from the clone.

Original Card:   Tag 93 = A1B2C3D4...  (always the same)
Cloned Card:     Tag 93 = A1B2C3D4...  (copied verbatim)
                         ↑
              Terminal sees no difference

This is why SDA cards are effectively extinct in developed markets. They were common in early EMV deployments (2000-2010) but have been replaced by DDA and CDA cards.

SDA in the Terminal Verification Results

When SDA fails, the terminal sets byte 1, bit 7 of the TVR (tag 95):

Decode TVR values in our EMV Tag Inspector — paste the 5-byte TVR (tag 95) to see which checks passed or failed.

How DDA Works

Dynamic Data Authentication solves SDA’s cloning problem by requiring the card to perform a real-time RSA signature during each transaction. The card has its own private key that never leaves the chip.

DDA Step-by-Step

Card Personalization (at issuer):
┌──────────────────────────────────────┐
│ 1. Issuer generates RSA key pair     │
│    for the card (ICC keys)           │
│ 2. Issuer signs ICC Public Key with  │
│    Issuer Private Key                │
│ 3. ICC Public Key Certificate stored │
│    as tag 9F46                       │
│ 4. ICC Private Key stored in secure  │
│    element of chip (never exported)  │
└──────────────────────────────────────┘

Transaction (at terminal):
┌──────────────────────────────────────┐
│ 1. Terminal recovers Issuer PK       │
│    from tag 90 using CA PK           │
│ 2. Terminal recovers ICC PK          │
│    from tag 9F46 using Issuer PK     │
│ 3. Terminal sends INTERNAL AUTHENTICATE│
│    command with unpredictable number │
│    (random data from terminal)       │
│ 4. Card signs the data using ICC     │
│    Private Key (on-chip RSA)         │
│ 5. Card returns Signed Dynamic       │
│    Application Data (tag 9F4B)       │
│ 6. Terminal verifies signature using │
│    ICC Public Key                    │
│ 7. If valid → DDA passed             │
│    If invalid → set TVR bit 4 byte 1 │
└──────────────────────────────────────┘

What DDA Proves

Why Cloning Fails Against DDA

The critical difference is the ICC Private Key. This key is generated inside the chip’s secure element and cannot be extracted — even with physical access to the chip. A cloned card would need to sign data with a private key it doesn’t have:

Original Card:   INTERNAL AUTHENTICATE → signs with private key → unique signature
Cloned Card:     INTERNAL AUTHENTICATE → ??? no private key → FAILS

DDA Performance Consideration

The on-chip RSA operation takes 100-300 milliseconds depending on the key size and chip hardware. This is acceptable for contact transactions but adds noticeable latency for contactless tap-and-go payments, which led to the development of fDDA (fast DDA) for contactless.

fDDA: Fast DDA for Contactless

Visa’s payWave specification introduced fDDA (also called qVSDC mode) to speed up DDA for contactless transactions. The card pre-computes part of the signature and combines it with transaction-specific data on the fly:

How CDA Works

Combined DDA/Application Cryptogram Generation (CDA) is the strongest ODA method. It combines DDA’s dynamic signing with the application cryptogram (ARQC/TC/AAC) into a single operation, binding the authentication to the specific transaction.

CDA Step-by-Step

Card Personalization:
  Same as DDA — ICC key pair + certificates

Transaction (at terminal):
┌──────────────────────────────────────┐
│ 1. Terminal recovers Issuer PK       │
│    from tag 90 using CA PK           │
│ 2. Terminal recovers ICC PK          │
│    from tag 9F46 using Issuer PK     │
│ 3. Terminal sends GENERATE AC command│
│    (not INTERNAL AUTHENTICATE)       │
│ 4. Card generates cryptogram (ARQC,  │
│    TC, or AAC) using symmetric key   │
│ 5. Card signs the cryptogram + data  │
│    using ICC Private Key (RSA)       │
│ 6. Card returns Signed Dynamic       │
│    Application Data (tag 9F4B)       │
│    containing both the signature     │
│    AND the cryptogram                │
│ 7. Terminal verifies RSA signature   │
│    and extracts cryptogram           │
│ 8. If valid → CDA passed             │
│    If invalid → set TVR bit 3 byte 1 │
└──────────────────────────────────────┘

What CDA Proves

The Wedge Attack: Why CDA Matters

CDA’s critical advantage over DDA is protection against wedge attacks (also called man-in-the-middle or relay attacks). In a wedge attack against DDA:

DDA Vulnerability (wedge attack):
┌──────────┐     ┌──────────┐     ┌──────────┐
│ Terminal  │ ──▸ │ Attacker │ ──▸ │ Real Card│
│           │     │ (wedge)  │     │          │
│ INTERNAL  │     │ Pass     │     │ Signs    │
│ AUTH      │     │ through  │     │ data     │
│           │ ◂── │          │ ◂── │          │
│ DDA OK!   │     │ Modify   │     │          │
│           │     │ GENERATE │     │          │
│ GENERATE  │ ──▸ │ AC       │ ──▸ │          │
│ AC        │     │ (change  │     │ Generate │
│           │     │ amount!) │     │ TC       │
│           │ ◂── │          │ ◂── │          │
│ TC OK!    │     │          │     │          │
└──────────┘     └──────────┘     └──────────┘
      ↑
DDA and cryptogram are separate operations.
Attacker can pass DDA honestly, then
modify the GENERATE AC command data.

CDA Defense:
┌──────────┐     ┌──────────┐     ┌──────────┐
│ Terminal  │ ──▸ │ Attacker │ ──▸ │ Real Card│
│           │     │ (wedge)  │     │          │
│ GENERATE  │     │ Cannot   │     │ Signs    │
│ AC        │     │ modify   │     │ cryptogram│
│ (CDA)     │     │ without  │     │ + data   │
│           │ ◂── │ breaking │ ◂── │ together │
│ Verify    │     │ signature│     │          │
│ signature │     │          │     │          │
│ + crypto  │     │          │     │          │
│ ATOMIC!   │     │          │     │          │
└──────────┘     └──────────┘     └──────────┘
      ↑
Cryptogram is INSIDE the signed data.
Any modification breaks the signature.

Side-by-Side Comparison

This table summarizes the key differences across all three ODA methods:

Application Interchange Profile (AIP) - Tag 82

The AIP (tag 82) tells the terminal which ODA methods the card supports. This is a 2-byte value where specific bits indicate SDA, DDA, and CDA capability:

Reading the AIP

Here’s how to interpret common AIP values:

Try it yourself: Paste a complete Field 55 into our EMV Tag Inspector to see the AIP decoded with bit-level descriptions.

ODA in the Transaction Flow

Here’s where ODA fits in the overall EMV transaction flow:

Card Insertion / Tap
       │
       ▼
┌─────────────────────┐
│ SELECT Application  │  ← AID selection
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ GET PROCESSING OPTS │  ← Returns AIP (tag 82) + AFL (tag 94)
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ READ RECORDS        │  ← Read SDA/DDA/CDA data from card
└──────────┬──────────┘
           ▼
┌═════════════════════┐
║ OFFLINE DATA AUTH   ║  ← SDA, DDA, or CDA performed HERE
║ (ODA)               ║
└══════════╤══════════┘
           ▼
┌─────────────────────┐
│ Processing          │  ← CVM, risk management
│ Restrictions        │
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ GENERATE AC         │  ← Cryptogram (ARQC/TC/AAC)
│ (CDA: combined)     │     For CDA: ODA happens here instead
└──────────┬──────────┘
           ▼
   Online / Offline Decision

For SDA and DDA, ODA happens as a separate step before GENERATE AC. For CDA, authentication is combined with the GENERATE AC command — the card produces the cryptogram and the RSA signature in a single atomic operation.

What ODA Does NOT Protect Against

Understanding the limitations prevents overconfidence:

ODA answers one question: “Is this chip card genuine and unmodified?” It does not replace online authorization, cardholder verification, or issuer risk management.

Card Brand ODA Requirements

Each payment brand sets minimum ODA requirements for cards and terminals on their network:

Quick Reference Table

Next Steps

Now that you understand SDA, DDA, and CDA:

1. Decode chip data with the EMV Tag Inspector — look for tags 82, 90, 93, 9F46, and 9F4B
2. Look up ODA tags in the Reference Database for complete tag definitions
3. Understand the cryptogram in our EMV Field 55 Guide — CDA binds ODA to the ARQC/TC
4. Learn about HSMs in our HSM Basics Guide — the devices that manage CA and Issuer key pairs
5. Explore 3DES vs AES in our 3DES vs AES in Payments — the encryption that protects cryptogram keys
6. Review ARQC generation with the ARQC Calculator — the online counterpart to offline authentication
7. Understand entry modes in our POS Entry Mode Guide — entry modes 05 and 07 indicate chip/contactless ODA

This post is part of the ISO 8583 Mastery series. Follow along as we explore payment messaging in depth.