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 of object sharing

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 scenario of applet interaction 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 different 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).

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.
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 map. 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 used to search for the server applet. 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 parameter argument 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.

JCSystem. getAppletShareableInterfaceObject