Application Protocol Data Unit

from Wikipedia, the free encyclopedia

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 RESPONSEfetched 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

  1. 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)