In the context of smart cards, an Application Protocol Data Unit (APDU) is the unit of communication between a smart card reader and a smart card. The structure of the APDU is defined by ISO/IEC 7816-4, which specifies organization, security, and commands for interchange.
An APDU consists of either a command message or a response message, which are sent from the interface device to the card or vice versa. A command-response pair is formed by sending a command, processing it in the receiving entity, and sending back a response. A specific response corresponds to a specific command.
The structure of a Command APDU (C-APDU) includes a required header (CLA INS P1 P2) and an optional body ([Lc field] [Data field] [Le field]). The CLA byte defines an application-specific class of instructions, and the INS byte defines a specific instruction within that class. The P1 and P2 fields can further qualify the instruction and provide input data. The Lc field defines the number of data bytes in the Data field, which can contain up to 255 bytes of data. The Le field defines the maximum number of bytes in the data field of the Response APDU (R-APDU).
The structure of a Response APDU (R-APDU) includes an optional body and a mandatory trailer. The Data field contains the response data, which can be up to 255 bytes and is returned by the applet. The fields SW1 and SW2 provide feedback about the execution of the C-APDU, with the status word 0x9000 representing successful execution of the command.
APDU message structure
A step in an application protocol consists of sending a command, processing it in the receiving entity and sending back the response. Therefore a specific response corresponds to a specific command, referred to as a command-response pair.
An application protocol data unit (APDU) contains either a command message or a response message, sent from the interface device to the card or conversely. In a command-response pair, the command message and the response message may contain data, thus inducing four cases which are summarized in the table below.
Command APDU
A C-APDU consists of a required header (CLA INS P1 P2) and an optional body ([Lc field] [Data field] [Le field]). The CLA byte defines an application-specific class of instructions. According to the ISO7816 standard, byte values between 0xB0 and CF can be used. The INS byte defines a specific instruction within the class of instructions defined by the CLA byte. For valid CLA values, the application developer can define his own application specific instructions. The P1 and P2 fields can be used to further qualify the instruction and to provide input data respectively. The other fields are optional: the Lc field defines the number of data bytes in the data field; the Data field can contain up to 255 bytes of data; and the Le field defines the maximum number of bytes in the data field of the R-APDU.
Response APDU
An R-APDU consists of an optional body and mandatory trailer. The Data field contains the response data, maximum 255 bytes, returned by the applet. The fields SW1 and SW2 provide feedback about the execution of the C-APDU. Several status words are predefined in the ISO7816 standard. The status word 0x9000 represents successful execution of the command.
In Java Card programming, the applet receives the APDU instance to process from the Java Card runtime environment in the Applet. process (APDU) method. The APDU message is structured according to the ISO/IEC 7816-4 standard, which defines the organization, security, and commands for interchange between a smart card and a card accepting device.
The APDU message structure consists of a header (CLA, INS, P1, P2, P3) and an optional body ([Lc field] [Data field] [Le field]) for command APDU, and an optional body and mandatory trailer (SW1, SW2) for response APDU. The APDU message may contain data, which is transferred as bytes.
The Java Card runtime environment provides an APDU class, which is used to manage the APDU buffer and provides methods to read and write data to and from the APDU buffer. The APDU class API is designed to be transport protocol independent, which means that applets can use the same APDU methods regardless of the underlying protocol in use (e.g. T=0 or T=1 as defined in ISO 7816-3).
Command APDU |
||||||
Header (required) | Body (optional) | |||||
CLA | INS | P1 | P2 | Lc | Data Field | Le |
Command APDU | ||
---|---|---|
Field name | Length (bytes) | Description |
CLA | 1 | Instruction class – indicates the type of command, e.g. interindustry or proprietary |
INS | 1 | Instruction code – indicates the specific command, e.g. “write data” |
P1-P2 | 2 | Instruction parameters for the command, e.g. offset into file at which to write the data |
Lc | 0, 1 or 3 | Encodes the number (Nc) of bytes of command data to follow
0 bytes denotes Nc=0 |
Command data | Nc | Nc bytes of data |
Le | 0, 1, 2 or 3 | Encodes the maximum number (Ne) of response bytes expected
0 bytes denotes Ne=0 |
Response APDU | ||
Response data | Nr (at most Ne) | Response data |
SW1-SW2 (Response trailer) |
2 | Command processing status, e.g. 90 00 (hexadecimal) indicates success |
SW1-SW2 | 2 | Command processing status, e.g. 6A 82 (hexadecimal) indicates data object not found |
SW1-SW2 | 2 | Command processing status, e.g. 69 82 (hexadecimal) indicates security status not satisfied |
List of most common APDU commands:
- SELECT FILE (0x00A4)
- READ BINARY (0x00B0)
- UPDATE BINARY (0x00D6)
- READ RECORDS (0x00B2)
- UPDATE RECORDS (0x00DC)
- APPEND RECORD (0x00E2)
- VERIFY (0x0020)
- CHANGE REFERENCE DATA (0x0024)
- RESET RETRY COUNTER (0x002C)
- GET CHALLENGE (0x0084)
- INTERNAL AUTHENTICATE (0x0088)
- EXTERNAL AUTHENTICATE (0x0082)
- TERMINATE CARD USAGE (0x826E)
- ERASE BINARY (0x00DA)
- ERASE RECORDS (0x00DC)
Note that this is not an exhaustive list and there are many other APDU commands defined in the ISO/IEC 7816-4 standard.
List of more APDU’s:
Commands: https://gist.github.com/hemantvallabh/d24d71a933e7319727cd3daa50ad9f2c
Responses: https://www.eftlab.com/knowledge-base/complete-list-of-apdu-responses
More information about APDU’s: https://cardwerk.com/smart-card-standard-iso7816-4-section-6-basic-interindustry-commands/
Related Products
Related Articles
ACS Launches ACOS5-EVO Cryptographic Smart Card
HONG KONG, 3 May 2019 - Advanced Card Systems Ltd. (ACS), Asia Pacific's top supplier and one of the world's top 3 suppliers of PC-linked smart card readers (Source: Frost & Sullivan), introduces the ACOS5-EVO Cryptographic Smart
ACS Launches Smart Card Reader Module Product Line
HONG KONG, 20 April, 2015 - Advanced Card Systems Ltd. (ACS, a wholly owned subsidiary of Advanced Card Systems Holdings Ltd., SEHK: 8210), Asia Pacific's top supplier and one of the world's top 3 suppliers of PC-linked smart card readers