Abstract

Introduction

The Java [1] environment possesses a number of features that make it's adoption to smart cards attractive. A reasonable subset of the Java environment can constitute the base for a multifunction smart card platform. Applications can rely on standardized APIs and may be compiled into an intermediate bytecode representation enabling execution by a Java virtual machine. The simplicity and wide acceptance of the Java programming language is attractive to the smart card community where no standard language suitable for developing multifunction smart card applications has yet been established. Finally, they can benefit from the platform independence and security features provided by the Java environment.

However, Java's platform independence places significant constraints on the specific target platform. Java provides automatic memory management and does not foresee any means of manual memory control. In particular, it does not provide explicit support for persistent objects. In contrast, a smart card application requires random access to both transient and persistent memory. The limited amount of the memory resources available and their physical characteristics require simple and transparent manipulation of objects in both types of memory by the application. Hence, one of the challenges in the design of the Java Card is adapting Java's memory model to the constraints of smart card hardware.

Systems that require an intimate composition of long-lived data and programs are called persistent application systems [6] . Since applications in a Java Card are coupled with data, it enables the card to be a persistent application system. Orthogonal persistent systems [6] specially provide an appealing programming model for application development. Current smart card hardware typically offers around 16K bytes of persistent memory and nearly 1K bytes of transient memory. Given such constraints a Java Card cannot provide the same degree of transparency and orthogonality as an orthogonal persistent system. While it may not be desirable to completely hide the lifetimes of objects in the Java Card, it could be done in tandem with handing some control to the programmer. The necessary restrictions must be carefully chosen to provide a high degree of programmer convenience while enabling a reasonable utilization of the resources available in a smart card.

In this paper, we present the choices underlying different Java Card memory models. In particular, the differences, advantages, and drawbacks of each are highlighted. The notion of the transient and persistent environment is introduced as a solution toward simplifying Java programming on smart cards, data sharing, and support for efficient garbage collection.

The paper is organized as follows. Section [Smart Card Memory and Java Card Basics] describes the typical memory layout in smart cards and introduces the basic execution model of applications in a Java Card. Section [Object Lifetimes] lists the different lifetimes of objects which result from the given execution model and presents plausible allocation and placement strategies. Section [Persistent Systems] discusses concepts underlying persistent systems in general and their applicability to smart cards. Section [Proposed Approaches] outlines the approaches to introduce transience and persistence in the Java Card which were discussed during the Java Card specification process. Section [Transient Environment] introduces the basic concepts and usage of transient and persistent environments. Section [Implications] discusses the implications of the transient environment on security, memory reclaiming and object sharing contrasting it with the approach taken by the Java Card 2.1 Specification. Finally, we present our conclusions in Section [Conclusions and Future Work] .

Smart Card Memory and Java Card Basics

Current and upcoming smart card hardware provide very limited storage capabilities. The memory resources typically consist of Read Only Memory (ROM), Random Access Memory (RAM) and Electrically Erasable Programmable Read Only Memory (EEPROM). EEPROM is used to store long-lived data. In contrast, RAM loses its contents after a power loss and is thus only available for temporary storage. Both EEPROM and RAM can be read and written; however, write operations to EEPROM are typically thirty times slower than to RAM and the possible number of EEPROM writes over the lifetime of a card is physically limited. Another difference lies in the physical size of each of these memory types. The physical size constraints on a smart card dictate RAM/EEPROM ratios often resulting in considerably smaller RAM in comparison to EEPROM.

A typical Java Card design places the operating system, the virtual machine and one or more applications in ROM. EEPROM is used to store applications which have been loaded after a card has been issued. Java Card applications, also referred to as applets, correspond to Java packages and are not loaded as regular Java class files [2] . Instead, a converter coalesces all the class files that comprise the package into a compact representation with minimal symbolic information. The converted code is linked on the card against the system classes and other required packages. It is up to the converter and the virtual machine to assure the Java language protection rules for downloaded code.

Once downloaded the applet is installed in a separate step. The virtual machine calls the mandatory install method which allocates required resources and registers a persistent object, the applet instance, with the Java Card runtime environment for future invocations. Applet execution is tailored around the server centric nature of a smart card and takes place during sessions. When a card is placed in a card acceptance device (CAD) the runtime is initialized and awaits input. Communication is handled by the underlying operating system. An external application (the client) initiates a session with a specific applet (the server) by sending a select command to it. The runtime marks the selected applet active and forwards the command by invoking the applet's select method. Each command sent by the client hence is forwarded and handled by invoking the applet's process method. The applet processes the command and prepares a response which is sent after the applet has returned from its invocation. A session ends when a new select command is received. The runtime deselects the currently selected applet by invoking its deselect method and initiates a session with the newly selected applet.

