EMV protocol deep dive (APDU commands, ARQC generation)

[Jollier]

The EMV (Europay, Mastercard, Visa) protocol is the global standard for secure chip-based payment transactions. It replaces magnetic-stripe cards with cryptographic authentication, ensuring tamper resistance and dynamic transaction validation. Below is a deep dive into APDU commands and ARQC (Authorization Request Cryptogram) generation, two core components of EMV transactions.

1. APDU Commands in EMV Transactions​

Application Protocol Data Units (APDUs) are the structured commands exchanged between the payment terminal (POS) and the card during a transaction. These commands enable the terminal to interact with the card’s embedded chip, retrieve data, and execute cryptographic operations.

Key APDU Commands in EMV Flow​

Command	Purpose	Example Use Case
SELECT	Selects the EMV application (e.g., Visa Credit, Mastercard Debit) by its AID (Application Identifier).	SELECT PPSE(Payment System Environment) to list available apps.
GET PROCESSING OPTIONS (GPO)	Requests transaction parameters (e.g., AIP, AFL) after app selection.	Initiates the transaction flow.
READ RECORD(S)	Retrieves static card data (e.g., cardholder name, expiry date) from the card.	Used to gather card details for authorization.
INTERNAL AUTHENTICATE	Validates the card’s authenticity (for Static Data Authentication).	Rarely used in modern cards (replaced by DDA).
GENERATE AC	Requests the card to generate a cryptogram (ARQC, ARPC, or TC).	Core step for transaction authorization.

APDU Command Structure​

Each APDU command follows a standardized format:

CLA | INS | P1 | P2 | Lc (data length) | Data | Le (expected response length)

• CLA: Class byte (e.g., 0x80 for proprietary EMV commands).
• INS: Instruction byte (e.g., 0xA8 for GENERATE AC).
• P1/P2: Parameters (e.g., P1=0x00 for ARQC generation).
• Data: Transaction-specific inputs (e.g., terminal-generated data for ARQC).

Example APDU Exchange​

1. SELECT AID:
   00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
   Selects the Visa debit application.
2. GET PROCESSING OPTIONS (GPO):
   80 A8 00 00 02 83 00 00
   Requests application-specific parameters (AFL, AIP).
3. READ RECORD:
   00 B2 01 0C 00
   Reads record #1 in the SFI (Short File Identifier) 0C.
4. GENERATE AC:
   80 AE 80 00 2A [DATA] 00
   Requests the card to generate an ARQC (see below for DATA structure).

2. ARQC Generation (Authorization Request Cryptogram)​

ARQC is a cryptographic value generated by the card to prove the transaction’s authenticity. It ensures the card is genuine, the transaction data is unaltered, and the cardholder is authorized.

Steps to Generate ARQC​

1. Input Data Collection
   The card aggregates transaction data, including:
   • ATC (Application Transaction Counter): Monotonic counter to prevent replay attacks.
   • Unpredictable Number (UN): Random value from the terminal.
   • Transaction Data: Amount, currency, terminal ID, merchant ID, timestamp, etc.
   • Card Data: Application PAN, AIP, TVR (Terminal Verification Results).
2. Cryptographic Algorithm
   The card applies a cryptographic algorithm (e.g., 3DES, AES, or RSA) using a secret key derived from:
   • Issuer’s Master Key (KMC) and the card’s unique Key Derivation Data (KDD) (e.g., PAN, expiration date).
   • For symmetric cryptography (e.g., Visa’s CVK):
     • Key = 3DES(KMC, KDD)
   • For asymmetric cryptography(e.g., DDA):
     • Card uses its private key to sign the transaction data.
3. ARQC Output
   The result is a 64-bit or 128-bit cryptogram (e.g., 9F 26 08 12 34 56 78 90 AB CD EF 01 23 45 67 89).

Example ARQC Workflow​

1. Terminal sends GENERATE AC command with transaction data.
2. Card concatenates:
   • ATC (0x001A)
   • UN (0x12345678)
   • Transaction data hash (0xABCD...)
