« Back to Glossary Index

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.

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 (See Runtime Environment Specification, Java Card Platform, Classic Edition, section 6.2.2 for details). 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.

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

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