During a session, an applet can access both the services of linked packages and services exported by other applets. A client applet can ask a server applet for a service by obtaining a reference to a shared object and invoke it freely during the session. When invoked, the server object can check the identity of the caller and grant the requested service. Note that the Java stack is completely unwound upon cessation of communication with the CAD.

Object Lifetimes

The object allocation, placement and invocation model influences the lifetime of objects in the system. Object lifetimes in persistent systems fall into one of the following general categories [4] :

1. Transient (temporary) results in expression evaluations and local variables in procedure activation.
   Data in this category resides in the individual bytecode frames and is of a primitive type. Java and Java Card do not allow the explicit allocation of objects on the stack which is especially limited on the Java Card. The stack contents must only be valid during applet invocation in a session.
2. Instance variables, class variables and heap items whose extent is different from their scope.
   Among these items are especially objects which must be accessible during applet invocation or the entire session. They must not be saved in case of power loss. For example, objects of this type are used to store the state of the communication, session keys or the communication buffer.
3. Data that exists between two program executions.
   Objects in this category cover data which must be stored in EEPROM to survive a power loss.
4. Data that exists between different versions of a program or data that outlives the program.
   The Java Card environment currently does not address this category.

The object lifetime categories and the memory types in smart cards give rise to the three following allocation strategies for objects in a Java Card:

1. Objects are instantiated in RAM and are serialized by the applet into EEPROM via a file system etc.
   This strategy resembles the regular Java environment and of early Java Cards [11] . The applet instantiates objects in RAM and stores their data with the help of specific API functions into the long-term store. Each applet has to implement the functionality required for serializing and deserializing its state. There are two drawbacks with this approach. First, the working set of an applet could be larger than the available RAM. Second, the underlying operating system must manage the contents of the long-term store, i.e., it must provide a name binding with the serialized state and a means of checking the access rights of applets.
2. Object instantiation is always in EEPROM.
   If objects are instantiated in EEPROM the language protection rules can be used to verify the integrity of the system.This provides an uniform access to all the objects of an applet. This strategy is attractive since most data manipulations are performed on long-lived data. However performing all allocations in EEPROM may never be feasible since writes to EEPROM are extremely expensive and it's life limited.
3. Object instantiation is in RAM and EEPROM.
   The instantiation of objects with limited lifetime in RAM saves space in EEPROM, increases the performance and adds additional security in case of sensitive objects like session keys which must get lost in case of power loss. Long-lived data is placed appropriately in EEPROM. The utilization of both stores for object allocation and manipulation should still aim at the benefits of object instantiations only in EEPROM, i.e., allowing uniform access to objects and relying on Java's language protection rules.

Persistent Systems

The Java environment is designed as a transient programming environment. The Java Card environment however must support access to both transient and persistent objects within Java language expressions. Persistent programming languages and environments strive to enable such manipulations transparently [5] . Language expressions manipulating persistent data are made to appear similar to expressions operating on data with shorter lifetimes. Other than transparency, persistent systems provide different degrees of data type orthogonality. Full orthogonality expresses the demand that any instance can be persistent regardless of its type and that its lifetime may not be expressed at instantiation time [6] . In any case, the lifetime of data must be easily expressible by the programmer and persistent data must be identifiable as such by a simple and consistent mechanism. The principles of transparency, orthogonality and identification serve as the basis for persistent systems.

Orthogonal persistent systems offer the highest degree of transparency and orthogonality and were hence chosen as the basic architecture for adding persistence to Java in the PJama project [7] . PJama allows any instance to be persistent regardless of its type and any object is identified as being persistent by verifying reachabilty from a persistent root set. Persistent objects are always manipulated in RAM and are lazily stabilized into the long-term store.

Proposed Approaches

In a Java Card objects allocated in RAM must be immediately copied into EEPROM when assigned to a persistent reference. Otherwise, unexpected power losses will lead to illegal references and loss of data integrity. Since the working set of the applet can exceed the available RAM it can only be used as a cache. However, the extremely limited resources on a smart card make it impossible to determine a suitable caching scheme which delivers sufficient results without assistance from the programmer. It is worth noting that even large orthogonal systems tend to be inefficient [10] .

