With increasing use of Java Card, Multos and Windows for Smart Cards, the term ‘open platform’ has also come into more general use. This term refers to smart card operating systems that allow third parties to load applications and programs into smart cards without the involvement of the producer of the operating system. Generally speaking, most open platform specifications are public and are generated by a consortium of companies (such as Java Card Forum). Most open smart card operating systems are available from several producers, who provide systems having similar or mutually compatible functions. The opposite of an open platform is a ‘proprietary’ platform. This term is often used in a deprecatory sense to refer to a company-specific solution. In many cases, the specifications for such platforms are not fully published or are the property of a single company. However, both terms – ‘open’ and ‘proprietary’ – are used in a manner that is by no means unambiguous or non-partisan. In many cases, it is instead marketing-driven. Objectively, many so-called ‘open’ smart card operating systems are rather proprietary and dependent on a particular company. Truly open platforms in the sense of Linux, with free access to the source code, no licensing restrictions and independence from specific companies or organizations, presently do not exist in the area of smart card operating systems.

Java Card
In 1996, Europay presented a paper on ‘open terminal architecture’ (OTA) that described and largely specified a Forth interpreter for terminals. The objective was to generate a uniform software architecture for terminals in order to create a basis for hardware-independent terminal programming. Given this, a specific application (such as paying with a credit card) would only have to be programmed once, and the resulting software would run without any modifications on all terminals made by various manufacturers. Although the proposed design has never been fully implemented, it certainly gave rise to extensive discussions in the smart card world. Consequently, when it became known in the fall of 1996 that Schlumberger was developing a smart card that could run platform-independent programs written in the Java language, no one was particularly surprised. The idea of combining an interpreter with a memory-poor microcontroller was already well known from the OTA proposal. The published specification (Java Card 1.0) provided an application programming interface (API) for integrating Java into an ISO/IEC 7816-4 operating system, in order to allow Java to access the standard smart card file system with its MF, DFs and EFs. Many producers of smart card operating systems were initially astonished at the idea that a language such as Java, which normally requires well over a megabyte of memory, should be used with smart cards. However, nearly all major smart card manufacturers were represented at the first meeting with Sun, the company that developed and promoted Java, in the spring of 1997. This was the first conference of what has since become known as Java Card Forum (JCF), which functions as the international standardization panel for Java in smart cards. The tasks of the technical group of Java Card Forum are to define a subset of Java for use in smart cards, to specify the outlines of the Java interpreter (known as the Java virtual machine or JVM) and to define both a general-purpose API and application-specific APIs (for telecommunications and financial transactions, for example). These APIs form the interface between the smart card operating system and Java. The task of the marketing group of JCF is to promote Java technology for smart cards. The names of the current specifications at the time of writing10 are Java Card Virtual Machine Specification, Java Card Runtime Environment (JCRE) Specification and Java Card Application Programming Interface. Up-to-date versions are available at no charge from the WWW server of Java Card Forum [JCF].

The Java programming language
In 1990, a research group at Sun managed by James Gosling started developing a new programming language. The objective was to create a hardware-independent, secure and modern language that could be used for microcontrollers in consumer products (such as toasters and espresso machines). A large variety of microcontroller types with different architectures are used in such products. This nonuniformity, combined with frequent hardware modifications, makes it difficult for software developers to write portable program code. Remarkably enough, smart cards exactly match the characteristics of the original target application area. The programming languagewas first called ‘Oak’, after the oak furniture in James Gosling’s office, but in 1995 it was renamed ‘Java’11 and the objectives were redefined. In the summer of 1995, Sun began to intensively promote Java as the hardware-independent language for the heterogeneous Internet. The slogan coined by Sun, Write Once – Run Anywhere, which was frequently quoted at that time, probably provides the clearest indication of the intended level of hardware independence. The beginning of the widespread use of Java coincides with the beginning of the enormous growth of theWorldWideWeb (WWW).12 For a variety of reasons that were not just technical, but which entirely arose from the realms of business politics and worldviews, the new language excited researchers, universities and software companies throughout the world [Franz 98]. As a result, Java became the de facto standard for Internet applications within an extremely short time. Naturally, the characteristics of this new language favored this development. The Java programming language is a fully object-oriented and strongly typed language. It is easily learned by programmers, since it has much in common with C and C++. Java is also a robust language, which means that it does not permit the tricks and popular but dubious techniques possible with C and C++ (for example). For example, no pointers are used in Java, field boundaries are monitored at run time and there is strict type checking. In addition, memory management is handled by Java and an associated ‘garbage collector’, so ‘memory leaks’ (a much-feared phenomenon in C and C++) are impossible by design. Java is also a secure programming language, which means that when a program is run the functions that it wants to perform are monitored while it is running, so the runtime environment can stop the program if necessary. This is one of several possible reasons for calling an exception handler. If an exception occurs, a call is made to a specific routine in which the response to this particular case can be defined. The majority of these features are only possible because Java is an interpreted programming language that is not executed directly by the processor. Java also has other features, such as multithreading capability and support for distributed processing, but these are presently not supported in the smart card environment. The intention of Sunwas to have Java standardized in the form of an ISO standard. However, for a number of reasons this did not happen. One of the reasons was doubtless that the five-year review and revision cycle of ISO is too long for a new programming language such as Java, since it would have made it difficult to make the necessary modifications arising from practical experience, as well as delaying the introduction of such modifications. Another conceivable reason may be that before Java technology can be used in products, such as smart cards, a rather costly licensing agreement must be concluded with Sun. This is contrary to the usual convention regarding ISO standards.

