Restricting Method Access through a SIO

Normally in Java [ 1 ], it would be possible to access public methods across packages. Therefore, one could use public methods in other packages without a need for a sharing mechanism.

But this poses a problem for Java card, because the applet entry points are necessarily public, yet we must restrict access to them to prevent applets from running other applet methods without permission. So the JCRE does not permit any method to be invoked in other applets, except through the SIO mechanism. This prevents obvious hacks, such as casting an object reference to gain access to all of the public object methods, bypassing the restriction of the interface.

Applet Context

The object system in a Java Card is partitioned into separate protected object spaces referred to as contexts. All applets in a given package share the same context, and are prohibited from accessing objects in a different context due to firewalls which are enforced by the Java Card Runtime Environment (JCRE) [ 8 ]. The JCRE is able to access objects in any context, and global arrays such as the APDU buffer (which are owned by the JCRE) can be accessed by applets in any context.

Shareable Interface Objects (SIO)

Shareable interfaces are a new feature in the Java Card 2.1 API [ 9 ] to enable applets to explicitly share objects by defining a set of shared interface methods. Such shareable objects are called Shareable Interface Objects (SIO). We can think of those applets which provide SIO as server applets (since they will provide access to their services via the SIO), and those applets which use the SIO of another applet as client applets. Note that an applet may be a server to some applets, and yet a client of other applets.

Creating a SIO

In order to create a new SIO, a server applet A must first define a shareable interface X, which extends the interface javacard.framework.Shareable. Applet A then defines a class C that implements the shareable interface X, and creates an instance O of class C. Object O is now a SIO. An instance of applet A with an AID is registered with the JCRE, as shown in Figure See Creating and accessing a SIO. , step 1; this AID is subsequently used by client applications to specify the server applet.

Obtaining a SIO

A client applet must obtain this SIO in order to access object O. The process of a client obtaining an SIO is shown in Figure See Creating and accessing a SIO. , step 2.

In order for client applet B to access object O, applet B must create an object reference BO of type X, and then call a system method getAppletShareableInterfaceObject with the AID of the server, and an optional byte which selects which interface is desired (for those servers with more than one interface available). The JCRE looks up the server applet associated with that AID, and forwards the request to the server, replacing the first argument with the client AID. Server applet A receives the request and the AID of the requester (applet B), and determines whether or not it will share object O with applet B. If applet A finds the request agreeable, then a reference to O is provided; otherwise, null is returned. The JCRE forwards this reference to Applet B. Applet B receives this reference (which is of type SIO), casts it to type X, and stores it in BO.

Using a SIO

Once a SIO has been obtained, applet B can invoke any methods from interface X on object reference BO, which then accesses object O. However, this is not as straightforward as it might seem, due to the firewalls.

Figure See Creating and accessing a SIO. , step 3 shows the client applet B on the left, and the server applet A on the right, with a firewall in between. Note that the only part of applet A that is visible through the firewall is object O. When applet B invokes a method on BO, a context switch is triggered in the JCRE, leading to the situation in Figure See Server has no access to client data. . At this point, applet B is not visible at all; the only data visible from B are the arguments passed on the stack (and the global APDU array).

Note than it is pointless to pass object references on the stack, since the firewall will prevent object O (in Applet A) from using them, due to the context switch. However, object O can access any allowed data in Applet A as shown in Figure See Server has no access to client data. .

Access To All Interface Methods Of A Class

The JCRE protection mechanisms do not prevent interfaces from being maliciously cast into other kinds of interfaces that might exist for a given object.

Once granted any interface, it is possible to access all of the shareable interface methods of an object via an explicit cast (not just the interface granted to a particular client). So if my server applet has two interfaces, intended for different kinds of clients, a client who legitimately obtains one interface, could cast it into the other interface, and gain access to unintended methods.

For example, suppose an applet ABCLoyaltyApplet has two different services that it intends to offer exclusively to two different clients, i.e. grantFequentFlyerPoints for client Airline, and grantLoyaltyPoints for client Purse. Both of these services are accessible to respective clients via different published interfaces, but both are defined in the Applet class, as illustrated in Code See Server defines and grants access to SIO. .

package AppABC;

import javacard.framework.*;

public interface ABCLoyaltyAirlineInterface extends Shareable {

public void grantFrequentFlyerPoints(int amount);

}

