LaMeH@CkeR

The Java Card application firewall allows certain forms of object access across different group contexts. It is a fact that JCApplets always need access to services provided by the JCRE. These services are provided by JCRE Entry Point Objects (EPO). These objects belong to the JCRE system context but can be accessed by any other Service Object when needed. There are permanent entry point objects (PEPO), temporary entry point objects (TEPO), and global arrays. Global arrays share many properties of TEPO. A JCApplet can invoke methods on entry point objects, but not access their fields.

Global Arrays

The global nature of some objects requires that they be accessible from any context [1]. The Java Card VM allows an object to be designated as global. All global arrays are TEPO. These objects are owned by the system context and can be accessed from any context, meaning from any SO. No reference to these objects can be stored as a class variables, instance variables or array components [1]. The JCRE can detect and will restrict attempts to store references to SO as part of the firewall security requirement to always prevent unauthorized object re-use. For security reasons, only arrays can be designated as global and only the JCRE itself is capable for designating global arrays. JCRE implementers are responsible for implementing the mechanism of global arrays [1].

Object sharing

The Java Card specification introduces mechanisms that allow object sharing between JCApplets. The object sharing mechanism (OSM) allows the Java Card programmer to build OSMs that provide means for accessing object methods rather than just data. OSM is not a file sharing mechanism.

The JCApplet firewall, defined in Java Card 2.1 specification for first time, completely prevents a non global JCApplet from accessing the data corresponding to other JCApplets. But a provision was made for a JCApplet to be capable of invoking interface methods belonging to different packages. This is the basis of OSMs.

In the Java programming language invoking an interface method belonging to different package, if the specific method is public, is not illegal. However in Java Card because the PEPO and TEPO already are public, object sharing must be restricted, so as no normal JCApplet can execute malicious methods.

Shareable Interface Object (SIO)

Sharable Interfaces enable JCApplets to explicitly share objects by defining sets of shared interfaces. These sharable objects are called Sharable Interface Objects (SIO). The JCApplets implementing these interfaces are usually called Server JCApplets and the JCApplets using these services are usually called Client JCApplets. Note that some Server JCApplets might also be Server JCApplets to some other Client JCApplets.

Creating a Shareable Interface Object

Creating a new SIO happens when a Server JCApplet defines a Sharable Interface ServerInterface X which extends the javacard.framework.Sharable package. The Server JCApplet then has to define a ServerApplet class A to implement the sharable interface X and create an instance of the ServerApplet class O; the ServerApplet instance now is called SIO and is registered with the JCRE.

Obtaining a Shareable Interface Object

In order now for a Client JCApplet B to access the ServerApplet instance O has to create an object reference called BO of type X, and then call the system method getSharableInterfaceObject with the AID of the server and an optional byte which selects which interface is desired (it refers to the Server JCApplets that implement more than one interface). The JCRE looks up the AID associated with the relevant Server JCApplet and forwards the request to that Server JCApplet, replacing the first argument with the client AID. The Server JCApplet A receives the request and the AID of the clie nt requesting the ServerInterface and decides whether is going to return the SIO or not. If A finds the request agreeable then a reference to O is returned, otherwise the null value is returned.Using a Shareable Interface Object

Once a SIO is obtained, JCApplet B can successfully invoke any methods from interface X on object reference BO, which then can access object O. Only part of JCApplet A is visible to JCApplet B through the firewall. When JCApplet B invokes the method on BO automatically a context switch is triggered in JCRE.

The JCRE, the Client JCApplet and the Server JCApplet, as already mentioned, reside in different contexts. In order for the SIO mechanism to work properly several context switches must occur during the object sharing process. Notice in figure 30 that the JCRE passes the client AID through the getAppletSharableInterfaceObject(AID clientAID, byte parameter) method, which is a method that belongs to JCSystem class, to the Server JCApplet and the server AID through the getSharableInterfaceObject(serverAID, byte parameter) method to the Client JCApplet.

SIO issues

The JCRE protection mechanism does not prevent malicious interface casting. Once granted an interface can be used to access all interfaces within the Server JCApplet by simply a casting the obtained interface into the desired type.

References:

[1]Zhiqun Chen, Java Card ^TM Technology for Smart Cards, June 2000, Sun Microsystems Inc.