Protective elements: smart card operating systems
Protective mechanisms in the hardware form the basis for protective mechanisms in the operating system software. No potential weakness may be overlooked, since the three components of the protective mechanisms – hardware, operating system and application – are linked in a logical AND relationship. This is similar to a chain, in which the weakest link determines its breaking strength. If a particular mechanism fails in a smart card, the entire security of the card collapses. The operating system in particular forms the basis for the actual application, whose information and processes must be protected. The following material deals specifically with measures for protecting against typical attacks, rather than general smart card security functions. However, most of these general functions also contribute significantly to operational security and protection against attacks. For this reason, you are explicitly referred to the appropriate sections of Chapter 5.

Protection: hardware and software tests following a reset
When the operating system is initialized, at minimum the most important parts of the hardware must be tested to see if they are in proper working order. For instance, a RAM test is indispensable, since all access conditions are stored in the RAM while the chip is operating, and failure of a single bit could cause a complete security collapse. It is likewise necessary to compute and test the checksums for the most important portions of the ROM and EEPROM. The CPU is at least implicitly tested by sending the ATR, since the bulk of all possible machine instructions must be executed faultlessly for this to be possible. Explicit testing of the CPU and any NPU that may be present can usually be limited to sample testing, since completely testing all functions for flawless operation would take too much time and code. If the operating system discovers a hardware error or checksum error, there are two possible ways to proceed. The first option is for the software to immediately jump to an endless loop, which means that an ATR cannot be sent and subsequent commands can no longer be received. The main disadvantage of this is that the cause of this behavior cannot be recognized from the outside. The problem might be a broken bonding wire, a fractured chip or a checksum error in the EEPROM, but this cannot be determined by the user. A better option is to have the smart card attempt to send a special ATR before disabling itself by entering an endless loop. The error ATR at least gives the outside world an indication of what has happened inside the smart card. However, it must not be overlooked that simply sending an error ATR requires a largely functional CPU, a few bytes of RAM and several hundred bytes of program code in the ROM.

Protection: layer separation in the operating system
Layer separation, with clearly defined parameters for transitions between the individual layers, is a sign of a stable and robust smart card operating system. The consequences of possible design or programming errors in the operating system are minimized by clean separation of the layers within the operating system. Of course, this does not mean that such errors will not occur, but the effects of the errors will not be as extensive as with an operating system programmed in very compact, condensed code. Layer separation makes it difficult for any error that occurs in one layer to propagate to other layers.

Protection: supervising data transmission
Another very important element of security is to supervise the data transmission process in order to protect the memory against unauthorized accesses. All communications to and from the smart card take place via an I/O interface supervised by the operating system. No other form of access is possible. This represents an effective form of memory protection in the smart card, since it ensures that the operating system always retains control over access to memory regions. The transmission protocol, which is controlled by the transport manager, must intercept all possible incorrect inputs. There must be no possibility of influencing the data transmission process by manipulating transfer blocks in order to cause data to be illicitly sent from the memory to the terminal.

Protection: checksums for important memory contents
The file structure, and in particular the file headers (file descriptors), should be protected using checksums. This enables the operating system to at least detect any unintentional changes to data stored in memory. This requirement is especially important in light of the fact that the object-oriented access conditions for each file are stored in this part of the file. All memory regions of the EEPROM that are vitally important for the smart card operating system must be protected using checksums (EDCs). Whenever such a region is accessed or the code it contains is called to be executed, the consistency of its contents must be verified before the access or code execution is allowed to proceed.

Protection: encapsulation of applications
Some operating systems encapsulate the individual DFs containing the applications and their files, so that individual applications are isolated from each other. However, this concept is based on software protection alone, with no support from the chip hardware. The amount of protection is thus not as great as it could be. Nonetheless, even this software approach to application encapsulation can be very beneficial in case of an error, since it makes it impossible for the file manager to exceed the boundaries of aDFwithout explicit prior selection. The effects of a memory error on a file are thereby at least limited to the DF in question. If hardware support for the operating system is present in the form of a memory management unit (MMU), the various applications can be fully isolated from each other. In this case, even manipulated software within an application cannot obtain unauthorized access to the memory regions of other applications.

Protection: camouflaging the activities of the operating system
Whenever data must be written to the EEPROM, the charge pump in the chip must first be switched on. This increases the current consumption of the chip, and with some types of microcontrollers this can easily be detected using a suitable measurement setup. This means that the fact that it may be possible to externally determine when EEPROM write accesses occur must be taken into account in the design of the operating system. The software in the smart card must prevent an attacker from being able to take advantage of this knowledge. It is very important that it should not be possible for an attacker to draw any useful conclusions about processes and decisions in the machine program by measuring the current drawn by the card. For instance, it would be fatal if it were possible to use such measurements to reliably judge the outcome of a PIN comparison before the completion of command processing and transmission of the return code, since this information could very easily be used to analyze the value of the PIN.

Protection: object-oriented access conditions
Early smart card applications were always based on a centrally managed access mechanism. One disadvantage of centralized access management mechanisms is that software or memory errors can affect the overall security of the smart card. Modern object-oriented file management systems, in which the access conditions are stored in the individual files, have the advantage that only a single file is affected by a memory error, with the security of all other files remaining intact. This is actually a fundamental property of all distributed systems. They are somewhat more difficult to program, but they provide significantly stronger security against attacks and errors, due to their self-sufficiency.

Protection: disabling the smart card
The operating system must allow the smart card to be fully disabled. This is very important for the final stage of the smart card life cycle. Using statistical methods, it is possible to perform very exact analyses of the software in the chip by collecting discarded but still fully functional smart cards. To prevent this, mechanisms for completely disabling the operating system and all of its routines must be available in the operating system, in order to make it impossible to analyze the electrical or runtime behavior of the cards.

Attack and defense: random number generator
The random numbers generated by the smart card are used in authentication to individualize a session, which means to make each session unique and different from all preceding and following sessions. The objective of this is to make it impossible to successfully replay data that have been obtained by tapping a previous session. Another form of the attack would be to have the smart card generate so many random numbers that their sequence becomes predictable. Yet another possibility is to keep requesting random numbers from the smart card until the EEPROM memory of the random number generator no longer works properly, so that the same number is generated over and over again. Any of these attacks could, if successful, bypass the authentication of the terminal by the smart card. Without exception, they work only with the first generation of smart cards. They will all fail with modern operating systems. The cycle length of current random number generators is so large that the same random number never appears twice within the lifetime of an individual smart card. It is also no longer of any benefit to generate so many random numbers that problems start to occur with the EEPROM. If this happens, random number generation is simply blocked, so further authentication is prevented. A high-quality random number generator must meet some additional requirements, such as producing non-predictable random numbers and having a long cycle length (the number of values that are generated before the generator repeats itself). In addition, all smart cards within a particular application must generate different random numbers. This may sound extremely obvious, but problems have repeatedly occurred in the past in this regard! This different behavior is achieved by entering a starting value for the pseudorandom number generator when the smart card is initialized or personalized. This starting value is often called a seed number, in allusion to a biological seed that determines the growth of a plant. The design and evaluation criteria for pseudorandom number generators are extensively discussed in Section 4.9, ‘Random Numbers’, along with methods to measure the quality of random numbers.