How terminals verify offline data (SDA/DDA)

[Jollier]

In EMV (Europay, Mastercard, Visa) chip card transactions, offline data authentication ensures the card is genuine and its data has not been tampered with, even when the terminal cannot connect to the issuer’s network. This is achieved through Static Data Authentication (SDA) and Dynamic Data Authentication (DDA). Below is a technical breakdown of how these mechanisms work:

1. Static Data Authentication (SDA)​

SDA verifies static data stored on the card (e.g., card number, expiration date, certificate). It ensures the card’s data has not been altered or cloned.

How SDA Works​

1. Issuer Certificates:
   • The issuer (bank) embeds a digital certificate in the card during personalization. This certificate is signed by a Certification Authority (CA) public key (stored in the terminal’s secure element).
   • The card also stores a hash of its critical data (e.g., PAN, expiration date) and a digital signature generated by the issuer’s private key.
2. Terminal Verification:
   • The terminal reads the card’s certificate chain and verifies the CA’s signature using its preloaded CA public key.
   • Once the issuer’s public key is authenticated, the terminal recalculates the hash of the card’s static data and compares it to the decrypted signature using the issuer’s public key.
   • If the hashes match, the data is confirmed as genuine and unmodified.

Limitations​

• SDA only validates static data, making it vulnerable to cloning if the card’s data is copied.
• It does not detect counterfeit cards that replicate valid static data.

2. Dynamic Data Authentication (DDA)​

DDA enhances security by validating dynamic data unique to each transaction, preventing replay attacks and cloning.

How DDA Works​

1. Card Challenge:
   • The terminal generates a random challenge (a unique number) and sends it to the card.
   • The card combines the challenge with its internal data (e.g., transaction counter, unpredictable number) to generate a cryptogram (dynamic signature).
2. Digital Signature:
   • The card signs the challenge using its private key (unique to the card and derived from the issuer’s private key).
   • The terminal verifies the cryptogram using the card’s public key, which is itself validated through the issuer’s certificate chain (similar to SDA).
3. Dynamic Validation:
   • Since the challenge is random and changes per transaction, the cryptogram is unique for each interaction. This prevents attackers from reusing intercepted data.

Advantages​

• Prevents replay attacks: Each transaction requires a new cryptogram.
• Detects counterfeit cards: Attackers cannot forge the dynamic signature without the card’s private key.

3. Combined SDA + DDA (Hybrid)​

Some implementations use both SDA and DDA for layered security:

• SDA validates static data integrity.
• DDA ensures dynamic transaction uniqueness.

Offline Transaction Flow​

1. Card Insertion:
   • The terminal reads the card’s ATR (Answer To Reset) and selects the EMV application.
2. Data Authentication:
   • The terminal requests the card’s certificate chain and performs SDA/DDA.
3. Risk Management:
   • If authentication passes, the terminal checks offline risk parameters (e.g., transaction counter, floor limit, velocity checks).
4. Authorization:
   • If risks are acceptable, the terminal approves the transaction locally (without contacting the issuer).

Security Implications​

• SDA is sufficient for low-risk environments but is deprecated in favor of stronger methods.
• DDA is mandatory for high-security scenarios (e.g., contactless payments) to resist cloning.
• Offline vs. Online: Even with strong offline authentication, terminals may still require online authorization for high-value transactions or to update revocation lists.

Example (Simplified)​

1. SDA:
   • Card sends:
     Hash = SHA-1(Card Number + Expiry Date)
     Signature = RSA_Encrypt(Issuer Private Key, Hash)
   • Terminal:
     • Verifies issuer certificate with CA key.
     • Recalculates hash and compares to decrypted signature.
2. DDA:
   • Terminal sends challenge RND = 0x123456.
   • Card computes:
     Cryptogram = RSA_Encrypt(Card Private Key, RND + ATC),
     where ATC (Application Transaction Counter) increments with each transaction.
   • Terminal verifies cryptogram using card’s public key.

Conclusion​

SDA and DDA are foundational to EMV’s offline security model. While SDA ensures data integrity, DDA adds dynamic proof of card authenticity. These mechanisms work alongside Cardholder Verification Methods (CVMs) (e.g., PIN, signature) and terminal risk management to create a layered defense against fraud. Understanding these processes is critical for analyzing payment systems in cybersecurity contexts.

 

[Professor]

How EMV Terminals Verify Offline Data: SDA vs. DDA​

EMV cards use offline data authentication (ODA) to verify card legitimacy without contacting the bank. The two main methods are SDA (Static Data Authentication) and DDA (Dynamic Data Authentication). Here’s how they work in a cybersecurity/pen-testing context (for research only).

1. Static Data Authentication (SDA)​

How It Works​

• The card contains pre-signed static data (PAN, expiry, service code) signed by the issuer’s private key.
• The terminal verifies this signature using the issuer’s public key (from the card’s CA certificate).

Steps:​

1. Terminal reads:
   • Signed static data (from card’s EF.SDA file).
   • Issuer’s public key certificate (from EF.Cert).
2. Terminal validates:
   • Certificate chain (up to the payment scheme’s root key, e.g., Visa/Mastercard).
   • Digital signature over card data.

