All files in a smart card are stored in the EEPROM. This is the only type of memory in the smart card that can retain stored data without power and that also allows data to be altered if necessary (when power is available). It also provides the only means to save information from one session to the next, since the contents of the RAM are lost when the smart card is deactivated, and the contents of the ROM cannot be altered after the chip has been manufactured. In earlier smart cards, files were directly accessed using physical addresses. Actually, there were no files in the true sense of the word. Instead, the entire memory was linearly addressable from the outside and could be accessed using write and read commands. However, this is not allowed in modern operating systems, for reasons related to security and applications. Objectoriented file management, with access condition information located directly in the files, is currently the standard. The organization and management of these files is the task of the file manager portion of the operating system. With an objected-oriented structure, every file must have a file descriptor that contains all the information relevant to the file itself. In smart card technology, the file descriptor is referred to as the file header. The data content of a file, or in other words the user data, is located in the ‘body’ of the file.
The information contained in the file descriptor depends strongly on the capabilities of the file manager. However, the file descriptor must contain at least the following items:
–file name (e.g. FID =’0001′)
–file type (e.g. EF)
–file structure (e.g. linear fixed)
–file size (e.g. 3 records of 5 bytes)
–access conditions (e.g. READ = after PIN code has been entered)
–attribute (e.g. WORM)
–link to the file tree (e.g. directly under the MF).

With an EF or the MF, the file name is the two-byte file identifier (FID). With a DF, the application identifier (AID) also forms part of the file name. The file type, which may be MF, DF or EF, must also be indicated. Depending on the file type, there may be an element in the header that describes the internal structure of the file (transparent, linear fixed, linear variable, cyclic or executable). All information relating to the length of the transparent data portion, or the number and length of the records, also depends on the file type. Besides the basic attributes of the file, which have just been described, the operating system needs even more detailed information about the access conditions, which means which commands are allowed to access the file and what types of access are allowed. The access conditions must be individually specified for every possible command. Special file attributes, such as high update activity, WORM or EDC protection, can also be marked if they are supported by the file manager. All of the above information relates to the file as an isolated object. In order to define the location of the file in the file tree, an additional pointer is needed to specify the exact position of the file within the MF or DF.

Pointer-based file management
In simple operating systems, the file headers have fixed lengths that depend on the file type (MF, DF or EF). This reduces the amount of administrative and computational overhead for internal file management. However, such an arrangement has the major disadvantage of being relatively inflexible with regard to extension. Another drawback is that it does not allow an unlimited number of different access conditions to be implemented for any given EF, or even a very large number. This is because the memory that would have to be reserved to accommodate a large number of access conditions in the header would not be fully used by most applications. Consequently, variable-length headers are very popular in smart card file management systems. Such headers can be automatically adapted to the needs of specific applications by the smart card operating system.

FAT-based file management
A type of file management that is widely used for the hard disk drives of PCs is based on file allocations tables (FATs). This method can be adopted for use in the memory management of smart cards without any essential modification.With this method, the EEPROMto be managed is divided into many equal-sized pieces, which are called sectors. Ideally, the sizes and start addresses of the sectors should correspond to the EEPROM pages. This allows write and erase operations to be performed on integral EEPROM pages. The FAT contains pointers to each of the sectors of the memory, with FAT entries also being linked to each other by means of pointers. Vacant FAT locations and defective sectors are marked by special entries. With regard to memory space, the FAT can be significantly compressed if there is a direct relationship between FAT locations and sectors. In this case, the sector pointers within the FAT are unnecessary. Figure 5.29 shows a possible implementation of a FAT for file management in a smart card. The file descriptor, which contains the essential information about the structure of the file, contains a pointer to the initial entry in the FAT. In the FAT, a number of sectors corresponding to the size of the file are linked using internal FAT pointers. The final entry always contains an end-of-file (EOF) marker. There is a one-to-one relationship between the FAT entries and the sectors in the memory that contain the user data belonging to the file descriptor. The question of whether file management is implemented using file headers and file bodies linked by pointers or using a FAT largely depends on various technical considerations and constraints. Both approaches have advantages as well as disadvantages. A FAT-based file management system requires memory for the FAT itself, and particularly in the case of small files, this is disproportionately larger than the amount required by a pointer-based system. However, memory fragmentation does not occur in a FAT-based system, since it fundamentally cannot occur in such a system. Requesting and releasing memory within the memory management system of a smart card is implemented using a variety of services. At the lowest level, these services include requesting and releasing memory, increasing memory, reading and writing data and writing data as an atomic operation. The file management interface constructed on top of these services usually includes services to create and delete files, read data from files, write data to files, select the MF, select the higher level DF, select a file using its FID and select a file using its DF name.