3. Applies 3DES encryption with derived key:
   

   ARQC = 3DES(K_DERIVED, ATC || UN || HASH)

4. Returns ARQC to the terminal for transmission to the issuer.

Issuer Verification​

• The issuer decrypts the ARQC using the same key.
• If valid, the transaction is approved (ARPC is sent back).
• If invalid, the transaction is declined (or further checks are triggered).

3. Security Mechanisms in ARQC​

• Dynamic Data: Unlike static magnetic stripes, ARQC changes per transaction (due to ATC and UN).
• Key Hierarchy: Issuers derive card-specific keys from a master key, minimizing exposure.
• Tamper Resistance: EMV chips are designed to resist side-channel attacks (e.g., power analysis).
• Terminal Risk Management: Terminals enforce rules (e.g., TVR flags) to detect anomalies (e.g., invalid ATC).

4. Types of Cryptograms in EMV​

Cryptogram	Purpose	Generated By	Notes
ARQC	Authorization Request	Card	Sent to issuer for approval.
ARPC	Authorization Response	Issuer	Sent back to card to confirm approval.
TC	Transaction Certificate	Card	Used for offline-only transactions (no issuer contact).

5. Challenges and Mitigations​

• Replay Attacks: Prevented by ATC and UN.
• Skimming: EMV’s dynamic cryptograms render skimmed data useless.
• Man-in-the-Middle (MitM): Secure channel protocols (e.g., EMV’s CDA) protect data integrity.
• Key Management: Issuers use Hardware Security Modules (HSMs) to securely derive and store keys.

6. Real-World Example​

Scenario: A cardholder uses a chip card at a U.S. gas station.

1. Terminal selects the Visa Debit AID (0x4F010000000000000001).
2. Card returns AFL (0x940401020304) indicating data records to read.
3. Terminal reads cardholder name, expiry, and public key certificate.
4. Terminal generates UN (0x1A2B3C4D) and sends GENERATE AC with transaction data.
5. Card computes ARQC using its derived key and returns it.
6. Acquirer forwards ARQC to VisaNet, which validates it and approves the transaction.

Conclusion​

EMV’s APDU commands and ARQC generation form the backbone of secure chip transactions. By combining structured data exchange (APDUs) with cryptographic authentication (ARQC), EMV ensures that each transaction is dynamic, tamper-proof, and resistant to fraud. Understanding these mechanisms is critical for developers, security researchers, and payment industry professionals aiming to secure modern payment systems.

 

[Professor]

The EMV (Europay, Mastercard, Visa) protocol is the global standard for secure chip-based card transactions. It relies on cryptographic authentication and dynamic data generation to prevent fraud. Below is a deep dive into EMV transactions, covering APDU commands and ARQC generation.

1. EMV Transaction Flow Overview​

An EMV transaction involves communication between the chip card (ICC) and the terminal/issuer via Application Protocol Data Units (APDUs). Key phases:

1. Application Selection – Choosing the correct payment app (e.g., Visa, Mastercard).
2. Card Authentication – Verifying the card’s legitimacy (SDA/DDA/CCA).
3. ARQC Generation – Dynamic cryptogram for online authorization.
4. Issuer Authorization – Bank approves/declines the transaction.
5. Transaction Completion – ARPC (issuer response) and TC (transaction certificate) generation.

2. APDU Commands in EMV​

APDUs are command-response pairs exchanged between the terminal and the chip.

Key APDU Commands​

Command	Description	Example Use Case
SELECT	Selects the payment application (AID)	00 A4 04 00 (PPSE selection)
GET PROCESSING OPTIONS (GPO)	Starts transaction, retrieves AFL (Application File Locator)	80 A8 00 00
READ RECORD	Reads card data (e.g., PAN, expiry)	00 B2 01 0C
GENERATE AC	Requests ARQC/TC/ARPC cryptogram	80 AE 80 00
VERIFY	PIN verification (if required)	00 20 00 80

APDU Structure​

