ARPC Verification Process in EMV Transactions

[Papa Carder]

The Authorization Response Cryptogram (ARPC) is a cryptographic value (typically 8 bytes) generated by the card issuer in response to a valid Authorization Request Cryptogram (ARQC) from the chip card during an online EMV transaction. Its primary purpose is to authenticate the issuer's response back to the card, ensuring the authorization decision (e.g., approve or decline) has not been tampered with during transmission. This prevents man-in-the-middle attacks and confirms the integrity of the response.

The verification process occurs on the card side after the issuer's response is relayed through the payment network and terminal. It relies on shared symmetric cryptography (usually 3DES or AES) using a session key (SK_AC) derived from the card's master key and transaction-specific data like the Application Transaction Counter (ATC). Below is a step-by-step explanation of the ARPC verification process, based on EMV specifications (e.g., EMV Book 2: Security and Key Management).

Step-by-Step ARPC Verification Process​

1. Preceding Steps: ARQC Generation and Submission:
   • During the transaction, the card generates an ARQC (via the first GENERATE AC command) if online authorization is needed (e.g., based on risk parameters like exceeded offline limits or high transaction value).
   • The ARQC is a MAC computed over transaction data (from CDOL1, padded per ISO 9797-1) using SK_AC.
   • The terminal forwards the ARQC, along with other transaction details (e.g., amount, currency, Terminal Verification Results), to the acquirer and then the issuer via the payment network (e.g., in ISO 8583 messages).
2. Issuer Side: ARQC Validation and ARPC Generation:
   • The issuer derives the same SK_AC using the card's master key (MK_AC) and the ATC from the request.
   • The issuer recomputes the ARQC as a MAC over the same transaction data. If it matches the received ARQC, the card is authenticated as genuine.
   • If valid, the issuer performs risk checks (e.g., account balance, fraud scoring) and assigns an Authorization Response Code (ARC, e.g., '00' for approval, '05' for decline).
   • The issuer then generates the ARPC:
     • Common method (Method 1): ARPC = MAC(SK_AC, ARQC XOR ARC) (padded to 8 bytes; leftmost 8 bytes of the result).
     • Alternative (Method 2): ARPC = MAC(SK_AC, ARQC || Card Status Update (CSU) || Proprietary Data) (4-8 bytes).
     • This uses the same MAC algorithm (e.g., 3DES CBC with ISO 9797-1 Algorithm 3, IV=0).
   • The issuer sends the ARPC, ARC, and any scripts back to the terminal (e.g., in ISO 8583 field 91 for ARPC, field 39 for ARC).
3. Terminal Forwards Response to Card:
   • The terminal receives the issuer's response and issues a second GENERATE AC command to the card, including the ARPC and ARC as part of the Card Risk Management Data Object List 2 (CDOL2) data.
4. Card Side: ARPC Verification:
   • The card uses its locally derived SK_AC to recompute the expected ARPC over the received ARC (e.g., MAC of ARQC XOR ARC, matching the issuer's method).
   • If the computed ARPC matches the received ARPC, the issuer's response is authenticated as genuine and untampered.
   • The card then evaluates the ARC:
     • If ARC indicates approval (e.g., '00'), the card generates a Transaction Certificate (TC) to confirm completion.
     • If ARC indicates decline or referral (e.g., '05' or '01'), or if ARPC verification fails, the card generates an Application Authentication Cryptogram (AAC) to reject the transaction.
   • Verification failure may update internal risk flags (e.g., in Terminal Verification Results, TVR) and force future transactions offline or to require PIN.
5. Transaction Completion:
   • The card sends the final cryptogram (TC or AAC) back to the terminal in the GENERATE AC response.
   • The terminal processes the outcome: Approve if TC, decline if AAC. The transaction is logged for settlement, where the issuer may optionally verify the final cryptogram.

Key Security Aspects​

• Cryptographic Algorithm: Primarily 3DES in CBC mode (Retail MAC), with IV=0 and padding per ISO 9797-1. Newer EMV versions support AES for stronger security.
• Uniqueness: Tied to ATC and unpredictable numbers, ensuring ARPC can't be replayed.
• Contactless (NFC) Notes: The process is identical in NFC modes (ISO 14443), but optimized for speed with streamlined kernels; added risks like relay attacks are mitigated via distance bounding.

This process ensures end-to-end security in online EMV transactions. For full normative details, refer to EMVCo specifications. If implementing or testing, tools like cryptographic calculators can simulate ARQC/ARPC flows.