Java Card Execution Environment

The Java Card interpreter does not load CAP files on its own. It only executes the code that is contained in the CAP file. In Java Card technology, the mechanisms for downloading and installing CAP files are implemented in a program called an installer.

The Java Card installer is located on the card. It is paired with an external installation program. This program transmits executable binary codes to the installer, which are located in the CAP file, through a card reader. The installer writes binary codes to the memory of the smart card, associates them with other classes that are already loaded on the card, and then creates and initializes all data structures that are used by the internal Java Card execution environment. Interaction of the installer with an external installation program, as well as with other components of the Java Card platform.
The separation of functions between the interpreter and the CAP file installer reduces the size of the interpreter, and also provides a large level of flexibility for installer implementations. Later in this chapter, we will look at the installation process of the applet and focus in more detail on the functions of the installer.

Java Card Installer and external installation program

The Java Card runtime environment (JCRE) includes Java Card system components that work directly on the card. JCRE provides resource management, communication with the outside world, applet execution, as well as security at the system and applet levels. Thus, the execution environment actually performs the functions of the smart card operating system.

JCRE is a kind of proxy server that hides the details of the hardware and software implementations of the smart card from applications. JCRE includes the Java Card Virtual Machine (bytecode interpreter), programming interfaces (APIs) with Java Card base classes, industry extensions and JCRE system classes. JCRE completely hides from applets the features of specific technologies implemented by smartcard manufacturers, and provides standardized system and high-level application programming interfaces. As a result, the applet development process is simplified. In addition, applets are compatible with various smart card architectures.
The lower level of JCRE includes the Java Card Virtual Machine (JCVM) and native methods. JCVM executes bytecodes, manages memory allocation and objects. Also, as noted earlier, JCVM provides runtime security. Native methods provide support for JCVM and next-level system classes. Using these methods , it is organized

Hardware and native smart card code

Operation of low-level communication protocols, memory management, cryptography support, as well as other functions.
System classes act as the JCRE runtime environment. They can be compared to the operating system kernel. System classes are responsible for managing transactions, for organizing communication between host applications1 and Java Card applets, and also provide creation, selection and deselection of applets. To perform these tasks, system classes usually call native methods.

The Java Card application framework defines programming interfaces. This environment includes four API packages – basic and extensions. The API classes are compact and optimized for developing smartcard applets. The main advantage of this model is that it makes it easier to develop applets. Applet developers can focus on implementing algorithms without thinking about the intricacies of the smart card infrastructure. Applets access JCRE services using API classes.

Representatives of various industries or business lines can develop their own libraries designed to provide additional services or more accurately define the system model and security model. For example, the Open Platform specifications extend the capabilities of JCRE, providing a level of security accepted in the financial industry. In addition to additional functionality, such extensions provide control by smart card issuers, and also define a standard set of commands for card personalization.

The installer provides secure loading of software and applets into the card after its production and transfer to the owner. It is paired with an external installation program. These components ensure that the binary codes contained in the CAP files are loaded. The installer is an optional JCRE component. In the absence of an installer, all software for the card, including applets, must be written to the card’s memory during its production.

In terms of the Java Card platform, applets are user applications. Of course, applets are written in a subset of the Java programming language. Their support and execution is provided by the JCRE environment. Applets can be loaded into the card. They can be downloaded after the release of the smart card.

JCRE lifetime

When running on a PC or workstation, the Java Virtual Machine is an operating system process. Data and objects are created in RAM. After the OS process is completed, Java applications and the objects generated by them are automatically destroyed.
In Java Smart Cards, the Java Card virtual Machine runs in the Java Card runtime environment. JCRE initialization occurs during card initialization. During the life cycle of the card, this operation occurs once. By

Host applications are applications that run on the terminal side and interact with applets, or client applications.

At the same time, JCRE initializes the virtual machine and creates objects for organizing JCRE services and managing applets. After installing the applets, JCRE creates their instances, then the applets create objects to store data.

Most of the information recorded in the memory of the smart card must be saved after the card is powered off (removing it from the reader). For this purpose, permanent memory technologies (for example, EEPROM) are used. Data and objects are created in permanent memory. The lifetime of the JCRE is equivalent to the full life of the card. After the power is turned off, the virtual machine goes into standby mode. The state of JCRE and the objects created on the card are saved.

After the next power-up, JCRE restarts the virtual machine by downloading data from the permanent meme1. It should be noted that JCRE does not resume the virtual machine from the point corresponding to the moment of power outage. The virtual machine is reset, and its operation begins with the main cycle. JCRE reset is different from initialization, because when reset, the applets and objects recorded on the card are saved. If the reset occurred during the execution of the transaction, JCRE performs all necessary actions to clean up resources in order to move to a consistent state.

How does JCRE work during a communication session with a reader

A CAD communication session is a period of time from the moment the card is inserted into the card reader (CAD) and its power is turned on until the card is removed from the card reader. During the CAD communication session, the JCRE environment performs all the functions of the card, supporting the exchange of APDU packets with the host application. APDU (application protocol data unit) packages are data blocks for exchanging commands and information between applets and host applications. Each APDU packet is either a command of the host application intended to be executed by the applet, or the response of the applet to the host system.
After the JCRE is reset, the environment goes into standby mode for APDU commands from the host system. The host application sends the APDU Java Card commands to the platform. For

After receiving the command, JCRE either selects the applet specified in the command for execution, or redirects the command to the active applet. Control is transferred to the active applet, which provides processing of the APDU command. After processing is completed, the applet sends a response to the host application and transfers control to JCRE. When the next command arrives, the cycle repeats. Details on how applets handle APDU commands will be described in chapters 7 and 8.

Additional features of the Java Card execution environment

In addition to supporting the Java execution model, the JCRE runtime provides three additional functions:
· Support for permanent and temporary objects – Java objects by default
Cards are permanent and stored in permanent memory. The memory occupied by such objects and the data they represent are stored between CAD communication sessions. For security and performance reasons, applets can create objects in RAM. Such objects are called temporary. Temporary objects contain data that is not saved between CAD communication sessions.
· Atomic operations and transactions – The Java Card Virtual Machine ensures the indivisibility, or atomicity, of each write operation in a single field of an object or class. If the operation is completed completely, a new value is assigned to the field. If the operation is interrupted, the previous value of the field is restored. In addition, JCRE provides a programming interface to support transactions. An applet can start executing a transaction that includes multiple write operations. At the normal completion of the transaction, all fields that were recorded take on new values. If the transaction is interrupted, the values of these fields do not change.

· Applet Protection system and data sharing mechanisms – The applet protection system (applet firewall) ensures their isolation from each other. Each applet works in the space allocated to it. The existence and functioning of a particular applet does not affect other card applets. The Java Card virtual Machine contains bytecodes that ensure the operation of the applet security system. If you need to provide data sharing by applets or provide access to JCRE services, the virtual machine provides its own protected mechanisms for this.