3.2 An overview of the chip card technology

This section presents a quick overview of the chip card technology. The functionality of an ICC is based on the standard ISO/IEC 7816, "Identification cards ”Integrated circuit(s) card with contacts" [4 “7]. First, we look at the hardware and software structure of a chip card. Second, we review the basics about a card file system and the methods of referencing files. Third, the format of the command/response pairs sent to and returned from the card as well as the most common commands are briefly presented. Finally, the concepts of terminal application, card application, and their interaction in a client server model are presented.

3.2.1 Hardware and software structure of chip cards

The chip card is a plastic card that incorporates an integrated circuit, which is a single-chip computer. This computer contains a microprocessor that can access read-only memory (ROM), electrically erasable programmable memory (EEPROM), and RAM. The memory management unit (MMU) controls the access to these memories. The hardware structure of the single-chip computer is shown in Figure 3.1.

Figure 3.1: Hardware structure of the single-chip computer in the card.

The ROM is masked in the chip and cannot be changed during the whole lifetime of the chip card. The EEPROM permanently stores data that can be read but also modified during the lifetime of the card. The RAM is volatile memory that keeps data needed for the processing performed by the chip's microprocessor during one card session.

The chip is connected to the outside world through five contacts, which are assigned as follows :

I/O: The chip has only one input/output serial line for communicating with the outside world. The universal asynchronous receiver transmitter (UART) serializes both commands coming from and responses going to the terminal. Among the protocols that can be implemented at the transmission level between the chip card and the terminal, we mention only two protocols known as T = 0 and T = 1 [4], since they are the only transmission protocols accepted by the EMV ¢ cards.
V _CC and GND: The electrical power for the chip is provided by the terminal on these two contacts.
CLK: The execution of all the processing in the chip is synchronized with a clock that is received from the terminal.
RST: This contact receives the electrical reset signal from the terminal, which brings the chip to an initial status (see Section 3.2.4).

The single-chip computer is a slave depending on the terminal, which can be regarded as a master. The chip does not take initiative, but is simply driven by the terminal. Figure 3.2 shows two possible software architectures of a chip card, which can be regarded as a pile of software packages.

Figure 3.2: Two software architectures for chip cards.

The left side of Figure 3.2 shows a proprietary software organization that does not allow for the portability of card applications. It can be seen that the card application makes direct calls to either a proprietary application programming interface (API) or to the card's operating system. Since each ICC producer has its own operating system and its own proprietary API, the card application is not portable from one chip card to another. Every time an issuer changes the chip card producer, the card application has to be rewritten. Regarding the mapping of hardware resources to the software architecture, it must be noted that a large diversity of possibilities exists, depending on the memory capacity allocated for ROM and EEPROM. The operating system and proprietary API are masked in the ROM, whereas the card application can reside either in the ROM or in the EEPROM. In the majority of the proprietary card implementations , however, the card application physically resides in the ROM and is logically integrated in the operating system instead of being on top of the operating system. The card file system that contains the data structures needed during the processing performed by the card application is always kept in the EEPROM, since both read and write operations must be available on the permanently stored data.

In the right side of Figure 3.2 the software organization of a Java card [8] is presented. In this software architecture the code of the card application is isolated from specific hardware and operating system libraries through the Java virtual machine (JVM). The JVM interprets the byte code corresponding to the Java source of the card application and translates it into instructions that are executable by the hardware and native operating system. Each chip hardware platform has its own JVM, which allows the card application to be independent of the hardware and the native operating system of the card. One of the big benefits of this platform, which can justify its higher price, is the reduced time to get new applications to the market. They also support the downloading of "cardlets", which is the term sometimes used for the applets downloaded to a chip card, even when the card is already in its utilization stage. Last but not least, the applications written for one chip card can be ported to other chip cards, provided they have the same Java card API, which is actually standardized as Java Card 2.1.1 [9]. Thus, this software organization guarantees the interoperability of card applications written for different chip card platforms.

The actual competitor of the Java card is the MULTOS operating system for chip cards, whose specifications are created by the MAOSCO consortium [10]. Card applications are coded in the MULTOS executable language (MEL), which is an interpreted language that is hardware-independent. Therefore, similar to the Java card, the MULTOS architecture bases its functionality on a MEL interpreter, which can be regarded as a virtual machine, and an application loader. Generally there is a distinction between off-card and on-card virtual machines. In contrast to the Java card, the MULTOS virtual machine is completely realized on-card. This allows implementing firewalls between the applications, which provides a suitable security level for multiapplication environments. The application loader ensures the possibility of secure loading and deletion of card applications to and from the EEPROM, even during the utilization life stage of the card.

