Ultra-Detailed Technical Guide: EMV Application Cryptogram

[Student]

The Application Cryptogram (AC) is the cornerstone of EMV chip card security, providing dynamic data authentication that proves the physical presence and authenticity of a genuine card during a transaction. It replaces the static CVV/iCVV of magnetic stripes with a unique, cryptographically secure value computed for every single transaction. This mechanism is why EMV has reduced card-present counterfeit fraud by 85–95% in fully migrated markets and rendered traditional mag-stripe cloning economically unviable.

All details below are based on EMVCo Integrated Circuit Card Specifications for Payment Systems, Book 3 – Application Specification v4.3 (November 2011, with subsequent bulletins up to 2025), which remains the authoritative standard. Minor updates in 2025 bulletins focused on AES migration, post-quantum readiness studies, and kernel clarifications.

Types of Application Cryptograms – Detailed Breakdown​

Cryptogram Type	First Byte (in Response)	Full Name	When Generated	Data Authenticated	Issuer/Terminal Action
ARQC	40 hex	Authorization Request Cryptogram	Card requests online authorization (e.g., exceeds floor limit, random online selection, merchant forcing online, velocity checks).	Transaction data + UN + ATC → MAC proves card wants issuer decision.	Terminal sends to issuer; issuer verifies and returns ARPC (or decline).
TC	80 hex	Transaction Certificate	Card approves transaction offline (risk parameters allow, CDA/DDA successful).	Same data → MAC proves card approved offline.	Terminal approves offline (after CDA verification if required).
AAC	00 hex	Application Authentication Cryptogram	Card or terminal declines (e.g., expired card, PIN tries exceeded, offline decline limits).	Same data → MAC proves decline decision.	Transaction declined (online or offline).

• Second Byte Variants: Indicate method (e.g., 40 = ARQC with no advice, 41 = ARQC with advice required).
• 8-Byte Structure: The cryptogram itself is typically 8 bytes (for 3DES/AES MAC).

Cryptogram Generation Process (Step-by-Step)​

1. Terminal Initiates:
   • Sends GENERATE AC command (P1 parameter: '80' for first, '00'–'40' for second).
   • Includes CDOL1 data: Amount, Currency, Terminal Country, TVR, Transaction Date/Type, UN (Unpredictable Number – 4 bytes, must be cryptographically random).
2. Card Processing:
   • Performs internal risk management (Application Usage Control, floor limits, velocity counters, random selection).
   • Builds Session Key(SK):
     • For Symmetric AC (most common): SK = 3DES/AES (Issuer Master Key ⊕ ATC) over diversification data.
     • Session key derivation: Two 8-byte keys (left/right) for 3DES; single 16/32-byte for AES.
   • Constructs Input Data Block(from CDOL1 + internal data):
     • ATC (2 bytes)
     • UN (4 bytes)
     • Amount Authorized + Other Amount + Currency + Date + Type
     • Terminal capabilities, CVM results, etc.
     • Issuer Application Data (IAD) – proprietary issuer data.
   • Computes MACover the block:
     • 3DES: Retail MAC (ISO 9797-1 Algorithm 3) – padding method 2.
     • AES: CMAC (NIST SP 800-38B).
   • Decides cryptogram type (ARQC/TC/AAC) based on risk.
3. Card Response:
   • Returns: Cryptogram (8 bytes) + ATC + IAD + Cryptogram Information Data (CID: indicates type + version).
   • If CDA requested: Additional dynamic signature (Signed Dynamic Application Data) over cryptogram + selected data using card's private RSA/ECDSA key.
4. Verification:
   • Offline (CDA): Terminal verifies RSA/ECDSA signature using card's public key (from certificate chain).
   • Online (ARQC): Issuer recomputes MAC using shared session key → validates card authenticity.
   • ARPC: Issuer returns 2-byte response cryptogram (MAC over ARQC ⊕ Auth Code) for card to verify genuine issuer.

Cryptogram Versions & Methods​

Version	Method	Cryptogram Length	Notes (2025 Status)
1–3	Legacy static/offline data auth	Variable	Phased out
4	Symmetric AC (ARQC/TC/AAC)	8 bytes	Standard symmetric
5	Combined Data Authentication (CDA)	8 bytes + dynamic signature	Mandatory in most regions; strongest protection

CDA Flow:

• Card signs: Hash (cryptogram + terminal data + card data).
• Signature length: 128–256 bytes (RSA 2048/3072 or ECDSA P-256/P-384).
• Terminal verifies chain: ICC Public Key → Issuer PK → CA PK.

Data Elements in Cryptogram Calculation (Key CDOL1 Items)​

Tag	Name	Length	Mandatory for AC?
9F02	Amount, Authorized	6	Yes
9F03	Amount, Other	6	Yes
9F1A	Terminal Country Code	2	Yes
95	Terminal Verification Results (TVR)	5	Yes
9F26	Application Cryptogram (output)	8	Output
9F36	Application Transaction Counter (ATC)	2	Yes
9F10	Issuer Application Data (IAD)	Var	Often
9F37	Unpredictable Number (UN)	4	Yes

Why Application Cryptograms Defeat Cloning​

• Dynamic: ATC increments every transaction → same data never repeats.
• Challenge-Response: UN unique per transaction → pre-computed responses impossible.
• Secret Key: Never leaves secure element; extraction requires invasive lab attacks (infeasible at criminal scale).
• CDA Signature: Proves card performed computation (no relay/pre-play).

Result: True functional EMV chip cloning is cryptographically and practically impossible in 2025 criminal operations.

Practical Examples (Illustrative – Real values are binary)​

• ARQC Response (partial): 771C...9F268123456789ABCDEF9F368201239F1080...
  • 9F26 = ARQC value 123456789ABCDEF
• TC: Similar but CID first byte 80.
• Failed CDA → terminal declines even if cryptogram present.

The Application Cryptogram, especially with CDA, is the primary reason EMV remains the most secure card-present payment technology worldwide.

If you'd like even deeper specifics — e.g., exact 3DES Retail MAC algorithm steps, sample APDU traces, CDA certificate chain validation, or AES-CMAC migration details — let me know and I'll expand further!