Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Java Card Runtime Environment
Before getting into the details of the JCRE, it is important to describe the lifecycle of an applet inside a smart card. Figure 1 shows the lifecycle, highlighting the main stages a Java-enabled smart card passes through.
){kind=link}
Figure 1 The lifecycle of a Java Card applet.
First, the application is developed with software on a desktop computer, in which the developers can take advantage of tools such as Integrated Development Environments (IDE), debuggers, emulators, and so on. Finally, the final CAP files are obtained, and the stage of JCRE initialization takes place. The virtual machine is initialized, and all the JCRE support objects are created. This stage is performed only once during the card lifetime.
Another stage is applets installation. When applets are installed, the JCRE creates applet instances, as prescribed in the installed code, along with the other objects to store business data. Such objects are created in the EEPROM memory. This is one of the most interesting features of Java Card applets: the capability to be loaded dynamically. Most of the previous smart card software was hardwired onto ROM at card initialization, once and for all. The applet installation stage can be repeated many times.
In Figure 1, the final layering of the different computation environments is also shown. It is composed of the pre-existing manufacturer hardware topped by the Java Card interpreter that executes installed client applets together with some other system applets.
Java Card Lifecycle
When we introduce smart cards in ATMs or other devices, cards are activated and the code they contain is executed. Such devices are called card acceptance devices (CADs). The period of time from the card activation inside such a device to the end of the business transaction and subsequent removal is called a CAD session.
At the end of a CAD session, when the power is removed from the card, the JCRE is only suspended. Thanks to the persistent storage (EEPROM), the whole computation state is preserved. Only transient objects (created in RAM for security and performance reasons) are permanently deleted. The next time power is switched on, which starts a new CAD session, the JCRE interpreter will be reset to the beginning of the main loop.
During a CAD session, the card program emerges from hibernation and starts to run. Usually, its main activity is communicating with the hosting application via the CAD hardware support. This I/O process is known as application protocol data unit (APDU) I/O. APDUs are low-level data packets exchanged between applets and the host application. APDUs can contain both data and commands, and are processed by one of the currently installed applets that eventually will return an APDU response to the host application.
An important feature offered by the interpreter is the atomicity of operations and transactions. Simple operations, such as modifying the fields of a class instance, are ensured to be atomic by the JCRE (the state after the operation will be either modified to the new value or restored to the previous one—no inconsistent states are possible). Transactions are supported via an API that allows developers to encapsulate several operations in one transaction. In case of failure during the transaction execution, all performed operations are rolled back, restoring the computation state just before the transaction started.
Various Actors
The Java Card Virtual Machine (JCVM) differs from the usual JVM because is separated in two pieces: one (the interpreter) is on the card, and the other (the converter) is implemented as a software program running on a workstation or PC.
The converter's job is to create card executables files from the Java .class files. Such executable files are called CAP (converted applet) files. Together with CAP files, the converter produces export files that contain descriptions of the CAP file. The export files are similar to C header files, and are produced only to be used internally by the converter for linking and verification purposes.
The converter plays an important role: It transforms the class files into a compact, optimized format suitable for execution on such a limited environment. Furthermore, it is responsible for checking compliance with the Java Card language specification. It raises an error if, for example, a long variable is used in one of the input class files.
The CAP file format, the main output of the converter, is itself JAR-compatible (that is, compliant with the ZIP standard format), but it is optimized for occupying the minimum size, using compact data structures and limited indirection for the ZIP format. CAP files are conceptually equivalent to what JAR files are on other Java platforms: a standard means of distributing Java programs.
The other piece of the JCRE, the interpreter, is what physically resides on the smart card. It enables a normal smart card to support the Java Card platform. It performs the tasks of execution of bytecode, allocating space for the created Java objects (remember that garbage collection is not supported) and ensuring runtime security.
Applet deployment is not possible without another software module, the installer, which resides with the interpreter on the card. It works (together with an off-card installation software) during a CAD session to download and install the CAP file.