COMMANDS FOR HARDWARE TESTING
During initialization, the operating system of the smart card tests various hardware components, both implicitly and explicitly. The commands described here, however, go far beyond the selftest routines integrated directly into the operating system. As part of production quality assurance, it is necessary to separately verify certain critical parts of the microprocessor. These tests focus particularly on the EEPROM, since experience shows that most problems show up here. The operation of the processor is implicitly verified if the terminal can receive a correct ATR. Since there are no standards for test commands, their functionality and coding depend on the producer of the operating system, and sometimes on the operating system itself. The test commands may be permanently stored in ROM. However, it is also quite common for them to be loaded into the EEPROM via the completion commands and then executed in the EEPROM. Obviously, this can cause problems if the EEPROM is not fully functional. The advantage of using EEPROM is that it makes more space available in the ROM. In the interest of operating system security, using test commands must be restricted to the stage preceding completion. This means that all test commands are blocked in a card that has been initialized or even personalized. Possible exceptions are the RAM test and the ROMor EEPROMchecksum tests, since these commands do not affect security. The following commands may be used for extensive hardware tests. A dysfunctional RAM would cause a complete operating system crash even before the ATR could be sent, but it is possible for a few RAM bits or bytes to be ‘dead’. This would only affect certain functions or routines. The TEST RAM command checks the entire RAM and sends an appropriate response to the terminal. During the test, all available bytes must be written and read using a variety of test patterns.Atypical test consists of writing’55′and’AA’alternately, since these two hexadecimal values form a checkerboard pattern at the bit level. Another effective method is the wave test, in which the RAM is first written from the lowest to the highest address and then read, and then from the highest to the lowest address. The exact implementation of this test depends on the operating system. Sometimes this test is omitted. The TEST EEPROM command is used to perform an EEPROM endurance test by overwriting the contents of the EEPROM. The smart card receives two patterns, which it writes alternately to an area of memory. The size of this area and the number of write attempts can be specified in the command, within certain limits. Naturally, the operating system must check the memory content for errors after each write cycle.

Since the number of write cycles is supplied to the smart card as a command parameter, this command can be fully processed inside the smart card. This is much faster than sending a sequence of individual commands. If the card discovers a write error, it returns the number of already completed write cycles and the address of the error to the terminal. The EEPROM endurance test can be used not only for destructive testing of the EEPROM, but also for writing data to freely chosen regions of the EEPROM. In the latter case, the number of write cycles is set to one. The COMPARE EEPROM test is used to test whether a pattern written to the EEPROM is still present in the EEPROM. This command is primarily used in combination with the TEST EEPROM command to test EEPROM data retention at various temperatures. This is done by writing a pattern to several memory pages, placing the smart card in an environmental test chamber for a certain length of time, and then checking whether the pattern has been retained. In principle, the TEST EEPROM command can be used to erase the entire EEPROM if the start and end addresses are appropriately specified. However, many operating systems have a command that we can call DELETE EEPROM. It erases the entire EEPROM in one go by overwriting the entire contents of the EEPROM. This command is employed for only two purposes. The first is to restore the EEPROM to a predefined state with a minimum of effort after various tests have left their test data in the EEPROM. The second is to reduce the time required to initialize or complete the operating system. If the DELETE EEPROM command is executed prior to either of these activities, the EEPROM can subsequently be written faster, since it avoids the frequently encountered need to erase an EEPROM page before writing new data to it.

COMMANDS FOR DATA TRANSMISSION PROTOCOLS
In principle, data transmission protocols should be designed to be fully independent of the data and commands of the application layer. This is also the intention of the OSI layer model. Unfortunately, there is a discrepancy here between theoretical requirements and actual practice. There are two commands whose only purpose is to allow transport mechanisms to be utilized at the application level, namely GET RESPONSE and ENVELOPE. There is also another command, MANAGE CHANNEL, whose function is not used by the application layer alone. In the T = 0 protocol, it is not possible to send a block of data to the smart card and receive a block of data from the smart cardwithin a single command–response cycle.5 This protocol thus does not support case 4 commands, although they are frequently used. It is thus necessary to use a work-around for the T = 0 protocol. This operates in a simple manner. The case 4 command is first sent to the card, and if it is successful, a special return code is sent to the terminal to advise the terminal that the command has generated data that are waiting to be retrieved. The terminal then sends a GET RESPONSE command to the smart card and receives the data in the response. This completes the command–response cycle for the first command. As long as no command other than GET RESPONSE is sent to the card, the response data can be requested multiple times.

If commands are completely encrypted as part of secure messaging, transmission problems can occur with the T = 0 protocol, which requires both an unencrypted instruction byte and an unencrypted Le byte. The ENVELOPE command gets around this restriction by embedding a complete APDU, with its header and data section, in the data section of the APDU of the ENVELOPE command. This can be encrypted without any restrictions and transmitted using any protocol. The same procedure is used for the response generated by the smart card, which is also embedded in the APDU of the ENVELOPE command. The ENVELOPE command is also used to implement proactive commands for the SAT and USAT.6 This use corresponds to the above description, with the exception that the data are not encrypted. Logical channels can be used which allow up to four applications in a single smart card to be addressed independently of each other.7 The commands and applications are coordinated by two bits in the class byte. Before the terminal can use a new logical channel, it must explicitly advise the smart card via the MANAGE CHANNEL command. This signals to the card that an additional channel is needed. The channel number can be specified explicitly by the terminal, or the card can supply the number of a free channel in its response. When a new logical channel is opened from the standard channel (channel 0), the behavior of the card in the new channel is the same as after a reset, which means that the MF is selected and no security state has been attained. When a new logical channel is opened from a channel other than channel 0, the current DF selection and current security state are retained. When a logical channel is closed, the associated file selection and security state are deleted.