EXECUTABLE NATIVE CODE
Presently, most microcontrollers for smart card still have processors that do not have any sort of memory protection mechanisms or any supervisory or monitoring capability. As soon as the program counter finds itself addressing ‘foreign’ machine code, control of all of the memory and all of the processor’s functions rests entirely with this executable code. At this point, it is no longer possible to restrict the functions of the executable program. Every addressable memory location can be read by bypassing any memory manager or handler that may be present, and memory locations in EEPROMandRAMcan also be written. The entire content of the memory could thus easily be sent to a terminal via the card interface. This is precisely the weak point of downloadable and executable programs. If everyone was allowed to download programs, or if programs could be downloaded by circumventing protective mechanisms, the security of any secret keys or other confidential information within the entire memory region could be no longer assured. This would be the ideal form of attack on a smart card. The card would still behave in the same way as a non-manipulated card with respect to the outside world, but special commands could be used to read out its entire memory or write data to portions of the memory There is yet another compelling argument against third-party downloadable programs. The producer of the files to be downloaded must know all of the entry points ( jump addresses) and calling parameters of the operating system routines in order to use important operating system functions. However, some operating system producers prefer to reveal as little information as possible about the internal processes and addresses of their program code, since they consider such information to be critical with regard to the security of their products. In addition, it would be necessary to verify that the downloaded code does exactly what it is supposed to do without any errors, and without harboring a Trojan horse. This can only be done by an independent party.

The most elegant solution to this problem, and probably the one holding the most promise, is to use a hardware-based memory management unit (MMU) in the smart card, in addition to the actual processor. This approach uses hardware circuitry to monitor the program code while it is executing in order to verify that it stays within its assigned boundaries. Only with such a solution is it possible to allow application operators to download programs that have not been certified by the card issuer, while still preserving the security of the card. Each such application would be assigned a physically contiguous region of memory, representing a DF. The MMU would then monitor the assigned memory boundaries when a downloaded program in a DF is called. If these boundaries were exceeded, the program could be immediately halted via an interrupt, and the application could then be blocked pending further action. There are two different ways to implement downloadable code capability. The first is to put the program code in an EF whose structure is ‘executable’. The content of this file can be executed by means of the EXECUTE command after it has first been selected. Depending on the application, prior authentication may be required. The parameters for running the program are passed to the smart card in the EXECUTE command, and the response generated by the program in the EF is sent back to the terminal. The second approach takes a somewhat different form, since it is based on the principles of object-oriented design. This option is described in the EN 726-3 standard (among others) as ‘application-specific commands’ (ASC). As specified in this standard, the complete application, including all of its files and application-specific commands, is contained in a single DF. The program code can be downloaded into a memory region within this DF that is managed by the operating system. This is done using a special command that transfers all the necessary information to the smart card. If the DF in question is selected and a command is then sent to the card, the operating system checks whether the command belongs to the downloaded commands. If it does, the operating system immediately calls the program code located in the DF. If the command instead selects a different DF, the downloaded commands effectively do not exist in the context of the command.

Example of native program code downloaded to an EF
There are several large smart card applications whose operating systems allow executable code to be downloaded after the card has been personalized. However, the specifications for this capability are almost always confidential, and in some cases, even the fact that this capability exists is confidential. Consequently, we can only describe the general principles of this capability here, independent of any actual operating system. A possible implementation is described in detail following the description of the basic principles. In the first place, the program code to be downloaded must satisfy certain basic prerequisites before it can be run in a smart card. It may sound obvious, but the most important prerequisite is that the processor type must be known (for example, 8051 or 6805). Particularly in a heterogeneous environment with many different types of smart card microcontrollers, satisfying this requirement may well involve a certain amount of effort. Along with this comes the requirement that the smart card operating system and its application programming interface (API) must be known, including all entry points and the parameters passed to and returned from its routines. The program code to be downloaded, which is always native code (machine code of the target processor), should be programmed so that it is relocatable. If it is not, it must be relocated on the fly by the smart card when it is downloaded. The requirement for relocatability, which means that the program can be shifted within the memory, comes from the fact that the memory addresses where the code will be stored are known only to the smart card operating system and not to the outside world. A program is usually made relocatable during the programming stage. In concrete terms, relocatability means (for instance) that jumps to absolute physical addresses are not allowed, but only jumps relative to the address of the jump instruction. If the program code satisfies all of these requirements, it can in principle be loaded into the memory of a smart card and run there. The program code can of course be structured as desired. The actual structure can be completely different, depending on the operating system. The first data element in this example is a unique label that tells the smart card operating system that this is program code. Such a label is commonly called a ‘magic number’. For example, with Java Class files, it is a sequence of four bytes forming the word ‘CAFEBABE’.