It is important to note that the software configuration and the file system loaded in the card are dependent on the life stage of the chip card. Table 3.1 presents each life stage of the card, along with the most important operations performed by a certain role in that stage.

Table 3.1: The Life Cycle of a Chip Card
Life Stage	Operation	Role Involved
IC fabrication	The integrated chip (IC) is produced, with the operating system in the ROM mask. For a proprietary card, this mask can contain the card application. For a Java card, the ROM contains the Java virtual machine. A unique ICC serial number is assigned to each chip.	IC manufacturer
ICC fabrication	The integrated chip is embedded in the plastic card.	Card manufacturer
Prepersonalization	The file system of the card is created. The data that is specific to the payment system and is common to all chip cards participating in the same scheme is also written during this stage. For a proprietary card, if the card application is resident in the EEPROM, the application software is loaded. For the Java card all the card applications that are foreseen in the standard configuration of the card are loaded.	Card manufacturer
Personalization	The data specific to each cardholder is filled in the appropriate files of the card.	Card issuer
Utilization	The card is operated according to the business goals of each application. For Java cards, card applications can be dynamically added in the EEPROM during the utilization stage. The only restriction is that the corresponding byte code originates from an application provider agreed upon by the card issuer and there is enough EEPROM space. Card applications can be also dynamically deleted from the EEPROM, according to the preferences of the cardholder.	Cardholder
End life	When the validity of the card expires , the card is disaffected by the card issuer, which can for example block the entire card.	Card issuer

3.2.2 Card file system and file referencing

The operating system of the chip card manages a file system that stores the data needed by each card application. ISO/IEC 7816-4 [5] supports two categories of files: dedicated files (DFs) and elementary files (EFs). They are organized in a hierarchical tree, with DF as branches and EF as leaves . A typical organization of the card's file system is schematized in Figure 3.3.

Figure 3.3: The organization of the card's file system.

3.2.2.1 Master file and dedicated files

The highest DF in the hierarchy, which is the root of the tree, is also called the master file (MF), which is the only mandatory DF in the file organization. In the example presented in Figure 3.3, the MF contains one leaf, the elementary file EF1, and two branches, the dedicated files DF1 and DF2. Data that is used for all the applications in the card (e.g., administrative and general security information such as the ICC serial number, access control keys, card's general PIN, as well as data concerning the management of the card's life cycle) are stored in elementary files at the MF level. This information can be used by the operating system for creating another DF at the MF level.

The dedicated file DF1 contains four leaves. The first three of them (EF11, EF12, and EF13) are working EFs, while EF14 is an internal EF. We will later see the difference between working and internal elementary files. The semantic of the information in DF1 and its elementary files will be explained in Section 3.3. The dedicated file DF2 contains only two leaves, which are the working elementary files EF21 and EF22. Each dedicated file can further contain other hierarchically inferior dedicated files. In Figure 3.3, DF2 contains one subdedicated file DF21.

A dedicated file can be seen as a container of data belonging to one card application. Several data elements of the card application that are semantically related are stored in the same elementary file. Application control information and cardholder's financial data are stored in the elementary files encompassed in the same DF. Each DF may contain cryptographic keys for implementing various security services, and each may have its own application PIN, which can be used to refine the access control mechanism of a multiapplication card.

The referencing of a DF in the card's file system, which corresponds to the possibility of selecting a card application from the terminal's side, can be performed in two distinct ways:

Referencing with a fixed file identifier (FID), which consists of 2 bytes (4 hexadecimal digits) . For example, the MF always has the FID equal to 3F00, while DF1 has the FID equal to 7F01 and DF2 has the FID equal to 7F02, and so on. In order to be able to select a card application with its FID, the terminal application must know beforehand the file organization in that card. For example, in order to select DF21 starting from the MF level as the current directory, the terminal must first select DF2 with its FID, and only after this selection is successful can it select DF21 with its corresponding FID.
Referencing with an application identifier (AID), which consists of up to 16 bytes . The encoding of the AID is detailed in the ISO/IEC 7816-5 [6]. The AID comprises either the registered application provider identifier (RID), which optionally is concatenated with the proprietary application identifier extension (PIX), or the proprietary application identifier. The referencing of card applications with registered application provider identifiers has the advantage that the terminal does not have to know in advance the FID of the DF that stores the application or its position in the card's file system. Moreover, since the RID is unique worldwide, several applications can be stored in the card with no danger of referencing conflicts.