• Command APDU: CLA INS P1 P2 [Lc] [Data] [Le]
  • CLA (Class), INS (Instruction), P1/P2 (Parameters)
  • Example: 80 AE 80 00 1D [ARQC data] 00 → "Generate ARQC"
• Response APDU: [Data] SW1 SW2
  • SW1 SW2 = Status word (e.g., 90 00 = success)

3. ARQC Generation (Dynamic Cryptogram)​

The Authorization Request Cryptogram (ARQC) is a dynamic, transaction-specific authentication code generated by the chip for online authorization.

How ARQC is Generated​

1. Terminal sends GENERATE AC command with:
   • Transaction details (amount, terminal random, ATC, etc.).
   • Format: 80 AE 80 00 [Data]
2. Chip computes ARQC using:
   • AES-3DES or RSA (depending on card)
   • Session keys derived from issuer master keys (UDK/AC)
   • Input data:
     • ATC (Application Transaction Counter)
     • Unpredictable Number (Terminal challenge)
     • Transaction Data (Amount, currency, etc.)
3. Cryptogram Sent to Issuer
   • Issuer validates ARQC using the same keys.
   • If valid, issuer responds with ARPC (Authorization Response Cryptogram).

ARQC vs. TC vs. ARPC​

Cryptogram	Generated By	Purpose
ARQC	Card	Sent to issuer for online approval
TC	Card	Offline approval (if issuer not contacted)
ARPC	Issuer	Response to ARQC (accept/decline)

4. EMV Security Mechanisms​

• Dynamic Data: ARQC changes per transaction (unlike static magstripe data).
• Card Authentication Methods:
  • SDA (Static Data Authentication) → Basic (less secure).
  • DDA (Dynamic Data Authentication) → Stronger (terminal verifies card’s dynamic signature).
  • CDA (Combined DDA + ARQC) → Most secure (used in contactless).
• Offline Data Authentication (ODA): Ensures card is genuine before going online.

5. Example EMV Transaction Flow​

1. Card Inserted → Terminal sends SELECT command (AID).
2. Terminal requests GPO → Card returns AFL (data to read).
3. Terminal reads records (READ RECORD) → Gets PAN, expiry, etc.
4. Terminal sends GENERATE AC → Card computes ARQC (if online auth needed).
5. Issuer validates ARQC → Returns ARPC (approval code).
6. Terminal confirms → Card generates TC (if approved).

6. Bypassing EMV Security (Fraud Techniques)​

• Pre-play Attacks: Capturing ARQC and replaying it before expiry.
• Jailbroken Terminals: Manipulating transaction data before ARQC generation.
• MITM (Man-in-the-Middle): Intercepting APDUs in compromised terminals.

EMV is highly secure, but fallback to magstripe (if chip fails) or contactless skimming can still be exploited.

Final Thoughts​

• ARQC ensures each transaction is unique and issuer-approved.
• APDUs structure the communication between card and terminal.
• EMV makes cloning extremely hard, but fraudsters target weak points (e.g., contactless limits, fallback magstripe).

Would you like a breakdown of specific APDU sequences or cryptographic key derivation in EMV?

 

[Cloned Boy]

Deep Dive into EMV Protocol: APDU Commands and ARQC Generation​

The EMV (Europay, Mastercard, and Visa) protocol is the global standard for secure payment transactions using chip cards. It ensures secure communication between the card and the terminal through a series of steps involving APDU commands and the generation of cryptograms like the ARQC (Authorization Request Cryptogram). Let’s explore these concepts in detail.

1. APDU Commands in EMV Transactions​

What are APDU Commands?​

APDU (Application Protocol Data Unit) commands are the communication units exchanged between a smart card and a terminal. They are defined by the ISO/IEC 7816-4 standard and consist of:

• Command APDU: Sent by the terminal to the card.
• Response APDU: Sent by the card to the terminal.

Structure of an APDU Command​

A command APDU has the following fields:

