EMV model of interaction with smart cards

APDU Protocol

The APDU protocol is defined in the ISO 7816-4 standard. (Later in this book we will refer to the sections of the standard as follows: ISO 7816-X – specification X of the ISO 7816 standard.) This is an application-level protocol for data exchange between a smart card and a host application. According to the ISO 7816-4 specification, APDU messages come in two formats: the first format is used by the host application on the CAD side to transmit commands to the card, the second format is used by the card to send response messages to the host application. The first format is called the APDU command (C-APDU), and the second is called the APDU response (R-APDU). Each APDU command must have an APDU response. The structure of the command and response is shown in Tables 2.1 and 2.2, respectively.

The APDU command header consists of 4 bytes: CLA (instruction class), INS (instruction code), P1 and P2 (parameters 1 and 2). The class byte defines the category of the APDU command or response. The instruction byte defines the instruction that is contained in the command. The bytes of the parameters P1 and P2 are used to further refine the instruction.

An optional variable-length block can be passed after the APDU command header. The Lc field in this block defines the length of the data field in bytes. The data field contains information that is sent to the card. It is designed to execute the instruction specified in the APDU header. The last byte in the optional APDU block is the Le field, which defines the length in bytes of the message expected by the host application in response to this command. The APDU response message corresponding to the received APDU command contains an optional block and a mandatory final part. This block includes a data field whose length is defined in the Le field of the corresponding APDU command. The final part consists of two fields SW1 and SW2. These fields are called the status word (SW), which defines the state of the map after executing the APDU command. For example, the value of the status word “0x9000” indicates that the command was executed successfully and completely.

The data field in the APDU command and response packets may be missing. Thus, it is possible to continue the classification of APDU packages, dividing them into four types, depending on the presence of a data field in C-APDU or R-APDU:
· In case 1, no data is transmitted to or from the card. Therefore, the APDU command consists only of the header, and the APDU response consists of the final part (the status word).
· In case 2, data is not transmitted to the card, but is returned from the card. The optional APDU command block contains only one byte – the Le field. It specifies the number of bytes that the corresponding APDU response should contain.
· In case 3, data is transferred to the card, but not returned from the card after executing the command. An optional APDU command block includes an Lc field and a data field. The Lc byte defines the length of the data field. The APDU response contains only the final part (the status word).
· In case 4, data is transferred to the card and returned from the card after executing the command. The optional APDU command block includes the Lc field, the data field, and the Le field. The APDU response contains the data and the final part (the status word).

TPDU Protocol

APDU blocks are transmitted in accordance with the next level protocol – the transport protocol. This protocol is defined in the ISO 7816-3 standard. The data structures exchanged between the host application and the smart card are called data blocks of the transport protocol (transmission protocol data unit, TPDU). Currently, two transport protocols are mainly used in the smart card industry: the T=0 protocol and the T=1 protocol. The protocol T=0 is byte-based. This means that the smallest unit of data that can be transmitted and processed in accordance with this protocol is one byte. The T=1 protocol, on the contrary, is block-oriented. In other words, the smallest unit of data that can be transmitted according to this protocol is a block consisting of a sequence of bytes.
The TPDU block structures used in the T=0 protocol are very different from the structures used in the T=1 protocol. Additional information about the transport protocol is contained in the ISO 7816-3 standard.

ATR Message

Immediately after the power is turned on, the smart card sends a response to the reset signal (ATR message) to the host application. In this message, the card parameters that are necessary for organizing a communication channel for data exchange are transmitted to the host application. An ATR message can contain up to 33 bytes. It includes transmission parameters, such as the transport protocol supported by the card (usually T=0 or T=1); data transfer rate; hardware parameters of the card, for example, the serial number of the processor and the version number of the software recorded in the ROM memory, as well as other information about the card that the host application needs to work.

Smart card operating systems (OS) have very little in common with desktop operating systems: UNIX, Microsoft Windows, and even DOS. The OS for smart cards contain a set of functions for processing instructions. These functions can be used in client applications. The ISO 7816-4 standard lists a complete set of instructions in the APDU format. The smart card OS can support all of these APDUs or some of them. Additions and extensions made by the card manufacturer may also be supported.

Most smart card operating systems support the simplest file system based on the ISO 7816-4 standard. The APDU commands defined in this standard are mostly file system-oriented. Such commands include, for example, file selection commands and file access commands. In this case, the client application is often a data file that stores information related to a specific application. The semantics and instructions for accessing application file data are implemented in the operating system. Therefore, the boundary between the OS and applications is not very clearly defined.

Such file system-oriented operating systems have proven themselves well in the smart cards available today. However, recently, the popularity of more modern operating systems has been growing, in which system-level operations and instructions for accessing application files are better isolated from each other. Java Card is one of the technologies in this new direction.

Smart Card File Systems

Smart cards conforming to the specifications of the ISO 7816-4 standard can have a file system with a hierarchical structure. The ISO 7816-4 file system supports three file types: root directory (Master File, MF), directory (Dedicated File, DF) and data file (Elementary File, EF). Each file is defined either by an identifier 2 bytes long, or by a symbolic name up to 16 bytes long.
Before performing any operations with the file, it must be selected. (This action is equivalent to opening a file in traditional OS.) Some cards automatically select the root directory when power is turned on. Access to the file is determined by the access conditions. You can separately set the read and write availability of the file.

The technology does not provide software interfaces to support the ISO file system. In most cases, access from applications to the ISO file system can be implemented using the Java programming language. With the help of encapsulation, files are represented as arrays or objects. The reference implementation of the Java Card 2.1 programming interface provides an example of a JavaPurse application that can be downloaded from a Web site http://java.sun.com/products/javacard /. This example shows how you can organize access to ISO 7816 files and work with APDU blocks oriented to the file system defined in the ISO 7816-4 standard.