FUNDAMENTALS
Smart card operating systems, in contrast to commonly known operating systems, do not include user interfaces or the possibility of accessing external memory media. This is because they are optimized for completely different functionality. Security during program execution and protected access to data have the highest priority. Due to the limitations imposed by the amount of available memory, smart card operating systems have a very small amount of program code, which normally lies in the range of 3–250 kB. The lower limit relates to special applications, while the upper limit relates to multiapplication operations systems, some of which have interpreters for downloadable program code.However, the average memory requirement is around 64 kB for operating systems that do not support downloadable third-party program code. The program modules are written as ROM code. This limits the programming techniques that can be used, since many techniques typically used with RAM program code (such as selfmodifying code) are not possible withROMcode. The fact that the code is inROMalso explains why no changes at all are possible once the microcontroller has been programmed and manufactured. Correcting an error is thus extremely expensive and takes 10 to 12 weeks. If the smart cards have already been issued, errors can only be corrected by a large-scale recall campaign, which could destroy the reputation of a system using smart cards. ‘Quick and dirty’ programming is thus clearly out of the question. Consequently, the amount of time spent on testing and quality assurance is usually significantly greater than the amount of time spent on programming. These operating systems must not only have a very small number of errors, they must also be very reliable and robust. They must not allow their functionality, and above all their security, to be impaired by any command coming from the outside world. System crashes or unpredictable responses to an erroneous command or the failure of a page of EEPROM must never occur under any circumstance.

From the perspective of operating system design, it is an unfortunate fact that the implementation of certain mechanisms is influenced by the hardware that is used. Above all, the secure state of the EEPROM has a small but noticeable effect on the design of the operating system. For example, all retry counters must be designed such that their maximum value corresponds to the erased state of the EEPROM. If this were not the case, it would be possible to reset a counter to its initial value by (for example) intentionally switching off power to the card while it is writing a new value to the retry counter. This is because the EEPROM must be erased before certain types of write operations. If the power can be switched off exactly at the time between erasing the EEPROM and writing the new value, the portion of the EEPROM used for the retry counter would be in the erased state. If the operating system were designed incorrectly, this would amount to resetting the retry counter to its initial value. This type of attack can be countered by properly coding the counter, as just described, or by making the process of writing the retry counter an atomic operation. The situation with regard to the retry counter and the secure (lowest energy) state of the EEPROM is similar. The retry counter must be coded such that its maximum count corresponds to the secure state of the EEPROM. If this were not the case, it would be possible to reset the retry counter (by locally heating certain EEPROM cells, for example). These are only two examples of hardware dependences in the design of a smart card operating system; there are many others. For reasons of security, a smart card operating system must be closely coupled to the hardware of the microcontroller used. Consequently, it can never be fully hardware-independent. There is also another aspect to the concept of a secure operating system. ‘Trap doors’ and other types of hidden access points for system programmers are frequently found in large operating systems, in which they are perfectly normal features. However, they must be totally excluded in smart card operating systems. There must not be any possibility that someone could use some mechanism to bypass the operating system and (for example) obtain unauthorized read access to a file. Another aspect that should not be underestimated is the required processing capacity. The cryptographic functions present in the operating system must execute in very short lengths of time. It is thus common to expend weeks of painstaking effort to optimize the algorithms in question in assembler code. Due to the hardware platforms used and the required level of reliability, it is obvious that there is no place for multitasking capability in smart card operating systems. However, the limitation to a single executing task also restricts the use of security processes that monitor operating system components with regard to process execution and constraints.
In summary, the primary tasks of a smart card operating system are the following:
–transferring data to and from the smart card
–controlling the execution of commands
–managing files
–managing and executing cryptographic algorithms
–managing and executing program code.

Command processing
Commandprocessing in smart cards that do not support downloadable program code is typically organized as shown in Figure 5.2. The smart card receives each command via the serial I/O interface. The I/O manager performs error detection and correction procedures as necessary, fully independent of the other, higher level layers. After a command has been completely received without errors, the secure messaging manager must decrypt the message or test its integrity. If secure data transmission is not used, this manager is completely transparent to both the command and the response. After this processing, the next higher level, which is the command interpreter, attempts to decode the command. If this is not possible, the return code manager is called. It generates a suitable return code and sends it back to the terminal via the I/O manager. It may be necessary to design the return code manager in an application-specific fashion, since the return codes are not necessarily the same for all applications. If the command can be decoded, the logical channel manager determines which channel has been selected, switches to the state of this channel and invokes the state machine if no error occurs. The state machine checks whether the command, in combination with its accompanying parameters, is permitted in the current state of the smart card. If it is, the program code of the application command that processes the received command is executed. If the command is prohibited in the current state, or if its parameter values are not allowed, the terminal receives a message to this effect via the return code manager and the I/O manager. If it is necessary to access a file while processing the command, this occurs only via the file manager, which converts all logical addresses into physical addresses within the chip. The file manager also monitors all addresses with regard to region boundaries and tests access conditions for the file in question. The file manager utilizes a lower level memory manager, which performs all management functions for the physically addressed EEPROM. This ensures that this program module is the only one that uses physical addresses, which significantly increases the portability and security of the entire operating system. A central return code manager is responsible for generating the return code. It always produces the complete response sent to the calling routine. This level is responsible for managing
and generating the return codes used in all other parts of the operating system. Since smart card operating systems usually utilize cryptographic functions, there is normally also a dedicated library of cryptographic functions separate from the rest of the operating system. This library serves all other modules as a central point of departure for using cryptographic functions. In addition to these levels, an interpreter or verification routine for executable files may be present in the region above the application command level. It monitors the programs contained in these files and runs or interprets them. The exact design and implementation depends on whether there are actually any files with executable code present, and on whether the stored code is machine code for the processor or code to be interpreted. This subject is described in detail in Section 5.10, ‘Smart Card Operating Systems with Downloadable Program Code’.

Smart card profiles
In contrast to the realm of PC operating systems, the memory space of smart cards is so severely limited that in many cases not all of the standard commands and file structures are implemented. Consequently, ‘profiles’ for smart cards are included in the two relevant standards for generalpurpose operating systems (EN 726-3 and ISO/IEC 7816-4). Each profile defines a subset of the commands and file structures of the standard in question. A smart card that matches a certain profile must at least incorporate the defined subset for that profile. However, the descriptions of the profiles are contained in appendices in both standards and are designated ‘informational’ instead of normative. They thus represent only recommendations to operating system designers. The five profiles defined in the ISO/IEC 7816-4 standard are summarized in Table 5.3. Commercial smart card operating systems normally support various types of smart card microcontrollers with various amounts of memory. Consequently, there are in practice also operating system profiles that specify certain ranges of functions, depending on the chip type. These profiles within an operating system are normally designed such that applications can migrate relatively easily, at least from a smaller memory to a larger one, without any changes to commands or file structures.