| Runtime Environment Specification for the Java Card Platform, Version 2.2.2 |    
|
| Runtime Environment Specification for the Java Card Platform, Version 2.2.2 |
|
| C H A P T E R 6 |
|
Applet Isolation and Object Sharing |
Any implementation of the Java Card RE shall support isolation of contexts and applets. Isolation means that one applet cannot access the fields or objects of an applet in another context unless the other applet explicitly provides an interface for access. The Java Card RE mechanisms for applet isolation and object sharing are detailed in the following sections.
The applet firewall within Java Card technology is runtime-enforced protection and is separate from the Java technology protections. The Java programming language protections still apply to Java Card applets. The Java programming language ensures that strong typing and protection attributes are enforced.
Applet firewalls are always enforced in the Java Card VM. They allow the VM to automatically perform additional security checks at runtime.
The Java Card technology-based firewall (Java Card firewall) provides protection against the most frequently anticipated security concern: developer mistakes and design oversights that might allow sensitive data to be "leaked" to another applet. An applet may be able to obtain an object reference from a publicly accessible location. However, if the object is owned by an applet protected by its own firewall, the requesting applet must satisfy certain access rules before it can use the reference to access the object.
The firewall also provides protection against incorrect code. If incorrect code is loaded onto a card, the firewall still protects objects from being accessed by this code.
The Runtime Environment Specification, Java Card Platform, Version 2.2.2 specifies the basic minimum protection requirements of contexts and firewalls because the features described in this document are not transparent to the applet developer. Developers shall be aware of the behavior of objects, APIs, and exceptions related to the firewall.
Java Card RE implementers are free to implement additional security mechanisms beyond those of the applet firewall, as long as these mechanisms are transparent to applets and do not change the externally visible operation of the VM.
Firewalls essentially partition the Java Card platform's object system into separate protected object spaces called contexts. These are illustrated in FIGURE 6-1. The firewall is the boundary between one context and another. The Java Card RE shall allocate and manage a context for each Java API package containing applets[1]. All applet instances within a single Java API package share the same context. There is no firewall between individual applet instances within the same package. That is, an applet instance can freely access objects belonging to another applet instance that resides in the same package.
In addition, the Java Card RE maintains its own Java Card RE context. This context is much like the context of an applet, but it has special system privileges so that it can perform operations that are denied to contexts of applets. For example, access from the Java Card RE context to any applet instance's context is allowed, but the converse, access from an applet instance's context to the Java Card RE context, is prohibited by the firewall.
At any point in time, there is only one active context within the VM. This is called the currently active context. This can be either the Java Card RE context or an applet's context. All bytecodes that access objects are checked at runtime against the currently active context in order to determine if the access is allowed. A java.lang.SecurityException is thrown when an access is disallowed.
If access is allowed, the VM determines if a context switch is required. A context switch occurs when certain well-defined conditions, as described in Section 6.2.8, Class and Object Access Behavior, are met during the execution of invoke-type bytecodes. For example, a context switch may be caused by an attempt to access a shareable object that belongs to an applet instance that resides in a different package. The result of a context switch is a new currently active context.
During a context switch, the previous context and object owner information is pushed on an internal VM stack, a new context becomes the currently active context, and the invoked method executes in this new context. Upon exit from that method the VM performs a restoring context switch. The original context (of the caller of the method) is popped from the stack and is restored as the currently active context. Context switches can be nested. The maximum depth depends on the amount of VM stack space available.
Most method invocations in Java Card technology do not cause a context switch. For example, a context switch is unnecessary when an attempt is made to access an object that belongs to an applet instance that resides in the same package. Context switches only occur during invocation of and return from certain methods, as well as during exception exits from those methods (see Section 6.2.8, Class and Object Access Behavior).
Further details of contexts and context switching are provided in later sections of this chapter.
Any given object in the Java Card platform's object space has a context and an owner associated with it. When a new object is created, it is associated with the currently active context, but the object is owned by the applet instance within the currently active context when the object is instantiated. An object can be owned by an applet instance, or by the Java Card RE.
Following are the combined rules of context and object ownership within the firewall:
For example, assume that applets A and B are in the same package, and applet C is in another package. A and B therefore belong to the same context: 1. C belongs to a different context: 2. For an illustration of this situation, see FIGURE 6-2.
If context 1 is the currently active context, and a method m1 in an object owned by applet A is invoked, no context switch occurs. If method m1 invokes a method m2 in an object owned by applet B, again no context switch occurs (in spite of the object "owner" change), and no firewall restrictions apply.
However, if the method m2 now calls a method m0 in an object owned by applet C, firewall restrictions apply and, if access is allowed, a context switch shall occur. Upon return to method m2 from the method m0, the context of applet B is restored.
Keep the following points in mind:
In general, an object can only be accessed by its owning context, that is, when the owning context is the currently active context. The firewall prevents an object from being accessed by another applet in a different context.
In implementation terms, each time an object is accessed, the object's owner context is compared to the currently active context. If these do not match, the access is not performed and a SecurityException is thrown.
An object is accessed when one of the following bytecodes is executed using the object's reference:
getfield, putfield, invokevirtual, invokeinterface,
athrow, <T>aload, <T>astore, arraylength, checkcast, instanceof
<T> refers to the various types of array bytecodes, such as baload and sastore.
This list includes any special or optimized forms of these bytecodes implemented in the Java Card VM, such as getfield_b and getfield_s_this.
Transient objects of CLEAR_ON_RESET type behave like persistent objects in that they can be accessed only when the currently active context is the object's owning context (the currently active context at the time when the object was created).
Transient objects of CLEAR_ON_DESELECT type can only be created or accessed when the currently active context is the context of the currently selected applet. If any of the makeTransient factory methods of JCSystem class are called to create a CLEAR_ON_DESELECT type transient object when the currently active context is not the context of the currently selected applet (even if the attempting context is that of an active applet instance on another logical channel), the method shall throw a java.lang.SystemException with reason code of ILLEGAL_TRANSIENT. If an attempt is made to access a transient object of CLEAR_ON_DESELECT type when the currently active context is not the context of the currently selected applet (even if the attempting context is that of an active applet instance on another logical channel), the Java Card RE shall throw a java.lang.SecurityException.
Applets that are part of the same package share the same context. Every applet instance from a package shares all its object instances with all other instances from the same package. This includes transient objects of both CLEAR_ON_RESET type and CLEAR_ON_DESELECT type owned by these applet instances.
The transient objects of CLEAR_ON_DESELECT type owned by any applet instance in the same package shall be accessible when any of the applet instances is the currently selected applet.
Instances of classes (objects) are owned by contexts. Classes themselves are not. There is no runtime context check that can be performed when a class static field is accessed. Neither is there a context switch when a static method is invoked. Similarly, invokespecial causes no context switch.
Public static fields and public static methods are accessible from any context: Static methods execute in the same context as their caller.
Objects referenced in static fields are just regular objects. They are owned by whomever created them and standard firewall access rules apply. If it is necessary to share them across multiple contexts, these objects need to be Shareable Interface Objects (SIOs), see Section 6.2.4, Shareable Interfaces.
Of course, the conventional Java technology protections are still enforced for static fields and methods. In addition, when applets are installed, the Installer verifies that each attempt to link to an external static field or method is permitted. Installation and specifics about linkage are beyond the scope of this specification.
The Java Card RE may perform optional runtime checks that are redundant with the constraints enforced by a verifier. A Java Card VM may detect when code violates fundamental language restrictions, such as invoking a private method in another class, and report or otherwise address the violation.
The applet firewall confines an applets actions to its designated context. To enable applets to interact with each other and with the Java Card RE, some well-defined yet secure mechanisms are provided so one context can access an object belonging to another context.
These mechanisms are provided in the Java Card API and are discussed in the following sections:
Secure computer systems must have a way for non-privileged user processes (that are restricted to a subset of resources) to request system services performed by privileged "system" routines.
In the Java Card API, this is accomplished using Java Card RE Entry Point Objects. These are objects owned by the Java Card RE context, but they are flagged as containing entry point methods.
The firewall protects these objects from access by applets. The entry point designation allows the methods of these objects to be invoked from any context. When that occurs, a context switch to the Java Card RE context is performed. These methods are the gateways through which applets request privileged Java Card RE system services. The requested service is performed by the entry point method after verifying that the method parameters are within bounds and all objects passed in as parameters are accessible from the caller's context.
Following are the two categories of Java Card RE Entry Point Objects:
Like all Java Card RE Entry Point Objects, methods of temporary Java Card RE Entry Point Objects can be invoked from any context. However, references to these objects cannot be stored in class variables, instance variables or array components. The Java Card RE detects and restricts attempts to store references to these objects as part of the firewall functionality to prevent unauthorized reuse.
The APDU object and all Java Card RE owned exception objects are examples of temporary Java Card RE Entry Point Objects.
Like all Java Card RE Entry Point Objects, methods of permanent Java Card RE Entry Point Objects can be invoked from any context. Additionally, references to these objects can be stored and freely re-used.
Java Card RE owned AID instances are examples of permanent Java Card RE Entry Point Objects.
The Java Card RE is responsible for the following tasks:
|
Note - Only the methods of these objects are accessible through the firewall. The fields of these objects are still protected by the firewall and can only be accessed by the Java Card RE context. |
Only the Java Card RE itself can designate Entry Point Objects and whether they are temporary or permanent. Java Card RE implementers are responsible for implementing the mechanism by which Java Card RE Entry Point Objects are designated and how they become temporary or permanent.
The global nature of some objects requires that they be accessible from any context. The firewall would ordinarily prevent these objects from being used in a flexible manner. The Java Card VM allows an object to be designated as global.
All global arrays are temporary global array objects. These objects are owned by the Java Card RE context, but can be accessed from any context. However, references to these objects cannot be stored in class variables, instance variables or array components. The Java Card RE detects and restricts attempts to store references to these objects as part of the firewall functionality to prevent unauthorized reuse.
For added security, only arrays can be designated as global and only the Java Card RE itself can designate global arrays. Because applets cannot create them, no API methods are defined. Java Card RE implementers are responsible for implementing the mechanism by which global arrays are designated.
At the time of publication of this specification, the only global arrays required in the Java Card API are the APDU buffer and the byte array input parameter (bArray) to the applet's install method.
Because it is the "system" context, the Java Card RE context has a special privilege. It can invoke a method of any object on the card. For example, assume that object X is owned by applet A. Normally, only the context of A can access the fields and methods of X. But the Java Card RE context is allowed to invoke any of the methods of X. During such an invocation, a context switch occurs from the Java Card RE context to the context of the applet that owns X.
Again, because it is the "system" context, the Java Card RE context can access fields and components of any object on the card including CLEAR_ON_DESELECT transient objects owned by the currently selected applet.
|
Note - The Java Card RE can access both methods and fields of X. Method access is the mechanism by which the Java Card RE enters the context of an applet. Although the Java Card RE could invoke any method through the firewall, it shall only invoke the select, process, deselect, and getShareableInterfaceObject (see Section 6.2.7.1, Applet.getShareableInterfaceObject(AID, byte) Method) methods defined in the Applet class, and methods on the objects passed to the API as parameters. |
The Java Card RE context is the currently active context when the VM begins running after a card reset. The Java Card RE context is the "root" context and is always either the currently active context or the bottom context saved on the stack.
Shareable interfaces are a feature in the Java Card API to enable applet interaction. A shareable interface defines a set of shared interface methods. These interface methods can be invoked from one context even if the object implementing them is owned by an applet in another context.
In this specification, an object instance of a class implementing a shareable interface is called a Shareable Interface Object (SIO).
To the owning context, the SIO is a normal object whose fields and methods can be accessed. To any other context, the SIO is an instance of the shareable interface, and only the methods defined in the shareable interface are accessible. All other fields and methods of the SIO are protected by the firewall.
Shareable interfaces provide a secure mechanism for inter-applet communication, as described in the following sections.
1. To make an object available for sharing with another applet in a different context, applet A first defines a shareable interface, SI. A shareable interface extends the interface javacard.framework.Shareable. The methods defined in the shareable interface, SI, represent the services that applet A makes accessible to other applets.
2. Applet A then defines a class C that implements the shareable interface SI. C implements the methods defined in SI. C may also define other methods and fields, but these are protected by the applet firewall. Only the methods defined in SI are accessible to other applets.
3. Applet A creates an object instance O of class C. O belongs to applet A, and the firewall allows A to access any of the fields and methods of O.
1. To access applet A's object O, applet B creates an object reference SIO of type SI.
2. Applet B invokes a special method (JCSystem.getAppletShareableInterfaceObject, described in Section 6.2.7.2, JCSystem.getAppletShareableInterfaceObject Method) to request a shared interface object reference from applet A.
3. Applet A receives the request and the AID of the requester (B) via Applet.getShareableInterfaceObject, and determines whether it will share object O with applet B. A's implementation of the getShareableInterfaceObject method executes in A's context.
4. If applet A agrees to share with applet B, A responds to the request with a reference to O. As this reference is returned as type Shareable, none of the fields or methods of O are visible.
5. Applet B receives the object reference from applet A, casts it to the interface type SI, and stores it in object reference variable SIO. Even though SIO actually refers to A's object O, SIO is an interface of type SI. Only the shareable interface methods defined in SI are visible to B. The firewall prevents the other fields and methods of O from being accessed by B.
In this sequence, applet B initiates communication with applet A using the special system method in the JCSystem class to request a Shareable Interface Object from applet A. Once this communication is established, applet B can obtain other Shareable Interface Objects from applet A using normal parameter passing and return mechanisms. It can also continue to use the special JCSystem method described above to obtain other Shareable Interface Objects.
1. Applet B can request service from applet A by invoking one of the shareable interface methods of SIO. During the invocation the Java Card VM performs a context switch. The original currently active context (B) is saved on a stack and the context of the owner (A) of the actual object (O) becomes the new currently active context. A's implementation of the shareable interface method (SI method) executes in A's context.
2. The SI method can determine the AID of its client (B) via the JCSystem.getPreviousContextAID method. This is described in Section 6.2.5, Determining the Previous Context. The method determines whether or not it will perform the service for applet B.
3. Because of the context switch, the firewall allows the SI method to access all the fields and methods of object O and any other object in the context of A. At the same time, the firewall prevents the method from accessing non-shared objects in the context of B.
4. The SI method can access the parameters passed by B and can provide a return value to B.
5. During the return, the Java Card VM performs a restoring context switch. The original currently active context (B) is popped from the stack, and again becomes the currently active context.
6. Because of the context switch, the firewall again allows B to access any of its objects and prevents B from accessing non-shared objects in the context of A.
When an applet calls JCSystem.getPreviousContextAID, the Java Card RE shall return the instance AID of the applet instance active at the time of the last context switch.
The Java Card RE context does not have an AID. If an applet calls the getPreviousContextAID method when the context of the applet was entered directly from the Java Card RE context, this method returns null.
If the applet calls getPreviousContextAID from a method that may be accessed either from within the applet itself or when accessed via a shareable interface from an external applet, it shall check for null return before performing caller AID authentication.
A shareable interface is simply one that extends (either directly or indirectly) the tagging interface javacard.framework.Shareable. This Shareable interface is similar in concept to the Remote interface used by the RMI facility, in which calls to the interface methods take place across a local/remote boundary.
Interfaces extending the Shareable tagging interface have this special property: Calls to the interface methods take place across Java Card platform's applet firewall boundary by means of a context switch.
The Shareable interface serves to identify all shared objects. Any object that needs to be shared through the applet firewall shall directly or indirectly implement this interface. Only those methods specified in a shareable interface are available through the firewall.
Implementation classes can implement any number of shareable interfaces and can extend other shareable implementation classes.
Like any Java platform interface, a shareable interface simply defines a set of service methods. A service provider class declares that it "implements" the shareable interface and provides implementations for each of the service methods of the interface. A service client class accesses the services by obtaining an object reference, casting it to the shareable interface type, and invoking the service methods of the interface.
The shareable interfaces within the Java Card technology shall have the following properties:
Inter-applet communication is accomplished when a client applet invokes a shareable interface method of a SIO belonging to a server applet. For this to work, there must be a way for the client applet to obtain the SIO from the server applet in the first place. The Java Card RE provides a mechanism to make this possible. The Applet class and the JCSystem class provide methods to enable a client to request services from the server.
This method is implemented by the server applet instance. It shall be called by the Java Card RE to mediate between a client applet that requests to use an object belonging to another applet, and the server applet that makes its objects available for sharing.
The default behavior shall return null, which indicates that an applet does not participate in inter-applet communication.
A server applet that is intended to be invoked from another applet needs to override this method. This method should examine the clientAID and the parameter. If the clientAID is not one of the expected AIDs, the method should return null. Similarly, if the parameter is not recognized or if it is not allowed for the clientAID, the method also should return null. Otherwise, the applet should return an SIO of the shareable interface type that the client has requested.
The server applet need not respond with the same SIO to all clients. The server can support multiple types of shared interfaces for different purposes and use clientAID and parameter to determine which kind of SIO to return to the client.
The JCSystem class contains the method getAppletShareableInterfaceObject, which is invoked by a client applet to communicate with a server applet.
The Java Card RE shall implement this method to behave as follows:
1. The Java Card RE searches its internal applet table which lists all successfully installed applets on the card for one with serverAID. If not found, null is returned.
2. If the server applet instance is not a multiselectable applet instance and is currently active on another logical channel, a SecurityException is thrown. See Section 4.2, Multiselectable Applets.
3. The Java Card RE invokes this applet's getShareableInterfaceObject method, passing the clientAID of the caller and the parameter.
4. A context switch occurs to the server applet, and its implementation of getShareableInterfaceObject proceeds as described in the previous section. The server applet returns a SIO (or null).
5. getAppletShareableInterfaceObject returns the same SIO (or null) to its caller.
For enhanced security, the implementation shall make it impossible for the client to tell which of the following conditions caused a null value to be returned:
A static class field is accessed when one of the following Java programming language bytecodes is executed:
getstatic, putstatic
An object is accessed when one of the following Java programming language bytecodes is executed using the object's reference:
getfield, putfield, invokevirtual, invokeinterface, athrow,
<T>aload, <T>astore, arraylength, checkcast, instanceof
<T> refers to the various types of array bytecodes, such as baload, sastore, etc.
This list also includes any special or optimized forms of these bytecodes that can be implemented in the Java Card VM, such as getfield_b and getfield_s_this.
Prior to performing the work of the bytecode as specified by the Java VM, the Java Card VM will perform an access check on the referenced object. If access is denied, a java.lang.SecurityException is thrown.
The access checks performed by the Java Card VM depend on the type and owner of the referenced object, the bytecode, and the currently active context. They are described in the following sections.
getstatic, putstatic
<T>aload, <T>astore, arraylength, checkcast, instanceof
getfield, putfield
invokevirtual
invokeinterface
invokeinterface
athrow
checkcast, instanceof
checkcast, instanceof
checkcast, instanceof
|
Note - The method access behavior of global arrays is identical to that of Java Card RE Entry Point Objects. |
invokevirtual
| Runtime Environment Specification for the Java Card Platform, Version 2.2.2 | 3-8-06 |
|
Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.