Java Card Object System

Switching contexts in the process of sharing objects

JCRE, applet client and applet server are executed in different contexts. To ensure the possibility of sharing objects, it is necessary to organize context switching. To request access to SIO, the client applet calls the JCSystem.getAppletShareableInterfaceObject method. In this case , the internal mechanism of the method switches the context from client to JCRE . JCRE then calls the getShareableInterfaceObject server applet method. As a result of this call, the context switches again. The applet server context becomes the current one. During the return process, the context of the client applet is restored from both methods.

The client applet can make a request to execute the server applet service by calling one of the available interface methods of the requested SIO object. During the call, the Java Card Virtual Machine switches the context. The current active context becomes the context of the applet server.
At this moment, the context of the server applet is active, so all its protected resources are available – instance fields, other methods, and even objects belonging to the context of the server applet. After returning from both methods, the context of the client applet is restored. The sequence of switching contexts in the process of sharing objects.

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 the applets, the firewall provides protection against the most common security threats: programmer errors and design oversight, which 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:

b.virtual_method_a();

· Calling the interface method:

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

· Initiation of exclusion:

throw b;

· Conversion to the specified type:

(givenType)b;

· Verification of belonging to the specified 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)
ISOException.throwIt(ISO7816.SW_CLA_NOT_SUPPORTED);

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 execution of the method is completed (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 an applet calls the method of the JCRE entry point object, it switches from the applet context 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.