It will become obvious in Section 3.3 that referencing a DF with its FID is suitable for closed design proprietary card applications. In Section 3.4 we show that the open design interoperable card application uses DF referencing through the AID.

3.2.2.2 EFs

The data elements of a card application are encoded in elementary files. The elementary files of a card application can be further subdivided into working EF and internal EF:

A working EF stores data that is not interpreted by the card application, but rather used by the terminal application exclusively during the execution of a protocol with the card.
An internal EF stores data managed only by the card application for management and control purposes. Cryptographic parameters used for security services provided by the card as well as the cardholder's witness PIN or other cardholder verification codes (CHVs) are stored in internal EFs.

Two referencing methods for elementary files are used:

Referencing with an FID, which consists of 2 bytes (4 hexadecimal digits) . The same FID referencing mechanism as that described for the DF can be also used for the EF. The disadvantage of this referencing mode is that before a file management command can be applied on an EF, the terminal must explicitly select this EF inside the DF corresponding to the card application. Examples of file management operations are the reading of some bytes from a transparent EF or the writing of a record in a linear fixed EF. Another disadvantage is that the terminal must know beforehand the FID of all the elementary files inside the card application's DF. The advantage of this referencing mode, however, is that the selection of either a DF or EF in the card is done uniformly, which simplifies the card's implementation. This referencing mode of EF is suitable for closed design proprietary card applications (see Section 3.3).
Referencing with a Short File Identifier (SFI), which consists of a number between 1 and 30 that can be encoded on 5 bits . This referencing method has the advantage that the SFI can be used as a file handler, which can be given as an input parameter to a file management command. This means that there is no need of executing an explicit selection of an EF inside the DF before calling a read/write command from/to an EF. Moreover, the SFI of all the working EFs in the card's application DF can be easily listed in a kind of DF table of contents. This helps the terminal learn by itself the publicly available working EF(s) existing in a DF. Therefore, this referencing method of EFs is preferred in open design interoperable card applications (see Section 3.4).

The structure of an EF depends on its intended use. As explained in ISO/IEC 7816-4 [5] one can distinguish among four basic types of EF structures. Transparent files consist of a sequence of bytes. A linear fixed file consists of a number of records, all having the same length. A linear variable file consists of a number of records, each with a variable length. The cyclic files contain records of fixed length organized in a ring structure. After all the records are written, the oldest entry in the file will be overwritten by the current entry to be stored. Figure 3.4 schematizes the four types of file structures.

Figure 3.4: Four types of elementary file data structures.

