COMPLETION
The life cycle of a smart card operating system passes through two major stages – that before completion and that after completion. In the stage before the card is completed, in which the microcontroller comes from the semiconductor plant with an empty EEPROM, all parts of the program run in ROM. No data are read from the EEPROM, nor is any code run from the EEPROM. If an error in the ROM code that makes completion impossible is discovered at this time, the entire batch of microcontrollers must be destroyed, since the chips are unusable. To minimize the likelihood of such a situation, it would be possible to have the ROM contain only a small routine for loading the EEPROM, and load the actual operating system into the EEPROM. However, the chip area per bit is four times as much with EEPROM as with ROM, which means that such an approach would excessively increase the cost of the chip. For purely economic reasons, therefore, as much of the code as possible must be located in ROM. Consequently, all of the core operating system routines, as well as substantial parts of the rest of the operating system, are stored completely in the ROM. Only a few jumps to the EEPROM are provided for use in the completed version. Some operating systems run completely in ROM even after completion, with only data being stored in the EEPROM, in order to keep the size of the relatively expensive EEPROM as small as possible. Of course, minimizing the area used by the memory comes at the price of major limitations on the flexibility of the operating system. In the completion process, the code in the ROM is adapted to the actual application. The ROMcode can be regarded as a large library that is interconnected and expanded to form a functional application by the code in the EEPROM. In addition, almost all operating systems allow program code for additional commands or special cryptographic algorithms to be loaded into the EEPROM during completion. This has nothing to do with any executable files that may be present, since the contents of such files can be downloaded at a later time, such as when the card is personalized. The routines that are entered into the card during completion are completely integrated into the operating system and can be utilized directly by the operating system. In order to complete a smart card operating system in the EEPROM, unilateral or mutual authentication between the smart card and the outside world is necessary. There are many different methods that can be used for this. Figure 5.6 shows a typical example that uses a simple but relatively flexible approach. The producer of the smart card operating system incorporates a secret value in the ROM code for the microcontroller, which is thus specific to this ROM version of the operating system. During chip fabrication, the semiconductor manufacturer writes a secret key to the EEPROM, which may have a different value for each fabrication batch. After this, if the ROM and EEPROM keys are known, a cryptographic algorithm can be used to compute an authentication value for smart card completion. The operating system can be completed only after successful authentication.

This method allows batch-specific authentication to be performed. For instance, if an operating system producer provides only one authentication value to a card manufacturer, the latter can only use it to complete one particular batch of smart card microcontrollers. The advantage of this method is that the producer of the operating system only has to have one ROM mask, instead of generating a different version of the ROM for each card manufacturer. This method can be further refined. For instance, a chip-specific authentication value can be generated using the microcontroller serial number. Not only does this increase the level of security if the chips fall into the wrong hands on their way to being completed, it also allows the producer of the operating system to control the completion process at the individual chip level.With such an approach, the completion agent receives a list of authentication values and can only complete the operating system in the corresponding microcontrollers. This method, or a similar method, is commonly used in practice. Conceivably, a special smart card containing a function for reading out the contents of the memory could be smuggled into the smart card manufacturing process and be completed, initialized and personalized, after which the secret data loaded into memory during these steps could be read out. Although this would be rather difficult in a typical smart card manufacturing process, due to the strong security measures that are used, it is certainly not possible to fully exclude such a scenario. In order to provide inherent defense against this conceivable form of attack, the authenticity of the microcontroller can be verified prior to completion. This method requires an individual key to be stored in each microcontroller by the semiconductor manufacturer. Prior to completion, a random number is sent to the smart card in order to prevent playback attacks. This random number, the individual card key and the content of the ROM are then converted into a hash value by a hash function in the smart card, and this hash value is conveyed to the outside world along with a card identifier. There the card-specific key can be computed using the card identifier. Since the ROM content and the random number are known to the outside world, the hash computation can be reproduced in the outside world, and the result can be compared with the hash value received from the smart card. If the two values match, the smart card is authentic. Although this method is simple, it is without doubt sufficiently effective. Certain aspects can be further refined, but our primary objective here is to present a conceivable approach to verifying authenticity prior to completion.

