In the case of smart card operating systems that support downloadable program code, one of the requirements is that code must be loaded into the memory of the smart card in a secure manner and in compliance with conditions imposed by the issuer of the smart card. There are a number of highly different, generally company-specific concepts for achieving this. The only internationally used industrial standard for this purpose is the Open Platform (OP) specification from Global Platform [GP]. An application is loaded into the smart card by transferring its load file to the card using the LOAD command. The INSTALL command, which continues the process, establishes the loaded application by invoking various on-card functions of the card manager and the security domain. The DELETE command is used to delete uniquely identifiable objects in a smart card, such as load files, applications and keys. Open Platform is described in Section 5.11, ‘Open Platform’.

When smart card microprocessors are manufactured, only the ROM is programmed. The EEPROM remains empty, apart from a chip number and a card-specific key. After the card body and the microcontroller have been combined to produce a smart card, the operating system code in the ROM must be supplemented by the portions that reside in the EEPROM. This is called ‘completing’ the smart card. Only after it has been completed does a smart card contain a full operating system, with all its functionality. There is a relatively simple loader program in the ROM for writing these parts of the operating system to the EEPROM. It can be used to write data to the EEPROM following a key verification. The EEPROM memory is addressed linearly, either byte by byte or page by page, using direct physical addresses. Once all necessary data have been entered into the EEPROM in this way, the operating system is switched over from pure ROM operation. From this point on, processes and routines also run in the EEPROM. This switchover can be performed by a command whose execution condition has been satisfied, following a prior checksum comparison for all of the completed EEPROM data. The checksum ensures that all the data have been correctly stored in the EEPROM. Completion does not employ particularly complex functions or authorization procedures, since it is necessary to rely on the ROM portion of the operating system. Even the smallest error here could make it impossible to complete the smart card. Such an error would be time-consuming and, all told, very expensive. In the rest of this section, three representative commands for completing the smart card operating system are described. The commands used for this purpose vary greatly depending on the operating system and chip manufacturer. Here we can only illustrate the necessary functions. However, practically all smart cards use this procedure or a similar procedure to complete the operating system. The COMPARE KEY command tests a password sent to the card against a reference password stored in the ROM and EEPROM by the manufacturer during chip fabrication. This key (password) is card-specific and is quite long (approximately 32 bytes). If the comparison is successful, subsequent load commands are permitted. Otherwise, a retry counter is incremented. Once the retry counter reaches a predefined value (e.g., 3), it blocks any further access to the card. The card can then be sent for recycling, since the only thing it can do is to generate an ATR.

After the load password has been successfully verified usingCOMPAREKEY, all necessary data can be written to the EEPROM using the WRITE DATA command. At this point, the EEPROM can be addressed and written byte by byte. This means that in addition to the data for the operating system, complete applications may also be loaded. Incidentally, this is the method normally used to load applications into smart cards having very little memory, since they do not have enough room for complex CREATE FILE commands and their associated state machines. If the amount of ROM in the smart card is so small that there is not even enough room for EEPROMtest commands, the basic functions of the test commands can be simulated using this command. This is done by repeatedly writing data to a specific memory location until the card reports a write error. If the number of write cycles is totaled, the number of possible write/erase cycles is known. This is the primary result expected from an EEPROM test command in the context of quality assurance. Once all data have been written to the EEPROM using one or more successive WRITE DATA commands, the content of the EEPROM is tested to see that it is correct, and the completion procedure is then terminated. The command used for this is COMPLETION END. After successful execution of this command, a card reset is normally triggered to reinitialize the operating system and allow it to achieve a new state. For tests and experiments, it is often necessary to be able to delete an existing completion. This is usually not possible, but a command that provides this capability is available in a few isolated operating systems. This is the DELETE COMPLETION command, which can reverse the completion of the operating system. With this command, it is not necessary to use a new smart card for every new completion. This command is used exclusively for testing purposes. The correct completion of a smart card operating system can be verified using the CHECK COMPLETION command. For this purpose, the smart card computes a checksum from the completion data and compares it with a reference value stored along with the completion data. If the two checksums match, the completion is correct.