Without exception, file management in all modern smart card operating systems is objectoriented. Among other things, this means that before any action can be performed on an object (which corresponds to a file), it must first be selected. Only then does the system know which file is meant, and all subsequent file-specific commands apply to this file alone. Of course, the access conditions for the file still must be checked within the operating system, in order to determine whether the command in question is allowed or even possible. The master file (MF) is always implicitly selected after the card has been reset, so it does not have to be specifically selected. Other files are subsequently selected by executing the SELECT FILE command. A file is addressed using its 2-byte file identifier (FID) or, in the case of a directory file (DF), a 1-byte to 16-byte DF name. A DF name can contain an internationally unique application identifier (AID) that is 5 to16 bytes long. It is possible to pass only a portion of the AID, omitting the less significant bytes (those to the right). An additional parameter causes the card to select the first, last, next or previous DF relative to the DF identified by the abbreviated AID. In connection with an older set of command definitions, the GSM 11.11 standard allows only the 2-byte FID to be used for file selection. The ISO command set, by contrast, also supports a type of file selection using the path name of the file in question. The path name can be either relative, in which case the file is selected starting from the currently selected DF, or absolute, in which case the file is selected starting from the MF. Only successful selection of a new file causes the previously selected file to be deselected. If the selection cannot be completed, for instance because the requested file does not exist, the previous selection remains in force. This ensures that a file is always selected, even in the event of an error. After successful file selection, the terminal may request information about the new current file if necessary. This request, including the desired number of data items, is sent to the card using the SELECT FILE command. The exact contents of these data items are defined in the applicable standard. The data items returned by the card may include information about the structure, size and amount of free memory of the newly selected file. The amount of data may also depend on the file type. Table 7.1 lists the explicit file selection options permitted by ISO/IEC 7816-4 for the SELECT FILE command, and Figure 7.4 depicts the sequence of events in a typical file selection process. In addition to explicit file selection using an FID, DF name or a path specification in a SELECT FILE command, implicit file selection can be used. However, this is only possible with standard read and write commands. A file can be selected before the command is actually executed by specifying its 5-bit short FID as a supplementary parameter. However, in this case the file must be an EF and it must be located within the current DF. The advantage of this method lies in simplified command execution and increased processing speed, since it is not necessary to send an explicit SELECT FILE command to the card. GSM 11.11 defines the STATUS command, which returns the same data to the terminal as successful file selection using SELECT FILE. These data provide information about the currently selected file: its type and structure, size, FID, access conditions and whether it is blocked. This command is rarely used, and its main purpose is to allowthe terminal to determine which file is currently selected during a session and the currently valid access conditions. EN 726–3 specifies the CLOSE APPLICATION command, which supplements SELECT FILE and STATUS and is used to close applications. The FID of the application to be closed is provided with the command, and the card responds by deleting the previously attained security state. This command is mainly useful when a terminal needs to ensure resetting of the state attained by the card. If the card’s operating system does not support such a command, this result can only be achieved by a card reset. In the ISC/IEC 7816-4 definitions, selecting the MF is sufficient to cause the security state of the previously selected file to be reset to its initial state.

Read and write commands primarily support using smart cards for secure data storage. These commands can be used to write data to appropriate EFs and subsequently read these data. If these EFs have specific access conditions, only authorized users are allowed to read them. The data are thus stored in the card with protection against unauthorized access. Since there are various types of EF data structures, there are also various types of read and write commands for these files. Unfortunately, this does not fully correspond to an objectoriented file management system. In a purely object-oriented system, the operating system must be built such that an object can determine its own access mechanisms. This is not the case for smart card file management. This non-compliance dates back to the historical emergence of commands that were subsequently incorporated into current standards. The precursors of smart cards, which are memory cards, have only one memory region that can be read and written using offset and length parameters. Externally, this memory can be regarded as a single file with a transparent structure. The first smart cards were built according to the same principle, and the definitions of the commands for reading and writing transparent files date from this time. Later, when other types of file structures were defined, new commands specifically adapted to these structures were defined for use with such files. As a result, there are two different types of file access. Therefore this class of commands must be divided into commands for accessing EFs with transparent structures and commands for accessing EFs with the other types of structures (cyclic, linear fixed and linear variable). However, several standards (such as EN 1546 for electronic purses) explicitly state that read commands for files with transparent structures may also be used to read files with other types of structures. In any case, such commands can be used to obtain additional data about the internal structure of the file. An EF with a transparent logical structure is amorphous, which means that it does not have any internal structure. It corresponds to a linearly addressable memory with byte access. The READ BINARY command is used to read such a file, while the WRITE BINARY and UPDATE BINARY commands are used for writing.

The fundamental difference between the WRITE BINARY and UPDATE BINARY commands relates to the secure state of the card’s EEPROM. The secure EEPROM state is the logical state of the EEPROMbits when the memory cells have taken on their minimum-energy state. Since the memory cells are small capacitors, this means the state in which they contain no charge, which is usually the logic 0 state. In order to change a bit from state 0 to state 1, it must be erased. This restores the charge on the capacitor. A WRITE command can only be used to change bits from the non-secure state, which is usually logic 1, to the secure state, which is usually logic 0. In this case, the WRITE command produces the logical AND of the transferred data and the file content. By contrast, if the secure state of the chip corresponds to logic 1, the WRITE command must produce the logical OR of the data provided by the command and the data in the file. The result of the logical coupling of the data provided by the command and the data in the file is that the secure state of the EEPROM is always achieved using a WRITE command. In addition, a WRITE command may support write once, read multiple (WORM) access, depending on the file. WRITE commands originate from a time when using atomic operations for file access was still unknown in the smart card realm. They are presently used only very rarely. An UPDATE command, by contrast, performs a genuine write to the file. The previous state of the data in the file does not affect the content of the file following execution of an UPDATE command. UPDATE BINARY can thus be considered to be equivalent to using ERASE to erase the file, followed by WRITE BINARY. These commands can be utilized to construct physically secure smart card counters. The principle involves a bit field in which each bit that is set represents a monetary unit. When a payment is made, the counter is decremented bit by bit using OR operations generated by WRITE BINARY commands. After authentication, the counter value can be increased again using an UPDATE BINARY command. The main advantage of this technique is that it makes it impossible to increase the counter value by manipulating the EEPROM, such as by heating it, since the secure state of each bit represents a value of 0.