The characteristics of Java
Programs written in Java are translated into ‘Java bytecode’ by a compiler. Java bytecode is simply processor-independent object code. In a manner of speaking, bytecode is a program consisting of machine instructions for a virtual Java processor. This processor does not actually exist; instead, it is simulated by the target processor. This simulation takes place in the Java virtual machine (JVM or VM), which is the actual interpreter. Seen from a different perspective, the JVM is a simulation of the Java processor on an arbitrary target system. The target processor in turn naturally uses native code. The main advantage of this arrangement is that only the JVM, which is programmed in native code, has to be ported to a particular target processor. Once this has been done, the Java bytecode will run on the new system. Since the runtime task of the VM involves more than just mindlessly interpreting the bytecode and includes type checking and monitoring accesses to objects, the VM is also called the ‘sandbox’. This name graphically suggests that a Java program is only allowed to work within its own environment (sandbox) and is not allowed to leave this environment, since the VM will otherwise put a stop to its activities. A compiled Java program, which means one that has been translated into bytecode and provided with certain supplementary information, is stored in a ‘class file’. Class files are executed by the Java virtual machine after they have been loaded. One or more class files constitute an ‘applet’, which contains a complete smart card application and has its own application identifier (AID). In the context of Java for smart cards, applets are sometimes called ‘cardlets’. The hardware independence of Java naturally has its price, which primarily consists of its very slow execution speed compared with other standard programming languages. This problem has still not been solved in a satisfactory manner, although further developments and improvements of Java are focused on this issue. One step that is already being taken is to use a ‘just-in-time’ (JIT) compiler, which translates the Java bytecode into the machine language of the processor the first time the program is run. Although this causes the program to run rather slowly the first time it is used, it runs significantly faster afterwards. However, the software of a JIT compiler is rather complex, and the limited memory space of smart cards means that it will be several years before such a compiler can be implemented in a smart card. Direct compilation of Java programs into the machine language of the target processorwould not be worthwhile in the heterogeneous world of smart cards, in contrast to the PC world. The last remaining alternative is to use special hardware. One possibility is to integrate a special Java processor on the semiconductor die, in addition to the 8051 and 6805 kernels presently used. This would provide the advantage of allowing time-critical routines (such as those used for data transmission or cryptographic algorithms) to still be programmed in assembler, while allowing a high-level language, such as Java, to be used for all higher software layers. Technically, this would not present any problems, as can be seen from the following facts: Sun’s Java chip (microJava 701) has an edge length of 7 mm with a 0.25-μm process, works at 200 MHz with a 2.5-V supply voltage, contains 2.8 million transistors and has a power consumption of only 4W. 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.

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. 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 interfaces for the interpreter. These applications programming interfaces (APIs) allow interpreted program code to call machine-language routines. The native code routines called in this manner 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 instead 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 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. 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. The correctness of this relatively small program is extraordinarily important, since an error or security gap in the JavaVMcould 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 OffcardVMwithout 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.

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 function of the bytecode verifier is to perform a variety of static tests on the class file passed to the JavaVM.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 Java Card specification. Here the OP specification14 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 associated 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.

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 certainlyworthwhile 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. 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.

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 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 appletindependent 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 elementary 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 management, data exchange with the terminal and various constants in accordance with ISO/IEC 7816-4. The package, which contains cryptographic functions, provides interfaces to a variety of cryptographic algorithms. For reasons related to export legislation, this package is constructed such that it does not allowthe 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.

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 CAPfile, 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 OncardVMcannot perform a full set of tests due to memory space limitations. After this, the applet is loaded into the smart card in the form
of a CAP file. This is usually done using the OP mechanisms.15 The smart card first verifies the digital signature, which is usually present, and then passes the applet to the Oncard VM once it has been checked. What happens after this is largely the same as for program execution using a virtual machine in a PC. The Oncard VM tests and interprets the bytecode line by line and generates machine instructions for the smart card processor from the bytecode. In actual practice, the process is naturally somewhat more complicated than what has just been described. It is to be hoped that the developer will not immediately start writing Java code immediately after being given his or her assignment, but will instead use analysis and design methods to determine the actual requirements before starting to program. In order to quickly locate errors during and after the coding, the developer uses a Java smart card simulator. This allows the developer to follow the execution of the code step by step, examine variables and make any necessary corrections quickly and easily. Besides this, a suite of tests is run for relatively large projects and those that are critical for security. These tests check all good cases and the most important bad cases for commands and responses. Source code inspection by an independent party may also be included. As you can see from this example, Java for smart cards significantly reduces development time, and it reduces possible error sources as a secondary benefit. However, coding by itself is only one of many aspects of developing a smart card application. The primary advantage of Java for smart cards is that it allows a large number of developers to generate executable programs for smart cards, rather than just a few software developers employed by card manufacturers. If a particular applet must be loaded into a very large number of smart cards in identical form, some implementations of Java Card also allow part of the applet to be defined as a portion of the ROM mask. However, the parts of the applet that contain modifiable code must remain in EEPROM. Such an applet is frequently called a ‘ROMable applet’. In generating Java applets for smart cards, several properties of the current Java Card specification should be taken into account in addition to the particular features of the operating system being used.16 These are listed and briefly described below.

