Explain ARPC cryptogram process

Good Carder

Professional
Messages
208
Reaction score
169
Points
43

What is ARPC?​

The Authorization Response Cryptogram (ARPC) is a cryptographic value generated by the card issuer during an EMV transaction to authenticate the authorization response back to the chip card. It serves as a digital signature that verifies the issuer's identity, confirms the response's integrity, and prevents tampering or replay attacks. ARPC is typically 4 or 8 bytes long and is produced in response to a valid Authorization Request Cryptogram (ARQC) from the card. This process is defined in EMV specifications (e.g., Book 2), using symmetric cryptography like 3DES or AES with shared keys between the issuer and card. Unlike ARQC (generated by the card), ARPC is issuer-initiated and optional but commonly used in online transactions to enable the card to produce a final Transaction Certificate (TC) or Application Authentication Cryptogram (AAC).

ARPC Generation Process on the Issuer Side​

ARPC is created after the issuer validates the incoming ARQC. This occurs in the issuer's secure environment (e.g., using a Hardware Security Module or HSM). The process ensures the response is tied to the specific transaction and card.
  1. Receive and Validate ARQC:
    • The issuer receives the ARQC (tag 9F26) along with transaction data (e.g., from CDOL1, including amount, ATC, unpredictable number) via the payment network (e.g., in an ISO 8583 authorization request).
    • The issuer recomputes the ARQC using the same inputs:
      • Derive the session key (SK_AC) from the Issuer Master Key (IMK-AC), PAN, ATC, and derivation method (e.g., EMV Common Session Key or scheme-specific like Visa Option A).
      • Compute a Message Authentication Code (MAC) over the concatenated transaction data using SK_AC (e.g., 3DES in CBC mode).
    • If the recomputed ARQC matches the received one, the request is authenticated; otherwise, it's declined.
  2. Prepare Input for ARPC:
    • Gather response-specific data: Typically includes the Authorization Response Code (ARC, a 2-byte value like '00' for approval) or Card Status Update (CSU, 4 bytes for additional info).
    • Concatenate with ARQC or other elements, padded as needed (e.g., ISO 9797 Method 1 or 2).
  3. Compute ARPC:
    • Use the same session key (SK_AC) to generate a MAC over the prepared input.
    • There are two standard methods (per EMV):
      • Method 1 (Common, 8-byte ARPC): ARPC = MAC(SK_AC, ARQC XOR ARC). Used for simple approvals/declines.
      • Method 2 (4-byte ARPC): ARPC = MAC(SK_AC, ARQC + CSU + Optional Proprietary Data (0-8 bytes)). Allows more issuer-specific info.
    • Scheme variations:
      • Visa: Often Method 1 with ARPC = MAC(SK_AC, ARQC ⊕ ARC).
      • Mastercard: ARPC = MAC(SK_AC, ARC + Padding).
    • The algorithm is typically 3DES, though AES is supported in newer specs.
  4. Send ARPC:
    • The issuer includes ARPC in the authorization response (e.g., ISO 8583 field 91) back to the acquirer and terminal.

ARPC Validation Process on the Card​

  1. Terminal Forwards ARPC:
    • The terminal sends ARPC to the card via a second GENERATE AC command (P1=01 for response processing) or EXTERNAL AUTHENTICATE (INS=82).
  2. Card Recomputes and Verifies:
    • The card derives the same SK_AC and recomputes ARPC using the received ARC/CSU and its stored ARQC.
    • If the recomputed ARPC matches the received one, the response is authenticated.
    • The card then generates a final cryptogram: TC (for approval) or AAC (for decline), tagged as 9F26 in the response APDU.

Variations and Notes​

  • Offline vs. Online: ARPC is primarily for online transactions; offline approvals may skip it.
  • Contactless Optimizations: In modes like qVSDC, ARPC may be omitted to avoid re-taps, with transactions relying on ARQC alone.
  • Security: The use of session keys and dynamic data ensures each ARPC is unique, protecting against man-in-the-middle attacks.
  • Tools/Testing: Cryptographic calculators (e.g., from EFTLab or NEAPAY) can simulate ARPC for development.

For scheme-specific details, consult EMVCo documents or network guides, as variations exist (e.g., in key lengths or padding).
 
Top