To counter inefficiency and provide control to the programmer, some persistent systems limit the extent of one or more principles of orthogonal persistent systems, i.e., they may restrict transparency or orthogonality [5] . The programming style is affected as little as possible. This is crucial for the Java Card which touts the simple and popular programming style of Java. Hence changes to the language to support persistence are prohibited. Introducing lifetime aware bytecode instructions to the virtual machine must be avoided as they would hinder upgrading to another memory model.

Transient Data (Java Card 2.1 Specification)

Since the main requirement is to disable storing sensitive and data requiring fast access to long-term store a memory model may allocate data associated with certain objects in short-term store. The current Java Card 2.1 Specification follows this approach and is based on two basic design decisions. Firstly, applets must be designed to not expect any form of memory reclamation on the card. Applets are required to instantiate needed data at installation time and reuse it throughout their lifetime. Unreferenced data cannot be expected to be reclaimed and therefore new allocations may fail. The second design decision is to avoid dangling pointers in case of sudden power loss by expecting all objects to be referenced persistently via EEPROM. Only the data of arrays of primitive types can be allocated in RAM. As the new bytecodes allocate objects in the persistent store special static factory methods makeTransientBooleanArray, makeTransientByteArray, and makeTransientShortArray are used for allocating only the object header in EEPROM and the data in RAM.

RAM usage between Applets

Although the data part of such objects in transient memory is lost at power loss, the location and size information in the persistent header reserves its space over multiple card sessions. However, as RAM is shared by all available applets on the card it must be possible to limit the reservation of the transient data to less than a whole card session. Otherwise the entire RAM may be reserved after the installation of a few applets allocating transient data. The factory methods therefore take an additional argument, the duration identifier which either allows instantiations of arrays with ``clear on reset'' or ``clear on deselect'' duration. Arrays with the ``clear on reset'' duration will keep their values during the whole card session, i.e., their contents are not reset between multiple applet selections during a card session. The value of arrays with the ``clear on deselect'' duration are always cleared before their owning applet is selected. This coarse grained lifetime specification allows overlapping the ``clear on deselect'' RAM space across different applets. Figure See RAM usage between Applets. shows an organization of the transient memory using this overlap. RAM is split into two segments, the ``clear on reset'' and ``clear on deselect'' spaces which grow in opposite directions. Each newly allocated "clear on reset" array gets allocated from the globally reserved "clear on reset" space while each newly allocated "clear on deselect" array gets allocated at the beginning of the per applet "clear on deselect" space. The runtime must ensure that these two spaces do not overlap.

A consequence of this design is that the entire ``clear on deselect'' space must be cleared at once before a new applet is selected. If a package contains more than one applet the ``clear on deselect'' space has to be shared by all applets as they are allowed to share their transient arrays as per the Java Card 2.1 Specification. On the other hand, an applet shall allocate all its needed data, especially its worst case usage of transient data, at install time. This can easily lead to the situation where the first applet in a package, having access to a sufficient amount of memory, will install successfully whereas the installation of a cooperating applet in the same package may fail. The problem is compounded as the runtime is unable to verify the usage of two very important memory resources pertaining to the applet, the required stack space and the worst case usage of the transaction buffer. These resources cannot be pre-calculated as they depend on the card specific bytecode frames, implementation of the required packages, and the implementation of the transaction mechanism in case of the transaction buffer. This leads to a programming model where the programmer is forced to allocate some memory resources in advance but still needs to check for their unavailability at runtime.

The lack of transient objects and the restriction on transient arrays especially effects the convenient Java programming model. A programmer is forced to load and store values from persistent objects into transient arrays and vice versa. Additionally, since resources are limited and differ from card to card, programmers have to code to a least common dominator and cannot rely on the flexible use of transient data. Not only will this force programmers to use entirely persistent objects, the larger RAM capacities of upcoming smart card hardware will ironically remain unused. The different handling of transient and persistent data also causes different transient and persistent object layout due to the indirect access to transient data through a persistent header.

Transient Environment

Monk: Why would anyone hurry to create gardens and buildings and monuments?
Lord Buddha: Everything is transient and nothing endures.

The problem of persistent and transient objects in Java Card can be stated as follows: How can the persistent object model of Java Card be augmented to enable flexible use of transient objects? The solution surprisingly lies in introducing a mechanism that is symmetrical to the persistent environment. The persistent environment consists of a persistent root, the applet instance and a set of objects reachable therefrom allocated in EEPROM. Analogously, the transient environment is formed by a tree of objects with the difference that all objects reside in RAM.

