Java Card Technology for Smart Card's architecture and programmer's Guide (zhiqun Chen)

Chapter 2 Java card objects

 

In Java card technology, jcres and applets Express, store, and operate data by creating objects. Applets uses Java
Programming Language. The applets running on the card is the object of the Applet Class.
 
Objects on the Java card platform follow the Java programming rules:
 
All objects on the Z-Java card platform are class instances or arrays. They all have the same root class.
Java. Lang. object.
Z fields in a new object or components in a new array are set to their default values (0, null, or false), unless
Initialize them into some other values in the constructor.
 
Java card technology supports both permanent and temporary objects. However, the concept of permanent and temporary objects in the Java card platform and their support mechanisms
It is different from the Java platform (see the supplementary description at the bottom of this page ).
 
4.1.java card storage mode
Smart Card has three types of memory: Rom, ram, and EEPROM. Rom is read-only memory, but it is the most expensive among the three. In
During card manufacturing,ProgramAnd data is burned into the Rom. Ram and EEPROM are both readable and writable, but they are
The gas characteristics are different. When the power is down, Ram will lose its content, but the content of the eeprom will be saved.
Generally, the write operation on the EEPROM is 1000 times slower than the write operation on the ram.
The number of write operations is actually limited. In addition, a ram unit is generally about four times larger than an EEPROM unit. Current
A smart card generally provides 16 K-byte EEPROM and 1 K-byte RAM.
 
The Java card storage mode is affected by the type and physical characteristics of the smart card storage. A typical Java Card SystemCode
(Virtual machines, APIs, and other software) are stored in the Rom. The applet code can also be stored in the Rom. Ram is used as temporary
Memory. The Java card runtime stack is allocated in Ram. Intermediate Results, method parameters, and local variables are placed on the stack. Native
Methods, such as those that execute crypto. calculation, also save the intermediate results in Ram. Long-lived data is stored
The same applies to downloaded applet classes in the EEPROM.
 
Most jcres and Applet objects indicate the information to be retained during power failure. RAM/EEPROM ratio in Smart Card
For example, it is natural to set the object space in the EEPROM. Therefore, the new operator is used to automatically implement
Sample A permanent object.
 
However, some objects are frequently accessed and their data (domain content) does not need to be permanent. Java card technology also
Supports temporary objects in Ram. Temporary objects are created by calling the Java card APIs.
 
Permanent and Temporary objects in the Java platform
On the Java platform, objects are created in Ram. When the Java Virtual Machine exits, or when the object is spam collector
They are automatically abolished during collection. The attributes, fields, and status information of some objects can be serialized using the object (seriealization)
And deseriealization. Object serialization records the current status and attributes of an object in the byte stream.
In the future, this byte stream will be serialized to restore the object in the same state and attribute. The Java language also supports key transient
(Keyword ). Mark the domain as a temporary (transient) to indicate that they are not an integral part of the permanent state of an object. In
Temporary domains are not retained during serialization.

Java card technology does not support object serialization and transient keywords.

4. 2. Permanent object
Permanent object storage and data are retained across CAD sessions. A permanent object has the following attributes:
 
A permanent object in Z is created using the new operator.
The State and value of a permanent object in Z remain unchanged across CAD sessions.
Any modification to a single domain of a permanent object by Z is atomic. That is, if a power loss or failure occurs during the modification process
The domain is restored to its original value.
Z a permanent object can be referenced by a domain in a temporary object.
Z The Field in a permanent object can reference a temporary object.
Z if a permanent object is not referenced by other objects, it becomes inaccessible or can be used as a garbage collection object.
 
4. Temporary objects
The word "temporary object" is a bit inappropriate. It may be incorrectly interpreted as the object itself is temporary:
The object is discarded. In fact, the word "temporary object" means that the content of the object's domain has temporary attributes. And permanent object
Similarly, the space allocated for temporary objects is retained and cannot be recycled unless the system implements a garbage collector.
 