Memory partitioning into pages
The limited number of write/erase cycles of the EEPROMand the partitioning of the EEPROM into pages create a general problem for file management. This has a considerable effect on the entire design of the file manager and the internal file structures. The sizes of both file headers and file bodies must be adapted to the predefined size of the memory page to prevent them from being split by page boundaries. File management information in the memory must also be strictly separated from the actual file data contents. If this were not the case, undesired side effects could occur between the management data in the header and the user data in the file body. These could destroy the entire internal security structure of the smart card operating system. This is briefly illustrated in the following example. Suppose the access conditions for a file containing secret, non-readable keys are stored on the same memory page as the public, writeable data of another file. If a write operation to this file is interrupted, for example by pulling the card out of the terminal, this will affect the access conditions stored on the same page. In theworst case, no access conditions at all will remain, and the file containing the secret keys can be read by everybody. It is thus fundamentally important to store the internal file structures for file management and the user data on separate memory pages.

DF separation
One way of understanding the function of a DF is to see it as representing all of the memory provided to a particular application. Within this region, the application operator is fully responsible for his application and can essentially do and permit whatever he wishes. However, he must under no circumstances be able to access a memory region assigned to a different application from within his own region in any manner, nor should he be able to read or alter data stored in another region. Consequently, some smart card operating systems have special mechanisms that always test every memory access to see whether the physical address is located within the limits of the current DF. If this is not the case, the process is terminated and a severe internal error is reported. This address monitoring is currently performed by suitable software routines in the operating system, due to the lack of hardware support. The security of this solution is naturally significantly lower than what could be achieved with suitable hardware, since it is more easily bypassed. In the future, smart card microcontrollers will probably have memory management units (MMUs), as do all current CPUs.6 Such units can be used to achieve secure control over memory accesses within a DF. Until then, the only option is to employ suitable operating system routines to monitor the address boundaries of the DFs. This principle of memory organization – storing all of the components of a DF within a single contiguous region of memory – had to be abandoned in the development of recent operating systems, since memory management would otherwise have been too inflexible.

Free memory management mechanisms
The small amount of available memory imposes major restrictions on smart card operating systems with regard to free memory management for the EEPROM. Only since the mid-1990s have operating systems been available that can create and subsequently delete files (DFs and EFs) after the card has been personalized. Given the secure nature of a smart card, this must naturally be protected in a cryptographically flawless manner. The ideal solution is to execute the appropriate commands in the secure messaging mode following an initial mutual authentication. Free memory management must also take into account the fact that in the event of a sudden loss of power, which can for example occur if the card is pulled out of the terminal, the entire file tree must remain in a well-defined state. Particularly in such circumstances, the security of a smart card can completely collapse if file pointers suddenly become undefined. The satisfactory approaches to solving this problem once again involve atomic operations, although in this case, due to the large data volumes, such processes require a relatively large amount of time and correspondingly large memory buffers. There are various realization strategies for memory management, and incidentally for all types of file management in smart cards, and they differ significantly in terms of software implementation. This is illustrated in Figure 5.30 and the associated description, using smart card memory management as an example. The simplest type of memory management is a sort of write once, read multiple (WORM) functionality.With such an approach, once memory space has been occupied by storing a file, it remains occupied even after the file has been (logically) deleted. The administration overhead with this approach is minimal.