Execution speed
Aside from its memory demands, the major point of criticism with regard to Java for smart cards is its low execution speed. However, it is relatively difficult to make fair comparisons between assembler programs and Java. This is primarily because it is not necessary to create exactly the same processes in Java as in assembler, as long as the program behaves the same way at the interface to the terminal. For example, a file system is not always necessary with a Java program, and probably nobody would ever program a cryptographic algorithm in Java. Another general consideration is that the methods of the Java Card API should be used as much as possible, since they are in part coded in the native instructions of the target processor. This can yield a considerable increase in processing speed. When typical smart card commands are implemented in Java with intensive utilization of the interfaces to native library routines, it can be assumed that the execution time (excluding the data transmission time) will be approximately 50 % longer than for a comparable implementation in C or assembler. With unfavorable programming, a Java program can easily be a factor of 2 to 3 slower than a corresponding native program.

Application selection
Selecting a particular application in a Java Card amounts to selecting the corresponding applet by means of its unique AID. This selection starts the applet, so that it can perform any necessary initializations. After this, the applet automatically receives all command APDUs that are sent from the terminal to the smart card. If the applet is not selected, it remains inactive and is not involved in any data transfers.

Firewalls – keeping applications separate
From an IT perspective, individual applets in a smart card are completely isolated from each other. Any possible mutual interference is prevented by the security manager of the Java virtual machine. With Java Card, all applets of a package are automatically located inside the same security environment. Applets within an environment can mutually access objects. If it is necessary for applets to access common data (such as a PIN) across environment boundaries, the JCRE mechanisms provide secure access to objects belonging to a different environment. Naturally, the object that is to be accessed from within a different environment must explicitly allow such access.

Transaction integrity – atomic operations
A sudden loss of power during a session must not be allowed to cause the data of an applet to assume undefined states. This is implicitly guaranteed by the virtual machine or operating system when an object is modified. However, if it is necessary to guarantee unconditional integrity across several objects or procedures, there are special mechanisms that can be used by the applet developer. These mechanisms can be used to ensure that the objects in question either retain their original states or properly assume new states.

File system
It is not mandatory for an applet to have its own file system.With some applications, it can be fully adequate to create file-independent data objects that can be accessed using either standard commands or commands defined by the programmer (‘private-use’ commands). The advantage of using applets without file systems is once again related to the ever-present underlying need to conserve memory usage in smart cards. In addition, the object-oriented nature of Java allows data objects to be accessed by calling objects according to their associated calling conditions. This makes it possible to implement accesses that meet very specific requirements of certain applications. For example, an application or user could be given the opportunity to allow another party to inherit their access privileges. Nonetheless, common present-day applications for both smart cards and PCs show that data are very often stored and managed using file-oriented structures. Although this possibility is not excluded by the Java Card specification, it is unfortunately not directly supported. File management, for example using an ISO/IEC 7816-4 file structure, must be specifically implemented in Java using several classes. This is frequently necessary to support issuing Java smart cards that are compatible with previously developed applications having standard file trees. Deleting objects – persistent and transient objects All objects are inherently created as persistent objects in EEPROM when they are generated using the new( ) method. Persistence refers to the ability of an object to exist past the end of a session, and is the opposite of transience. Persistent objects thus survive both the end of a session and a sudden loss of power, without losing data or consistency. Any object exists only as long as there is a reference that points to it. If this reference is deleted, the object is effectively no longer present, even though it still occupies memory. The only remedy for this would be a file manager with garbage collection, but this capability is not yet available in the current Java Card specification. (The next version of the Java Card specification, Version 2.2, will have provision for a garbage collector.) Persistent objects can be converted into transient objects so that they can be stored in RAM, although this conversion cannot be reversed. Data contained in transient objects are lost at the end of the current session, and such objects are re-initialized to their default values the next time they are called.