An applet should create a temporary object only once in its lifecycle, and the reference of this object should be stored in a permanent
In the long domain, 4.1 is shown. When the card is powered on next time, the applet uses the same object reference to access the temporary object, even if the previous
The object data of the session has disappeared.

4.3.1. Temporary Object Attributes
 
In Java card 2.1, only arrays with basic types or arrays with object reference types can be declared
. The basic types of the Java card platform are byte, short, Int, and Boolean. This book uses temporary objects and
Temporary array. On the Java console, a temporary object has the following attributes:

A temporary object of Z is created by calling the Java card APIs.
Between Two CAD sessions, a temporary object does not save its State and value. When some events occur, a temporary object
Is cleared as its default value (0, false, or null ).
Z does not modify any field in a temporary object as an atom. That is, if a card loses power or
Error. The domain is not restored to its original value. If you include write operations on a temporary domain in a transaction (see
Chapter 5th), a abolished transaction will never restore the domain in a temporary object to its original value.
Z a temporary object can be referenced by a field in a permanent object.
Z The domain in a temporary object can be referenced by a permanent object.
Z if a temporary object is not referenced by other objects, it becomes inaccessible or can be collected by the garbage collector.
Z has no performance loss for write operations on the domain in a temporary object, because Ram has a much faster write than EEPROM.
Cycle.

Temporary object attributes that need to be modified frequently for a small amount, but do not need to retain the number of temporary applets between CAD sessions
Data is an ideal object. The applet developer should ensure that such temporary data is stored in the temporary array. This will reduce the number of permanent storage
The potential loss of the storage device ensures good Write Performance and increases the security of sensitive data to be protected. Based on experience
If all APDU commands need to modify a data multiple times, the applet developer should take it to a temporary array.

4.3.2. Temporary object type

There are two types of temporary data objects: clear_on_reset and clear_on_deselect. Either
Temporary objects of the type are all associated with an event. When this event occurs, it causes JRE to clear the domain of the object.

The clear_on_reset temporary object is used to keep the objects that need to be saved between the selection of each applet.
Data stored between reset slices. For example, the master session key of a card should be declared as clear_on_reset,
In this way, the same session key can be shared among the selected applets during a cad session. When a card is
When reset, the domain of the clear_on_reset temporary object is cleared. Reset signal sent to card circuit (warm reset) or Power Supply
Switching from disconnected to open may cause the card to be reset again.

The clear_on_deselect temporary object is used to maintain the objects that must be retained during the selection of the applet without cross-site
Applet selection or card reset. For example, the session key owned by an applet needs to be declared as clear_on_deselect.
Type of temporary object. In this way, when the applet is disabled (deselect), the session key is automatically cleared by JRE. This
Is a security precaution, so that another applet cannot see the session key data and impersonate the original key pair
Image applet.

Because the card reset implies that the selected applet is disabled, the domain of the clear_on_deselect object is also set
Clear the same event specified by clear_on_reset. In other words, the clear_on_deselect object is also
Clear_on_reset object. In addition, the clear_on_deselect temporary object also has its
Its Attributes (See Chapter 9th for details ).

4.3.3. Create a temporary object

In Java card technology, temporary objects are created using one of the factory methods in the jcsystem class, as shown in table 4.1:

The first parameter length in each method call specifies the length of the requested temporary array. The second parameter event refers
Specifies the event to clear the object. Therefore, the method call indicates the type of the temporary array, clear_on_reset or
Clear_on_deselect. Two constants in the jcsystem class are used to represent the type of the temporary array:

// Clear_on_reset temporary Array
Public static final byte clear_on_reset

// Temporary array of clear_on_deselect type
Public static final byte clear_on_deselect

The following code snippet creates a clear_on_deselect array:

Byte [] buffer =
Jcsystem. maketransientbytearray (buffer_length,
Jcsystem. clear_on_deselect );


4.3.4. query temporary objects

An applet may need to access objects created by other applets. Jcsystem provides an easy-to-query method for the applet.
Query method to determine whether an object being accessed is temporary:

