Explain ARPC verification process

[Papa Carder]

Overview of ARPC Verification Process​

In EMV (Europay, Mastercard, and Visa) transactions, the Authorization Response Cryptogram (ARPC) is an 8-byte cryptographic value generated by the card issuer in response to a valid Authorization Request Cryptogram (ARQC) from the chip card. The ARPC serves as a Message Authentication Code (MAC) that authenticates the issuer's response, confirming the authorization decision (e.g., approve or decline) and preventing man-in-the-middle attacks. It ensures the card only proceeds with a legitimate issuer response. This process is part of the online authorization flow and is defined in EMV specifications (e.g., EMV Book 2: Security and Key Management). The verification occurs on the card side after the issuer's response is relayed back through the payment network and terminal.

The ARPC verification is symmetric to ARQC generation: Both use the same session key (SK_AC) derived from the card's master key, but the ARPC focuses on validating the issuer's decision rather than requesting it. If verification fails (e.g., due to tampering), the card may decline the transaction or generate an AAC (Application Authentication Cryptogram) instead of a TC (Transaction Certificate).

Step-by-Step ARPC Verification Process​

The process begins after the card sends an ARQC to the terminal (via the first GENERATE AC command), which forwards it to the issuer. Here's how verification unfolds:

1. Issuer Receives and Verifies ARQC:
   • The terminal sends the ARQC, along with transaction data (e.g., amount, currency, terminal verification results), to the acquirer and then the issuer via the payment network.
   • The issuer derives the same SK_AC using the card's master key (MK_AC) and the Application Transaction Counter (ATC) from the request.
   • The issuer recomputes the ARQC as a MAC over the same input data (from CDOL1, padded per ISO 9797-1) using SK_AC in 3DES CBC mode (Retail MAC algorithm). If the computed ARQC matches the received one, the card is authenticated as genuine.
2. Issuer Generates ARPC:
   • If the ARQC is valid and the transaction is approved (based on account balance, risk scoring, etc.), the issuer assigns an Authorization Response Code (ARC, e.g., '00' for approval, '01' for referral, or '05' for decline).
   • The issuer computes the ARPC as a MAC using SK_AC over specific data, typically the XOR of the ARQC and ARC (or ARC concatenated with other elements like issuer proprietary data). The exact formula (per EMV Book 2, Annex A1.5) is:
     • Input = ARQC XOR ARC (padded to 8 bytes or more as needed).
     • ARPC = Left 8 bytes of 3DES_CBC_MAC(SK_AC, Input), using ISO 9797-1 Algorithm 3.
   • The issuer sends the ARPC and ARC back to the terminal in the authorization response message (e.g., ISO 8583 field 39 for ARC, field 91 for ARPC).
3. Terminal Forwards to Card:
   • The terminal issues a second GENERATE AC command to the card, including the ARPC and ARC (as part of CDOL2 data).
4. Card Verifies ARPC:
   • The card uses its locally stored SK_AC (from the same transaction) to recompute the expected ARPC over the received ARC (e.g., MAC of ARQC XOR ARC). If the computed ARPC matches the received one, the issuer is authenticated, and the response is trusted.
   • Upon successful verification, the card generates a final cryptogram: TC if approved (based on ARC), or AAC if declined or verification fails.
   • The card may also update internal counters or risk flags (e.g., in the Terminal Verification Results, TVR).
5. Transaction Completion:
   • The terminal receives the card's response (e.g., TC) and completes the transaction, logging it for settlement. If ARPC verification fails, the transaction is declined.

Key Security Aspects​

• Cryptographic Algorithm: Primarily 3DES, with IV=0 and padding per ISO 9797-1. AES variants are emerging in newer EMV specs.
• Failure Handling: If ARPC doesn't match, the card assumes tampering and may force the next transaction offline or decline.
• Contactless Considerations: In NFC modes (ISO 14443), the process is identical but faster, with added relay protections in modern kernels.

For precise implementations, consult EMVCo documents or network-specific guidelines (e.g., Visa or Mastercard), as variations exist (e.g., in CDOL2 data). Tools like cryptographic simulators can demonstrate this in practice.