Applet development process

AID is also assigned to each Java package. During the process of uploading a package to the card, their identifiers are used to link with other packages on the card.
The ISO 7816 standard specifies that AID should be used in smart card systems as unique identifiers of applications and files of certain types. AID is a byte array consisting of two independent
parts. The first part is 5 bytes long and is called RID (resource identifier). The second part has a variable length and is called PIX (internal identifier extension). The length of the PIX field can be from 0 to 11 bytes. Thus, the total length of the AID can be from 5 to 16 bytes.

AID (application ID)

Each company that produces smart card applets has its own unique RID. RID identifiers are allocated by the International Organization for Standardization (ISO). The value of the PIX field is determined by the company itself. This section provides a brief description of application IDs. Full information is provided in the ISO 7816-5 specification: “AID Registration Category D format”.

On the Java Card platform, the identifier of each package is formed by combining the RID identifier assigned to the company and the unique identifier of the PIX package. The applet’s AID is formed in the same way. It is a combination of the RID identifier assigned to the company and the unique identifier of the PIX applet. The AID of the applet must not match the AID of any package or any other applet. However, due to the fact that the RID field in the application identifier determines the manufacturer of the applet, its values for the package and all the applets defined in this package must match.
The package AID and default AID values for each applet defined in this package are specified in the CAP file. In the process of generating the CAP file, the converter uses them.

The development of the Java Card applet begins in the same way as the development of any other Java program: the developer writes one or more Java classes and compiles the source code using the Java compiler. This generates one or more class files.

Finally, the applet is written, tested and debugged in a simulation environment. The software simulator simulates the Java Card execution environment on a PC or workstation. In the simulation environment, the applet runs on a Java virtual machine, i.e. the applet class file is executed. Thus, the simulation environment can use a variety of Java development tools (virtual machine, debugger, and other tools). The developer has the opportunity to test the work of the applet and immediately see the results of its execution without starting the conversion process. At this stage, the general aspects of the functioning of the applet are tested. However, some functionality of the Java Card Virtual Machine, such as the applet protection system, the mechanism of temporary and permanent objects, is not available at this stage.

Then, using the Java Card converter, the applet class files that make up the Java package are converted into a CAP file. The Java Card Converter works not only with class files that need to be converted, but also with one or more export files. After the package is converted, the converter also generates an export file for it. A CAP file or an export file represents a single Java package. If the applet includes several packages, a separate CAP file or export file is created for each of them. At the next stage, the CAP file (or files) that represents the applet is loaded into the emulator environment for testing. The emulator also simulates the Java Card runtime environment on a PC or workstation. However, the emulator is

a more powerful tool for testing. It performs all the functions of the Java Card Virtual Machine. The behavior of the applet when working in the emulator environment fully corresponds to its behavior when working in a real card. At this stage of development, not only testing of the applet continues, but also its performance characteristics are measured.
Most simulation environments and emulators have a built-in debugger. The debugger allows the developer to set control points or execute the program step by step, observing the execution of the applet in an environment that simulates or emulates the Java Card runtime environment.
Finally, after the end of testing, the applet in the form of one or more CAP files is loaded into the Java smart card and installed.

During the production of a Java smart card, its internal system, as well as the Java Card execution environment, including native methods, the Java Card Virtual Machine, API classes and libraries, are written to permanent memory (ROM). The process of writing permanent components to the permanent immutable memory of the card is called “burning”. This technology is implemented by the card manufacturer and is not discussed in this book.

ROM Applets

Classes of Java Card applets can be written to the permanent ROM memory during the card production process together with JCRE and other system components. JCRE writes applet instances to EEPROM memory during its initialization at a later stage. Such applets are called ROM applets.
ROM applets are standard applets that are provided by the card issuer and are included in its delivery package. The card issuers are responsible for the contents of the ROM applets, so the Java Card technology allows the definition of native methods in such applets, the implementations of which can be developed in other programming languages, such as C or assembly language. Native methods are not subject to security checks performed by the Java Card Virtual Machine.

