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
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).
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.
||Instruction class – indicates the type of command, e.g. interindustry or proprietary
||Instruction code – indicates the specific command, e.g. “write data”
||Instruction parameters for the command, e.g. offset into file at which to write the data
||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)
||Nc bytes of data
||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
||Nr (at most Ne)
||Command processing status, e.g. 90 00 (hexadecimal) indicates success
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
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