Public static byte istransient (Object theobject)

The istransient method returns a temporary type constant (clear_on_reset or clear_on_deselect), or
The return constant jcsystem. not_a_transient_object indicates that the object is null or a permanent object.

4. A few words about object creation and Deletion
Because there is very little memory in the smart card, neither permanent objects nor temporary objects should be created in disorder. When
When the applet tries to use the new operator to create a permanent object, if there is not enough permanent storage available, JRE will
Cause code 1
Jcsyste. no_resource throws a systemexception exception. When an applet calls

When one of the make-transient-object methods does not have enough RAM space to be available, JRE uses the cause code
Jcsystem. no_transient_space throws a systemexception exception.
 
Once both permanent and temporary objects are created, as long as they are referenced from the static domain of the stack, class, other existing object domains, or from JRE,
You can access these objects. When all access to an object is discarded, the object becomes inaccessible. Whether
The space occupied by the object can be recycled depends on whether the garbage collector is implemented in the virtual machine. Jcres are not required for Java Card Technology
The implementation must include the Garbage Collector, because it is unrealistic to do so in low-end smart cards. Chapter 4 provides
How to reuse objects in applets during the set.

 

Chapter 2 atomicity and things

Smart cards are becoming one of the most widely used applications, such as storing private data and providing authentication services in mobile and distributed environments.
Preferred device. However, when using a smart card, there is a risk of failure at any time during Applet Execution. Original fault
Due to communication errors, or more often, the card user inadvertently pulls out the card from the CAD, leading to the disconnection from the card CPU
And terminate the execution of any applet. This early removal of the smart card from CAD is called pulling out (Tearing), or pulling
Card. This risk of incomplete execution poses a challenge to protecting the integrity of sensitive data operations in smart cards.

JRE provides a robust mechanism to ensure atomic operations. This mechanism is supported at two levels. First, Java card
The modification of permanent object domain or a class domain is atomic. Second, the Java card platform supports a transaction mode,
In this mode, an applet can organize a group of modifications into a transaction. This mode ensures the original
Child.

This chapter explains what atomicity means in the Java card platform and how applet developers can use it to protect data integrity.
Program.

5. 1. atomicity
On the Java platform, atomicity means that modifications to a permanent object domain (including array elements) or a class domain are required.
Or, if an error occurs during the modification, it is restored to its original value. For example, a domain in an object
It currently contains value 1 and is being modified with value 2. While a card is at a critical moment of rewriting this domain, the card is inadvertently removed from the CAD
. When power-on is re-enabled, this field will not leave a random value, but will be restored to its original value 1.

The concept of atomicity applies only to permanent memory content. It defines power loss or other errors during modification of a Data Element
In this case, how does JRE process this data element. The atomicity of jcres is not applicable to temporary arrays. Modify temporary array elements
In the case of power loss, the original value of this element is not retained. When the card is inserted into CAD next time, the elements of a temporary array are
Set it to its default value (0, false, or null ).

. Modify block data in the array

The javacard. Framework. util class provides the arraycopy method, which ensures that multiple data elements in an array are segmented.
Atomic modification:

Public static short arraycopy (byte [] SRC, short srcoff, byte [] DEST, short desoff, short length );

The util. arraycopy method ensures that either all bytes are correctly copied or the target array is restored to its original byte value.
If the target array is temporary, it does not have the atomic property.

However, arraycopy requires additional EEPROM write operations to support atomicity, so it is very slow. An applet can
To avoid the atomicity of array modification. Therefore, a util. arraycopynonatomic method is provided:

Public static short arraycopynonatomic (byte [] SRC, short srcoff,
Byte [] DEST, short desoff, short length );

Method arraycopynonatomic does not use the transaction facility during the copy operation, even if a transaction is being executed. Because
In this case, only when a power-down event occurs in the middle of the copy operation, the contents of the target array can be partially modified.

