Java Card Objects

In accordance with the Java Card technology, the JCRE runtime environment and applets create objects for representing, storing and processing data. Applets are written in the Java programming language. Executable applets on the card are objects of applet classes.
Java Card platform objects obey the rules of the Java programming language:
· All Java Card platform objects are instances of classes or arrays that share a common java.lang.Object root class.
· The fields of the new object or the components of the new array are assigned default values (zero, null or false), unless the constructor provides assignment of other values.
Java Card technology supports both permanent and temporary objects. However, the concept of permanent and temporary objects, as well as the mechanisms for their support on the Java Card and Java platforms differ from each other.

Smart cards typically use three types of memory: ROM, RAM, and EEPROM. The fifth ROM is read-only, but at the same time has the lowest cost. Programs and data are written to the ROM memory in the smart card manufacturing process. Random access memory (RAM) and programmable permanent memory (EEPROM) support write and read operations, but differ in performance characteristics. When the power is turned off, the data in the operational memory is lost, and the data in the EEPROM memory is saved. But writing to EEPROM memory is about 1000 times slower than writing to RAM. In addition, the number of write cycles to the EEPROM memory during the service life of the card is limited. In addition, the size of one RAM memory cell is approximately four times the size of an EEPROM cell. Modern smart cards usually contain about 1 KB of RAM and 16 KB of programmable permanent memory.

The Java Card memory model is determined by the types of available memory and their physical their characteristics. Typically, in Java Card systems, JCRE code (virtual machine, API classes, and other system software) is stored in ROM memory. The application code can also be stored in permanent memory. RAM is used for temporary data storage. The Java Runtime Card stack is located in RAM. The stack stores intermediate results
of calculations, method parameters, and local variables. Native methods,

Permanent objects

For example, the methods of the cryptography subsystem also record intermediate results in RAM. Data intended for long-term storage, such as loadable applet classes, are written to EEPROM memory.
Most JCRE objects and applets contain information that should be saved when the power is turned off. The ratio of RAM/EEPROM memory in smart cards leads to the fact that objects are most often placed in EEPROM memory. For example, when executing the new operator, a permanent object is automatically placed in the EEPROM memory.
However, some objects require frequent access, and the data related to them (the contents of their fields) are not permanent. Java Card technology also supports the placement of temporary objects in RAM. Temporary objects are created using Java Card programming interfaces.

PERMANENT AND TEMPORARY JAVA PLATFORM OBJECTS

The Java platform provides for the creation of objects in RAM. Objects are automatically deleted when the Java Virtual bus ends. Objects that are not referenced are also deleted during the garbage collection process. Properties and fields of some objects, as well as information about their state, can be saved using serialization and deserialization mechanisms. During serialization, the current state and properties of the object are written to a byte stream. During the recovery process, this stream is transformed into an internal representation of the state and properties of the object. The Java language has the transient keyword. The values of fields with the transient attribute are not saved during serialization.
Java Card technology does not support saving objects in the external memory and the transient keyword.

The state of permanent objects, including the values of their fields, is saved between CAD communication sessions. A permanent object has the following properties:
· A permanent object is created using the new operator.
· Permanent objects retain their state and field values between communication sessions with the CAD device.
· Any update of the value of each field of a permanent object is an illegal operation. Thus, if a power outage or other failure occurs during the update process, the previous value of the field will be preserved.
· A temporary object field may contain a reference to a permanent object.
· A permanent object field may contain a reference to a temporary object.
· If a persistent object has no references to other objects, it becomes unavailable and can be deleted by the garbage collection process.
After creating an instance of the applet, as well as any permanent object, the memory it holds and the values of its parameters are stored between CAD communication sessions.

In fact, the term “temporary object” (transient object) is not entirely accurate. Such a name can be misinterpreted, considering that this object is temporary in general: after a power outage, it is deleted. In fact, the term “temporary object” means that the values of the fields of such an object are temporary in nature. As in the case of permanent objects, the space occupied by temporary objects is reserved and cannot be reused, even if there is a “garbage collector” in the system.
An applet can create a temporary object only once during its existence. At the same time, the link to such an object should be stored in a permanent field, as shown in Figure 4.1. The next time the power is applied to the card again, the applet will use the same link to access the temporary object, despite the fact that the data that was written to the fields of this objects that have not been preserved since the previous communication session with the reader.

Properties of temporary objects

