Applet Firewall and Object Sharing

The Java Card platform is an environment for many applications to work. Several applets from different manufacturers can be stored in one card. After the card is made, additional applets can be loaded into it. Applets often contain extremely critical information, such as bank account data, identification data, secret cryptographic keys, etc. The exchange of such secret data between applets must be strictly limited.

On the Java Card platform, a security system, or firewall of applets, is implemented to isolate applets. The firewall restricts applets’ access to data that does not belong to them. An applet cannot directly read or change the values of fields of objects owned by other applets.
Often the same smart card performs a variety of functions. It can be used, for example, as a bank, identification, discount or telephone card. To support the collective work of several applets in one card, Java Card technology provides well-defined and secure mechanisms for sharing objects.

The presence of a firewall and object sharing mechanisms requires compliance with certain rules when developing applets. In this chapter, we will discuss the features of the behavior of objects, exceptions and applets related to the protection system, as well as consider ways to organize secure data exchange between applets using Java Card programming interfaces. JCRE implementation details that are not available for applets will be intentionally omitted.

By isolating applets, the firewall provides protection against the most common security threats: programmer errors and design mistakes that can lead to secret data becoming available to other applets. In addition, the firewall provides protection against unauthorized access. An applet can get a reference to an object if it is stored in a public memory area, but if the owner of this object is an applet from another package, access to the object will be prevented by a firewall. Thus, an applet that does not work correctly, or even an “malicious” applet, will not be able to affect the operation of other applets or JCRE.


The applet protection system divides the Java Card object system into separate protected object spaces, which are called contexts. A firewall separates one context from another. After creating an instance of the applet, JCRE assigns it a context. Essentially, the context is a group one. All instances of applets defined in the same Java package share a common group context. No firewall is installed between two instances of applets that use the same group context. If the applets belong to the same group context, they can access shared objects. But the firewall prevents the applet from accessing the object from another group context.
In addition, the JCRE environment has its own context, which is called the JCRE context. The JCRE context is a specialized system context that has certain privileges: access from the JCRE context to any applet context is allowed, but access from any applet context to the JCRE context is prohibited by the firewall. Separation of the Java Card object system.

Ownership of objects

At any given time, there is only one active context in the VM: either a JCRE context or a group context of applets. When a new object is created, the current active context becomes its owner. All applet instances included in this context have access to this object. We can also say that after creating an instance of an object, the active applet from the current context becomes its owner. If the JCRE context is currently active, the JCRE will be the owner of the object.
When declaring static arrays of primitive types in applets, they can be initialized. Such static arrays are created and initialized by the converter. Static arrays are created even before all instances of applets are created on the card, so one of the applets of the package in which it is defined is accepted as the owner of such arrays. Any applet from this package has access to them. In other words, the owner of such arrays is the group context of the package in which they are defined.

Access to objects

When accessing objects, Java access controls are used. For example, a private method of a class instance cannot be called outside the object. In addition, the context to which the object belongs is compared with the current active context. If these contexts do not match, a SecurityException is thrown. Here are some examples that illustrate these arguments. Let context A not be the owner of object b. Then the following operations of accessing object b from context A will cause the Java Card Virtual Machine to trigger a SecurityException interrupt:
· Getting and assigning field values:

short a = b.field_a;// get object b’s field b.field_a = 5;// set object b’s field

· Calling an open method of a class instance:


· Calling the interface method:

b. interface_method_a(); // if b is an interface type

· Initiation of exclusion:

throw b;

· Conversion to the specified type:


· Verification of belonging to a given type:

if (b instanceof givenType)

· Access to an array element:

short a = b[0];// if object b is an array type b[0] = 5;
· Getting the length of the array:

int a = b.length;// if b is an array type

Contexts and access to temporary arrays

As in the case of permanent objects, access to temporary arrays of the CLEAR_ON_RESET type is possible only if the owner of the array is the current active context.
Temporary arrays of the CLEAR_ON_DESELECT type are resources belonging to the applet. Their creation is possible only if the currently selected applet belongs to the current active context. The applets defined in the same package have a common group context, so access to a temporary array of type CLEAR_ON_DESELECT is also allowed for all applets from this context. However, such access is possible only if one of them is the currently selected applet.

Static fields and methods

Contexts are the owners of only instances of object classes, not classes as such. When accessing a static field or calling a static method, no runtime context checks are performed. In other words, static fields and methods are accessible from any context. For example, any applet can call the static throwIt method of the ISOException class:

If (apdu_buffer[ISO7816.OFFSET_CLA] != EXPECTED_VALUE)

Of course, Java access rules also apply to static fields and methods. For example, static fields and methods with the private access modifier have scope only inside the class in which they are defined. When a static method is called, it is executed in the calling context.
This, in particular, means that the calling context (the current active context) becomes the owner of the objects created in the static method.
Static fields are accessible from any context. However, objects (including arrays) referenced in static fields are ordinary objects. The owner of such objects is the applet that created them (or JCRE). Standard access rules are applied to them, which are set by the firewall.

The firewall restricts the actions of applets only to the context to which they belong. The applet cannot go beyond its context to semi-
allow access to objects owned by JCRE or an applet from another context. But to support the collective work of several applets, Java Card technology provides well-defined and secure mechanisms for sharing objects, which include the following tools:
· JCRE privileges.
· Objects are entry points to JCRE.
· Global arrays.
· Sharing interfaces.
Sharing mechanisms, under certain conditions, allow applets from one context to access objects belonging to other contexts.