Both environments are separated in as far as references to transient objects are forbidden to be held in the persistent set. Storing references to transient objects in the persistent store is prevented by the virtual machine (VM) which throws an exception when such assignments are attempted. The Java (Card) bytecode instruction set uses different instructions to store primitive and reference types; only the latter must be checked by the VM, making the overhead negligible compared to the necessary EEPROM write operation in case of a store. Assignments of persistent references in transient stores need not be checked as it does not affect the integrity of the persistent store. Dangling pointers in case of power losses are avoided as transient references are never stored in the persistent set.

Implications

Apart from enabling a convenient programming mechanism the transient environment scales into the future when more smart card resources become available. The only limitation introduced by the transient environment is the restriction on assignment. Future systems may choose to remove this restriction and still provide binary compatibility. The restricted assignment also enhances security in that an applet cannot store a reference to a transient object which it received from the system or from a different applet in its persistent set. Since the object is only accessible during a session it cannot be accessed in situations not foreseen by the service provider. For instance, it allows the deletion of a server applet without the danger of dangling pointers in the client applet. The transient data approach is not upgradable in large part due to the fixed lifetimes in the API. The transient space is statically split for the individual applets which make temporary allocations and deallocation in the future practically impossible. Lifetimes contradict the ease-of-use of standard Java.

The transient environment also strengthens other aspects of the Java Card runtime, especially memory reclamation and the sharing mechanism.

Conclusions and Future Work

The contributions of this paper are:

• We suggest a terminology and framework with which to describe the issues underlying memory models in Java Card.
• We identify the restriction that can be placed on orthogonal persistent systems while retaining all the benefits of persistent systems for the Java Card programmer.
• We have presented other solutions attempting to solve the problems of transient data and shown their weaknesses. In particular we have shown that the static memory model described in the Java Card 2.1 Specification results in an unusual programming model and restricts the possibilities for memory reclamation and object sharing to an unsatisfying degree.
• We have shown that, by making support for transience explicit, a Java Card can provide a scalable API that can allow the manipulation of transient data similar to the standard Java environment. The resulting dynamic memory model naturally fits Java Card's execution model, allowing the simple and effective deployment of a garbage collector and enhances object sharing.

The proposed environment has been implemented and tested on a number of applets. In the future we hope to provide concrete benchmarks supporting its simplicity and performance to enable comparison of the design choices. We hope the transient environment will further demystify smart card programming and permit Java Card programmers to truly enjoy the benefits of persistence.

Acknowledgments

We are deeply indebted to Peter Buhler and Michael Baentsch for their invaluable input on implementation and many productive discussions. We are grateful to Stephan Hild for carefully reviewing the paper.

References

1. Arnold, K. and Gosling, J., The Java Programming Language, Addison-Wesley, 1996.
2. Lindholm, T. and Yellin, F., The Java Virtual Machine Specification, Addison-Wesley, 1996.
3. Sun Microsystems Inc., Java Card API 2.1 Specification, //java.sun.com/products/javacard/JavaCard21API.pdf
4. Atkinson, M.P., Bailey, P.J., Chisholm, K.J., Cockshott, W.P. and Morrison, R., An approach to Persistent Programming, Computer Journal, 26(4), 360-365, Nov. 1983.
5. Hosking, A. L. & Moss, J.E.B., Approaches to Adding Persistence to Java, Proceedings of the First International Workshop on Persistence and Java, Drymen, Scotland, Sept. 1996.
6. Atkinson, M.P. and Morrison, R., Orthogonally Persistent Object Systems, VLDB Journal, 4(3), 1995.
7. Atkinson, M.P., Daynès, L., Jordan, M.J., Printezis, T. and Spence, S., An Orthogonally Persistent Java, ACM SIGMOD Record, Dec. 1996.
8. Hosking, Anthony L. and Moss, J. Elliot B., Compiler Support for Persistence, COINS Technical Report 91-25, March 1991.
9. Schuh, Dan, Cory, Michael and Dewitt, David, Persistence in E revisited - Implementation Experiences, Proceedings of the Persistent Object Systems Workshop, Martha's Vineyard, MA, September 1990.
10. Cooper, Tim and Wise, Michael, Critique of Orthogonal Persistence, International Workshop on Object Orientation in Operating Systems, October 1996.
11. Guthery, Scott. B., Java Card: Internet Computing On A Smart Card, IEEE Internet Computing, pp. 57-59, Jan/Feb 1997.
12. Jones. R. and Lins. R., Garbage Collection, Algorithms for Automatic Dynamic Memory Management, Wiley, 1996.