Hardware recognition
Most relatively recent operating systems can be used with microcontrollers having various amounts of EEPROM, although the size of the ROM and RAM are not allowed to vary. This allows the card issuer to always use the least expensive version of the microcontroller that meets his needs. For example, he could start with an inexpensive single-application card with 1 kB of EEPROMand then migrate to more expensive microcontrollers with 4, 16, 32 or 64 kB of EEPROM as needed for his multiapplication cards. To the extent that the microcontroller manufacturer supports such a range of chips, the smart card operating system must also have matching capabilities. This means that it must be able to automatically recognize the size of the EEPROM, and consequently set up its internal pointer structures for maximum free memory, file sizes and similar operational parameters. The technical implementation of this involves using an operating system routine to read the manufacturer’s fabrication data and calculate the size of the available EEPROM from this data. This technique can only handle variable EEPROMsizes; current smart card operating systems cannot adapt themselves to various sizes of ROM or RAM. The main advantage of this hardware recognition capability is that the producer of the smart card operating system does not have to match the program code to the size of the EEPROM. This eliminates a possible source of errors, and above all it means that the operating system does not have to be re-evaluated for every new hardware platform. The hardware recognition capability of modern operating systems saves considerable time in software development and can thus reduce product development time by several weeks.

Soft masks and hard masks
The terms ‘soft mask’ and ‘hard mask’ are often used in connection with field trials and smart card operating systems. Strictly speaking, both terms are nonsensical from a purely logical point of view, since a ROM mask – which means the program code located in the ROM – is always unalterable and thus ‘hard’. In the jargon of the smart card world, however, the term ‘soft mask’ means something only roughly similar to a ROM mask. This term is used when part or all of the program code for a smart card operating system, or the commands for an application, is located in the EEPROM. This means that the code can be altered relatively easily, without the cost and time involved in generating a new ROM mask. This type of mask is thus alterable, or ‘soft’. Soft masks are primarily used in testing and field trials, since they allow errors to be corrected and programs to be modified quickly and at minimal cost. The disadvantage of using a soft mask is that it requires using chips with large EEPROMs, which are more expensive than equivalent chips with program code in ROM. However, since field trials normally do not involve issuing millions of cards, the increased cost of using chips with large EEPROMs is entirely acceptable. Once the test or field trial using a soft mask has been completed and the program code in the EEPROMis operational without any further modifications, it can be moved from the EEPROM to the ROM by generating a true ROM mask. This can be done with relatively little effort, and the result is called a ‘hard mask’, since it cannot be readily altered. Strictly speaking, the only advantage of a hard mask is that a given amount of memory occupies significantly less chip area in ROM than in EEPROM, thus allowing a smaller and less expensive microcontroller to be used for the same amount of program code. This two-stage process using soft and hard masks for new smart card applications also provides flexibility and allows substantial changes to the program code to be made even shortly before the cards are issued to users. With a traditional process using a pure ROM mask, it is not possible to make significant changes to the program code once the mask has been given to the manufacturer. Since the two-stage process is superior to the traditional process in this regard, nowadays a soft mask is almost always used initially when introducing a new smart card application. Migration to a hard mask occurs only after any necessary modifications have been made to the program code.

Operating system APIs
Originally, smart card operating systems did not allow third-party software to be loaded into the card and executed as needed. Consequently, at that time operating systems did not have published programming interfaces that could be used by third parties to call operating system functions. More recent developments in smart card operating systems, such as MULTOS and operating systems that support Java (Java Card), allow third parties to load their own program code into smart cards. In order to eliminate the need to again program routines already present in the operating system, such operating systems include carefully conceived application programming interfaces (APIs) that provide access to the most important functions of the operating system. Naturally, practically all operating systems have their own internal APIs, but these APIs are not designed for external use and are usually confidential. As an exception to the usual situation in the smart card world, there are no general standards relating to APIs for smart card operating systems. Instead, two industry standards have come into predominant use. One of them consists of the various Java Card APIs, while the other is the Multos API. The APIs described in the related specifications provide access to the essential functions of the operating system.2 These functions include access to the file manager, calls to the available cryptographic functions and, naturally, transmitting and receiving data. The only essential difference between any of the well-known PC operating systems and a smart card operating system with a complete operating system API and provision for downloaded program code is the amount of memory available to the operating system.

