Explain ARQC cryptogram process

[Good Carder]

What is ARQC?​

The Authorization Request Cryptogram (ARQC) is an 8-byte cryptographic value generated by an EMV chip card during a transaction to request online authorization from the issuer. It serves as a digital signature that authenticates the card, verifies the integrity of transaction data, and prevents replay attacks or tampering. ARQC is used in online transactions where the terminal cannot approve offline, ensuring the issuer can validate the request in real-time. This process is part of the EMV standard, typically involving symmetric encryption like 3DES or AES, and relies on shared secrets between the card and issuer.

ARQC Generation Process on the Card​

The ARQC is generated by the chip card in response to a GENERATE APPLICATION CRYPTOGRAM (GENERATE AC) command from the terminal, typically during the transaction initiation phase (e.g., after GET PROCESSING OPTIONS). The process ensures uniqueness per transaction using dynamic elements like the Application Transaction Counter (ATC). Here's a step-by-step breakdown:

1. Key Derivation:
   • The card starts with an Issuer Master Key (IMK-AC or MKAC), a secret key shared with the issuer and personalized on the card.
   • From this, a Unique Derived Key (UDK) or Card Master Key is derived using the card's Primary Account Number (PAN) and PAN Sequence Number (often 00). This uses a diversification algorithm (e.g., Option A or B in EMV specs).
   • Next, a session key (SKAC) is derived from the UDK/MKAC using the ATC (a 2-byte counter incremented per transaction) and sometimes other data like the Application Reference Currency. The session key is unique to each transaction, preventing reuse.
2. Input Data Preparation:
   • The card collects data from the Card Data Object List 1 (CDOL1), which includes transaction-specific elements provided by the terminal (e.g., amount, date, terminal country code, unpredictable number) and card data (e.g., ATC, Issuer Application Data).
   • These are concatenated into a single input block. Minimum required EMV tags include 9F02 (Authorized Amount), 9F1A (Terminal Country Code), 9F37 (Unpredictable Number), 9F36 (ATC), and others like 5F2A (Transaction Currency Code). The data is padded if needed (e.g., ISO 9797 Method 1 or 2).
3. Cryptogram Computation:
   • The session key is applied to the input data using a cryptographic algorithm: typically Triple DES (3DES) in CBC mode or AES, depending on the card scheme (Visa and Mastercard may differ slightly in key derivation). This produces an 8-byte Message Authentication Code (MAC), which is the ARQC.
   • For example, in 3DES: The input is encrypted with the left half of the session key, decrypted with the right half, and re-encrypted with the left half (or similar per scheme).
   • The ARQC is tagged as 9F26 in the response APDU.
4. Response to Terminal:
   • The card sends the ARQC back in the Response APDU (e.g., with status 9000 for success), along with other data like ATC (9F36) and Cryptogram Information Data (9F27, indicating ARQC type). The terminal forwards this in the authorization request (e.g., ISO 8583 message) to the acquirer and then the issuer.

ARQC Validation and Response by the Issuer​

1. Issuer Receives ARQC:
   • The issuer's Host Security Module (HSM) or system receives the ARQC via the payment network.
2. Recompute and Verify:
   • The issuer regenerates the session key using the same IMK, PAN, ATC, and derivation method.
   • It recomputes the ARQC using the received transaction data and compares it to the submitted one. If they match, the card and data are authenticated.
3. Generate ARPC (Optional):
   • If approved, the issuer generates an Authorization Response Cryptogram (ARPC) using a similar process (session key on response data like authorization code). This is sent back for the card to verify in a second GENERATE AC (producing TC for approval or AAC for decline).

Variations and Notes​

• Algorithms: Visa often uses 3DES with specific derivation (e.g., Option A), while Mastercard may use AES or different padding. EMVCo allows flexibility.
• Contactless: In modes like qVSDC, ARQC is generated early for speed.
• Testing/Tools: Tools like BP-Tools or Thales simulators can emulate this for development.
• Security: The use of ATC and unpredictable numbers ensures each ARQC is unique, mitigating replay risks.

For precise implementations, refer to EMVCo specifications (Books 2 and 3) or scheme-specific docs, as algorithms can vary.