Explain ARQC generation using SK_AC

[Papa Carder]

Overview of ARQC Generation​

The Authorization Request Cryptogram (ARQC) is an 8-byte cryptographic value generated by an EMV chip card during an online transaction to request authorization from the issuer. It serves as a Message Authentication Code (MAC) that authenticates the card and transaction data, ensuring integrity and preventing replay attacks. The ARQC is computed using the Session Key for Application Cryptogram (SK_AC), which is a transaction-specific key derived from the card's master key. This process follows EMV specifications (e.g., EMV 4.3 Book 2, Section 8.1), typically employing Triple DES (3DES) in CBC mode with ISO 9797-1 MAC Algorithm 3 (also known as Retail MAC). Some modern implementations may use AES instead.

The generation occurs in response to the terminal's GENERATE AC command, which includes data from the Card Risk Management Data Object List 1 (CDOL1). The card decides to generate an ARQC if the transaction requires online processing (based on risk parameters like Issuer Action Codes).

Step-by-Step ARQC Generation Using SK_AC​

1. Derive the Session Key (SK_AC):
   • SK_AC is a 16-byte key unique to each transaction, derived from the ICC Application Cryptogram Master Key (MK_AC) and the 2-byte Application Transaction Counter (ATC), which increments per transaction.
   • MK_AC is a card-specific master key (16 bytes, often 2-key 3DES), derived from the issuer's master key and the card's Primary Account Number (PAN).
   • Derivation uses the Common Session Key (CSK) method (EMV Book 2, Annex A1.4):
     • Prepare left diversification data: ATC || 0xF000 (padded to 8 bytes).
     • Prepare right diversification data: ATC || 0x0F00 (padded to 8 bytes).
     • SK_LEFT = 3DES_encrypt(MK_AC, left data) [first 8 bytes].
     • SK_RIGHT = 3DES_encrypt(MK_AC, right data) [first 8 bytes].
     • SK_AC = SK_LEFT || SK_RIGHT.
   • Some networks (e.g., Mastercard) may include the terminal's Unpredictable Number (UN) in derivation for added randomness.
2. Prepare the Input Data:
   • Collect transaction data as specified in CDOL1 (a list of EMV tags the card requests from the terminal, e.g., Tag 9F02: Authorized Amount, Tag 9F03: Other Amount, Tag 5F2A: Transaction Currency Code, Tag 95: Terminal Verification Results (TVR), Tag 9F37: Unpredictable Number, etc.).
   • Concatenate these data elements in the order defined by CDOL1 (typically 21-55 bytes).
   • Pad the concatenated data to a multiple of 8 bytes using ISO 9797-1 Method 2: Append 0x80, followed by 0x00 bytes as needed.
3. Compute the MAC (ARQC):
   • Use SK_AC to compute a CBC MAC over the padded input data.
     • Split SK_AC into two 8-byte DES keys: SK_AC_Left and SK_AC_Right.
     • Initialize IV (Initialization Vector) to 0x0000000000000000.
     • Encrypt the first block with SK_AC_Left.
     • For subsequent blocks: XOR the previous ciphertext with the next block, then encrypt with SK_AC_Left; for the final block, use a full 3DES (encrypt with Left, decrypt with Right, encrypt with Left).
   • The result is a 16-byte value, but ARQC is the leftmost 8 bytes.
4. Send and Verify:
   • The card sends the ARQC to the terminal in the GENERATE AC response.
   • The terminal forwards it to the issuer, who recomputes the ARQC using the same MK_AC and data to verify authenticity. If valid, the issuer responds with an Authorization Response Cryptogram (ARPC).

Example (Simplified)​

• MK_AC: 0123456789ABCDEF0123456789ABCDEF
• ATC: 0001 → SK_AC: 022551C4FDF76E45988089BA31DC077C (as per sample derivation).
• CDOL1 Data (example): Amount (9F02: 000000010000) + UN (9F37: 12345678) + ... (concatenated ~30 bytes).
• Padded Data: [Data] || 80 00 00 ... (to 32 bytes).
• ARQC = Left 8 bytes of CBC_MAC(SK_AC, Padded Data).

This ensures each ARQC is unique and tamper-proof. For exact computations, use tools like cryptographic calculators or EMV testing software. Refer to EMVCo documents for normative details.