Security Weaknesses (For Research)​

• SDA is vulnerable to cloning:
  • If an attacker extracts signed data (e.g., from a stolen card), they can copy it to a blank card.
  • No dynamic challenge-response (unlike DDA).
• Used in older/magstripe-emv hybrid cards.

2. Dynamic Data Authentication (DDA)​

How It Works​

• The card dynamically signs a unique terminal challenge (nonce) during each transaction.
• Uses an asymmetric key pair (private key burned into the chip, public key signed by the issuer).

Steps:​

1. Terminal sends a random challenge (e.g., 8A 23 F1 9D...).
2. Card signs it with its private key, returns:
   • Dynamic signature (Signed Dynamic Application Data, ICC Dynamic Number).
   • Public key certificate (from EF.Cert).
3. Terminal verifies:
   • Certificate chain (like SDA).
   • Signature matches the challenge.

Why DDA is More Secure​

• Prevents cloning: Private key cannot be extracted (hardware-protected).
• Unique per transaction: Even if data is intercepted, it can’t be reused.

Limitations (For Research)​

• Side-channel attacks: Timing/power analysis to extract keys (theoretical, requires lab access).
• Fault injection: Glitching the chip to bypass checks (advanced hardware hacking).

3. Combined DDA + CDA (CDA = Combined DDA/AC)​

• CDA adds cryptogram generation (ARQC/TC) to DDA for full transaction security.
• Used in modern contactless (NFC) transactions.

4. How Terminals Detect Fraud​

1. Offline Checks:
   • SDA/DDA validation (as above).
   • Velocity checking (too many offline transactions → forced online).
2. Online Checks (if available):
   • ARQC cryptogram sent to issuer for real-time approval.

5. Ethical Research & Testing​

Legal Tools to Experiment​

• jCardSim (Java-based EMV simulator).
• PyResMan (Python tool to analyze APDU flows).
• Test cards from Visa/Mastercard (e.g., Visa Test Card 4761 1200 0000 0004).

What You Can’t Do Legally​

• Extract keys from real payment cards.
• Modify live cards to bypass SDA/DDA.

6. Attack Scenarios (Theoretical)​

• SDA Cloning: Copying signed data to a programmable card (e.g., JCOP).
• DDA Relay Attacks: Using a proxy to forward challenges (complex, requires NFC MITM).
• Terminal Spoofing: Fake POS that doesn’t enforce DDA (rare in modern systems).

Key Takeaways​

• SDA = Static, weaker (clonable if data is copied).
• DDA = Dynamic, strong (requires chip’s private key).
• Research safely: Use simulators, test cards, and never target live systems.

Need details on specific APDU commands or CDA implementation? Ask for a deep-dive!

 

[Cloned Boy]

Offline Data Authentication (ODA) in EMV Transactions​

Overview of Offline Authentication Methods​

EMV terminals use three primary methods for offline data authentication:

1. Static Data Authentication (SDA)
   • The most basic and least secure method
   • Validates that card data has not been fraudulently altered since personalization
   • Uses a digital signature created with static card data
   • No longer widely supported due to security limitations
2. Dynamic Data Authentication (DDA)
   • More secure than SDA
   • Generates a unique digital signature for each transaction
   • Prevents card cloning and provides stronger authentication
3. Combined Data Authentication (CDA)
   • The most secure method
   • Combines DDA with application cryptogram generation
   • Protects against counterfeit, skimming, and man-in-the-middle attacks

How Terminals Verify Offline Data​

Authentication Process for DDA​

1. Key Retrieval
   • Terminal retrieves Certification Authority (CA) Public Key
   • Uses CA Public Key to decrypt Issuer Public Key Certificate
   • Decrypts ICC (Integrated Circuit Card) Public Key Certificate
2. Dynamic Authentication
   • Terminal sends INTERNAL AUTHENTICATE command with:
     • Dynamic Data Authentication Data Object List (DDOL)
     • Includes unique terminal data (unpredictable number)
   • Card uses its private key to generate a dynamic digital signature
   • Returns Signed Dynamic Application Data (SDAD) to terminal
3. Signature Verification
   • Terminal uses ICC Public Key to decrypt and verify the signature
   • Checks multiple validation steps to ensure data integrity
   • Compares generated signature with received signature

Selection of Authentication Method​

The terminal chooses the authentication method based on card and terminal capabilities:

• If both support CDA, CDA is used
• If both support DDA, DDA is used
• If both support SDA, SDA is used
• If no method is supported, the 'Offline data authentication was not performed' bit is set

Key Security Considerations​

• Dynamic Elements: Each authentication uses unique data to prevent replay attacks
• Multi-Layer Verification: Uses multiple key pairs (CA, Issuer, Card) to ensure integrity
• Cryptographic Protection: Utilizes RSA public key cryptography for offline authentication

Practical Applications​

Offline authentication is crucial in environments with:

• Unstable network connectivity
• Need for rapid transactions
• Limited online authorization capabilities (e.g., transit systems)

Important Notes​

• Online and offline authentications are not mutually exclusive
• Most transactions will check both offline and online authentication methods
• The specific implementation depends on card and terminal capabilities