Context switching

Recall that when the Java Card Virtual Machine is running, there is only one active context at any given time. When trying to access any object, the VM checks whether access is allowed. Usually access is not allowed if the context that is the owner of the object does not match the current active context. The mechanism of object sharing is implemented in the Java Card Virtual Machine using context switching.

Object members are methods and instance fields. Accessing an instance field of an object from another context does not change contexts. Only JCRE has access to the fields of objects belonging to different contexts. Context switching occurs only during the call of a non-static method of an object belonging to another context, or when returning from this method, as well as if an exception occurred during the execution of such a method.
In the process of preparing a method call that requires context switching, the current context is remembered, and the new context becomes the current active context. The called method is executed in the new current context and has all the access rights defined by it. After the completion of the method execution (normal or as a result of raising an exception), the original (calling) context is restored, which again becomes the current active context. For example, if the applet calls the method of the JCRE entry point object, the applet context switches to the JCRE context. All objects created in the called method are associated with the JCRE context.
Nested method calls are allowed, so context switches in the Java Card Virtual Machine can also be nested. When the VM is started after the card is reset, the current active context always becomes the JCRE context.

In the following sections, we will look at all the mechanisms for sharing objects, as well as discuss when and how context switching occurs when each scenario is executed.

JCRE Privileges

On the Java Card platform, the JCRE runtime performs the functions of a dispatcher. The JCRE context is “system”, so it has special privileges. JCRE can call methods of any objects and has access to non-static fields of any objects on the card. Such system privileges allow JCRE to control system resources and manage objects. For example, when JCRE accepts the APDU command, it calls one of the methods of the currently active applet: select, deselect or process.
Before calling the applet method, the JCRE context switches to the context of this applet. Control is transferred to the applet. At the same time, it does not have system privileges. Any objects created after context switching belong to the currently active applet and are associated with its context. After returning from the applet method, the JCRE context is restored.

Objects–entry points to JCRE

JCRE has access to all applet contexts, but the JCRE context is not available for applets. In a secure computing system, applications are divided into unprivileged, to which only a certain subset of system resources are available, and privileged, or system, to which all resources are available. In such systems, there is a certain mechanism for accessing protected resources. Unprivileged applications make a request that system applications execute. On the Java Card platform, such a mechanism is implemented using JCRE entry point objects.
The entry point objects in JCRE are ordinary objects owned by the JCRE context, but they have a sign indicating that they contain entry point methods. Usually, the firewall completely prohibits applets from accessing such objects. But open methods of entry point objects can be called from any applets. When such a method is called, it switches to the JCRE context. Thus, these methods are gateways through which applets request privileged JCRE services. Note that the firewall only allows access to the open methods of the JCRE entry point objects. The fields of these objects are not available to applets.
Perhaps the most commonly used object is the entry point to the JCRE – the APDU object. Chapter 8 describes how applets make requests to JCRE for receiving and transmitting APDU data by calling methods of the APDU object.

JCRE entry point objects are divided into two categories:
Temporary objects–entry points in JCRE – like methods of all objects– entry points in JCRE, methods of temporary objects can be called from any context. However, references to such objects cannot be stored in class variables, instance variables, or array fields (including temporary arrays) of the applet. JCRE monitors and prevents attempts to write references to such objects. This is one of the functions of the firewall to prevent unauthorized access. Examples of temporary entry point objects are APDU objects and all exception objects owned by JCRE.

Permanent objects–entry points in JCRE – like methods of all entry points, methods of permanent objects can be called from any context. In addition, references to such objects can be saved for free reuse. Examples of permanent entry point objects are AID instances owned by JCRE. JCRE creates an AID instance during the applet instance creation process to encapsulate the applet AID.
Only JCRE can assign objects as entry points and determine whether they will be temporary or permanent. JCRE developers must implement JCRE correctly, including mechanisms for assigning entry point objects and separating them into temporary and permanent ones.

Global arrays

JCRE entry point objects allow applets to use certain JCRE services by calling the appropriate methods. The data that is encapsulated in such JCRE objects is not directly accessible to the objects. But on the Java Card platform, some data is global, so access to it is necessary from any context – both applets and JCRE.
The firewall provides a flexible way to access such data. JCRE can define arrays of primitive types as global. In fact, global arrays are memory buffers for collective use. They can be accessed from any applets and from JCRE. Only one context is active at any given time, so synchronizing access is not a problem.
A global array is a special type of object–the entry point to JCRE. The firewall allows all applets from any contexts to access the open fields of such arrays (array elements and array length). The open methods of global arrays are completely similar to the methods of other JCRE entry point objects. The only method in the array class is equals. It inherits from the root class Object. As in the case of calling any method of the JCRE entry point object, when calling the equals method of the global array, the context switches to the JCRE context.

Only arrays of primitive types can be global. Only JCRE can define an array as global. All global arrays are temporary entry points to JCRE. Therefore, references to such arrays cannot be stored in class variables, instance variables, or array fields (including temporary arrays) of the applet.
The only global arrays defined in the Java Card programming interfaces are the APDU buffer and the byte array parameter of the install applet method.

Typically, in JCRE implementations, an APDU buffer is passed as a byte array – the parameter of the install method. All applets have the right to view and access the contents of global arrays, so JCRE clears the contents of the APDU buffer before selecting the next active applet, as well as before receiving a new APDU command. This is necessary in order to prevent the potential possibility of “leakage” of confidential information through the global APDU buffer.