The file header of each EF stores information about the type of EF file structure and the size of the file. It also stores the possible actions to be performed on the file (read, write, invalidate, rehabilitate, increase) as well as the access conditions under which a terminal application can perform that action (card's general PIN or application PIN, authentication with a symmetric key, access always permitted or access never permitted).

3.2.3 Command and response format

In accordance with the OSI 7-layer model, the information transaction exchanged between the card and the terminal can be divided into three protocol sections:

The physical layer protocol (layer 1) corresponds to the electrical signals on the I/O contact of the card.
Data transmission protocols (layer 2) correspond to T = 0 and T = 1 protocols [4]. They are both asynchronous, half-duplex protocols. T = 0 is a byte-oriented transmission protocol of the first-generation chip cards when the computing power and the RAM on the chip was limited. It does not allow the transmission of data both in the command and in the response. T = 1 is a block-oriented protocol, which better respects the OSI reference model and allows transmission of data both in the command and in the response. The data is handled in blocks and the error checking is carried out on an entire block of data rather than on 1 byte.
Application protocols for command and response data (layer 7). A step in an application protocol consists of sending a command application protocol data unit (C-APDU) from the terminal application to the card application. The latter processes it and sends back the response application protocol data unit (R-APDU) to the terminal application. A schematized picture of a C-APDU/R-APDU pair is given in Figure 3.5.

Figure 3.5: Command/ response pair (C-APDU/ R-APDU).

The C-APDU consists of a mandatory header of 4 bytes and an optional body of a variable length. The header includes the class of instructions to which the command belongs (CLA), the instruction code (INS) determining the command inside of a class, and the parameters of the instruction [parameter 1 (P1) and parameter 2 (P2)]. The meaning of these parameters is dependent on the instruction code. The body of the command is optional and may contain the following fields:

L _c : This field (of 1 or 3 bytes) can contain the number of bytes present in the data field of the command.
Data field : This field (of L _c bytes) contains the string to be sent as input data to the card application.
L _e : This field (of a variable length up to 3 bytes) can contain the maximum number of bytes expected in the data field of the response returned by the card.

The R-APDU contains a conditional body of variable length L _r that can be less than or equal to L _e . The R-APDU includes the trailer, which is a mandatory field of 2 bytes containing the status words (SW1, SW2). The status words inform the terminal application about the result of executing the command in the card application.

The ISO/IEC 7816-4 [5] standard defines only the basic commands. They can be grouped in file selection, read data, modify/delete data, generate data, compare data, and authenticate through cryptographic functions. In addition to these standardized commands, each card operating system or each card application defines private use commands. For example, the EMV ¢ debit/credit card application defines its own commands beside those in ISO/7816-4 (e.g., the GET PROCESSING OPTIONS , and GENERATE AC ). The commands for the creation and personalization of files in the card's file system and the commands for blocking either an application or the entire card are further examples of private use commands. One can understand why even if chip card operating systems have been implemented according to the ISO/IEC 7816 standard, it does not necessarily mean that they are compatible with each other [11].

3.2.4 Card application and terminal application

The terminal at the point of service is a card acceptor device (CAD) equipped with a chip card reader, which is often referred to as the Interface Device (IFD). The terminal interacts with an ICC according to the client server model.

A client application runs in the terminal. This client application is referred to as the terminal application.
A server application runs in the ICC. This server application is referred to as the card application.

The terminal application sends commands as a client to the card application, which responds as a server.

To easily explain the processing performed by both the terminal application and the card application, as well as their interaction in the client server model, it is convenient to represent them as algorithmic state machines (ASM). For an ASM the next state depends on the actual state and the event that triggers the transition from one state to another. The state of the ICC consists of a set of data elements and cryptographic parameters. The cryptographic parameters are organized in the card's file system. From this point of view the ICC can be seen as a permanent storage medium. Compared to a magnetic stripe card, which was a passive storage medium, the ICC has computational power provided by its own microprocessor. The event that triggers the transition of the ICC from one state to another is a command with parameters received from the terminal. As a consequence of this transition the ICC performs an action. First, the action consists of updating the value of the data elements and cryptographic parameters stored in the ICC (i.e., the state of the ICC), according to the requirements of the command and the accompanying parameters. Second, the action computes a response that is returned to the terminal. The response can contain the value of one or more data elements stored or computed in the card and a status word, which describes whether or not the command was successfully completed in the card. In case of failure, the status word indicates the source of error. The response received from the card represents the event that triggers the transition of the terminal from one state to another.

The terminal brings the ICC from an initial state S to an operational state S ₁ through an electrical reset. The action performed by the card following the reset is to prepare and send back to the terminal an answer to reset (ATR) response, which contains enough information to allow the communication subsystem of the terminal to synchronize with the communication subsystem of the card. Once this initial handshake is performed, the terminal can send C-APDU to and receive R-APDU from the card. The clientserver relationship established between the terminal and the card is presented in Figure 3.6.

Figure 3.6: Terminal application and card application in a client server configuration.

The set of commands and responses exchanged between the terminal and the ICC in the framework of a transaction is called a transaction profile.

A card application in the ICC contains a set of data elements that can be accessed by the terminal after a successful selection of the application. A data element is the smallest information unit that can be identified by a name , a description of its logical content, and a format. Data elements are mapped onto data objects, which are encoded according to a certain format (e.g., fixed length format, BER-TLV format, and others).

The terminal application consists of the sequence of commands, which are launched by the terminal to trigger the transition of the card application from one state to another. This determines the processing in the card according to the functionality of the card application. The terminal application also processes the data objects received in the responses from the card and the status words reported at the end of each command.

Several issues are identified in relation to the design of a card and terminal application, indifferent to whether it is a proprietary or interoperable solution:

One has to define the encoding of data elements into data objects in the card and the terminal application.
The organization of these data objects in a file system stored in the card and the referencing of files in this system must be defined. If several card applications reside in the same card, it is necessary to specify the separation of files corresponding to each application.
The set of commands supported by the card and the possible responses elaborated towards the terminal must be also defined.
The underlying cryptographic technology used for implementing the necessary security protections in both the card and the terminal must be chosen .

The possible solutions to these issues are restricted to the framework provided by the ISO/IEC 7816. The next two sections show how the aforementioned issues are solved in the case of a proprietary and closed payment application and in the case of an interoperable and open payment application, respectively.