306 Smart Card Operating Systems program generation target processor linked object code (native program code) compiler or assembler linker object code C code or assembler code Figure 5.48 Top-level data flow diagram of the usual process for converting source code in C or assembler into executable machine code for the target processor program generation Java compiler Java VM class file Java source code class file JIT compiler Java processor general- purpose processor general- purpose processor native program code native program code bytecode (native program code for Java processor) general- purpose processor native program code Figure 5.49 Top-level data flow diagram of possible procedures for converting Java source code into executable machine code for a target processor. Although the route shown at the left is provided by some compiler producers, it does not correspond to the original philosophy of Java, since it does not maintain hardware independence at 200 MHz with a 2.5-V supply voltage, contains 2.8 million transistors and has a power consumption of only 4 W. Since this chip includes many functions that are not needed in smart cards (such as floating-point arithmetic and controlling external memory), it would certainly be technically possible to integrate a stripped-down Java processor meeting the needs of smart cards into a smart card microcontroller. 5.14 Open Platforms 307 Another possible solution to the speed problem is hardware extension of the instruction sets of smart card processors. Using this approach, approximately 80 % of the machine instructions of the Java VM could be handled by the processor. From a technical perspective, this would not be particularly difficult, and it would offer a pronounced increase in speed. This approach is presently preferred by many manufacturers of smart card microcontrollers as a solution to the speed problem. Table 5.22 Program execution time versus programming language, taking C/C++ as the reference. The stated values for programs running on a PC are estimates and are only intended to serve as guidelines. The reference PC processor is a 300-MHz Pentium II, while the reference Java processor is a 200-MHz picoJava 701 Programming language Execution time C, C++ 1 Java executed by an interpreter 20–40 Java executed by an interpreter using a JIT compiler ≈5 Java program code compiled as native code 1–2 Java executed by a Java processor ≈1.2 Another option for increasing the execution speed of Java bytecode is to use a 32bit smart card microcontroller. However, even with a 32-bit processor the execution speed of interpreted Java code is still 10 to 20 times slower than program code written in C. The primary advantage of these new processors is that they can be used for a wide variety of applications. The disadvantage of interpreted program code relative to compiled program code, namely inadequate processing speed, can be strongly reduced by using suitable programming inter- faces for the interpreter. These applications programming interfaces (APIs) allow interpreted program code to call machine-language routines. The native code routines called in this man- ner run at the full processing speed of the host processor. Although this may initially appear to be an ideal way to achieve increased processing speed, it has its own problems. The first is that the API for native code must be carefully conceived if it is to be generally useful in- stead of only useful in a few special cases. Still, this can be achieved with a bit of careful planning. The second problem is more serious. The compatibility and hardware independence of a programming language such as Java is only possible if all APIs are the same. If there are several types of APIs that have different interfaces or provide different functions, using a standard programming language does not provide any significant advantage. Under such conditions, it would be necessary to make specific modifications to the source code for each platform having its own API. This is why Java Card Forum continues to invest considerable effort in standardizing APIs, since they are fundamentally important for achieving platform independence. The Java virtual machine (JVM) The Java virtual machine is the most essential element of the Java technology. It simulates a Java processor and can be implemented in software on any sufficiently powerful processor. If it is desired to run Java bytecode on a new type of processor, the Java virtual machine must be ported to this processor. It is usually written in the C programming language, so the actual 308 Smart Card Operating Systems porting may not require anything more than a few modifications and a recompilation of the source code. The size of a Java virtual machine on a PC ranges from 100 to 200 kB. The Java virtual machine has all the elements of a real processor. It has its own instruction set in the form of the bytecode, and it has registers such as the program counter and accumulator. The data to be processed are passed to the virtual machine in the form of a class file, which contains fixed constants, the bytecode to be executed in the form of methods, and various additional information. Table 5.23 Overall structure of a class file Data elements of a class file Label (‘magic number’) Version number Constants pool Methods Attributes of classes, fields and methods Java bytecode takes up very little space and is nearly as compact as machine code. The overall memory space balance relative to native machine code is made worse by the obligatory presence of the virtual machine. The difference naturally becomes greater as the size of the program code becomes smaller relative to the size of the virtual machine. Bytecode is fundamentally very similar to the machine instructions of a real processor. For example, there are instructions for stack manipulation, logical and arithmetic instructions, instructions that access the registers of the virtual Java processor, and even access methods for arrays. The Java virtual machine and the bytecode are extensively described by Tim Lindholm and Frank Yellin [Lindholm 97]. Due to the significantly restricted system resources of smart card microcontrollers, certain limitations must be imposed on the Java Card VM compared with the original Java VM for PCs. The Java Card VM does not have garbage collection to automatically return memory that is no longer needed to the free memory pool. (Version 2.2 of the Java Card specification, which was not yet officially released at the time of writing of this book, does provide for an optional garbage collector.) Support for class files is also drastically reduced. There are fewer data types available in smart cards, and the bytecode itself is reduced from 149 instructions to 76. The size of the program code for the oncard Java VM for smart cards is on the order of 40 kB of 8051 machine code when written in C. Approximately 400 bytes of RAM are also needed. The API with the classes from javacard.framework and javacardx.framework needs 3 to 4 kB of memory, the majority of which is Java bytecode. In addition, at least a rudimentary operating system is needed, with data transmission protocols, cryptographic algorithms and many functions that are closely linked to the hardware. The code size for this is 6 to 8 kB if it is programmed in assembler [Baentsch 99]. In connection with these memory size values, it must be noted that they are highly dependent on the available functions and other complex considerations. Consequently, the values stated above can vary considerably among individual implementations. 5.14 Open Platforms 309 Table 5.24 Limitations to the functional scope of Java Card relative to full Java Function Java Card Java Cloning of classes no yes Cloning of objects no yes Data type: int optional yes Data types: Boolean, byte, short yes yes Data types: long, float, double, character no yes Dynamic downloading of classes no yes Dynamic memory management (garbage collection) no yes Dynamic object creation yes yes Exception handling yes yes Fields for objects no yes Fields for supported data types only one-dimensional also multidimensional Interfaces yes yes Operators all all Packages yes yes Sequence control functions yes yes Threads no yes Virtual methods yes yes Table 5.25 Data types in Java for smart cards, with their memory requirements and ranges of values. The data type ‘int’ is optional Data type Size Range of values Boolean 1 byte true, false byte 1 byte –128 to 127 short 2 bytes –32,768 to 32,767 int 4 bytes –2,147,483,648 to 2,147,483,647 The correctness ofthis relatively small program is extraordinarily important, since an error or security gap in the Java VM could undermine the whole idea of providing a secure environment by incorporating Java in the smart card. The design and implementation must therefore be largely error-free. An ITSEC or Common Criteria evaluation is normally employed to verify this. Naturally, the small size of the program code for the Java VM considerably simplifies this process, especially since it allows the complete functionality of the VM to be formally described. ITSEC E4 certification is typical. Due to the small amount of memory present in smart cards, it was necessary to divide the Java virtual machine into oncard and offcard parts. Static tests can easily be performed outside of the smart card in the Offcard VM without reducing performance or security. The link between the two parts of the VM is formed by data in CAP format. For complete security, such data must be cryptographically protected, ideally using digital signatures, so that they cannot be manipulated during transmission. They would otherwise present an attacker with a promising starting point, since the security mechanisms of the offcard VM could be circumvented using manipulated data. 310 Smart Card Operating Systems Table 5.26 Summary of the limitations of Java Card. These broadly defined limits currently do not impose any restrictions on the development of software for smart cards Classes An instance of a class may contain at most 255 fields. A class may have at most 256 static methods and at most 256 static fields. A class may have at most 15 interfaces. Package A package may contain at most 255 public classes and interfaces. Methods A method may have at most 255 local variables and contain at most 32,767 bytecodes. Arrays Arrays may contain at most 32,767 fields. Switch instruction A switch may support at most 65,536 branches. If the ‘int’ data type is supported, the maximum number of branches in the switch instruction depends on the value range of the selected data type (char, byte, short or int), as with Java for PCs. Since Java is stack-oriented, it naturally needs a stack as well as a heap. These are created and managed separately for each applet in the smart card. The stack is primarily used for passing data when calling methods, while the heap serves as a storage area for objects. Common sizes are approximately 700 bytes of RAM for the stack and approximately 5 to 8 kB of EEPROM for the heap. However, relatively small applets can certainly manage with 50 to 60 bytes for the stack and a few hundred bytes for the heap. The Java VM consists of four functional parts, as shown in Figure 5.49: the bytecode verifier, the loader, the bytecode interpreter and the security manager. bytecode interpreter security manager smart card operating system microcontroller hardware loader bytecode verifier Figure 5.50 The individual components of the Java Card virtual machine The function of the bytecode verifier is to perform a variety of static tests on the class file passed to the Java VM. It first checks the file format. Following this, it checks the constants pool, checks the bytecodes for syntactical correctness, and checks the arguments of the methods and the object inheritance hierarchies. A few other tests may also be performed. They are described in detail by Frank Yellin [Yellin 96]. After the bytecode verifier is finished, the loader takes the checked data and sends them in CAP format to the actual interpreter in the smart card. For security reasons, the data should be provided with a digital signature so they cannot be manipulated on their way from the loader to the oncard part of the Java VM. The actual loading process is independent of the 5.14 Open Platforms 311 Java Card specification. Here the OP specification 14 has come to be the prevailing industry standard. After being loaded, the executable bytecode is located in the memory of the smart card together with various of supplementary data, where it can be executed by the oncard part of the Java VM. The actual interpreter reads the bytecodes one at time, together with their asso- ciated arguments, and converts them into native machine instructions for the target processor. The security manager works in parallel with the bytecode interpreter. Among other things, it constantly checks compliance with the field, stack and heap boundaries. If it detects a violation of the defined security rules, it is authorized to immediately initiate an exception and stop the processing of the bytecode that caused the problem. Listing 5.1 The basic functions of the main program loop of the Java bytecode interpreter DO ( Interpreter main loop fetch and save program counter Fetch and save the value of the program counter for later comparison. fetch opcode fetch operands execute machine instruction Execute the virtual Java processor machine instruction, which consists of the opcode and the operands. IF (machine instruction did not alter the program counter) If the Java machine instruction that has just been executed has not altered the program counter (which THEN (increment program counter) means that it was not a GOTO bytecode, for instance), then set the program counter to the next opcode. ) WHILE (opcodes available) Repeat the loop until all opcodes have been processed. Java for smart cards The truly significant benefits of a modern programming language such as Java with regard to its use with smart cards extend beyond the fact that it allows everyone to write programs for smart cards. This would also be conceivable for most smart card operating systems using assembler or C, publicly revealed interfaces and a few modifications. A concept such as Java is also attractive for operators of large systems. They have the problem of being forced to purchase a variety of smart card operating systems running on different microcontrollers from various card manufacturers. Although this multiple sourcing is certainly worthwhile for tactical reasons (due to reduced dependence on a single supplier and the resulting price pressure on the suppliers), it constantly creates problems with regard to compatibility and testing. Within the foreseeable future, it is not possible to have different operating systems from two different producers, with all their various versions, behave the same way at the interface level. This represents a serious problem for system operators. 14 See also Section 5.11, ‘Open Platform’ 312 Smart Card Operating Systems From the system operator’s point of view, the ideal solution to this problem would be hardware-independent program code that could be executed by an evaluated interpreter in smart cards in a standardized manner. An application program could then be written, tested and evaluated only once, after which it could be run using all different types of smart card operating systems. No differences would be visible ‘from the outside’, which means at the interface. This would preserve the advantages of multisourcing while eliminating its disadvantages. You should bear this thought in mind when examining how Java is integrated into smart cards. The first versions only allowed Java bytecode to be stored in an EF located under the MF or under a DF. An EXECUTE command then started up the virtual machine to run the program stored in the EF. An application programming interface (API) associated with the file system allowed data to be read from and written to files. Java Card commands for managing applets applet(s) file tree program code for commands Figure 5.51 The two basic IT components of a smart card with Java However, this approach has not prevailed. According to the Java Card specification, a smart card with Java has a Java virtual machine that is activated during card manufacturing and deactivated at the end of the card’s life cycle. The lifetime of the Java virtual machine thus corresponds to the lifetime of the smart card. When a smart card is electrically deactivated, the Java virtual machine only suspends its activities, while still remaining active. This is a fundamental difference compared with a Java virtual machine on a PC, where the Java virtual machine ceases to exist when the computer is switched off. A file system in accordance with ISO/IEC 7816-4 is no longer provided, since a file system can be constructed using objects within Java applets. There are also several classes that make it relatively easy to construct a file tree that complies with the ISO/IEC 7816-4 specification. The program code and its associated file tree are both part of the applet that is loaded into the smart card. The applet in the card can be selected by its unique AID using the SELECT command. After the applet has been selected, it automatically receives all further APDUs for processing. The program code of the applet can then evaluate and process the commands and their associated data, perform appropriate accesses to the file system and finally generate a response. This approach provides maximum flexibility and compatibility, since each application is contained in an applet along with its file tree. The actual card commands, such as READ BINARY and MUTUAL AUTHENTICATE, are located in the applet as program code. This allows a single card to have different codings and different procedures in two separate applets that support the same command in mutually independent manners. Of course, this advantage comes at the price of a significant amount of memory space for the applets, since they must necessarily contain redundant data and routines. This conspicuous 5.14 Open Platforms 313 Java Card API Java virtual machine smart card operating system microcontroller hardware loading an applet applet Figure 5.52 The basic process for loading an applet in a smart card operating system with Java consumption of memory can be somewhat reduced in some cases by allowing the objects of one applet to be shared with other applets (‘object sharing’). For reasons of security, this can only be provided by the applet that creates the object in question. The process of sharing an object cannot be reversed. This means that if an object is made available for access by other applets, it remains available for the lifetime of the card. The only applet-independent commands that remain are those used for securely loading applets into smart cards. The program code for commands is stored in EEPROM and run by the Java virtual machine. The only common elements for the entire smart card are the transmission protocols. Java Card Framework In order to make the programming of smart cards in Java as easy as possible, there are four packages that provide standardized application programming interfaces (APIs) with functions that are useful for smart cards. Three of these packages are mandatory for all Java Cards that do not necessarily require certain key lengths or cryptographic algorithms to be present. The fourth package, which is optional and is distinguished by an ‘x’ (for ‘extension’), can be included if necessary. There are also many other application-specific packages, such as those for GMS functions (GSM 03.48). Since the program code ‘underneath’ the API can be generated in the machine language of the target processor, this approach not only provides a standard interface but also yields an enormous increase in processing speed. The obligatory package java.lang forms the basis for Java in smart cards. It defines the ele- mentary classes for exceptions. It is complemented by the package javacard.framework, which defines the core functions for Java Card applets, such as elementary classes for applet man- agement, data exchange with the terminal and various constants in accordance with ISO/IEC 7816-4. The package javacard.security, which contains cryptographic functions, provides in- terfaces to a variety of cryptographic algorithms. For reasons related to export legislation, this package is constructed such that it does not allow the smart card to be used as a general-purpose encryption and decryption tool. The optional package javacardx.crypto, which contains the interfaces to the associated decryption methods, is needed to provide this capability. 314 Smart Card Operating Systems hardware HAL (hardware abstraction layer) JCVM Java Card virtual machine)( JCRE Java Card runtime environment)( Java Card API card manager applet 1 applet 2 firewall Open Platform API other APIs native services (transmission protocols, cryptographic algorithms, memory management) Figure 5.53 Schematic representation of the basic architecture of a Java Card system. This example contains several typical APIs as well as application management for the Open Platform mechanisms. The location of the applications is shown in the form of two applets Table 5.27 The most important classes of the java.lang package of the Java Card application programming interface Class Description java.lang.Exception Class for exception handling for Java Card. java.lang.Object The class for all Java Card classes. java.lang.Throwable The class of all exceptions and errors for the Java Card. Software development for Java in smart cards How does one go about developing a Java program for a smart card and then running it? The first thing the programmer does is to generate the actual Java source code using a text editor. He or she then compiles the source code using any desired Java compiler, which yields the machine-independent bytecode. Up to this point, the process is identical to Java programming for PCs. The bytecode is then transferred as a class file to the Java Card Converter (which actually means the offcard portion of the Java virtual machine). The Java Card Converter tests the format, syntax, field references and similar items in the program. If all these tests are passed successfully, the Java Card Converter creates what is known as a card application file (CAP file). If necessary, a digital signature is generated for the CAP file, depending on the application. A digital signature provides assurance that the CAP file has been checked by the Offcard VM and is authentic. In the absence of a verifiable signature, the security of the Oncard VM could be bypassed using a manipulated applet, since the Oncard VM cannot perform a full set of tests due to memory space limitations. After this, the applet is loaded into the smart card in the form [...]... algorithms javacard.security.DSAKey javacard.security.DSAPrivateKey javacard.security.DSAPublicKey javacard.security.Key javacard.security.KeyBuilder javacard.security.KeyPair javacard.security.MessageDigest javacard.security.PrivateKey javacard.security.PublicKey javacard.security.RandomData javacard.security.RSAPrivateCrtKey javacard.security.RSAPrivateKey javacard.security.RSAPublicKey javacard.security.SecretKey... modest smart card market, Windows for Smart Cards was cancelled in mid-May and the source code was offered for sale to several companies Due to a lack of acceptance by the smart card industry, which is very demanding with regard to reliability and security, WSC never achieved any significant market success during this period 3 24 Smart Card Operating Systems Windows for Smart Cards was a smart card operating... other smart card operating systems with interpreters 5. 14. 4 Windows for Smart Cards In 1998, Microsoft announced Windows for Smart Cards (WSC) as a version of Windows for smart cards This smart card operating system was intended to increase the bandwidth of the Microsoft operating system and was doubtless intended to be an alternative to Java Card, which was not yet a widely used operating system After... objects and for type conversion javacard.framework.APDU javacard.framework.Applet javacard.framework.ISO7816 javacard.framework.JCSystem javacard.framework.OwnerPIN javacard.framework.PIN javacard.framework.Util javacardx.framework.Shareable This interface is used to identify shareable objects of a CAP file This is usually done using the OP mechanisms.15 The smart card first verifies the digital signature,... operating system for smart cards to appear The only important consideration is that it can be used without licensing, since the high licensing fees resulting from the large quantities in which smart cards are produced and used represent one of the most significant barriers to the use of standard operating systems in smart cards 326 Smart Card Operating Systems 5.15 THE SMALL-OS SMART CARD OPERATING SYSTEM... the history of smart cards began with the introduction of Java, since it is the first language that allows third parties to run executable program code in smart cards in a straightforward manner Java has now become the standard programming language for smart card applications 5. 14 Open Platforms 321 Table 5.31 Several useful programming guidelines for generating Java applets for smart cards, based on... code to the card and then execute it in the card In summary, Small-OS is comparable to the first general smart card operating systems, such as are still used in various forms for GSM applications The ISO/IEC 7816 -4 standard describes a basic file system and several fundamental commands for smart cards, among other things In this way, it primarily characterizes the interface of the smart card, rather... several decades It has also been extended to include some functions specific to smart cards, such as an interface to the smart card file system In addition, there is support for the T = 0 and T = 1 data transmission protocols for contact-type cards, and for contactless data transmission in accordance with the ISO/IEC 14 443 B standard For typical security applications, a variety of cryptographic algorithms... in smart cards to be developed quickly and easily, Basic Card can certainly represent an alternative to other smart card operating systems The main unconventional aspect of Basic Card is the fact that it is the product of a relatively small company, which has continued to further develop it over the course of many years, rather than one of the giants of the IT industry, as some of the other smart card. ..5. 14 Open Platforms 315 Table 5.28 The most important classes of the javacard.framework package of the Java Card application programming interface Class Description javacard.framework.AID Encapsulates the 5–16 byte application identifier (AID) as specified in ISO/IEC 7816-5 Provides methods for exchanging data between the smart card and the terminal at the APDU level Defines an applet for a smart card . smart card operating systems with interpreters. 5. 14. 4 Windows for Smart Cards In 1998, Microsoft announced Windows for Smart Cards (WSC) as a version of Windows for smart cards. This smart card. available in smart cards, and the bytecode itself is reduced from 149 instructions to 76. The size of the program code for the oncard Java VM for smart cards is on the order of 40 kB of 8051. byte true, false byte 1 byte –128 to 127 short 2 bytes –32,768 to 32,767 int 4 bytes –2, 147 ,48 3, 648 to 2, 147 ,48 3, 647 The correctness ofthis relatively small program is extraordinarily important,