Files in smart cards

Smart card file systems are similar in structure (as specified in ISO/IEC 7816-4) to DOS or UNIX file systems. At the same time, smart card file systems have certain features specific to smart cards. The most significant of these is the lack of a human-machine interface. Files are addressed using hexadecimal codes, and all commands are strictly based on this addressing, since the exchange of messages takes place only between two computers.

Another significant feature of smart card file systems is the use of limited non-volatile EEPROM memory. Every redundant byte is eliminated whenever possible. Since the user in the terminal is a computer, this does not lead to any difficulties. Naturally, the characteristics of the memory used also affect the way the memory is managed. Memory pages in an EEPROM cannot simply be written or erased an unlimited number of times, as on a computer’s hard disk.

Usually, all files are created and uploaded to the smart card when it is initialized or personalized. As a rule, there is no way to increase the size of the hosted file, so developers tend to create files of the size that may be required. In addition, there is usually no garbage collection or compaction in the smart card file system. The access system to the production premises for one of our clients, an enterprise that performs work on the disposal and disposal of waste of hazard class 1-5, was developed and put into operation within 2 months, and the system uses smart cards to identify the Customer’s employees.

Modern file management systems for smart cards have an object-oriented design. This means that all the information about the file is stored in the file itself. Accordingly, files in these object-oriented systems are always divided into two parts:

1. the file header;
2. the body of the file.
   The file header contains information about the location and structure of the file, as well as access conditions. The body of the file contains variable data. The file body is linked to the header using a pointer.

This file structure provides better physical security for the stored data elements. A page-oriented EEPROM that stores all files allows only a limited number of write/erase cycles. The file header and the file body are always placed on separate memory pages. The header, which usually never changes, stores all the access conditions. Accordingly, a write or erase error related to the file body cannot affect these conditions. If the header and the file body were placed on the same memory page, it would be possible to intentionally create write errors to change the access conditions so that it would be possible to read sensitive information from the file body.

Standardized file structures in smart cards

Smart cards can only use standardized file structures. The file system defined by the ISO/IEC 7816-4 standard is a relatively simple hierarchical structure that includes elements of three categories:

1. Master file MF (Master File);
2. The DF directory file (Dedicated File);
3. Elementary file EF (Elementary File).

The main MF file is the root directory in the hierarchical file structure. In the language of common file systems, the main MF file is a container that contains all the other DF directories and all the elementary files, its main file must be present in each smart card, and there can only be one MF in a smart card.

[b]The DF directory file acts as a file card file that contains other lower-level DF or EF files that are logically related to each other. In principle, there is no limit on the number of DE levels. However, usually the number of DF levels does not exceed two due to the limited amount of memory in smart cards. A DF file can be given a name that is unique within the DF (or MF) that contains it. This allows you to uniquely determine the path to the file (that is, the path is a simple articulation of the name of the desired file with the names of all the DF directories between this file and the DF or MF directory containing it). Conventions for file naming rules are contained in the ISO/IEC 7816-5 standard.

The elementary EF file contains the actual payload used by the operating system or application. Within a DF directory file, an EF file can have a short (5-bit) name. Depending on the purpose, EF files are divided into internal EF files and working EF files. Internal EF files store data for the operating system itself, data for application execution, secret keys, or program code. Access to this data is securely protected by the operating system. All application data that needs to be read or written from the terminal, or in other words, all data that is intended for the outside world, is located in the EF working files. The data contained in such files is not used by the operating system.

All EF files containing useful data for a particular application are always grouped together in the same DF directory. This technique creates a clear structure and facilitates the entry of a new application into the smart card by creating the appropriate DF. In a smart card with a single application, all EF files can be placed either directly under the main MF file or in a separate DF directory. Smart cards with multiple applications have a corresponding number of DF directories where EF files belonging to specific applications are placed.

This file structure contributes to the security of your data. For example, for a Kiev enterprise aquasystem.kiev.ua Akvasistem, which offers finishing materials from well-known manufacturers, used Motorola smart cards and readers for the access system to the inventory management room of the enterprise, which allowed the Customer to get a reliable and modern ACS in a short time. Each time an application makes a request for memory access, the operating system can check whether the requested memory is outside the boundaries allocated in the DF directory for the application in question. If this is the case, the OS can deny access.

Unlike files in DOS systems, EF files in smart cards have an internal structure. This structure can be individually selected for each EF according to the intended use. The selected file structure allows you to build data elements in such a way as to provide direct and quick access to them. There are the following main variants of the internal structure of EF files:

1. a simple binary file;
2. linear file with fixed-length records;
3. linear file with variable-length records;
4. a circular file with fixed-length records.

Simple binary files are single unstructured blocks of smart card memory, the structure of which the application program can set in a convenient way for it. A simple binary file can be viewed as a string of bytes. When a command is executed to read or write information in a simple binary file, you must set the offset in bytes (from the beginning of the file) to the specific byte (within the simple binary file) from which the read or write will begin. A command to read or write information in a simple binary file must also contain a counter or the length of a byte string that is read from or written to the file.

Linear files with records are files containing smaller parts called records. The entries within the files are numbered sequentially. Records can be accessed by their numbers or by performing sequential read operations in the forward or reverse direction. In a file with fixed-length records, all records contain the same number of bytes. In a file with variable-length records, each record can contain a different number of bytes. A file with variable-length records requires more read/write access time and administration costs. Some smart card operating systems support limited line file search functionality.

Cyclic files are linear files that cycle back to the first record when the record following the last record is read or entered. It is convenient to think of a cyclic file as a ring of records. Each subsequent write operation to the file is performed on the next physical record in the ring. Read operations are performed on the last physical record.

Smart card operating systems support the usual set of operations with all files, such as creating, deleting, reading, writing, and updating. To work with the smart card file system, an application layer protocol is defined in the form of a set of functions for selecting, reading and writing files. Each smart card file has an access control list associated with it. This list specifies which operations each of the objects that have access to the card is allowed to perform on the file. For example, object A can read a specific file but cannot update it, while object B can perform read, write, and even modify the access control list in the file.