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.
The JCRE entry point objects are divided into two categories:
· Temporary objects–entry points to JCRE – like methods of all objects– entry points to JCRE, methods of temporary objects can be called from any context. However, references to such objects cannot be saved-

They are 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 to JCRE – as well as methods of all objects–
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 objects are then login receipt – 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–entry points 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. Consequently, 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.

Interface mechanism for sharing objects

Let’s repeat the basic properties of the mechanisms for sharing JCRE objects with applets:
· JCRE has system privileges, so it can access any objects.
· The applet gets access to system services through JCRE entry point objects.
· JCRE exchange data of primitive types through special global arrays.
Java Card technology also provides for the sharing of objects by applets using an interface sharing mechanism.

Sharing Interface

The sharing interface directly or indirectly extends the javacard interface.framework.Shareable.

public interface Shareable {}

In essence, this interface is similar to the Remote interface, which is used in RMI, a technology for building distributed applications on the Java platform. None of these interfaces defines any methods or fields. Their purpose is that, if they are extended by other interfaces, they endow these interfaces with special properties.
The sharing interface defines a set of methods that are available to other applets. Any
number of sharing interfaces can be implemented in a class. A class can also extend other classes that implement such interfaces.

Sharing Interface Object

The object of the class in which the sharing interface is implemented is called the shared interface object (SIO). From the point of view of the context that owns it, SIO is an ordinary object. Access to its fields and methods from this context is allowed. For all other contexts, SIO is an implementation of a shared interface, so only the methods defined in this interface are available to them. All fields and other SIO methods are protected by a firewall.

Principles of operation of the interface mechanism for sharing objects

Applets store data in objects. To ensure data exchange, the applet that owns the object makes it available to other applets. In this way, the data encapsulated in the object is shared.
In the object-oriented world, access to objects (as opposed to direct access to variables) is carried out by calling methods. Objects interact with each other by exchanging messages or calling appropriate methods. The interface sharing mechanism allows applets to exchange messages to bypass firewall protection. The applet that owns the data creates a SIO object and implements the methods defined in the sharing interface. These methods make up a public interface with the data owner applet. With their help, other applets can send messages and thus gain access to the services that this applet provides.

The applet interaction scenario shown in Figure 9.2 can be represented as a client/server relationship. Applet A, which provides SIO objects, is the server, and applets B and C, which use SIO objects of applet A, are clients. The same applet can be a server for some applets and a client for others.
In the Java programming language, an interface defines a reference type that contains a set of method specifications and constants. The applet client sees SIO as an interface type of sharing. The SIO type class that implements the sharing interface remains invisible. In other words, the applet client has access only to the methods defined in the interface. Instance fields and other methods are not available to it. This approach allows the applet server to provide controlled access to the data that it wants to open to other applets.

The applet server can provide different data to different clients. To do this, you may need to configure services to meet the needs of various clients in order to open access only to the data that they need. The server can define several interfaces, each of which will contain specifications of methods required for a group of clients. If the methods in the interfaces are significantly different, the applet server can create classes, each of which will implement a separate interface. But usually the services partially coincide. The applet server can define a class in which several interfaces will be implemented. Therefore, SIO objects in such a class can perform several roles.

Example of sharing an object by different applets

In this section, we will look at the sharing of objects using the example of the “electronic wallet” and “air miles” applets. The “electronic wallet” applet is designed for performing payment transactions in electronic form. The money from the account can be used to purchase goods.
“Air miles” are advertising campaigns, the essence of which is that the purchase of goods in certain stores provides a free flight for a certain number of miles. Like the “electronic wallet” applet, this applet also accumulates data – the number of air miles that the cardholder has typed. Let’s assume that under the terms of the joint marketing agreement, every dollar spent through the e-wallet applet corresponds to one additional airmail.
Let’s assume that the “e-wallet” and “air miles” applets are in different contexts (they are defined in different packages). If there is a firewall, they can interact as follows:

  1. The Aviamily applet creates a sharing interface object (SIO).
  2. The electronic wallet applet makes a request to the Aviamily applet for access to SIO.
  3. The “electronic wallet” applet calls the SIO service method to transmit the number of miles added.
    In this case, the “aviamily” applet is a server that increases the number of available aviamiles at the request of the “electronic wallet” applet (client), as shown in Figure 9.3.