A somewhat more elaborate method, from a software engineering point of view, is memory management based on the last-in, first-out (LIFO) principle. With this approach, the most recently created file can always be deleted, releasing the space it previously occupied. This method is often used in simple smart card operating systems.With the somewhat more sophisticated best-fit algorithm, the operating system always attempts to find the smallest suitable region of free memory when creating a new file. When the file is deleted, this region again becomes free and can be used by other files. However, if files of various sizes are frequently created and then deleted, strong fragmentation of the memory occurs relatively quickly. As a result, large files can no longer be created, since no single region of free memory will be large enough to hold the entire file, even if the total amount of free memory is sufficient to hold the file. This is precisely where the defragmentation process comes into play. When the memory is heavily fragmented, this memory management process, which is relatively complex by smart card standards, repeatedly relocates the files in memory until it arrives at a situation in which all of the free memory forms a single contiguous block. The difficulty here comes from the fact that such an algorithm runs relatively slowly in smart cards, due to the need to perform many time-intensive EEPROM write accesses. Garbage collection is a process that can be regarded as independent of the processes just described. Operating either on demand or periodically, the garbage collection process searches the entire memory for areas of memory that are no longer used. If an area that is no longer needed is found, the garbage collection process automatically allocates it the free memory pool. A defragmentation process can subsequently be used to combine all of these small memory blocks to form a large, contiguous region of free memory.

Data integrity
Another important consideration is ensuring data integrity. The file manager should always be able to test whether the data in the memory have accidentally changed, which could occur due to factors such as aging. To minimize the administrative overhead for this function, the level of data redundancy and/or the extent of the supervisory protective functions should match the importance of the data. There is thus no need to protect all data with checksums as a matter of principle. Several data elements, such as a complete file header, can be protected as a group, or particularly important data elements can be individually protected. This primarily depends on how often the data elements are altered in the EEPROM and how much memory space the designer of the operating system is willing to sacrifice to ensure data integrity. Error detection codes are used to ensure data integrity. They are primarily used to protect critical data elements, such as data access privileges and file body pointers in file headers. Checksums based on CRCs are often used for this purpose, since they can be computed relatively quickly and do not require very much program code. However, Reed–Solomon codes are also often used to provide better protection against the typical failure mode of EEPROM cells. These codes are significantly better than CRC checksums for detecting the burst errors that typically occur when an entire EEPROM page has changed.

Cross-application access
Certain smart card functions are only enabled after the card user has entered a PIN code. Since the powers of memory of the average person are limited, it has become common to use only one PIN per smart card, even with cards that hold several applications. Every application in the card thus uses this common PIN. It could be stored separately for each application in an internal EF, but this would require each of the stored PINs to have its own retry counter. If there are five applications, for example, and each application allows three attempts, a total of 15 attempts to guess the PIN will be allowed. In many cases, this is not tolerable with regard to the design and security of the applications. Consequently, some operating systems allow cross-application access to PINs and keys. This utilization of shared resources is in principle implemented in a manner similar to the alias mechanisms commonly used in PC operating systems. The main difference is that smart card operating systems only allowreferences to higher level DFs, with theMFbeing the highest level entity. It would thus not be possible to access a PIN located in an arbitrary DF, but only one located in a higher level of the file hierarchy, such as the MF. In the case of the above example of a single PIN and retry counter that are shared by several applications, a possible implementation is as follows. The PIN is stored in an internal EF located immediately below the MF. In the application, which is located in a DF below the MF, a reference to the storage location of the PIN is stored in an internal EF. The states resulting from successful and unsuccessful PIN comparisons are naturally stored in the PIN record in the DF, since they apply to only one particular application. If a PIN comparison is triggered, the VERIFY command first accesses the PIN record in the current DF, from which it sees that the PIN and its associated retry counter are located at a different level. It then uses the indicated PIN for the PIN comparison. The state of the currently selected DF stored in the internal EF is set according to the result of the comparison. This procedure is presently supported by many smart card operating systems in various forms. Particularly for the utilization of data that are shared by two or more applications, it provides a very elegant and cryptographically faultless solution. In addition to allowing PINs and keys to be used across several applications, some operating systems also offer an equivalent mechanism for EFs. This makes it possible to directly access global data in EFs located immediately below the MF without first deselecting the current DF.