Expanded Guide to ARPC Calculation Techniques in EMV Transactions

[Student]

The Authorization Response Cryptogram (ARPC) is a critical component of online EMV transactions, providing issuer authentication back to the card. After the card generates an ARQC (Authorization Request Cryptogram) to prove its authenticity, the issuer (via Host Security Module - HSM) verifies the ARQC and, if approved, generates an ARPC. The card then verifies the ARPC before generating a TC (Transaction Certificate) for approval or an AAC (Application Authentication Cryptogram) for decline.

Prerequisite: Session Key Derivation (Essential for ARQC Verification and ARPC Generation)​

Both ARQC verification and ARPC require the same session key (SK_AC) derived from the Issuer Master Key (IMK_AC).

Common method (EMV Book 2, Option A - most widely used):

1. Derive ICC Unique Key (UDK) from IMK_AC using PAN + PSN (PAN Sequence Number).
2. Derive SK_AC = 3DES(UDK) on (ATC || padded/inverted ATC).

Variations exist:

• Visa: Specific CVN (Cryptogram Version Number) like 10, 18, 22 with slight differences in data padding/MAC algorithm.
• Mastercard: M/Chip profile with its own derivation.
• AWS Payment Cryptography and tools like neapay.com support multiple modes (EMV_OPTION_A, Visa, Mastercard).

The issuer must recreate the exact SK_AC to verify ARQC matches the recomputed cryptogram over transaction data (amount, TVR, etc.).

ARPC Methods (EMV Book 2, Section 8.2)​

Method 1: 8-Byte ARPC (Most Common, Used in Visa CVN 10, Many Legacy Implementations)​

Inputs:

• Verified ARQC (8 bytes)
• ARC (Authorization Response Code, 2 bytes, e.g., '3030' hex for "00" approval)
• SK_AC (16 bytes, 3DES)

Steps (Exact from EMV spec):

1. Pad ARC to 8 bytes: X = ARC || 000000000000 (6 zeros). Example: ARC = '3030' → X = 3030000000000000
2. Y = ARQC ⊕ X (XOR)
3. ARPC = 3DES-Encrypt(SK_AC, Y) (single 8-byte block)

Detailed Example (From public tools/forums):

• ARQC: 0C25134A77B0F6B3
• ARC: "Y3" (Unable to go online, offline approved) → 5933 → padded X = 5933000000000000
• SK_AC: 7CBA97ABD6CB6E0B29A7457A7332DFC4
• Y = 0C25134A77B0F6B3 ⊕ 5933000000000000 = 5516134A77B0F6B3
• ARPC = 47CA7F6274A9FCB1

This method is simple and embeds the ARC securely.

Method 2: 4-Byte ARPC (Used in Visa CVN 18/22, Mastercard M/Chip)​

Allows sending additional data (Card Status Update - CSU) to the card.

Inputs:

• ARQC (8 bytes)
• CSU (4 bytes, issuer instructions like script execution flags)
• Optional Proprietary Data (0-8 bytes)

Steps:

• Concatenate: Data = ARQC || CSU || [Proprietary]
• Compute MAC over Data using ISO 9797-1 Algorithm 3 (Retail MAC) with SK_AC (padding Method 2 often)
• ARPC = First 4 bytes of MAC

This provides more flexibility for issuer scripting.

Scheme-Specific Variations​

Scheme	Common CVN/Profile	ARPC Method	Key Notes
Visa	CVN 10	Method 1	Padding Method 1, simpler derivation
Visa	CVN 18/22	Method 2	Padding Method 2, includes more data
Mastercard	M/Chip	Method 2	Proprietary extensions, often 4-byte ARPC
Generic EMV	-	Both	Base spec, 3DES (migrating to AES)

Practical Tools and Implementation​

• Online Calculators: neapay.com, paymentcardtools.com (support CVN 10/18/MChip), eftlab.com Cryptographic Calculator.
• HSMs/Services: AWS Payment Cryptography (supports verification + ARPC gen), Thales/Atalla.
• Code Snippets(Java Card example for Method 1 verification):
  

  byte[] Y = xor(ARQC, paddedARC);
  Cipher cipher = Cipher.getInstance(Cipher.ALG_DES_CBC_NOPAD, false); // Or ECB for single block
  cipher.init(sessionKey, Cipher.MODE_ENCRYPT);
  byte[] ARPC = new byte[8];
  cipher.doFinal(Y, 0, 8, ARPC, 0);

• For testing: Use known test keys/ATC from EMV test card sets.

ARPC ensures mutual authentication in online flows, preventing man-in-the-middle attacks. Modern migrations include AES support (EMV 4.3+). For proprietary details, consult scheme specs (Visa VIS, Mastercard M/Chip). If implementing, start with public calculators for validation before HSM integration.