Previous Table of Contents Next


This application software makes use of a protocol to exchange control and information between the reader and the card. This protocol is based on a block structure called an APDU. These APDUs are exchanged by making use of the T=0 and T=1 link-layer protocols. A software component on the card interprets these APDUs and performs the specified operation; this architecture is illustrated in Figure 4.4.


Figure 4.4.  Application communications architecture.

The APDU structure defined in ISO 7816-4 is very similar to the TPDU structure defined in ISO 7816-3 for the T=0 protocol. When the APDU structure is transported by the T=0 protocol, the elements of the APDU directly overlay the elements of the TPDU; hence, the comments earlier about the lack of effective protocol layering with the T=0 protocol.

An ISO 7816-4 APDU is

  Link-level protocol independent
  Defined at the application level

An instruction APDU is a message structure which carries a command or instruction (and perhaps data) from the reader to the card. A response APDU is a message structure that carries a response (and perhaps data) from the card back to the reader.

The ISO 7816-4 APDU

The messages used to support the ISO 7816-4 defined application protocol(s) comprise two structures—one used by the reader-side of the channel to send commands to the card and the other used by the card to send responses back to the reader. The former is referred to as the command APDU and the latter as the response APDU.

As illustrated in Figure 4.5, the command APDU comprises a header and a body, each of which is further subdivided into several fields. The header includes CLA, INS, P1, and P2 fields. CLA and INS define an application class and instruction group as described, for example, in ISO 7816-4. The P1 and P2 fields are used to qualify specific instructions and are therefore given specific definitions by each [CLA,INS] instruction. The body of the APDU is a variable size (and form) component which is used to convey information to the card’s APDU processor as part of a command or to convey information from the card back to the reader as part of a response to a command. The Lc field specifies the number of bytes to be transferred to the card as part of an instruction; it contains the length of the data field. The data field comprises data which must be conveyed to the card in order to allow its APDU processor to execute the command specified in the APDU. The Le field specifies the number of bytes which will be returned to the reader by the card’s APDU processor in the response APDU for this particular command. The body of the APDU can have four different forms:

  No data is transferred to or from the card, so the APDU includes only the header component. This is referred to as Case 1.
  No data is transferred to the card, but data is returned from the card so the body of the APDU includes only a non-null Le field. This is referred to as Case 2.
  Data is transferred to the card, but no data is returned from the card as a result of the command so the body of the APDU includes the Lc field and the data field. This is referred to as Case 3.
  Data is transferred to the card and data is returned from the card as a result of the command so the body of the APDU includes the Lc field, the data field, and the Le field. This is referred to as Case 4.


Figure 4.5.  The command APDU structure.

Figure 4.6 illustrates the much simpler structure of the response APDU structure. It includes a body and a trailer. The body is either null or includes a data field, depending on the specific command that it is a response to, and on whether that command was successfully executed by the card’s APDU processor. If the response APDU does include a data field, its length is determined by the Le field of the command to which the response corresponds.


Figure 4.6.  The response APDU structure.

The response APDU also includes a trailer field, which can comprise two fields of status information that are referenced as SW1 and SW2. These fields return (from the card’s APDU processor) to the reader-side application a status code that, according to ISO 7816-4, has a numbering scheme in which one byte is used to convey an error category and the other byte is used to convey a command specific status or error indication. This numbering scheme is illustrated in Figure 4.7. Appendix A includes a table of error/status codes with each command.


Figure 4.7.  ISO/IEC 7816-4 return codes.

The CLA code that is included in each command APDU has two additional components to be noted:

  The two low-order bits of the CLA byte can be used to designate a logical communication channel between the reader-side application and the card’s APDU processor.
  The next two higher-order bits of the CLA byte can be used to indicate that secure messaging is to be used between the reader-side application and the card’s APDU processor.

Once the link-level protocol is established between the reader-side application and the card’s APDU processor, a base-level (command) logical channel is created. This is indicated (in the CLA byte) by both of the low-order bits being 0. Additional logical channels can be created by using the Manage Channel command, which is defined by ISO 7816-4.

ISO 7816-4 also defines a modest, secure messaging protocol which can be used to ensure privacy and integrity of APDUs transferred between the reader-side application and the card’s APDU processor.


Previous Table of Contents Next