public interface ABCLoyaltyPurseInterface extends Shareable {

public void grantLoyaltyPoints(int amount);

}

public class ABCLoyaltyApplet extends

javacard.framework.Applet implements

ABCLoyaltyAirlineInterface, ABCLoyaltyPurseInterface {

protected int loyaltyPoints;

protected int frequentFlyerPoints;

/* A service only for client 'Airline' */

public void grantFrequentFlyerPoints(int amount) {

frequentFlyerPoints += amount;

}

/* A service only for client 'Purse' */

public void grantLoyaltyPoints(int amount) {

loyaltyPoints += amount;

}

public ABCLoyaltyApplet() throws Exception {

loyaltyPoints = 0;

frequentFlyerPoints = 0;

/* Add code to initialize potential client AIDs ... */

register();

}

public void process() {

/* Various code specific to services for this applet,
such as point redemption code ... */

}

public Shareable getShareableInterfaceObject(

AID clientAID, byte parameter) {

if (clientAID.equals(purseAppletAID))

return (ABCLoyaltyPurseInterface) this;

else if (clientAID.equals(airlineAppletAID))

return (ABCLoyaltyAirlineInterface) this;

else

return null;

}

}

Server defines and grants access to SIO

If the Purse client was aware of the Airline client interface, it could make use of the interface it had been granted by the server applet to grant loyalty points, and instead use the grantFrequentFlyerPoints interface (intended for client Airline) to maliciously add unwarranted frequent flier points, as shown in Code See Client compromises SIO. .

package AppPurse;

import javacard.framework.*;

import AppABC.*;

public class PurseApplet extends javacard.framework.Applet {

private int value;

private ABCLoyaltyPurseInterface abcSIO;

public PurseApplet() throws Exception {

value = 0;

abcSIO = (ABCLoyaltyPurseInterface)

JCSystem.getAppletSharableInterfaceObject(

abcLoyaltyAppletAID, (byte)0);

register();

}

public void use(int amount) {

value -= amount;

if (abcSIO != null)

abcSIO.grantLoyaltyPoints(amount);

/* Attempt to 'hack' by using an SIO to access the Airline

* applet's exclusive service grantFrequentFlyerPoints */

ABCLoyaltyAirlineInterface hackSIO =

(ABCLoyaltyAirlineInterface)

JCSystem.getAppletSharableInterfaceObject(

ABCLoyaltyAppletAID, (byte)0);

if (hackSIO != null)

hackSIO.grantFrequentFlyerPoints(amount);

}

/* Other methods follow for adding points to the purse ... */

}

Client compromises SIO

Unfortunately, the JCRE is unable to prevent such access, since it does not violate the restriction of access only via shareable interfaces.

This problem can be eliminated by using separate delegate objects for each shared interface, and have the delegate objects handle or redirect the calls to the intended object. Another solution is to verify the AID of the caller upon each attempt to access a method in the server.

Furthermore, it is not possible to grant a client access to only certain methods of an interface. If such granularity is required, further delegates and interfaces must be used to separate the particular methods that are to be allowed for each applet. Alternatively, this granularity can be provided by having each method individually check the client AID, to determine whether the client should have access to that particular method.

AID Impersonation

The decision by a server applet to grant access to an object must be based solely on the AID of the requesting applet; no other information is available to the server applet. The intended use is clearly to allow certain interfaces to be granted only to particular client applets, as denoted by their unique AIDs. However, it is possible to maliciously set the AID of a rogue applet to be the same as the AID of a client applet known to have access to a particular interface. The rogue applet is then loaded instead of the applet that legitimately owns the AID. Once loaded, the rogue applet can request the desired interface. The server applet, having only the AID for reference, will naturally grant this request, since the AID matches the required AID for the interface. The rogue applet can then freely use the interface for malicious purposes.

This is a critical security problem. Current solutions to this problem require restrictions on applet loading, such as only allowing applets to be loaded that are signed by trusted sources. However, this approach greatly reduces the flexibility of Java Cards; for example, this prevents users from loading Java Card programs of their own devising.

Future Reference To Shared Objects

Granting access by AID necessarily assumes that the server applet that wishes to share the object has foreknowledge of all AIDs of all client applets that are to be loaded which will share particular interfaces. This is a difficult requirement for any kind of server. But what about other client applets that are written afterwards which legitimately need access to the shared object? Such applets are excluded from access to the object, since the server can only grant access based on the AID list that the server had when it was loaded. This necessitates rewriting and reissuing the server applet such that the new AIDs are included, which may pose an insurmountable hurdle when the server applet is already widely distributed.

