Explain EMV APDU examples

[Good Carder]

EMV and APDUs: Overview​

EMV (Europay, Mastercard, and Visa) is a global standard for chip-based payment cards that enhances security through dynamic data authentication and cryptograms during transactions. It builds on ISO/IEC 7816 standards for smart cards, using Application Protocol Data Units (APDUs) to communicate between the terminal (e.g., POS device) and the card. APDUs in EMV facilitate steps like application selection, data retrieval, and cryptographic operations. Commands are sent as Command APDUs (C-APDUs), and the card responds with Response APDUs (R-APDUs), often including status words (SW1-SW2, e.g., 9000 for success).

EMV transactions typically follow a sequence: application selection, initiation, data reading, cardholder verification (e.g., PIN), and cryptogram generation for authorization. Below, I'll explain key EMV APDU examples in this flow, with hexadecimal formats, breakdowns, and typical responses. These are for contact-based transactions; contactless (e.g., EMV Contactless) may vary slightly.

Typical EMV APDU Flow and Examples​

Here's a high-level sequence of APDUs in an EMV transaction, followed by detailed examples:

1. SELECT Payment System Environment (PSE): Discover available applications.
2. READ RECORD (from PSE): Retrieve Application Identifiers (AIDs).
3. SELECT AID: Choose a specific application (e.g., Visa or Mastercard).
4. GET PROCESSING OPTIONS (GPO): Get card capabilities and data locations.
5. READ RECORD: Fetch card data (e.g., PAN, expiry).
6. VERIFY (PIN): Optional cardholder verification.
7. GENERATE APPLICATION CRYPTOGRAM (AC): Produce ARQC for online authorization or TC/AAC for offline.

1. SELECT PSE (Payment System Environment)​

This command selects the PSE directory to list supported payment applications.

• C-APDU: 00 A4 04 00 0E 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
  • CLA: 00 (ISO 7816 class)
  • INS: A4 (SELECT)
  • P1: 04 (Select by name)
  • P2: 00 (First or only occurrence)
  • Lc: 0E (Length of data)
  • Data: 315041592E5359532E4444463031 ("1PAY.SYS.DDF01" in ASCII)
  • Le: 00 (Maximum response length)
• Typical R-APDU: Data (e.g., TLV-encoded directory) + 90 00 (Success). Example response might include tag 61 for application templates.

2. READ RECORD (from PSE)​

Reads records from the PSE to get AIDs.

• C-APDU: 00 B2 01 0C 00
  • CLA: 00
  • INS: B2 (READ RECORD)
  • P1: 01 (Record number)
  • P2: 0C ((SFI 1 << 3) | 4; SFI=1 for PSE)
  • Le: 00
• Typical R-APDU: 70 [Length] [TLV data, e.g., 61 [AID template]] + 90 00. For example, might return AID at tag 4F.

3. SELECT AID​

Selects a specific payment application by its AID (e.g., Visa Credit).

• C-APDU for Visa Credit: 00 A4 04 00 07 A0 00 00 00 03 10 10 00
  • Data: A0000000031010 (Visa AID)
• C-APDU for Mastercard Debit: 00 A4 04 00 07 A0 00 00 00 04 30 60 00
  • Data: A0000000043060 (Mastercard AID)
• Typical R-APDU: 6F [Length] 84 [AID] A5 [Proprietary data, e.g., PDOL at 9F38] + 90 00. Response includes Application Label (50), PDOL (Processing Data Object List), and preferences.

4. GET PROCESSING OPTIONS (GPO)​

Initiates the transaction by sending terminal data (based on PDOL) and retrieves AIP (Application Interchange Profile) and AFL (Application File Locator).

• C-APDU: 80 A8 00 00 [Lc] 83 [Length] [PDOL data, e.g., terminal country code] 00
  • Example: 80 A8 00 00 02 83 00 00 (Empty PDOL for simple cases)
  • Another: 80 A8 00 00 04 83 02 55 41 (With sample data)
• Typical R-APDU: 77 or 80 [Length] 82 [AIP] 94 [AFL] + 90 00. AIP indicates supported features (e.g., offline data auth); AFL lists files/records to read.

5. READ RECORD (Card Data)​

Reads specific records based on AFL (e.g., PAN, expiry).

• C-APDU: 00 B2 [Record] [P2] 00
  • Example: 00 B2 01 0C 00 (Record 1, SFI from AFL, e.g., 0C)
• Typical R-APDU: 70 [Length] [TLV data, e.g., 5A (PAN), 5F24 (Expiry)] + 90 00. Multiple READ RECORDs may be needed for all AFL entries.

6. VERIFY (PIN)​

Verifies the cardholder's PIN (offline).

• C-APDU: 00 20 00 80 08 [PIN data, e.g., 31 32 33 34 FF FF FF FF (padded "1234")]
• Typical R-APDU: 90 00 (Success) or 63 CX (Failed, X=retries left).

7. GENERATE APPLICATION CRYPTOGRAM (AC)​

Requests a cryptogram (ARQC for online, TC for approval, AAC for decline).

• C-APDU: 80 AE [P1] 00 [Lc] [CDOL data, e.g., amount, terminal data] 00
  • Example for ARQC: 80 AE 80 00 [Lc] [Data] 00 (P1=80 for first AC)
• Typical R-APDU: 80 or 9F27 [Cryptogram type] 9F10 [IAD] 9F36 [ATC] + 90 00. ARQC is used for issuer authorization.

Additional Notes​

• TLV Encoding: EMV data uses Tag-Length-Value (e.g., tag 4F for AID).
• Secure Messaging: Some commands may use encryption/MAC for security.
• Error Handling: SW like 6A82 (File not found) or 6982 (Security not satisfied) indicate issues.
• These examples are simplified; actual implementations depend on card scheme (Visa VSDC, Mastercard M/Chip) and terminal capabilities. For full specs, refer to EMVCo documents.