Deleting applets
The Java Card specification provides a mechanism for deleting an applet in a smart card. The memory space occupied by the deleted applet can be made available for use by other applets by using a suitable technique, such as defragmentation.

Cryptographic algorithms
Many of the currently used cryptographic algorithms either involve modifying or swapping data at the bit level (such as DES) or utilize the arithmetic of long numbers (such as RSA). Smart cards with Java are presently not suitable for programming such algorithms in Java, due to their low execution speeds and limited memory capacities (EEPROM and RAM). Consequently, such cards usually contain the javacardx.crypto class, which provides an interface (API) to cryptographic algorithms implemented in native machine code. This allows cryptographic algorithms to be used from Java programs without having to accept significant speed penalties.

Cryptography and export restrictions
In many countries, export permits are required for smart cards with general-purpose operating systems and freely usable data encryption and decryption functions accessible via internal interfaces. This means that such cards cannot be exported at all to certain countries, and an exporter may have to wait several months for a suitable permit to be issued by the responsible agency. Consequently, the classes for cryptographic functions are structured in Java Card such that they can be used directly for general data decryption and MAC computations but not for encryption. This is completely adequate for many applications, and in many countries it allows a ‘simplified’ export permit procedure to be used. If a particular application requires data to be encrypted, the card manufacturer can incorporate the classes . . . .cryptoEnc.DES3 EncKey and . . . .cryptoEnc.DES EncKey, which make encryption possible. From a purely cryptographic perspective, however, it is certainly possible to devise easily implemented procedures that can be freely used for encryption and decryption, without using these ‘encryption’ classes.

Memory space minimalization
In the near term, Java programs for smart cards will continue to be strongly influenced by the amount of available memory. This leads to certain compromises in programming that are not necessary for PCs. Table 5.31 lists a number of practical recommendations to help obtain the best possible match between Java programs and the special demands of the smart card environment.

Summary and future prospects
In spite of the unrelenting hype around Java, it should not be forgotten that it surely will not prove to be the solution to every informatics problem of the past and future years, and that it may not always be able to meet all of the expectations that have been invested in it. You only have to consider the fate of all of the previous programming languages that are no longer in fashion, such as Pascal (‘modular’), Lisp (‘AI for everyone’), C (‘portable’) and C++ (‘reusable program code’). Although these languages have improved the state of software technology by orders of magnitude, many of their predicted benefits failed to materialize. Nevertheless, it is true that a new era in 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. A few trends in the future development of Java are clearly visible. Version 2.2 of the Java Card specification will augment the current specification with several useful functions, such as logical channels, garbage collection and remote method invocation (RMI). RMI can be used to directly invoke methods in a smart card from a terminal. The next version of the specification, Version 3, will be optimized for the processing capacity and memory sizes of new 32-bit smart card microcontrollers and will offer significantly more features than the current versions. It can safely be assumed that Version 3 will be closer to regular Java on PCs and the functionality of such Java systems. By contrast, the large-scale loading and management of applets using applet management systems17 must be regarded as a longer term possibility, due to its enormous complexity. However, it is probable that within the foreseeable future, card manufacturers will load applets and their associated data into Java-based smart cards as part of the normal completion process, with such applets remaining unchanged in the card until the end of its useful life. Java Card is presently the only internationally used technology for realizing program-based applications in smart cards, and it will remain so within the foreseeable future. Within the various application areas, there are now a large number of specifications, APIs and extensions to Java Card, which provide a very broad basis for its utilization. In addition, the current degree of compatibility of Java cards produced by different manufacturers represents an attractive economic argument for card issuers, since it makes card manufacturers interchangeable. Java Card has also made it possible for short development cycles, which are particularly demanded in the IT sector, to be achieved for smart cards, while allowing all well-known, proven lifecycle models18 to be used. These reduced development and delivery times can open up new markets and applications for smart cards.