Detailed Breakdown: ARQC Validation Process at Issuer Banks

[Cloned Boy]

This technical guide explains the complete end-to-end validation process that occurs when an issuer bank receives an ARQC (Authorization Request Cryptogram) from a chip card during an EMV transaction.

1. ARQC Validation Overview​

The validation occurs in <50ms through these stages:

sequenceDiagram
Card ->> Terminal: Generates ARQC (Dynamic Cryptogram)
Terminal ->> Acquirer: Forwards ARQC + Transaction Data
Acquirer ->> Issuer: Routes Authorization Request
Issuer ->> HSM: Sends ARQC for Validation
HSM ->> Issuer: Returns ARPC (Approval/Decline)
Issuer ->> Acquirer: Authorization Response
Acquirer ->> Terminal: Final Approval

2. Step-by-Step Validation Process​

Phase 1: Cryptogram Receipt & Parsing​

1. Transaction Data Packet Received:
   • ARQC (8 bytes)
   • ATC (2 bytes)
   • Unpredictable Number (4-8 bytes)
   • Transaction details (amount, merchant ID, etc.)
2. Data Extraction:
   

   # Example transaction packet structure
   transaction = {
   'arqc': 'A1B2C3D4E5F6G7H8',
   'atc': '0001',
   'un': '12345678',
   'amount': '000000010000', # $100.00
   'pan': '411111******1111'
   }

Phase 2: Card Identification & Key Retrieval​

1. PAN BIN Lookup:
   • Identify issuing bank from first 6 digits
   • Route to correct authorization system
2. HSM Key Fetch:
   • Retrieve ICC Master Key (IMK) for the card
   • Uses hardware-secured key storage:
     

     // HSM Key Storage Structure
     struct CardKeys {
     char PAN[16];
     byte IMK[16]; // 112-bit TDES
     byte DerivationMethod;
     };

Phase 3: Session Key Regeneration​

Formula:

Session Key (SK) = TDES(IMK, ATC || ATC || 00000000)

HSM Calculation:

from Crypto.Cipher import DES3

imk = bytes.fromhex("00112233445566778899AABBCCDDEEFF")
atc = bytes.fromhex("0001")
input_block = atc + atc + bytes.fromhex("0000000000000000")

cipher = DES3.new(imk, DES3.MODE_ECB)
session_key = cipher.encrypt(input_block)
# session_key = A1B2C3D4E5F6G7H8

**Phase 4: ARQC Recalculation & Matching​

Data Preparation:

ARQC Input = Amount + UN + ATC + Terminal Data

HSM Recalculation:

def calculate_arqc(sk, data):
cipher = DES3.new(sk, DES3.MODE_CBC, iv=b'\x00'*8)
padded = data + b'\x80' + bytes((8 - len(data) % 8))
return cipher.encrypt(padded)[-8:]

expected_arqc = calculate_arqc(session_key,
bytes.fromhex("000000010000") + # Amount 
bytes.fromhex("12345678") +     # UN
bytes.fromhex("0001"))          # ATC

Validation Logic:

if expected_arqc == received_arqc:
status = "VALID"
else:
status = "INVALID_CRYPTOGRAM"

Phase 5: Additional Fraud Checks​

1. ATC Validation:
   • Must be > last recorded ATC
   • Checked against database:
     

     SELECT last_atc FROM cards WHERE pan='411111******1111'
     -- Current ATC must be > last_atc

2. Velocity Checking:
   • Multiple transactions in short time
   • Geographic impossibilities
3. Issuer-specific Rules:
   • Country restrictions
   • Merchant category blocks

Phase 6: ARPC Generation​

Approved Transaction:

arpc = calculate_arqc(session_key,
received_arqc +
bytes.fromhex("00")) # Approval code

Declined Transaction:

arpc = calculate_arqc(session_key,
received_arqc +
bytes.fromhex("01") + # Decline code
bytes.fromhex("0001")) # Reason

3. HSM Hardware Security Module) Operations​

Critical security components:

Component	Function
Key Vault	Secure IMK storage
Crypto Engine	TDES/AES acceleration
Tamper Detection	Zeroizes keys if breached
FIPS 140-2	Compliance certification

Sample HSM Command:

> validate_arqc --pan 411111******1111 --arqc A1B2C3D4 --atc 0001 --un 12345678
< status=VALID arpc=5E9A3FB27C01D466

4. Real-World Validation Flow Example​

Transaction Attempt:

• Card: Visa Platinum ending 1111
• Amount: $120.00
• ATC: 0027 (previous was 0026)

Validation Steps:

1. HSM derives session key:
   

   SK = TDES(IMK_VISA_1111, "0027002700000000")

2. Recomputes ARQC:
   

   ARQC = TDES(SK, "000001200000123456780027")

3. Compares with received ARQC
4. Checks ATC > 0026
5. Approves with ARPC:
   

   ARPC = TDES(SK, ARQC||00)

5. Why This Prevents Cloning​

1. No IMK Extraction:
   • Never leaves HSM
   • Different per card
2. Dynamic ARQC:
   • Changes with UN + ATC
   • Terminal-specific
3. Multi-Layer Validation:
   Diagram:
   
   
   
   
   

   graph TD
   A[ARQC] --> B{Cryptogram Valid?}
   B -->|Yes| C[ATC Check]
   B -->|No| D[Decline]
   C -->|Valid| E[Fraud Checks]
   C -->|Invalid| D
   E -->|Clean| F[Approve]
   E -->|Risky| G[Decline]

6. Edge Cases & Exceptions​

1. Offline Transactions:
   • Uses CDA cryptograms
   • Limited to small amounts
2. Network Outages:
   • Offline floor limits apply
   • Risk of later chargebacks
3. Legacy Systems:
   • Some still use SDA (static auth)
   • Being phased out globally

7. Security Evolution​

• 2005: Basic ARQC validation
• 2012: Mandatory DDA in Europe
• 2018: Contactless cryptogram limits
• 2023: AES-256 migration begins

This multi-layered validation explains why modern EMV cloning requires either:

• Physical issuer HSM compromise (near impossible)
• Quantum computing (not yet feasible)
• Terminal malware (only affects specific transactions)