MEMORY ORGANIZATION
The three different types of memory used in smart card microcontrollers have completely different properties. ROM can only be programmed using a mask during manufacturing, and it is all programmed at the same time. Its content is static for the life of the chip. Given the construction of ROM, the chance of an undesired change in the content of the ROM is practically zero. In contrast to ROM, RAM retains its content only as long as power is applied to the smart card. A power failure causes total loss of all data stored in the RAM. However, data can be written toRAMat the full operating speed of the processor, andRAMcan be erased an unlimited number of times. EEPROM, by contrast, can retain data without external power. However, it has three disadvantages, which are its limited lifetime, the fact that it is divided into pages and its relatively long write and erase times (around 1 ms/byte).With the exception of the interrupt vectors, which are prescribed by the microprocessor, the operating system program code stored in ROMdoes not have to comply with any particular structure. The individual routines can thus be linked to each other in any desired sequence, although an attempt is made to limit the length of jumps in order to save memory space. What is important is that the ROM is protected by error detection codes (EDCs), since it is certainly possible for errors to occasionally occur in the ROM.Ascratch in the ROMregion of the microcontroller, for example, or a fracture during the wire bonding process, can cause the data in the ROM to be incorrect. Interestingly enough, this does not necessarily mean that the operating system can no longer function; instead, it is certainly possible that only specific routines will run incorrectly. In order to prevent problems that might arise in such situations, the ROM is checked when the operating system starts up to verify that it is fundamentally free of errors. Figure 5.8 shows the usual memory organization of a 256-byte RAM. It is divided into regions for the registers, the stack, general variables, workspace for cryptographic algorithms and the I/O buffer. If an I/O buffer of 256 bytes is required, for example, or if additional variables must be stored in RAM, the limits of the available memory can be reached very quickly. This problem is solved by having workspace in the EEPROM, which is thus used like RAM. The disadvantage of this is that it takes around 10,000 times as long to write data to EEPROM as to write data to RAM. An additional disadvantage is the limited lifetime of EEPROM cells, since unlike RAM cells, they cannot be written an unlimited number of times. However, moving the content of the RAM to the EEPROM is often the only solution, such as when an I/O buffer is needed that is larger than the entire amount of available RAM. For comparison, Figure 5.8 also shows the typical organization of a 6-kBRAMin a high-performance telecommunications smart card.

The organization of the data stored in EEPROMis much more complicated and intricate than either of the other two types of memory.With modern operating systems, the basic partitioning of the EEPROMis essentially as follows (see Figure 5.9). First, many types of microcontrollers have a region at the beginning of the EEPROM with special hardware protection that can be used to store special manufacturing data, such as a number that is only used once and is thus unique to the chip. Many semiconductor manufacturers also record the chip type and the amount of EEPROM available to the operating system in this region. This region is usually designed for write once, read multiple (WORM) access, which means that it can be written only once, after which it can only be read. Technically, this is usually achieved by using regular EEPROM cells that have been modified so that they cannot be electrically erased. Above this region, which usually has a size of 16 to 32 bytes, come the tables and pointers for the operating system, which are loaded into the EEPROM when the card is completed. The combination of these tables and pointers and the routines stored in ROM yields the complete smart card operating system. In order to ensure that the operating system can always be used in a secure and stable state, this region is protected by an error detection code (EDC) that is recomputed and checked before the first EEPROMaccess or even before every EEPROMaccess. If a memory error is detected during EDC verification, the affected portion of the EEPROM must subsequently not be used, since this means that proper operation of the operating system cannot be assured. Above the protected portion of the operating system, there is a region that contains additional application program code. If need be, this region may also be protected against alteration by using a checksum. Application-specific commands or algorithms that should not be located in the ROM or that are too large to fit in the ROM are placed in this region. The next region contains all of the file structures, or in other words, the entire externally visible file tree. This region is not protected as a whole by a checksum, but instead usually has strong file-based protection. The internal structure of this region is shown in more detail in Figure 5.9. At the top of the EEPROM, there is an optional free memory region that has its own memory manager. However, the free memory is often assigned to individual applications in the file region, where it can be used within the applications for the creation of new files.