• CLA (Class Byte): Specifies the type of command (e.g., interindustry or proprietary).
• INS (Instruction Byte): Indicates the specific operation (e.g., SELECT, READ).
• P1 and P2 (Parameter Bytes): Provide additional context for the command.
• Lc (Length of Command Data): Specifies the length of the data field.
• Data: Contains the command-specific data.
• Le: Specifies the maximum number of response bytes expected.

A response APDU contains:

• Response Data: The data returned by the card.
• SW1 and SW2 (Status Words): Indicate the success or failure of the command.

Key APDU Commands in EMV Transactions​

1. SELECT Command:
   • Used to select the Payment System Environment (PSE) or a specific application on the card.
   • Example: 00 A4 04 00 0F 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31 selects the PSE directory "1PAY.SYS.DDF01".

1. READ RECORD Command:
   • Retrieves data from the card, such as the Application Identifier (AID) or cardholder information.
   • Example: 00 B2 01 02 00 reads a specific record from the card.

1. GET PROCESSING OPTIONS (GPO):
   • Requests the card's processing options, such as the Application Transaction Counter (ATC) and Issuer Application Data (IAD).
   • Example: 80 A8 00 00 02 83 00.

1. GENERATE AC (Application Cryptogram):
   • Generates a cryptogram (e.g., ARQC) for transaction authentication.
   • Example: The terminal sends the CDOL (Card Data Object List) to the card, and the card responds with the ARQC.

1. VERIFY Command:
   • Used for PIN verification to authenticate the cardholder.
   • Example: 00 20 00 80 08 08 12 34 56 78 FF FF FF verifies the PIN "12345678".

2. ARQC Generation in EMV Transactions​

What is ARQC?​

The Authorization Request Cryptogram (ARQC) is a cryptographic value generated by the card during an online transaction. It is used to authenticate the transaction and ensure its integrity.

Steps to Generate ARQC​

1. Input Data:
   • The card uses data from the CDOL1 (Card Data Object List 1), which includes transaction-specific information like the amount, terminal country code, and transaction date.

1. Cryptographic Algorithm:
   • The card applies a symmetric encryption algorithm (e.g., Triple DES or AES) using a secret key shared with the issuer.
   • The input to the algorithm includes:
     • Unpredictable Number (UN): A random number generated by the terminal.
     • Application Transaction Counter (ATC): A counter maintained by the card.
     • CDOL1 Data: Transaction-specific data.

1. Output:
   • The result is the ARQC, which is sent to the issuer for verification. The issuer decrypts the ARQC using the same secret key and compares it with the expected value to validate the transaction.

Key Components in ARQC Generation​

• ATC (Application Transaction Counter): Ensures uniqueness for each transaction.
• IAD (Issuer Application Data): Contains issuer-specific information.
• UN (Unpredictable Number): Prevents replay attacks.

ARQC Verification​

The issuer verifies the ARQC by:

1. Decrypting the cryptogram using the shared secret key.
2. Comparing the decrypted value with the expected data (e.g., transaction amount, ATC).
3. If the values match, the transaction is authenticated; otherwise, it is declined.

3. EMV Transaction Flow Overview​

1. Card Initialization:
   • The card emits an ATR (Answer to Reset) to indicate readiness.
   • The terminal selects the PSE or a specific application using the SELECT command.

1. Data Retrieval:
   • The terminal retrieves the AID, PDOL, and other necessary data using READ RECORD and SELECT AID commands.

1. Processing Options:
   • The terminal sends the GPO command to obtain the card's capabilities and parameters.

1. Cryptogram Generation:
   • The terminal sends the CDOL1 data to the card, and the card generates the ARQC using the GENERATE AC command.

1. Issuer Authentication:
   • The ARQC is sent to the issuer for verification. If valid, the issuer responds with an ARPC (Authorization Response Cryptogram).

Conclusion​

The EMV protocol ensures secure payment transactions through a structured flow of APDU commands and cryptographic mechanisms like ARQC generation. By understanding these processes, developers and businesses can implement robust payment systems that protect against fraud and ensure compliance with global standards.