This method should be used. In a similar way, util. arrayfillnonatomic fills in the elements of a byte array with the specified value.
Su:

Public static short arrayfillnonatomic (byte [] barray, short boff, short blen, byte bvalue );

5. 3. Transactions
Atomicity ensures atomic modification of a single data element. However, an applet may need to modify several different
As in. For example, a credit or debit transaction may require a wallet applet to increase the transaction counter and change the wallet.
Balance, and write transaction logs, all these operations should be taken as an atomic unit of work.

Readers may already be familiar with the use of the concept of database things. This concept includes start, commit, and rollback to ensure that
Or do not make any modifications. Java card technology supports a similar transaction mode, with the ability to submit and roll back,
To ensure that some compound operations can be performed atomically; or they are successfully completed, or some of their results are all invalid. Things
Thing-based mechanisms protect events such as program errors that may result in data corruption and power loss during transaction processing.
All the steps of a transaction will not be completed normally.

5.3.1. Submit a transaction

A transaction starts by calling jcsysten. begintransaction and by calling jcsysten. committransaction.
End:

// Start a transaction
Jcsysten. begintransaction ();

// Before the transaction is submitted, all modifications made to the permanent data set are temporary.
......

// Submit a transaction
Jcsysten. committransaction ();

Modification to a thing is conditional-the field or array element is modified. Read back these fields or array elements to get their final
But these modifications are not executed before calling jcsysten. committransaction.

5.3.2. Abolish things

Both Applet and JRE can abolish transactions. If the applet encounters an internal problem, it can call the Method
Jcsystem. aborttransaction explicitly deletes the transaction. Deleting a transaction will discard the execution of the transaction.
And restore the modified fields or array elements to their original values. Call the aborttransaction Method
A transaction must be in progress; otherwise, JRE throws an exception transactionexception.

Returns from an applet with a transaction that is still being executed (that is, the applet neither explicitly committed nor deleted
When jcret re-obtains program control, jcret automatically calls the aborttransaction method. Similar
If an exception is thrown in a transaction and the applet does not process it, JRE also needs to abolish the transaction.

If the power is down or an error occurs during a transaction processing, JRE calls its internal rollback facility when the card is powered on the next time.
Data Recovery involved in transactions is the value before their transactions.

In all circumstances, in a failed transaction (due to power loss, card reset, calculation error, or program Abolition)
The created temporary and permanent objects are deleted by JRE and their storage space is released.

5.3.3. nested things

Unlike most database transactions, transactions on the Java card platform cannot be nested. Only one transaction can be performed at a time. This
The requirement is due to the limited computing resources of smart cards.

If a transaction is in progress and the jcsystem. begintransaction method is called, JRE throws
Except for transactionexception. By calling jcsystem. transactiondepth, an applet can detect whether a transaction exists.
In progress. If a transaction is in progress, this method returns 1; otherwise, 0 is returned.

5.3.4. submission capability

To support rollback of unprocessed transactions, JRE maintains a commit buffer and stores the original content of the modified domain.
Here, until the transaction is committed. In case of a fault before the transaction is completed, the domain involved in the transaction will be restored from the buffer to its original
First. The more operations performed in a transaction block, the larger commit buffer is required to accommodate them.

The implementation of different commit Buffer Sizes varies depending on the size of available card memory. In general
The commit buffer allocated in the implementation of a JRE is large enough to meet the needs of most applets-generally an applet
A transaction contains dozens of bytes. However, because smart card resources are limited, only one logic is included in a transaction.
It is very important to modify the unit. It may be impossible to put too many things in a transaction.

Before executing a transaction, an applet can check whether the available commit buffer size can meet the requirements.
The size of the data block modified for a transaction. Jcsystem provides two methods to help applets determine the Java card Platform
What is the current submission capability.

Z jcsystem. getmaxcommitcapacity () returns the total number of bytes in a commit buffer.
Z jcsystem. getunusedcommitcapacity () returns the number of unused bytes in the commit buffer.

In addition to the content of the modified domain during a transaction, the commit buffer also contains some additional management data bytes,
For example, the domain address. The amount of data managed depends on the number of domains being modified and the internal implementation of the Transaction System. Returned by two methods
The commit capability is the total number of bytes (including management overhead) of permanent data that can be modified in a transaction ).