Joint use of the object by the “electronic wallet” applet and the “aviamily” applet

Let’s discuss the implementation of the “electronic wallet” and “aviamily” applets. For brevity, we will omit methods and fields that are not relevant to the topic under consideration, as well as condition checking and border control during the transaction.

Creating a Sharing Interface Object

To create a SIO, an applet server (in our case, the aviamily applet) First of all, I must define the sharing interface, which is a javacard extension.framework.Shareable.

package com.fasttravel.airmiles; import javacard.framework.Shareable;

public interface AirMilesInterface extends Shareable {

public void grantMiles (short amount);
}

Then the server creates a service provider class (such a class can be the applet class itself), which implements the sharing interface. The applet server can then create one or more objects of the service provider class and make these objects (SIOS) available to the applets in other contexts.

package com.fasttravel.airmiles; import javacard.framework.*;

public class AirMilesApp extends Applet
implements AirMilesInterface {

private short miles;

public void grantMiles(short amount){

miles = (short)(miles + amount);
}
}

Before the client can make a request for access to SIO, it must find a way to identify the server. On the Java Card platform, each applet is uniquely identified using AID.
Let’s go back to Chapter 7 and remember that when creating an instance of an applet, it is registered in JCRE using one of the two register methods. The method without parameters allows you to register an applet in JCRE using the default AID, which is defined in the CAP file. Another register method allows the applet to specify an AID other than the default value. JCRE stores the values of the AID identifier in the AID object (which belongs to JCRE). The AID object is associated with the corresponding applet. When objects are shared, the client uses the AID object to identify the server.

Requesting a Sharing Interface Object

Before making a request for access to SIO, the client must receive an AID object associated with the server applet. To do this, the applet client calls the lookupAID method of the JCSystem class:

public static AID lookupAID
(byte[] buffer, short offset, byte length)

The client must know the AID of the applet server. It passes its value in the buffer parameter. The lookupAID method returns an AID object belonging to JCRE, associated with the server applet, or null if this applet is not installed on the card. Due to the fact that the AID object is a permanent entry point object to JCRE, the applet client can request it only once. For further use, this object must be copied to the permanent memory area of the applet.
The client then calls the JCSystem.getAppletShareableInterfaceObject method using the AID object that defines the server:

public static Shareable
getAppletShareableInterfaceObject(AID server_aid, byte parameter)

The second parameter of the getAppletShareableInterfaceObject method is analyzed by the server applet. It can be used to select SIO if several such objects are defined in the server. In addition, this parameter can be used as an access token, which was previously agreed upon by the applet developers.
The JCRE getAppletShareableInterfaceObject method is designed to search for an applet server. The value of the server_aid parameter is compared with the AID of the applets registered in JCRE. If the applet server is not found, JCRE returns null. If the server is found, JCRE calls its getShareableInterfaceObject method.

public Shareable
getShareableInterfaceObject(AID client_aid, byte parameter)

Note that when calling the getShareableInterfaceObject method, JCRE replaces the first argument with the client_aid object. The byte argument parameter is the same argument that was set by the client applet. The server uses both arguments to determine which services are available to the applet that sent the request and which SIO object should be provided.
The getShareableInterfaceObject method is defined in the base class of javacard applets.framework.Applet. In the default implementation, this method returns null. If the applet class is intended to share any SIO objects, it should override this method. Let’s see how the getShareableInterfaceObject method can be implemented in the aviamily applet.

public class AirMilesApp extends Applet
implements AirMilesInterface {

short miles;
public Shareable getShareableInterfaceObject(AID client_aid,
byte parameter) {

// client authentication – will be reviewed later
// …

// the object of the sharing interface
return this is returned;
}

public void grantMiles(short amount){

miles = (short)(miles + amount);
}
}

When the applet server returns SIO, JCRE redirects it to the client applet that made the request. The process of requesting a shared interface.

JCSystem. getAppletShareableInterfaceObject