Inability To Pass Object Parameters

The inability to pass object parameters between applets can make many tasks cumbersome. For example, supposes as a client needs to pass an object when invoking a method on a server applet so that the server can manipulate and return the object, as in encrypting a buffer. In this case, the object might contain a field specifying the method of encryption, a key array, and a data array. But as stated earlier, the firewall prevents the server applet from accessing this data, even if an object reference from the client is provided.

One might envision a work around to this problem where the server A gets a shared interface on an object in client B in order to read the object data as shown in Figure See Server access blocked by firewall. .

Server applet registering its delegate

Note that the only novel aspect of this applet is when it creates and registers its delegate, as illustrated in Figure See Creating and accessing a delegate. , step 1. Whenever a server applet wishes to allow access to another applet, a delegate must be written which exposes the desired methods. Such a delegate is shown in Code See Server delegate. .

package AppABC;

import OSResources.*;

public class ABCLoyaltyDelegate extends Delegate {

final static byte CHALLENGE_LENGTH = (byte) 64;

final static byte FAILURES_ALLOWED = (byte) 2;

private byte[] secret1 = { /* initializing code ...*/ };

private byte[] secret2 = { /* initializing code ...*/ };

private ABCLoyaltyApplet myApplet;

private ChallengePhrase cp;

private ChallengePhrase checkcp;

private byte grantTriesRemaining = FAILURES_ALLOWED;

private byte useTriesRemaining = FAILURES_ALLOWED;

protected ABCLoyaltyDelegate(ABCLoyaltyApplet a) {

myApplet = a;

cp = new ChallengePhrase(CHALLENGE_LENGTH);

checkcp = new ChallengePhrase(CHALLENGE_LENGTH);

}

public boolean grantPoints(int amount) {

// do some checking

if (myApplet != null) {

ABCLoyaltyInterface pD = (ABCLoyaltyInterface)

OSystem.getDelegate(

OSystem.getPreviousContextAID());

if (pD != null) {

/* Create new random challenge phrase */

checkcp.setPhrase(cp.randomize());

/* Get client response to phrase */

byte[] response = pD.loyaltyChallenge(cp);

byte[] r = checkcp.encrypt(secret1);

if (isEqual(response,r)) {
/* See if client gave the correct response */

grantTriesRemaining = FAILURES_ALLOWED;

myApplet.grantPoints(amount);

return true;

} else {

if(--grantTriesRemaining == 0) myApplet = null;

return false;

}

}

}

return false;

}

public boolean usePoints(int amount) {

/* Access to this method uses secret2, for different

clients, but is otherwise similiar to grantPoints ... */

}

public int readPoints() {

if (myApplet != null)

return myApplet.readPoints();

else

return 0;

}

}

Server delegate

This delegate is registered with the AID of the server applet at the time the applet is instantiated on the Java Card. At this point, this delegate is publicly accessible by any other applet. This particular delegate defines the interface ABCLoyaltyInterface shown in Code See Server defines interface that each client must provide to handle challenge/response. , which must be implemented by client applications. The reasons for this interface are discussed in detail in Section See Delegate Security. .

package AppABC;

import OSResources.*;

public interface ABCLoyaltyInterface{

public byte[] loyaltyChallenge(ChallengePhrase cp);

}

Server defines interface that each client must provide to handle challenge/response

Client applet invoking server method

To handle the challenge/response, the client must supply a delegate as shown in Code See Client challenge/response delegate. that the server will call to perform the necessary encryption with the challenge phrase. This client delegate must implement the ABCLoyaltyInterface, as defined by the server applet. The delegate may not actually perform the encryption, but may instead pass the challenge/response request to the client applet for processing. This allows the delegate to avoid holding the shared secret, reducing the security risk.

package AppPurse;

import OSResources.*;

import AppABC.*;

public class PurseDelegate extends Delegate implements ABCLoyaltyInterface{

private PurseApplet myApplet;

protected PurseDelegate(PurseApplet a) {

myApplet = a;

}

public byte[] loyaltyChallenge(ChallengePhrase cp) {

if (myApplet != null)

return(myApplet.loyaltyChallenge(cp));

else

return null;

}

}

Client challenge/response delegate