If the commit capability is exceeded in a transaction, JRE throws a transactionexception exception. Even so
Things are still being executed, unless explicitly abolished by the applet or JRE.

5.3.5.transactionexception

If a problem is detected in a thing (such as nested thing or commit Buffer Overflow), JRE throws
Except for transactionexception.

Transactionexception is a subclass of the runtimeexception class. It provides a reason code to indicate the original cause of the exception
Because. The Java card exception and cause code are described in Chapter 1. The Reason code defined in the transactionexception class is as follows:

Z in_progress-The begintransaction method is called, and the transaction is in progress.
Z not_in_progress-The committransaction or aborttransaction method is called.
.
Z buffer_full-Modifications to permanent memory have been started during a transaction, but commit buffer has been caused
Overflow.
Z internal_falure-a serious internal problem occurs in the transaction system.

If the applet does not capture the exception of transactionexception, it will be captured by JRE. In the next case, JRE will automatically
Abolish this thing.

5.3.6. Local variables and temporary objects during a transaction

Readers should know that only modifications to permanent objects participate in one thing. For temporary objects and local variables (including method parameters
Changes will never be abolished, no matter whether they are in the "internal" of a thing ". Local variables are built on the Java card stack
Stored in Ram.

The following code snippet demonstrates three copy operations on a temporary array key_buffer. When a thing is abolished, regardless of the array
The copy operation or any modification to the key_buffer element contained in the for loop is not protected by transactions. Similarly,
The local variable a_local has a new value of 1.

Byte [] key_buffer = jcsystem. maketransientbytearray
(Key_length, jcsystem. clear_on_reset );

Jcsystem. begintransaction ();

Util. arraycopy (SRC, src_off, key_buffer, 0, key_length );
Util. arraycopynonatomic (SRC, src_off, key_buffer, 0, key_length );

For (byte I = 0; I <key_length; I ++)
Key_buffer [I] = 0;

Byte a_local = 1;

Jcsystem. aborttransaction ();

Because local variables or temporary array elements do not participate in things, an object is created and assigned to a local variable or a temporary
The group elements do not need to be carefully considered. Here is an example code:

Jcsystem. begintransaction ();

// Ref_1 is an instance (object) domain
Ref_1 = jcsystem. maketransientobjectarray
(Length, jcsystem. clear_on_deselect );

// Ref_2 is a local variable
Ref_2 = new someclass ();

// check the status
If (! Condition)
jcsystem. aborttransaction ();
else
jcsystem. committransaction ();
return ref_2;
in this example, the instance domain ref_1 stores a reference to a temporary object, the local variable ref_2 saves a reference to a
permanent object. As mentioned above, if a thing is abolished, the permanent and temporary objects created in the thing will be automatically discarded
. This has no impact on the instance domain ref_1. if the transaction is not completed properly, its content will be restored to its original value. However,
In the next row, a potential problem occurs when a newly created object is assigned to a local variable. When something fails, JRE
deletes this object. However, ref_2 still points to a unit that no longer has an object. If ref_2 is later used as a return value,
the problem is even worse. In this case, the caller will receive a floating pointer.
to avoid hanging pointers (compromising the security of Java language ), JRE ensures that references to objects created during an abolished event
are set to null. In this example, if the method aborttransaction is called, the local variable ref_2
is set to null. This situation is not ideal, but it avoids security violations when the system overhead is minimal.
This example cannot be used in most applets, because we do not encourage arbitrary object creation in a method. In the case of possible
, an applet should allocate the space of all the objects required by it during its initialization (See Chapter 7th ). However, Java
the implementer of the card installer may need to handle a considerable number of object creation tasks in one thing, avoid situations as described in
the above Code.