Attacks and defensive measures during development
A wide variety of security measures are employed starting with the development of microcontroller hardware and the software for smart card operating systems. Like quality, security is a factor that must be addressed from the very beginning of a development project; it cannot be designed into a product afterwards. With regard to attacks in the development stage, it can generally be said that access to the facilities in question is very difficult and the required level of expertise is very high. The attractiveness of an attack is thus correspondingly reduced. Nevertheless, the potential danger of a successful attack at this stage is significant, since there are very extensive possibilities for manipulating the hardware and software.

Development of the smart card microcontroller
The development of the hardware for a smart card microcontroller takes many months. It involves only a few persons and takes place in controlled-access, supervised rooms within the facilities of a semiconductor manufacturer. The computer systems used to design the IC are usually part of an independent network that is isolated from the rest of the world. This makes it impossible to alter the chip design from outside, as well as preventing outsiders from obtaining information about the internal design of the chip. A very extensive amount of insider knowledge is needed to undertake manipulations to a chip design that would weaken its security, so this type of attack is probably very unlikely. In addition, nowadays the designs and protection mechanisms of almost all smart card chips are evaluated by independent testing agencies, so an insider attack would not go undetected. However, it certainly could be advantageous to an attacker to know the exact design criteria and the arrangement of the functional elements on the chip, since he would then be aware of the protective mechanisms and sensors present in the chip and the scrambling of busses and memories. This knowledge could later be useful to an attacker with regard to physical chip analysis.

Protection: design criteria
There are a number of basic criteria that apply to the definition of the functions of a smart card microcontroller. One of these is that the mechanisms for protection against static and dynamic attacks must actually work. Sensors and other protective elements are of little use if they can be too easily circumvented or if they are not effective under certain conditions. An example is a sensor on the microcontroller chip that has such a large area that it can easily be destroyed by a needle, after which it no longer can fulfill its protective role. One design criterion that differs from the criteria used for standard chips but is nonetheless very important is that absolutely no undocumented mechanisms or functions must be present in the chip (‘that’s not a bug, that’s a feature’). Such undocumented features are usually not fully tested, since only a few people know about them, so they often exhibit various errors and weaknesses. Since they are not documented, they can be unintentionally overlooked during hardware evaluation and possibly be used later for attacks. The use of such undocumented features is thus strictly prohibited, even though they can often be very helpful for developers.

Protection: unique chip number
When the semiconductor hardware is being developed, all hardware security components must be first defined and then converted into hardware for the resulting microcontroller. One such component, in addition to sensors and protective coverings, is write once, read multiple (WORM) memory, which is also referred to as one-time programmable (OTP) memory. When the semiconductor chips are manufactured, a unique chip number is written to this memory. This means that each chip is different and can be uniquely traced, and smart cards can later be unambiguously identified within the system. In addition, chip numbers can also be used for the derivation of keys, and they make it possible to generate‘blacklists’ that can be used to take suspect cards out of circulation. It should not be overlooked that although these numbers cannot be altered in the original chips, they naturally provide no protection against imitation chips using freely programmable microcontrollers. This means that security measures cannot be based solely on the presence of a particular chip number in the WORM memory of a particular chip. Such a unique number can only be used as the basis for true cryptographic security mechanisms. For example, a chip number can be used for the derivation of secret keys, which are in turn used in a challenge–response authentication process.

Development of the smart card operating system
Software for smart cards is developed according to modern software development principles. Regardless of which life-cycle model is used (waterfall, spiral or whatever), certain general conditions must be observed. The development computer always requires a separate, completely isolated network that does not allow any external access. The development tools, such as compilers and simulators, are software packages whose proper operation must be verified in dedicated tests. Sometimes two different compilers are used in order to be sure that the results are correct. Using software whose origins are not completely traceable is fundamentally prohibited, since such software would offer a possible means to manipulate development tools and consequently modify the programs to be generated.

Protection: development principles
Just as with hardware development, no undocumented features may be built into the software. For example, it would certainly be possible to convert the laborious black-box tests that are commonly used with smart cards into white-box tests by incorporating commands that could be used to read out arbitrary regions of memory. However, should one of these commands be inadvertently left in the operating system, it could be used to read out secret keys in real smart cards. In order to eliminate the possibility of such an attack, the creation of dump commands is undesirable, even through they can save valuable development time. However, deadline pressure and the steadily increasing complexity of smart card operating systems have led to a relaxation of this principle. In order to ensure that none of these development-state commands ever comes to be present in real smart cards in actual use, special tests for the absence of such commands are performed during smart card completion. An additional principle is that programmers should never work alone on a project. This is already forbidden by considerations of software quality assurance, but the ‘four eyes’ principle must be observed for reasons of security as well. This effectively hinders attacks by insiders, since at least two developers must agree to work together on any attack. In addition, internal source code reviews are performed regularly, which assures the quality of the code and also supervises the development process. Once the software development is finished, the entire source code and its functions are often inspected by an independent testing agency, as part of a software evaluation. The main reason for performing this time-consuming and costly review is to check for software errors, but it also has the effect of making it impossible for a developer to hide a Trojan horse (for example) in the operating system. In practice, such items can be found only by reviewing the entire code, since an experienced programmer can certainly find means and techniques to hide a Trojan horse so that it cannot be found by a black-box test.

Protection: distributing knowledge
If several people work on a task, the result will be significantly more resistant to attack, due to the various opinions and experience of the people involved. The principle of distributing knowledge (shared secrets) is the opposite of the idea that ‘everybody knows everything about everything’. In the development of security components, complete knowledge of the component should fundamentally never be vested in a single individual, since that person would then be a target for an attack. As in many military realms, knowledge is divided over several individuals in the development stage, so that although it is possible for experts to discuss particular subjects, there is never any single person who knows everything. A similar situation exists with regard to completing the smart card operating system, during which tables, program code and configuration data are loaded into the EEPROM. In addition to providing increased flexibility, this procedure also has a security aspect. This is because the chip manufacturer, who receives the final, assembled ROM code for producing the fabrication masks, does not have complete knowledge of the operating system. The parts of the operating system that are located in the EEPROM are unknown to the chip manufacturer, so he cannot discover the complete security mechanisms and functions of the operating system by analyzing the ROM code.