Explain EMV cryptogram methods

[Good Carder]

Introduction to EMV Cryptogram Methods​

EMV (Europay, Mastercard, and Visa) standards define cryptographic methods to secure chip-based payment transactions, ensuring authenticity, integrity, and non-repudiation. These methods involve generating cryptograms — Message Authentication Codes (MACs) or digital signatures — using symmetric (e.g., 3DES, AES) or asymmetric (e.g., RSA) algorithms. Cryptograms are categorized into two main areas: transaction authorization (for online/offline approvals) and offline data authentication (to verify card legitimacy without issuer involvement). Key elements include session keys derived from master keys, dynamic data like the Application Transaction Counter (ATC), and transaction-specific inputs. Below, I'll explain the primary cryptogram types and methods.

Transaction Authorization Cryptograms​

These cryptograms handle online and offline transaction approvals/declines. They are generated using symmetric cryptography and rely on Card Data Object Lists (CDOL1/CDOL2) for inputs like amount (9F02), terminal country (9F1A), unpredictable number (9F37), and ATC (9F36). The process starts with key derivation:

• Master Key: Issuer Master Key (IMK-AC) shared between issuer and card.
• Unique Derived Key (UDK): Derived from IMK using PAN and PAN Sequence Number (e.g., Option A/B methods).
• Session Key (SK_AC): Derived from UDK using ATC (ensures uniqueness per transaction).

The cryptogram is then computed as a MAC over concatenated inputs, padded (e.g., ISO 9797 Method 1/2), using 3DES in CBC mode or AES. They are triggered via the GENERATE APPLICATION CRYPTOGRAM (GENERATE AC) APDU command.

1. ARQC (Authorization Request Cryptogram)​

• Purpose: Generated by the card to request online issuer authorization; authenticates the card and transaction data.
• Length: 8 bytes (tag 9F26).
• Generation: MAC(SK_AC, CDOL1 data). Issuer validates by recomputing and comparing.
• Use Case: When offline approval fails (e.g., over floor limit); sent in authorization request.

2. ARPC (Authorization Response Cryptogram)​

• Purpose: Generated by the issuer to authenticate the response (approve/decline); validates ARQC and issuer identity.
• Length: 4 or 8 bytes (sent in ISO 8583 field 91).
• Generation Methods:
  • Method 1 (8 bytes): MAC(SK_AC, ARQC XOR ARC), where ARC is the Authorization Response Code (e.g., '00' for approval).
  • Method 2 (4 bytes): MAC(SK_AC, ARQC + CSU + Proprietary Data), where CSU is Card Status Update.
• Use Case: Sent back to the card via second GENERATE AC; card validates to generate TC/AAC. Often omitted in contactless for speed.

3. TC (Transaction Certificate)​

• Purpose: Generated by the card to confirm an approved transaction (online or offline).
• Length: 8 bytes (tag 9F26).
• Generation: MAC(SK_AC, CDOL2 data, including approval indicators). Triggered after valid ARPC or offline approval.
• Use Case: Sent in clearing/settlement to prove transaction completion.

4. AAC (Application Authentication Cryptogram)​

• Purpose: Generated by the card to indicate transaction decline or termination.
• Length: 8 bytes (tag 9F26).
• Generation: Similar to TC but with decline indicators (e.g., after invalid ARPC or risk checks).
• Use Case: For offline declines or after issuer rejection.

5. AAR (Application Authorisation Referral)​

• Purpose: Rare; requests referral (e.g., voice authorization) instead of online.
• Generation: Similar to ARQC but with referral indicators.

Offline Data Authentication Methods​

These methods verify card authenticity offline using asymmetric cryptography (RSA) or static data, without cryptograms like ARQC but involving signatures. They use a certificate chain: Root CA → Issuer → Card.

• SDA (Static Data Authentication): Verifies static card data (e.g., PAN, expiry) signed by the issuer. Simple but vulnerable to skimming (no dynamic elements).
• DDA (Dynamic Data Authentication): Uses RSA to sign dynamic data (e.g., challenge from terminal). More secure as it proves card has private key.
• CDA (Combined DDA/Application Cryptogram Generation): Integrates DDA with transaction cryptogram (e.g., TC/AAC) generation; signs both static/dynamic data and cryptogram inputs for highest offline security.

Variations and Considerations​

• Algorithms: 3DES common for legacy; AES for modern (EMV 2nd Gen). Schemes (Visa, Mastercard) may differ in derivation (e.g., Visa Option A).
• Contactless: Optimizations (e.g., qVSDC) may skip ARPC for speed.
• Security: Dynamic elements (ATC, unpredictable numbers) prevent replays; failures lead to declines.

For implementation, refer to EMVCo Books 2 (Security) and 3 (Application Specs).