Explain APDU structures in detail

[Good Carder]

What is an APDU?​

An Application Protocol Data Unit (APDU) is the fundamental communication unit used between a smart card reader (or interface device) and a smart card, enabling the exchange of commands and responses. It is a binary format defined primarily in ISO/IEC 7816-4, which outlines the organization, security, and commands for interchange in integrated circuit cards. APDUs are protocol-agnostic and support various transmission protocols (e.g., T=0 or T=1 as per ISO/IEC 7816-3), making them essential for applications like payment cards, SIM cards, identification, and security tokens.

There are two main categories:

• Command APDU (C-APDU): Sent from the reader to the card to initiate an operation.
• Response APDU (R-APDU): Sent from the card to the reader in reply, indicating the outcome.

Each C-APDU typically pairs with an R-APDU, forming a command-response pair. The structures support data exchanges up to 65,535 bytes (or 65,536 in some extended cases), with fields encoded in hexadecimal.

Command APDU Structure​

A Command APDU consists of a mandatory 4-byte header and an optional body. The header specifies the instruction, while the body handles data input and expected output length. The length fields (Lc and Le) use variable encoding for efficiency: 0 bytes (absent), 1 byte (short, 1–255/256), or 2/3 bytes (extended, up to 65,535/65,536).

Here's a breakdown of the fields:

Field	Length (Bytes)	Description
CLA (Class)	1	Defines the instruction class (e.g., interindustry like 0x00, or proprietary). Indicates attributes like secure messaging or logical channel.
INS (Instruction)	1	Specifies the command (e.g., 0xA4 for SELECT, 0xB0 for READ BINARY).
P1 (Parameter 1)	1	Qualifies the instruction (e.g., mode or high byte of offset). Often 0x00 if unused.
P2 (Parameter 2)	1	Similar to P1 (e.g., low byte of offset or additional qualifiers). Often 0x00 if unused.
Lc (Length Command)	0, 1, 2, or 3	Encodes Nc (number of bytes in Data field): Absent (Nc=0), short (1–255), or extended (1–65,535; first byte 0x00 for 3-byte).
Data Field	Nc (0–65,535)	Command data (e.g., file ID, PIN, or write payload).
Le (Length Expected)	0, 1, 2, or 3	Encodes Ne (max bytes expected in response): Absent (Ne=0), short (1–256; 0x00=256), or extended (1–65,536; 0x00 00=65,536).

Four Cases of Command APDUs
Command APDUs are classified into four cases based on data exchange needs, as per ISO/IEC 7816-4. This determines the presence of Lc, Data, and Le:

1. Case 1: No data sent or expected (shortest). Format: CLA INS P1 P2. Example: Simple status check.
2. Case 2: Data sent, none expected. Format: CLA INS P1 P2 Lc Data. Example: WRITE BINARY (e.g., update file).
3. Case 3: No data sent, data expected. Format: CLA INS P1 P2 Le. Example: READ BINARY (e.g., fetch file content).
4. Case 4: Data sent and expected. Format: CLA INS P1 P2 Lc Data Le. Example: Authenticate with challenge-response.

Extended lengths apply mainly to Cases 2–4 for larger data.

Response APDU Structure​

A Response APDU includes optional data and a mandatory 2-byte trailer with status words. The data length (Nr) is ≤ Ne from the C-APDU's Le; if Le is absent, Nr can be arbitrary (up to card limits).

Field	Length (Bytes)	Description
Data Field	Nr (0–65,536)	Response data (e.g., read bytes, authentication result). If Nr < Ne, all data is sent; if larger, truncated to Ne.
SW1 (Status Word 1)	1	High byte of status (e.g., 0x90 for success, 0x6A for error).
SW2 (Status Word 2)	1	Low byte, providing details (e.g., 0x00 for no error).

Common SW1-SW2 pairs:

• 9000: Success.
• 6A82: File not found.
• 6982: Security condition not satisfied.
• 6300: Verification failed (e.g., wrong PIN).

Examples​

1. SELECT Application (Case 4, Short): C-APDU: 00 A4 04 00 07 A0 00 00 00 18 40 01 (Select AID A0000000184001, Le absent or 00). R-APDU: (No data) 90 00 (Success).
2. READ BINARY (Case 3): C-APDU: 00 B0 00 00 10 (Read 16 bytes from offset 0). R-APDU: [16 bytes data] 90 00.
3. VERIFY PIN (Case 2): C-APDU: 00 20 00 80 08 31 32 33 34 35 36 37 38 (Verify 8-byte PIN "12345678"). R-APDU: 90 00 (Success) or 6300 (Failed).

Additional Notes​

• Secure Messaging: CLA can indicate encryption or integrity protection.
• Chaining: For data >255 bytes, commands can be chained (e.g., via CLA bit).
• Standards Evolution: ISO/IEC 7816-4:2020 includes updates for extended lengths and biometrics. For SIM-specific, refer to ETSI TS 102 221.
• Implementation: In software (e.g., Java Card or NFC apps), APDUs are handled via buffers; errors in structure lead to rejection.

Additional APDU Examples​

Building on the previous examples, here are more common APDU command-response pairs based on ISO/IEC 7816-4 and related standards. These illustrate various operations like data retrieval, authentication, and updates. As before, examples are in hexadecimal format, and status words (SW1-SW2) indicate outcomes (e.g., 9000 for success).

1. GET DATA (Case 3, Short): Retrieves specific data objects from the card, such as the cardholder verification method list or application data. C-APDU: 00 CA 00 00 00 (Get data for tag 0x0000; Le=0 implies maximum available). R-APDU: [Data bytes, e.g., for a simple tag] 90 00 (Success with data returned).
2. INTERNAL AUTHENTICATE (Case 4, Short): Requests the card to perform internal authentication, often using a challenge for mutual verification. C-APDU: 00 88 00 00 08 01 02 03 04 05 06 07 08 00 (Authenticate with 8-byte challenge data; Le=0 for maximum response). R-APDU: [8-byte cryptogram or signature] 90 00 (Success).
3. EXTERNAL AUTHENTICATE (Case 2, Short): Authenticates the host to the card, typically sending a cryptogram in response to a previous GET CHALLENGE. C-APDU: 00 82 00 00 08 11 22 33 44 55 66 77 88 (Authenticate with 8-byte cryptogram). R-APDU: 90 00 (Success) or 6300 (Authentication failed).
4. UPDATE BINARY (Case 2, Extended): Updates (writes) data in a binary file at a specified offset. For larger data, use extended Lc. C-APDU: 00 D6 00 00 00 00 05 48 65 6C 6C 6F (Update 5 bytes "Hello" at offset 0; extended Lc with leading 00 for 3-byte). R-APDU: 90 00 (Success).
5. GET CHALLENGE (Case 3, Short): Requests a random challenge from the card for authentication processes. C-APDU: 00 84 00 00 08 (Get 8-byte challenge). R-APDU: [8-byte random data, e.g., 12 34 56 78 9A BC DE F0] 90 00 (Success).
6. GET RESPONSE (Case 3, Short): Retrieves remaining data from a previous command that returned partial results (e.g., SW1-SW2=61XX indicating bytes available). C-APDU: 00 C0 00 00 10 (Get 16 remaining bytes). R-APDU: [16 bytes of remaining data] 90 00 (Success).

These examples cover a range of security and file management operations typical in smart card interactions, such as in EMV payments or secure access systems. For real implementations, parameters like P1/P2 and data must align with the card's application-specific requirements, and secure messaging may encrypt or MAC the APDU. If you need examples for a specific context (e.g., Java Card or SIM), let me know!