As their names suggest, READ BINARY is a read command, while WRITE BINARY and UPDATE BINARY are write commands. The file is always accessed using a length parameter and an offset to the first byte to be addressed. Some operating systems also permit implicit file selection before the actual data access occurs, using a supplementary short FID parameter. However, this option is not present in all standards and operating systems. Figure 7.5 illustrates a typical command sequence using READ BINARY followed by WRITE BINARY and finally UPDATE BINARY. The effects on the content of the selected file are shown in Figure 7.6. Of course, this example assumes that file selection is successful and that the access conditions for the file to be written are met. ERASE BINARY is an exception among the commands that operate on transparent EFs. It cannot be used to write data to a file, but only to erase data starting from a given offset. If no second offset parameter is stated, the command erases all data to the end of the selected file. In this case, erasing data means that the data region specified in the command is set to the logical erased state. This state must be defined separately for each operating system, since it may not be the same as the physically erased state of the memory. Because the structures of linear fixed, linear variable and cyclic EFs are fundamentally different from the structure of a transparent EF, special commands for accessing these particular data structures are available in addition to the commands described above. All of these files have record-oriented structures. For write access, the smallest addressable unit in the data field is a single record. For read access, either an entire record or part of a record may be read, starting with the first byte of the record. These file structures, which transform a linear, onedimensional memory into a memory that can be addressed in two dimensions, yield access types that are significantly more complex than those used with a transparent structure. In principle, all possible data structures can be emulated using a transparent structure, but in specific cases this may prove considerably more complicated than using a higher-level structure. After an EF with a record-oriented structure has been selected, the card’s operating system creates a record pointer whose initial value is undefined. The value of this pointer can be set using a READ, WRITE, UPDATE RECORD or SEEK command. The pointer for the current file is saved as long as this file is selected. After successful explicit or implicit selection of another file, the value of the record pointer is again undefined.

All commands for record-oriented files can use a parameter byte to specify the type of access to the file. The basic type is direct access using the absolute number of the desired record. This type of access does not alter the record pointer. The number of the desired record is sent to the card, and the response contains the content of the record in question. If the parameter byte specifies the first record, the operating system sets the record pointer to the first record in the file, and this record is read or written according to the type of command used. The parameter value ‘last’ accesses the final record in a similar manner. The additional parameter values ‘next’ and ‘previous’ allow the next and previous records, respectively, to be selected and read or written. Finally, the parameter value ‘current’ can be used to address the record marked by the current value of the record pointer. This large variety of access methods for record-oriented data structures originates from the typical structure of a telephone directory. Consider a record whose initial part contains a surname and given name, followed in the same record by the associated telephone number. UsingREADRECORDand the parameters described above with a telephone directory mapped into an EF, you can ‘page’ forwards and backwards as desired within the directory or jump to the first or last entry. The record pointer can also be changed using the search command SEEK, which is described below. ISO/IEC 7816-4 also provides the option of reading all records from the first record up to a specified record number. Similarly, all records from a specified record number through to the last record can be read in a single command–response cycle using READ RECORD. Although these commands are very practical, the capacity of the I/O buffer can quite easily be exceeded if they are used with large files.

The APPEND RECORD command, given its functionality, could just as well be classified as a file management command. It can be used to append records to existing record-oriented files. The data for the entire new record are provided together with the command. A relatively complex memory manager, in smart card terms, is a prerequisite for the availability of this command with its full functionality. The function of the memory manager is to create a link between the new record and the ones already present in the file. It is then possible, within the limits of the available memory, to add an arbitrary number of new records. However, the number of new records that can be added is often restricted in order to simplify matters. In this case, when a record-oriented file is created, memory is reserved as necessary for adding future records. This space can later be filled using APPEND RECORD commands. Once this free space is used up, the APPEND RECORD command cannot be used again for this file. If APPEND RECORD is used in conjunction with a linear fixed or linear variable file, the new record is always added at the end of the file. If the structure is cyclic, however, the new record is always numbered 1, which corresponds to the currently written record in files of this type. APPEND RECORD can be used for various purposes. One possibility is a telephone directory, as already mentioned. Another possibility is a log file, in which the data to be recorded are written directly to the card by creating new records. There are two commands that complement the file-based read and write commands. They are designed for direct access to data objects. Depending on the selected DF, certain data can be written to or read from files or internal operating system structures, bypassing the fileoriented access mechanisms. Data objects can be written using PUTDATAand read using GET DATA. For both of these commands, the exact structure of the TLV-coded data objects must be transferred with the command. This means that it is necessary to know whether applicationspecific or standard coding is used for the data objects. This information is important inside the operating system, since it allows the objects to recognize the data according to how they are packaged. The appropriate access conditions must be satisfied in advance for both of these commands.