According to the Java Card 2.1 specification, temporary objects can only be arrays of primitive types, or arrays of references to variables of the Object type. The primitive types supported by the Java Card platform are byte, short, int and boolean. In this book, the terms “temporary object” and “temporary array” will be used synonymously. Temporary objects supported by the Java Card platform have the following properties:
· Temporary objects are created using Java Card programming interfaces.
· Temporary objects do not retain their state and field values between communication sessions with the CAD device. When certain events occur, the fields of temporary objects are assigned default values (zero, false or null).
· Any update of the value of each field of a temporary object is not an atomic operation. Thus, if a power outage or other failure occurs during the update process, the previous value of the field will not be saved. If the operations of updating the fields of a temporary object are part of a transaction (see Chapter 5), in the event of a transaction interruption, the previous values of the fields are not restored.

Temporary objects

· A permanent object field may contain a reference to a temporary object.
· A temporary object field may contain a reference to a permanent object.
· If a temporary object does not contain references to other objects, it becomes inaccessible and can be deleted by the garbage collection process.
· Write operations to the fields of temporary objects do not cause a decrease in performance, because writing to RAM is much faster than to EEPROM memory.

Temporary objects are an ideal option for online storage of small amounts of frequently changed data that will no longer be needed in the next session of communication with CAD. Applet developers must ensure that operational data is stored in temporary arrays. This practice avoids excessive consumption of permanent memory, contributes to increased productivity, and also provides additional protection for vulnerable data. Therefore, in practice, it is recommended to observe the following rule: if some data changes many times during the processing of the APDU command, it is better to store them in a temporary array.

Types of Temporary objects

There are two types of temporary objects: CLEAR_ON_RESET and CLEAR_ON_DESELECT. Temporary objects of each type are associated with a specific event. When such an event occurs, JCRE clears the fields of objects.
Data in temporary objects of the CLEAR_ON_RESET type is saved after selecting another applet, but is lost when the card is reset. For example, the master key of the card communication session must be declared as CLEAR_ON_RESET, because it is used by all the applets that are selected during the CAD communication session. After resetting the card, the fields of temporary objects of the CLEAR_ON_RESET type are cleared. Resetting the card can be caused either by applying a reset signal to the card (hot reset), or by turning off and then turning on the power.

Data in temporary objects of the CLEAR_ON_DESELECT type is stored all the time while the applet that generated them is active, but it is lost when another applet is selected or when the card is reset. For example, the applet’s communication session key must be declared as CLEAR_ON_DESELECT, because after deactivating the applet, it will be automatically deleted by JCRE. This precaution is necessary to ensure safety. No applet can get hold of another applet’s key to impersonate it.
Since when the card is reset, the current applet is implicitly deactivated, when events occur that lead to clearing the data of objects of the CLEAR_ON_RESET type, the data of objects of the CLEAR_ON_DESELECT type is also cleared. In other words, when the card is reset, the behavior of objects of the types CLEAR_ON_DESELECT and CLEAR_ON_RESET is the same. In addition, temporary objects of the CLEAR_ON_DESELECT type have additional properties that relate to the applet protection system.

Creating temporary objects

In Java Card technology, standard methods of the JCSystem class are used to create temporary objects, which are given in Table 4.1.
Table 4.1. Methods of the JCSystem class for creating temporary objects

Methods Result of calling the method

public static boolean[] makeTransientBooleanArray(short length,
byte event) Creating a temporary array of type boolean
public static byte[] makeTransientByteArray(short length,
byte event) Creating a temporary array of type byte
public static short[] makeTransientShortArray(short length,
byte event) Creating a temporary array of type short
public static Object[] makeTransientObjectArray(short length,
byte event) Creating a temporary array of type Object
The first parameter in the call of each method, length, determines the length of the created array. The second parameter, event, specifies the type of event when the object data is cleared. This parameter is used to set the type of temporary array:

CLEAR_ON_RESET or CLEAR_ON_DESELECT. To specify the type of a temporary array, two constants defined in the JCSystem class are used:
// a temporary array of the type CLEAR_ON_RESET public static final byte CLEAR_ON_RESET
// temporary array of type CLEAR_ON_DESELECT public static final byte CLEAR_ON_DESELECT

The following code snippet can be used to create an array of type
CLEAR_ON_DESELECT:

byte[] buffer =
JCSystem.makeTransientByteArray (BUFFER_LENGTH,
JCSystem.CLEAR_ON_DESELECT);

Requests to temporary objects

An applet may need access to an object created by another applet. The JCSystem class provides a convenient request method that allows the applet to determine whether the object it intends to access is temporary:

public static byte isTransient(Object theObject)

The isTransient method returns a constant of the temporary object type (CLEAR_ON_RESET or CLEAR_ON_DESELECT ) or the JCSystem.NOT_A_TRANSIENT_OBJECT constant, which indicates that the object is empty or permanent.