In the context of smart cards, an Application Protocol Data Unit (APDU) is the communication unit between a smart card reader and a smart card. The structure of the APDU is defined by ISO/IEC 7816-4 Organization, security and commands for interchange.

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.

 

 

 

 

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
1 byte with a value from 1 to 255 denotes Nc with the same length
3 bytes, the first of which must be 0, denotes Nc in the range 1 to 65 535 (all three bytes may not be zero)

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
1 byte in the range 1 to 255 denotes that value of Ne, or 0 denotes Ne=256
2 bytes (if extended Lc was present in the command) in the range 1 to 65 535 denotes Ne of that value, or two zero bytes denotes 65 536
3 bytes (if Lc was not present in the command), the first of which must be 0, denote Ne in the same way as two-byte Le

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

 

 

This class only supports messages which conform to the structure of command and response defined in ISO 7816-4. The behavior of messages which use proprietary structure of messages is undefined. This class optionally supports extended length fields but only when the currently selected applet implements the javacardx.apdu.ExtendedLength interface.

The APDU object is owned by the Java Card runtime environment. The APDU class maintains a byte array buffer which is used to transfer incoming APDU header and data bytes as well as outgoing data. The buffer length must be at least 133 bytes ( 5 bytes of header and 128 bytes of data ). The Java Card runtime environment must zero out the APDU buffer before each new message received from the CAD.

The Java Card runtime environment designates the APDU object as a temporary Java Card runtime environment Entry Point Object (See Runtime Environment Specification, Java Card Platform, Classic Edition, section 6.2.1 for details). A temporary Java Card runtime environment Entry Point Object can be accessed from any applet context. References to these temporary objects cannot be stored in class variables or instance variables or array components.

The Java Card runtime environment similarly marks the APDU buffer as a global array. A global array can be accessed from any applet context. References to global arrays cannot be stored in class variables or instance variables or array components.

The applet receives the APDU instance to process from the Java Card runtime environment in the Applet.process(APDU) method, and the first five header bytes [ CLA, INS, P1, P2, P3 ] are available in the APDU buffer. (The header format is the ISO7816-4 defined 7 byte extended APDU format with a 3 byte Lc field when the Lc field in the incoming APDU header is 3 bytes long).

The APDU class API is designed to be transport protocol independent. In other words, applets can use the same APDU methods regardless of whether the underlying protocol in use is T=0 or T=1 (as defined in ISO 7816-3).

The incoming APDU data size may be bigger than the APDU buffer size and may therefore need to be read in portions by the applet. Similarly, the outgoing response APDU data size may be bigger than the APDU buffer size and may need to be written in portions by the applet. The APDU class has methods to facilitate this.

For sending large byte arrays as response data, the APDU class provides a special method sendBytesLong() which manages the APDU buffer.

 

Related Products

Related Articles

ACS Launches Smart Card Reader Module Product Line

April 20th, 2015|

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

« Back to Glossary Index