The program code starts just after the label. In this example, it is divided into four parts. The first part contains all of the necessary initializations, data saving and the like. Following this startup routine comes the actual function routine, which contains the program code for the desired task. This is followed by the shutdown routine, which is the counterpart to the startup routine. The shutdown routine ensures that the program is correctly terminated, and if necessary it restores any saved data and adjusts the stack. The fourth part of the program, which follows the first three parts, is optional. It can include program code to be resistantly incorporated into the smart card software. Bug fixes for the operating system would typically be located here. The three prior routines would then modify pointers or handles so that the routines in this section would be permanently linked into the software of the operating system. The entire process is very similar to the well-known TSR (terminate and stay resident) routines of the DOS era. These routines only had to be called once in order for them to anchor themselves in the operating system until the next reset. In the case of a smart card, these resistant routines would be installed permanently after being called once, rather than only for the duration of a single session. Here we assume that the downloaded program is called using a Call instruction and that it returns control to the calling program with a Return instruction. In principle, a direct jump to the first machine code instruction (using a Jump instruction) would also be possible, but this would have the disadvantage that the called program would not know which program called it. For insurance against accidental changes, the entire data block should be protected by an error detection code (EDC). Alternatively, a digital signature could naturally be used to provide additional protection. The smart card would then have the public key, and the producer of the program code would hold the associated private key. This would provide binding assurance that authentic program code can be run in the smart card. The downloaded program code can be stored either in an EF or in a program memory region within a DF that is not visible to the outside world. The first option is described in some detail below, since it is encountered significantly more often in actual practice. EFs with transparent structures are ideal for storing program code, since they can be effectively written in several sections using UPDATE BINARY commands with offsets. Also, their maximum length of more than 65 kB is more than adequate, even for extensive programs. These EFs can have an attribute of ‘executable’, which means that the program code stored in them can be directly invoked using an EXECUTE command.

Instead of this, some operating systems have a file structure called ‘execute’ that is based on the transparent structure. This is not particularly important with regard to the outside world, especially since both types can normally be accessed using the UPDATE BINARY and EXECUTE commands. The EF can be selected via its FID or an SFI. The access condition for reading is always set to ‘never’. Writing data is normally allowed after prior authentication and using secure messaging. Figure 5.45 shows the essential elements of a procedure for loading program code into an EF in a smart card in a secure manner. If a suitable EF is not already available, it must first be created. Figure 5.46 shows in simplified form that the EF must first be selected, after which the program code must be run using an EXECUTE command. Data can optionally be transferred in the body of the command. If necessary, data can also be returned to the terminal in the response in a similar manner. Naturally, the called program must retrieve any data that is sent to it by reading it from the receive buffer, generate its response and write its response to the transmit buffer. Due to the severe requirements for unambiguous identification of the microcontroller, operating system and internal software interfaces, as well as those related to system management, it is usually only possible to download programs using an online connection to a background system. The databases located in the background system either hold all the necessary data keyed to the unique chip number, or they receive this information online via a direct end-toend link with the smart card. Using this information, a program with the desired functionality is selected from those available in the system and transferred to the smart card using the prescribed security mechanisms. The secret keys for this are normally managed and used in the background system exclusively within a security module. The method for loading native code into a smart card that has just been described has some attractive practical advantages. The procedure is simple and robust, and it can be implemented in a smart card operating system using a small amount of program code. The program code to be run does not have to be interpreted, since it can be directly executed by the processor. This yields a high processing speed, so this method can be used to downloading complex algorithms (such as DES, IDEA and the like).

Due to their low processing speeds, interpreter-based systems cannot provide this functionality in the foreseeable future. If there is no hardware-based memory management (MMU) to restrict free access to the memory, this method provides an excellent way to correct errors in the smart card software after the card has been issued. If an error is discovered, this method provides a unique ‘back door’ that can only be opened using this sort of software downloading. Other technologies, such as Java for smart cards, implement strict and unconditional memory partitioning and thus cannot modify the code of the operating system. If an MMU is present, it still might be possible to invoke an administrator mode to temporarily deactivate memory supervision. This brings us to the drawbacks. Downloading executable native code presupposes a high level of knowledge of the hardware and/or the operating system of the smart card. It may be necessary to have a separate program on hand for each type of smart card used in the system, even though all of these programs would have the same functionality. The second major drawback of this method is that, for reasons of security, the program must be developed by the card issuer (or under the authority of the card issuer). Loading unknown or thirdparty programs into the smart card must be strictly prohibited, since the downloaded program assumes control of the microcontroller once it is started and cannot be governed in any manner. Such a program could for example read out the secret keys of other applications present in the card and send them to the terminal via the I/O interface. Evaluation of the program code by the card issuer provides only weak protection against attacks of this sort. In this case, better protection can be obtained using hardware-based memory management, which makes only certain regions in EEPROM and RAM available to the downloaded program and immediately terminates the program if an attempt is made to exceed the boundaries of these regions.9 This makes it possible to fully isolate the applications in the smart card. Presently, due to the absence of suitable MMUs, the only available expedient is to carefully review the program to be downloaded.