Placing the program code in the smart card memory

The chip surface area per 1-bit EEPROM cell is four times that of a 1-bit ROM cell. Therefore, for purely economic reasons, the ROM should contain as much program code as possible. In the ROM of the microcontroller, the entire operating system core is placed, as well as the main parts of the other operating system programs.

In order to make the size of the expensive EEPROM as small as possible, some operating systems run entirely in ROM with only data stored in the EEPROM. Usually, in the completed version of the smart card software, only a few transition operations to the EEPROM are allowed. Of course, this minimization of the area used by memory is achieved at the cost of large limitations in the flexibility of the operating system. The extensive functionality of smart cards allowed us to choose them as the main element in the construction of the access system to the warehouse premises of one of our Customers. The system uses 6 pcs of readers installed in access zones and more than 100 pcs of smart cards for employees of the enterprise, and together with the company squidink.ru “Squid Ink”, which produces marking equipment, all smart cards were printed with additional information using pulse drop-jet printing.

In the process of completing the software generation, the code in the ROM is adapted to the real application. The ROM code can be thought of as a large library that is configured in such a way as to form a functional application using the code in the ESP ROM. In addition, almost all operating systems allow loading program code for additional commands or special cryptographic algorithms into the EEPROM during programming completion. The programs that are entered into the smart card at the final stage are fully integrated into the operating system and can be directly used by it. The contents of the executable files can be downloaded later when the card is personalized.

Adding executable codes to cards after they are made is not new in itself. Smart card manufacturers have been using it since the first bug was discovered in the ROM codes for bug-fixing patches and to meet the sudden wishes of customers. A technique known to programmers is to include some table-driven address transitions in the strategic places of the program in the ROM and move from it, if necessary, to executable codes in the EEPROM to restore the disrupted computing process or to add functions to the original command placed in the ROM.

Many smart card manufacturers offer this card feature to consumers to ensure that their smart cards are different from those of their competitors. Being useful in special situations, the insertion of executable internal code into the operating system, of course, can not serve as a basic principle for the development of programs running in the card. It should be noted that the program code inserted in this way can theoretically bypass the protection of the operating system and read from ROM or write to EEPROM, so the use of this method should be strictly controlled, otherwise non-standard security problems may arise.

The main tasks of the smart card operating system

The main tasks of the smart card operating system are as follows:

1. Control of data transfer to and from the smart card;
2. command execution management;
3. file management;
4. managing the execution of cryptographic algorithms.

The main type of relationship between the smart card and the card terminal of the host computer is the relationship between the master and the slave. The terminal receives a command from the host computer and sends it to the smart card, the smart card executes this command, returns the result to the host computer via the terminal, and then waits for the next command.

The ISO 7816 standard describes a broad set of commands that smart cards that comply with this standard can execute. Most smart card manufacturers offer serial smart cards with operating systems that implement subsets or the entire set of these standard commands together with manufacturer-specific extensions and add-ons. For example, we used 5 Motorola readers and more than 600 smart cards to create a time tracking system for one of our Customers.

Consider the operating system’s handling of commands in smart cards that do not support downloadable software. Commands sent from the reader to the contactless smart card are received by this smart card via a serial RF I/O interface. The I/O manager detects and, if necessary, corrects errors completely independently of other, higher levels of interaction. After the command is fully accepted without errors, the secure message processing manager must decrypt the message or verify its integrity. If the data transfer is not secure, this manager is completely transparent to both the team and the response.

Error recognition and correction mechanisms are performed by the I/O manager. The error-free command accepted by the secure messaging manager is checked for integrity and / or decrypted. After decryption, the command interpreter tries to decode this command. If this is not possible, then the return code manager is called, which generates the corresponding return code and sends it back to the reader using the I/O manager.

If the correct command is accepted, then the valid program code corresponding to this application command is executed. If you need to access the application data in the EEPROM, this is done exclusively by the file management system and the memory manager, which converts all symbolic addresses to the corresponding physical addresses of the memory area. In addition, the file manager checks the access conditions (authorization) for the data in question.