Overview of Java Card technology

Java Card technology allows you to execute programs written in the Java programming language on smart cards and other computing devices with limited resources. This chapter provides an overview of the Java Card technology – the architecture of the system and its components.

Smart cards are one of the most compact computing systems currently available. Smart cards usually contain 1 KB of RAM, 16 KB of programmable memory (EEPROM) and 24 KB of permanent memory (ROM). One of the most difficult tasks during the development of Java Card technology was to place Java system programs in the memory of the smart card so that there was a free area sufficient for client applications. Therefore, the Java Card technology supports only a subset of the Java programming language, and a distributed model is used to implement the Java Virtual Machine.

The Java Card virtual Machine is divided into two parts: one part runs on an external computing system, and the second part runs on a card. Many tasks that are not tied to execution time are performed by an external virtual machine, where, as a rule, there are enough computing resources for this. These are loading classes, checking bytecodes, link resolution, layout, optimization, etc.
There are several important differences between smart cards and desktop computers. In addition to Java language support, Java Card technology defines a runtime environment that provides smart card memory allocation, communication, security, and application execution model. The Java Card runtime environment complies with the ISO 7816 international smart card standard.

The most important feature of the Java Card runtime environment is a clear separation of client applications and the smart card system software. This environment allows you to hide the complexities associated with the details of the implementation of the hardware and software of the smart card at a low level. Applications request system services and resources through a well-defined high-level programming interface.
In essence, the Java Card technology is a platform that ensures the functioning of applications written in the Java programming language in smart cards and other computing devices with limited resources. (Applications developed for the Java Card platform are called applets.)

A subset of the Java Card language the form is distributed between the smart card and the desktop computer both in space and in time. The Java Card platform includes three components, each of which is defined in the corresponding specification:
· Java Card 2.1 Virtual Machine (JCVM). The specification defines a subset of the Java language and a Java virtual machine for smart cards.
· Java Card 2.1 Runtime Environment (JCRE). The specification strictly regulates the modes of operation of JCRE, including memory management, applets, as well as the performance of other runtime functions.
· Java Card 2.1 Application Programming Interface
(API). The specification describes a set of basic and additional Java packages and classes for programming smart cards.

Smart cards have very limited resources, so the Java Card platform supports only a carefully selected basic set of Java language functionality. This subset includes tools suitable for developing programs for smart cards and other compact computing devices, while retaining the basic object-oriented properties of the Java programming language. Some illustrative Java features that are supported and not supported by the Java Card platform are given.

It should not be surprising that keywords that relate to unsupported functions are also removed from this subset of the language. Many modern Java smart cards support a “garbage collection” mechanism for deleting objects.
Appendix A contains an exhaustive description of a subset of the Java Card language. Chapter 14 provides techniques for programming Java Card applets to work with large numbers without using long primitive data types.

The main difference between the Java Card Virtual Machine (JCVM) and traditional Java Virtual Machines (JVM) is that JCVM is implemented as two separate components. The part of the Java Card Virtual Machine that resides on the smart card itself includes the Java Card bytecode interpreter. The second part, the Java Card converter, runs on an external computer or workstation. A converter is an external component of a virtual machine. These two components jointly implement the functions of a virtual machine – downloading Java class files and executing them according to a certain set of semantic rules. The converter translates the usual class files that make up the Java package into a special CAP (converted applet) format. The CAP file is then loaded into the Java smartcard and executed by the interpreter. In addition to the converted bytecode (CAP file), the converter creates a so-called export file that describes the available programming interfaces of the converted package.

Java Card technology supports a subset of the Java language. Accordingly, JCVM implements only those functionality that are defined in this subset. All unsupported language components that are present in the applet cause error messages during conversion. CAP files and export files. Java Card technology defines two new file formats that ensure platform independence in the development, distribution and execution of Java Card applications. The CAP file contains an executable binary

Java Card Virtual Machine

Java package class code. JAR files are used as containers for CAP files. A CAP file is a JAR file containing a set of components, each of which is represented by a separate file inside a JAR container. These components include information about classes, executable bytecodes, information about layout, verification, etc. Optimization of the CAP file format, which reduces the space occupied by it, is achieved through the use of compact data structures and limited dereference capabilities. CAP files contain instructions in the form of bytecodes, which are an optimized subset of the Java instruction set.

Perhaps the most important advantage of the Java platform is the almost complete portability of programs (“write once, run anywhere”). The main component of the Java architecture is the class file. It defines the Java platform compatibility standard at the binary level. The architecture of the Java Card system is distributed in nature, and the CAP file is a standard file format that provides compatibility with the Java Card platform at the binary code level. CAP files store application bytecodes that are directly loaded into Java smart cards. In particular, using CAP files, it is possible to load applet classes after the card is made. Therefore, these files are called CAP files (converted applet, or converted applets).

Export files are not loaded into the smart card and are not used by the interpreter. They are generated and used by the converter for verification and program layout. Export files can be compared with the header files of the C programming language. The export file contains general API information for the entire class package. It records the names and scopes of classes, as well as the scopes and headers of methods and fields of each class. The export file also contains binding information, which is necessary to resolve links between smart card application packages.
The export file does not contain an implementation, i.e. bytecodes. This allows developers to freely distribute export files to potential applet users without revealing implementation details.

Java Card Converter

Unlike a traditional Java virtual machine that processes one class at a time, the converter converts the entire package. The Java compiler generates class files from the source code. The converter then converts all the class files that make up the Java package into a special CAP format.
During the conversion process, the tasks that the Java Virtual Machine for desktop systems performs at the class loading stage are solved:
· Verification of correctness (well-formed) of downloaded Java class images.
· Checking the compliance of the code with a subset of the Java Card language.
· Initialization of static variables.
· Transformation of symbolic links to classes, methods and fields into a more compact form to ensure their efficient processing in the card.
· Bytecode optimization based on information obtained at the stages of class loading and linking.
· Memory allocation and creation of virtual machine data structures representing classes.
The converter works not only with class files that need to be converted, but also with one or more export files. In addition to the CAP file, the converter generates an export file for the converted package. Figure 3.2 schematically shows the process of converting a package. The converter loads all classes of the Java package. If the package contains classes imported from other packages, the converter also downloads the export files of these packages. The results of the converter are a CAP file and an export file for the converted package.

Java Card Interpreter

The Java Card interpreter provides support for the Java language model (bytecode) at runtime. Interpretation guarantees the independence of the applet code from the hardware implementation. The interpreter performs the following tasks:
· Execution of applet instructions in the form of byte codes.
· Managing memory allocation and object creation.
· Ensuring safety during execution.
Thus, the Java Card virtual Machine is a complex that includes a converter and an interpreter. However, unofficially, the Java Card virtual Machine is usually referred to only as its internal component, which runs in the card itself. By our definition, it is an interpreter. This agreement was used in many early publications on Java Card technology. Therefore, later in this book, the terms “Java Card Interpreter” and “Java Card Virtual Machine” will be used synonymously, unless otherwise specified. But readers should understand that the Java Card platform differs from the Java platform in that the functions of executing Java class files are performed jointly by the converter and the interpreter.