Application Protocol Data Unit
Application Protocol Data Unit ( APDU ;Englishfor"data element of the application protocol ") denotes a combined command / data block of thecommunication protocolbetween achip card readerand achip card. A combinedcommand(orcommand) and data block is usedfor data exchange. The structure of the APDU is defined in theISO 7816standard.
APDUs are divided into command APDUs , which transmit commands to the chip card, and response APDUs , which transmit the respective response from the card to a command. Communication is always initiated by the connection interface. A response APDU from the card is sent to a command APDU of the connection interface . The chip card itself never initiates communication.
The structures of command APDU and response APDU are specified in the ISO 7816-4 standard. APDUs represent an information element at the application level. In the OSI layer model, this corresponds to layer 7.
Communication process
At the beginning of communication, the application protocol is usually initialized using answer-to-reset and optional protocol type selection ADPUs.
command APDU
The command APDU consists of a head ( english header ) and an optional trunk (Engl. Body ).
CLA | INS | P1 | P2 | Lc | Data | Le |
---|---|---|---|---|---|---|
Header | body |
The individual bytes have the following meaning:
Identifier | Surname | Length in bytes | meaning |
---|---|---|---|
CLA | Class | 1 | Specifies the command class. It is also signaled whether the secure messaging command is used. |
INS | Instruction | 1 | Specifies the command. Due to restrictions in the byte-oriented protocol T = 0 , only even-numbered instruction bytes may be used. |
P1 | Parameter 1 | 1 | Parameters for the command |
P2 | Parameter 2 | 1 | Parameters for the command |
Lc | Length command | 0, 1 or 3 | Length of the command data (see also section " Coding the length fields ") |
Data | Data | Lc | Command data |
Le | Length expected | 0 to 3 | Length of the expected response data (see also section " Coding the length fields ") |
If no response data are expected, the Le byte of the trunk (or Bodies ) omitted. Likewise, the Lc byte and the data are omitted if no command data is required. Depending on the command and response data, four cases with different structure of the command can be distinguished. They are designated with case 1 to case 4 (English for case 1 to 4 ).
Case 1 command
Case 1 is a simple command without command data and without response data. Therefore, the entire body of the command can be dispensed with:
Header |
Case 2 command
In case 2 the command has no command data, but expects response data. This results in the following command structure:
Header | Le |
Case 3 command
Case 3 describes a command with command data that does not expect any response data and therefore looks like this:
Header | Lc | Data |
Case 4 command
A Case 4 command has both command and response data and therefore the complete command body :
Header | Lc | Data | Le |
Coding of the length fields Lc and Le
There are two different codes for the length fields Lc and Le. The short length fields are supported as standard; the length specification is only one byte long and therefore supports values from 1 to 255 bytes (hexadecimal 0x01 to 0xFF). The special case of Le = 0x00 in this case means an expected length ( english expected length ) of 256 bytes. This means that a maximum of 255 bytes can be written (Lc) and 256 bytes can be read (Le).
Because of the increasing amounts of data that can be stored and read on smart cards (especially in the area of signatures), it became necessary to read or write larger amounts of data within an APDU. The extended APDUs were introduced for this purpose. The historical characters in the ATR can be used to determine whether a smart card supports these larger APDUs. With the extended APDU , Lc or Le can encode a value between 1 and 65535 or 65536. The first field to appear is coded with 3 bytes. With case-2 command APDUS this is the Le field, with case-3 and 4 command APDUS the Lc field. With Case-4-Command-APDUS, the Le field is coded with 2 bytes (the leading zero byte is omitted).
The first Lx field is therefore coded with 3 bytes (B1) = '00', (B2 || B3) = any value, whereby '0000' is not allowed for Lc here (if B2 and B3 for Le to '0000' set this is equivalent to 65536) and the second (if it is available Le) according to the same scheme without the leading zero byte.
response APDU
The so-called response APDU ( English for response APDU ) consists of an optional body and an obligatory end ( trailer ).
Data | SW1 SW2 |
---|---|
body | Trailer |
The termination (or trailer ) contains the two status bytes SW1 and SW2 , which together form the status word ( SW for short or the so-called return code ). The status word provides information about the successful processing of the command or the type of error that prevented or interrupted processing.
The body contains the response data of the command, the length of which was specified in the Le byte of the command APDU . If Le is zero or the command processing was canceled due to an error, no response data are sent. This results in two variants of a response APDU :
- Le not zero, and command successful
Data | SW1 SW2 |
- Le is zero or the command is unsuccessful
SW1 SW2 |
Status words
The status word has either the values 9000 or 61xx and thus indicates the error-free processing of the command, or the values 62xx to 6Fxx, which indicate the type of deviation from the normal sequence. The status words are subject to the systematics given in the table.
61xx and 9000 | 62xx | 63xx | 65xx | 64xx | 67xx to 6Fxx |
---|---|---|---|---|---|
Process completed | Process canceled | ||||
normal | warning | Execution failure | Examination errors | ||
No data changed | Data in EEPROM changed | No data changed |
The following table shows the most important status words and their meaning:
Status word | meaning | annotation |
---|---|---|
61xx | Command executed successfully. xx data bytes can be GET RESPONSE fetched with the '' command.
|
Status word for controlling the T = 0 protocol |
6281 | The data returned may be incorrect. | |
6282 | Since the end of the file was reached earlier, only fewer than Le Bytes could be read. | |
6283 | The selected file is locked ( English invalidated , literally "invalid"). | |
6284 | The File Control Information ( FCI ) does not conform to ISO 7816-4 . | |
62xx | Warning; State of the non-volatile memory not changed | |
63Cx | Counter has reached the value x (the exact meaning depends on the command) | |
63xx | Warning; State of the non-volatile memory changed | |
64xx | Execution failure; State of the non-volatile memory not changed | |
6581 | Memory failure | |
65xx | Execution failure; State of the non-volatile memory changed | |
6700 | Command length ( Lc ) or expected response length ( Le ) incorrect | |
6800 | Functions in the class byte are not supported | |
6881 | Logical channels are not supported | |
6882 | Secure messaging is not supported | |
6900 | Command not allowed | |
6981 | Command incompatible with the file structure | |
6982 | Security status not fulfilled | |
6983 | Authentication method is blocked | |
6984 | Referenced data are locked | |
6985 | Terms of use are not met | |
6986 | Command not allowed (no EF selected) | |
6987 | Expected secure messaging objects not found | |
6988 | Secure messaging data objects are incorrect | |
6A00 | Wrong parameters P1 / P2 | |
6A80 | Wrong data | |
6A81 | Function is not supported | |
6A82 | file was not found | |
6A83 | Record (Engl. Record ) not found the file | |
6A84 | Not enough space in the file | |
6A85 | Lc inconsistent with the TLV structure | |
6A86 | Incorrect parameters P1 / P2 | |
6A87 | Lc inconsistent with P1 / P2 | |
6A88 | Referenced data not found | |
6B00 | Wrong parameters P1 / P2 | |
6Cxx | Wrong length Le; xx indicates the correct length | Status word for controlling the T = 0 protocol |
6D00 | The command (INS) is not supported | |
6E00 | The command class (CLA) is not supported | |
6F00 | The command was canceled with an unknown error | |
9000 | Command executed successfully |
Web links
Individual evidence
- ↑ ISO / IEC 7816-4: 2005 Identification cards - Integrated circuit cards - Part 4: Organization, security and commands for interchange. Iso.org, October 3, 2008, accessed December 18, 2016 . (English)