Predefined and downloadable applets

Java Card applet classes and associated class libraries can also be written to programmable permanent memory (for example, to EEPROM memory) after the card is released. Such applets can be further categorized as predefined or downloadable. The terms “predefined” and “downloadable” reflect the time when the applet was written to the card – before or after its release. Predefined applets are no different from ROM applets. The card issuers are responsible for their contents.

Unlike ROM applets or predefined applets, downloadable applets cannot define their own methods. The reason is that JCRE does not have the ability to control the contents of the applets. Downloading applets containing native code may violate the security of the Java Card platform.
The following subsections are devoted to installing downloadable applets. Usually, the same mechanism is used to download predefined applets, but the decision on the use of a particular technology is made by card issuers.

Installing downloadable applets

Applet installation includes loading applet classes from the CAP file. JCRE is involved in this process. Then an instance of the applet is created. After that, it can be activated and executed.
For the Java Card platform, the unit of download and installation is the CAP file. The CAP file includes the classes that make up the Java package. A minimal applet is a Java package with a single class inherited from the javacard class.framework.Applet. More complex applets can contain several classes and represent one or more Java packages.

To download the applet, an external installation program opens the CAP file and converts it into a sequence of APDU commands, in the data fields of which the contents of the CAP file are written. The Java Card installer receives APDU commands from an external installation program and writes the contents of the CAP file to the card’s permanent memory. It then binds the classes defined in the CAP file to other classes that are available on the card. The installer also creates and initializes all internal JCRE data that is necessary to support the applet. If the applet consists of several packages, all the necessary CAP files are loaded into the card.
At the last stage of the applet installation, the installer creates an instance of the applet and registers it in JCRE1. To do this, the installer calls the install method:

public static void install(byte[ ] bArray, short offset, byte length)

The install method contains the entry point to the applet. It is similar to the main method in a Java application. The install method must be implemented in the applet. The install method calls the applet constructor, which creates and initializes an instance of the applet. The bArray argument of the install method is used to set the initialization parameters of the applet during installation. The installation parameters are passed to the card along with the CAP file. The format and content of these parameters are determined by the applet developer.

After the applet is initialized and registered in JCRE, it can be selected and executed. JCRE defines an applet (an instance of an applet) to be executed using AID. The applet can register itself in JCRE using the default identifier contained in the CAP file, or JCRE implementations can create an instance of the applet later, after the installation process is completed.

Select a different ID. Installation parameters can be used to set an alternative AID.
The install method can be called multiple times to create multiple instances of the applet. Each instance of the applet must have a unique AID.
In the Java Card environment, an applet can be developed and executed without having information about the mechanism for loading its classes. To ensure the installation of the applet, it is enough to implement the install method.

Error handling during applet installation

The installation process is a transaction. In case of an error, such as a software failure, lack of memory, premature removal of the card from the reader, as well as in case of other abnormal situations, the installer deletes the CAP file and all the applets created during installation, frees up memory and all resources. JCRE returns to the previous state.

Installation Restrictions

The reader should understand that the process of installing an applet is different from dynamically loading classes at runtime. Dynamic loading is supported by Java Virtual machines for desktop PCs. In fact, the installation of the Java Card applet is the loading of classes, which is performed after the card is made.

Therefore, during the installation of the Java Card applet, two conditions must be met. Firstly, applets can only refer to classes that already exist on the card, because there is no mechanism for loading classes during the execution of the applet code. Secondly, it is necessary to ensure such a loading order in which each downloaded package will have links only to those packages that have already been loaded into the card. For example, in order to install the applets, the javacard package must be present on the card.framework, because all classes of the applet are inherited from the javacard class.framework.Applet. If cyclic references are detected, for example, if packages A and B refer to each other, the installation is terminated.