44
`
`CHAPTER 3 JAVA CARD TECHNOLOGY OVERVIEW
`
`3.9 Applet Development Process
`
`Development of a Java Card applet begins as with any other Java program: a
`developer writes one or more Java classes and compiles the source code with a
`Java compiler, producing one or more class files. Figure 3.7 demonstrates the
`applet development process.
`Next, the applet is run, tested, and debugged in a simulation environment. The
`simulator simulates the Java Card runtime environment on a PC or a workstation.
`In the simulation environment, the applet runs on a Java virtual machine, and thus
`the class files of the applet are executed. In this way the simulator can utilize
`
`Step 1:
`
`Java
`,,
`files
`'
`
`-
`-
`
`Java
`compiler
`
`-
`
`-
`
`class
`files
`,
`
`'
`
`Step 2:
`
`Java Card -
`simulator
`
`-
`
`Step 3:
`
`export -
`file(s)
`•
`
`Java Card
`converter
`
`~
`
`export
`files
`I
`
`'
`
`1
`
`CAP
`file(s)
`•
`
`1 I
`
`Java Card
`emulator
`
`Step 4:
`
`Figure 3.7 Applet development process
`
`IPR2022-01239
`Apple EX1020 Page 52
`
`

`

`APPLET INSTAJ.LATION 45
`
`many Java development tools (the virtual machine, debugger, and other tools) and
`allow the developer to test the applet's behavior and quickly see the applet's
`results without going through the conversion process. During this step, the overall
`functional aspects of the applet are tested. However, some of the Java Card virtual
`machine runtime features, such as the applet firewall and the transient and persis(cid:173)
`tent behavior of objects, cannot be examined.
`Then the class files of the applet that make up a Java package are converted to
`a CAP file by using the Java Card converter. The Java Card converter takes as
`input not only the class files to be converted but also one or more export files.
`When the applet package is converted, the converter can also produce an export
`file for that package. A CAP file or an export file represents one Java package. If
`an applet comprises several packages, a CAP file and an export file are created for
`each package.
`In the next step, the CAP file(s) that represent the applet are loaded and tested
`in an emulation environment. The emulator also simulates the Java Card runtime
`environment on a PC or a workstation. However, the emulator is a more sophisti(cid:173)
`cated testing tool. It encompasses a Java Card virtual machine implementation.
`The behavior of the applet executing in the emulator should be the same as its
`behavior running in a real card. In this development phase, not only is the applet
`further tested, but also the runtime behavior of the applet is measured.
`Most Java Card simulators and emulators come with a debugger. The debug(cid:173)
`ger allows the developer to set breakpoints or single-step the program, watching
`the execution state of the applet change in the simulated or emulated Java Card
`runtime environment.
`Finally, when the applet is tested and ready to be downloaded into a real card,
`the applet, represented by one or several CAP files, is loaded and installed in the
`Java smart card.
`
`3.10 Applet Installation
`
`When a Java smart card is manufactured, the smart card proprietary system and the
`Java Card runtime environment-including native methods, the Java Card virtual
`machine, API classes, and libraries-are burned into ROM. This process of writing
`the permanent components into the nonmutable memory of a chip is called masking.
`The technology for performing masking is a proprietary technology of a smart card
`vendor and is not discussed further in this book.
`
`IPR2022-01239
`Apple EX1020 Page 53
`
`

`

`46
`
`CHAPTER 3 JAVA CARD TECHNOLOGY OVERVIEW
`
`3.10.1 ROM Applets
`
`Java Card applet classes can be masked in ROM together with the JCRE and other
`system components during the process of card manufacturing. Applet instances are
`instantiated in EEPROM by the JCRE during JCRE initialization or at a later stage.
`Such applets are called ROM applets.
`The ROM applets are default applets that come with the card and are provided by
`card issuers. Because ROM applet contents are controlled by issuers, Java Card tech(cid:173)
`nology allows ROM applets to declare native methods whose implementations are
`written in another programming language, such as C or assembly code. Native meth(cid:173)
`ods are not subject to security checks enforced by the Java Card virtual machine.
`
`3.10.2 Preissuance or Postissuance Applets
`
`Alternatively, Java Card applet classes and associated class libraries can be down(cid:173)
`loaded and written into the mutable memory (such as EEPROM) of a Java smart
`card after the card is manufactured. Such applets can be further categorized as
`preissuance or postissuance applets. The terms preissuance and postissuance
`derive from the fact that applets are downloaded before or after the card has been
`issued. Preissuance applets are treated the same way as the ROM applets; both are
`controlled by the issuer.
`Unlike ROM applets or preissuance applets, postissuance applets ary not
`allowed to declare native methods. The reason is that the JCRE has no way to con(cid:173)
`trol the applet contents. Allowing downloaded applets to contain native code
`could compromise Java Card security.
`The following subsections focus on postissuance applet installation. Usually
`preissuance applets are loaded using the same mechanism as postissuance applets,
`but Java Card technology leaves the decision to the card issuers.
`
`3.10.3 Postissuance Applet Installation
`
`Applet installation refers to the process of loading applet classes in a CAP file, com·
`bining them with the execution state of the Java Card runtime environment, and cre(cid:173)
`ating an applet instance to bring the applet into a selectable and execution state.
`On the Java Card platform, the loading and installable unit is a CAP file. A CAP
`file consists of classes that make up a Java package. A minimal applet is a Java pack(cid:173)
`framework.Applet. A more
`age with a single class derived from the class javacard.
`complex applet with a number of classes can be organized into one Java package
`or a set of Java packages.
`
`IPR2022-01239
`Apple EX1020 Page 54
`
`

`

`APPLET INSTALL.AT/ON
`
`47
`
`To load an applet, the off-card installer takes the CAP file and transforms it into
`a sequence of APDU commands, which carry the CAP file content. By exchanging
`the APDU commands with the off-card installation program, the on-card installer
`writes the CAP file content into the card's persistent memory and links the classes in
`the CAP file with other classes that reside on the card. The installer also creates and
`initializes any data that are used internally by the JCRE to support the applet. If the
`applet requires several packages to run, each CAP file is loaded on the card.
`As the last step during applet installation, the installer creates an applet
`instance and registers the instance with the JCRE. 3 To do so, the installer invokes
`the i nsta 11 method:
`
`public static void install(byte[]
`
`bArray, short offset,
`
`byte length)
`
`The i nsta 11 method is an applet entry point method, similar to the main method in
`a Java application. An applet must implement the i nsta 11 method. In the i nsta 11
`method, it calls the applet's constructor to create and initialize an applet instance.
`The parameter bAr ray of the i nsta 11 method supplies installation parameters for
`applet initialization. The installation parameters are sent to the card along with the
`CAP file. The applet developer defines the format and content of the installation
`parameters.
`After the applet is initialized and registered with the JCRE, it can be selected
`and run. The JCRE identifies a running applet (an applet instance), using an AID.
`The applet can register itself with the JCRE by using the default AID found in the
`CAP file, or it can choose a different one. The installation parameters can be used
`to supply an alternative AID.
`The i nsta 11 method can be called more than once to create multiple applet
`instances. Each applet instance is identified by a unique AID.
`In the Java Card environment, an applet can be written and executed without
`knowing how its classes are loaded. An applet's sole responsibility during installa(cid:173)
`tion is to implement the install method.
`
`3.10.4 Error Recovery during Applet Installation
`
`The installation process is transactional. In case of an error, such as programmatic
`failure, running out of memory, card tear, or other errors, the installer discards the
`
`3 In a JCRE implementation, the operation for creating an applet instance can be performed at a later
`stage after applet installation.
`
`IPR2022-01239
`Apple EX1020 Page 55
`
`

`

`48
`
`CHAPTER 3 JAVA CARD TECHNOLOGY OVERVIEW
`
`CAP file and any applets it had created during installation and recovers the space
`and the previous state of the JCRE.
`
`3.10.5 Installation Constraints
`
`Readers should be aware that applet installation is different from dynamic class
`loading at runtime, which is supported on a Java virtual machine on the desktop
`environment. Java Card applet installation simply means to download classes
`through an installation process after the card has been made.
`Therefore, Java Card applet installation has two finer points. First, applets
`executing on the card may refer only to classes that already exist on the card, since
`there is no way to download classes during the normal execution of applet code.
`Second, the order of loading must guarantee that each newly loaded package
`references only packages that are already on the card. For example, to install an
`applet, the javacard.
`framework package must be present in the card, because all
`applet classes must extend from the class javacard.
`framework.Applet. An instal(cid:173)
`lation would fail if there were circularity such that package A and package B ref(cid:173)
`erence each other.
`
`IPR2022-01239
`Apple EX1020 Page 56
`
`

`

`CHAPTER 4
`Java Card Objects
`
`.
`In Java Card technology, the JCRE and applets create objects to represent, store, and
`manipulate data. Applets are written by using the Java programming language. Run(cid:173)
`nable applets on the card are objects of applet classes.
`Objects in the Java Card platform are subject to the Java programming rules:
`
`• All the objects on the Java Card platform are instances of classes or array
`types, which have the same root class java. lang.Object.
`
`• Fields in a new object or components in a new array are set to their default val(cid:173)
`ues (zero, nul 1, or fa 1 se) unless they are initialized to some other values in
`the constructor.
`
`Java Card technology supports both persistent and transient objects. However,
`the concepts of persistent and transient objects and the mechanisms to support
`them in the Java Card platform are not the same as in the Java platform (see the
`sidebar on page 50).
`
`4.1
`
`Java Card Memory Model
`
`A smart card has three kinds of memory: ROM, RAM, and EEPROM. ROM is read(cid:173)
`only memory but is the least expensive of the three. Programs and data are burned
`into ROM during card manufacture. Both RAM and EEPROM can be read and writ(cid:173)
`ten, but they differ in many electrical characteristics. In case of a power loss, RAM
`loses its contents, but the contents of EEPROM are preserved. Write operations to
`EEPROM are typically 1,000 times slower than write operations to RAM, and the
`possible number of writes to EEPROM over the lifetime of a card is physically lim(cid:173)
`ited. In addition, a RAM cell tends to be approximately four times larger than an
`
`49
`
`IPR2022-01239
`Apple EX1020 Page 57
`
`

`

`50
`
`CHAPTER4 JAVA CARD OBJECTS
`
`EEPROM cell. Current smart cards typically offer about 16K of EEPROM and IK
`of RAM.
`The Java Card memory model is motivated by the kind of memory in sman
`cards and their physical characteristics. A typical Java Card system places the
`JCRE code (virtual machine, API classes, and other software) in ROM. Applet
`code can also be stored in ROM. RAM is used for temporary storage. The Java
`Card runtime stack is allocated in RAM. Intermediate results, method parameters,
`and local variables are put on the stack. Native methods, such as those performing
`cryptographic computations, also save intermediate results in RAM. Longer-lived
`data are stored in EEPROM, as are downloaded applet classes.
`Most JCRE and applet objects represent information that needs to be pre(cid:173)
`served when power is removed. The RAM/EEPROM size ratio in a smart card
`also makes it natural to designate object space in EEPROM. Therefore, using the
`new operator automatically instantiates a persistent object in EEPROM.
`However, some objects are accessed frequently, and their data (the contents of
`their fields) need not be persistent. Java Card technology also supports transient
`objects in RAM. Transient objects are created by invoking Java Card APis.
`
`Persistent and Transient Objects in the Java Platform
`
`In the Java platfonn, objects are created in RAM. Objects are automatically
`destroyed when the Java virtual machine exits, or when they are collected by the garbage
`collector. The properties, fields, and state infonnation of some objects can be preserved
`by using the object serialization and deserialization mechanism. Object serialization
`records the current state and properties of an object in a stream of bytes. The stream is
`later deserialized to restore the object with the same state and properties. The Java
`language also supports the transient
`keyword. Fields are marked as transient
`to
`indicate that they are not part of the persistent state of an object. Transient fields are not
`saved during object serialization.
`Java Card technology does not support object serialization or the transient
`keyword.
`
`4.2 Persistent Objects
`
`The memory and data of persistent objects are preserved across CAD sessions. A
`persistent object has the following properties:
`
`• A persistent object is created by the new operator.
`
`• A persistent object holds states and values across CAD sessions.
`
`IPR2022-01239
`Apple EX1020 Page 58
`
`

`

`TRANSIENT OBJECTS 51
`
`• Any update to a single field in a persistent object is atomic. That is, if the card
`loses power or a failure occurs during the update, the field is restored to its
`previous value.
`
`• A persistent object can be referenced by a field in a transient object.
`
`• A field in a persistent object can reference a transient object.
`
`• If a persistent object is not referenced by other objects, it becomes unreachable
`or can be garbage collected.
`
`When an applet instance is created, like any other persistent object, the applet's
`space and data persist indefinitely from one CAD session to the next.
`
`4.3 Transient Objects
`
`The term transient object is somewhat of a misnomer. It can be incorrectly inter(cid:173)
`preted to mean that the object itself is temporary: when power is removed, the tran(cid:173)
`sient object is destroyed. In fact, the term transient object means that the contents of
`the fields of the object have a temporary nature. As with persistent objects, the space
`allocated for transient objects is reserved and cannot be reclaimed unless a garbage
`collector is implemented.
`An applet should create a transient object only once during its lifetime and
`should save the object reference in a persistent field, as shown in Figure 4.1. The
`next time the card is powered on, the applet uses the same object reference to
`access the transient object, even though the object data from the previous session
`are lost.
`
`RAM
`
`EEPROM
`
`object
`reference
`
`object
`reference
`
`Figure 4.1 Transient objects
`
`IPR2022-01239
`Apple EX1020 Page 59
`
`

`

`52
`
`CHAPTER4 JAVA CARD OBJECTS
`
`4.3.1 Properties of Transient Objects
`
`In Java Card 2.1, only arrays with primitive types or arrays with references to
`Object can be declared transient. The primitive types in the Java Card platform are
`byte, short, int, and boolean. Throughout this book, the terms transient objects
`and transient arrays are used interchangeably. A transient object within the Java
`Card platform has the following properties:
`
`• A transient object is created by invoking the Java Card APls.
`
`• A transient object does not hold states and values across CAD sessions. The
`fields of a transient object are cleared to their default value (zero, false, or
`nu 11) at the occurrence of certain events.
`
`• Any update to a single field in a transient object is not atomic. That is, if the
`card loses power or a failure occurs during an update, the field is not restored
`to its previous value. If writes to the fields of a transient object are included in
`a transaction (see Chapter 5), an abort transaction will never cause a field in
`the transient object to be restored to a previous value.
`
`• A transient object can be referenced by a field in a persistent object.
`
`• A field in a transient object can reference a persistent object.
`
`• If a transient object is not referenced by other objects, it becomes unreachable
`or can be garbage collected.
`
`• Writes to the fields of a transient object do not have a performance penalty,
`because RAM has a much faster write cycle time than EEPROM.
`
`The properties of transient objects make them ideal for small amounts of tem(cid:173)
`porary applet data that are frequently modified but that need not be preserved across
`CAD sessions. The applet developer should ensure that such temporary data are
`stored in transient arrays. This reduces potential wear on persistent memory, guaran(cid:173)
`tees better write performance, and adds additional security to protect sensitive data.
`As a rule of thumb, if temporary data are being updated multiple times for every
`APDU processed, the applet developer should move them into a transient array.
`
`4.3.2 Transient Object Types
`
`There are two types of transient objects, namely, CLEAR_ON_RESET and
`CLEAR_ON_DESELECT. Either type of transient object is associated with an event,
`which, when it occurs, causes the JCRE to clear the fields of the objects.
`
`A
`
`IPR2022-01239
`Apple EX1020 Page 60
`
`

`

`TRANSIENT OBJECTS
`
`53
`
`transient objects are used for maintaining data that need to be
`CLEAR_ON_RESET
`preserved across applet selections but not across card resets. For example, a card
`type so that the same
`master session key should be declared as CLEAR_ON_RESET
`session key can be shared among applets that are selected during one CAD ses(cid:173)
`transient objects are
`sion. When a card is reset, the fields of CLEAR_ON_RESET
`cleared. A card reset can be caused by a reset signal sent to the card circuitry
`(warm reset) or by switching the power supply off and on again.
`transient objects are used for maintaining data that must
`CLEAR_ON_DESELECT
`be preserved as long as an applet is selected but not across applet selections or
`card resets. For example, an applet-owned session key needs to be declared as
`type so that when the applet is deselected, the session key is
`CLEAR_ON_DESELECT
`automatically cleared by the JCRE. This is a security precaution so that another
`applet cannot discover the session key data and pretend to be the previously
`selected applet that owns the key object.
`Because a card reset implicitly deselects the currently selected applet, the
`fields of CLEAR_ON_DESELECT objects are also cleared by the same events speci(cid:173)
`fied for CLEAR_ON_RESET. In other words, CLEAR_ON_DESELECT objects are also
`
`CLEAR_ON_RESET objects. In addition, CLEAR_ON_DESELECT transient objects have
`additional properties because of the applet firewall. (See Chapter 9 for details.)
`
`4.3.3 Creating Transient Objects
`
`In Java Card technology, transient objects are created by using one of the factory
`methods in the JCSystem class, as shown in Table 4.1.
`
`Table 4.1 Methods for creating transient arrays in the class JCSystem
`
`Methods
`
`public static boolean[]
`length,
`makeTransientBooleanArray(short
`byte event)
`
`public static byte[]
`makeTransientByteArray(short
`
`short[]
`public static
`makeTransientShortArray(short
`
`length,
`byte event)
`
`length,
`byte event)
`
`public static Object[]
`length,
`makeTransientObjectArray(short
`byte event)
`
`Result of the method call
`
`Create a transient boolean array
`
`Create a transient byte array
`
`Create a transient short array
`
`Create a transient Object array
`
`IPR2022-01239
`Apple EX1020 Page 61
`
`

`

`54
`
`CHAPTER4 JAVACARDOBJECTS
`
`The first parameter, 1 ength, in each method call specifies the requested
`.
`h' h .
`trans1e
`• di
`array length. The second parameter, event, m cates w 1c kind of event cl
`nt
`the
`object. Thus, it specifies the type of transient array, either CLEAR_ON_R::~
`
`CLEA~_ON_DESELECT. Two constants in the class JCSystem are used to denote tor
`~~~~:
`~
`
`array
`// CLEAR_ON_RESET type of transient
`
`public static
`final byte CLEAR_ON_RESET
`
`array
`// CLEAR_ON_DESELECT type of transient
`
`public static
`final byte CLEAR_ON_DESELECT
`
`The following code fragment creates a CLEAR_ON_DESELECT
`array:
`
`byte[] buffer=
`JCSystem.makeTransientByteArray (BUFFER_LENGTH,
`JCSystem.CLEAR_ON_DESELECT);
`
`4.3.4 Querying Transient Objects
`
`An applet may need to access an object that is created by a different applet. The
`class JCSystem provides a convenient query method for an applet to determine
`whether an object being accessed is transient:
`
`public static byte isTransient(Object
`
`theObject)
`
`The method i sTransi ent returns a transient type constant (either CLEAR_ON_RESET
`
`or CLEAR_ON_DESELECT) or the constant )(System.NOT _A_ TRANSIENT _OBJECT
`to indi(cid:173)
`cate that the object is null or is a persistent object.
`
`4.4 A Few Words about Object Creation and Deletion
`
`• t
`Because memory in a smart card is very scarce, neither persistent nor transi:.
`objects should be created willy-nilly. If there isn't sufficient nonvolatile space av the
`able when an applet tries to create a persistent object using the new operator, E
`.
`
`RESOURC •
`JCRE will throw a SystemExcepti on with the reason code 1 JCSystem · NO_
`
`i
`
`sll·
`t It encaP. ,
`•
`.
`.
`.
`.
`•
`specif)
`A reason code 1s similar to the detailed message contained in a Java exception obJec •
`10
`!ates th~ exception cause identifier in a Java Card exception object. Chapter 6 shows hOW
`and remeve the reason code from an exception object.
`
`IPR2022-01239
`Apple EX1020 Page 62
`
`

`

`A FEW WORDS ABOUT OBJECT CREATION AND DELETION
`
`55
`
`When an applet calls one of the make-transient-object methods and there is insuffi(cid:173)
`cient RAM space available, the JCRE throws a SystemExcepti on with the reason
`codeJCSystem.N0_TRANSIENT_SPACE.
`Once created, both persistent and transient objects are reachable as long as
`they are referenced from the stack, from class static fields, from fields in other
`existing objects, or from the JCRE. When all the references to an object are
`dropped, the object becomes unreachable. Whether the space the object occupies
`can be reclaimed depends on whether a garbage collector is implemented in the
`virtual machine. Java Card technology does not require a JCRE implementation to
`include a garbage collector, because it is not feasible to do so in low-end smart
`cards. Chapter 13 provides programming tips on how to reuse objects in applets
`when a garbage collector is not supported.
`
`IPR2022-01239
`Apple EX1020 Page 63
`
`

`

`CHAPTER 5
`Atomicity and Transactions
`
`Smart cards are emerging as a preferred device in such applications as storing per(cid:173)
`sonal confidential data and providing authentication services in a mobile and distrib(cid:173)
`uted environment. However, with smart cards, there is a risk of failure at any time
`during applet execution. Failure can happen due to a computational error, or, more
`often, a user of the smart card may accidentally remove the card from the CAD, cut(cid:173)
`ting off the power supply to the card CPU and terminating execution of any applets.
`Such premature removal of the smart card from the CAD is called tearing, or card
`tear. The risk of incomplete execution presents a challenge for preserving the integ(cid:173)
`rity of operations on sensitive data in a smart card.
`The JCRE provides a robust mechanism to ensure atomic operations. This
`mechanism is supported at two levels. First, the Java Card platform guarantees
`that any update to a single field in a persistent object or a single class field is
`atomic. Second, the Java Card platform supports a transactional model, in which
`an applet can group a set of updates into a transaction. In this model, the atomicity
`of all the updates is ensured.
`This chapter explains what atomicity means in the Java Card platform and
`how applet developers can program an applet by using transactions to protect data
`integrity.
`
`5.1 Atomicity
`
`On the Java Card platform, atomicity means that any update to a single persistent
`object field (including an array element) or to a class field is guaranteed to either
`complete successfully or else be restored to its original value if an error occurs dur(cid:173)
`ing the update. For example, a field in an object currently contains a value 1, and it
`is being updated with a value 2. The card is accidentally tom from the CAD at the
`
`57
`
`IPR2022-01239
`Apple EX1020 Page 64
`
`

`

`58
`
`CHAPTER 5 ATOMICITY AND TRANSACTIONS
`
`critical moment when the card is overwriting the field. When power comes back, the
`field is not left with a random value but is restored to its previous value, 1.
`The concept of atomicity applies to the contents of persistent storage. It
`defines how the JCRE handles a single data element in the case of a power loss or
`other error during an update to that element. The JCRE atomicity feature does not
`apply to transient arrays. Updating an element of a transient array does not pre(cid:173)
`serve the element's previous value in case of power loss. The next time the card is
`inserted into a CAD, elements of a transient array are set to their default values
`(zero, false, or null).
`
`5.2 Block Data Updates in an Array
`
`The class javacard. framework. Uti l provides a method arrayCopy that guarantees
`atomicity for block updates of multiple data elements in an array:
`
`short arrayCopy
`public static
`(byte[] src, short srcOff, byte[] dest,
`
`short desOff, short length)
`
`The Uti l . arrayCopy method guarantees that either all bytes are correctly copied or
`the destination array is restored to its previous byte values. If the destination array is
`transient, the atomic feature does not hold.
`However, arrayCopy requires extra EEPROM writes to support atomicity, and
`thus it is slow. An applet might not require atomicity for array updates. The
`Uti l . arrayCopyNonAtomi c method is provided for this purpose:
`
`short arrayCopyNonAtomic
`public static
`(byte[] src, short srcOff, byte[] dest, short desOff, short length)
`
`The method arrayCopyNonAtomic does not use the transaction facility during the copy
`operation even if a transaction is in progress. So this method should be used only if
`the contents of the destination array can be left in a partially modified state in the
`event of power loss in the middle of the copy operation. A similar method,
`Uti l. arrayFi 11 NonAtomi c, nonatomically fills the elements of a byte array with a
`specified value:
`
`short arrayFillNonAtomic
`public static
`(byte[] bArray, short bOff, short blen, byte bValue)
`
`-
`
`IPR2022-01239
`Apple EX1020 Page 65
`
`

`

`TRANSACTIONS
`
`59
`
`5.3 Transactions
`
`Atomicity guarantees atomic modification of a single data element. However, an
`applet may need to atomically update several different fields in several different
`objects. For example, a credit or debit transaction might require a purse applet to
`increment the transaction number, update the purse balance, and write a transaction
`log all as an atomic unit of work.
`Readers may be familiar with the use of the database transaction notions of
`begin, commit, and rollback to ensure that updates to multiple values are either
`completed in their entirety or not at all. Java Card technology supports a similar
`transactional model, with commit and rollback capability to guarantee that com(cid:173)
`plex operations can be accomplished atomically; either they successfully complete
`or their partial results are not put into effect. The transaction mechanism protects
`against such events as power loss in the middle of a transaction and against pro(cid:173)
`gram errors that might cause data corruption should all steps of a transaction not
`complete normally.
`
`5.3.1 Commit Transaction
`
`A transaction is started by invoking the method JCSystem. begi nTransacti on and
`ended by calling the method JCSystem. commi tTransacti on:
`
`JI begin a transaction
`JCSystem.beginTransaction();
`
`in a set of updates of persistent
`// all modifications
`JI are temporary until
`the transaction
`is committed
`
`data
`
`II commit a transaction
`JCSystem.commitTransaction();
`
`fields or array elements
`The changes within a transaction are conditional-the
`appear to be updated. Reading the fields or array elements back yields their latest
`conditional values, but the updates are not committed until the JCSystem. commit(cid:173)
`Transacti on method is called.
`
`S.3.2 Abort Transaction
`
`Transactions can be aborted either by an applet or by the JCRE. If an applet
`encounters an internal problem, it can expressly cancel the transaction by calling the
`
`IPR2022-01239
`Apple EX1020 Page 66
`
`

`

`60
`
`CHAPTER 5 ATOMICITY AND TRANSACTIONS
`
`method. Aborting a transaction causes the JCRE to
`JCSystem.abortTransaction
`throw away any changes made during the transaction and to restore conditionally
`updated fields or array elements to their previous values. A transaction must be in
`progress when the abortTransacti
`on method is invoked; otherwise, the JCRE
`throws a Transacti onExcepti on.
`When the JCRE regains programmatic control on return from an applet with a
`transaction still in progress-that
`is, when the applet did not explicitly commit or
`abort an ongoing transaction-the
`JCRE automatically calls the abortTransac(cid:173)
`ti on method. Similarly, the JCRE aborts a transaction if an exception is thrown
`within the transaction and the exception is not handled by the applet.
`If power is lost or an error occurs during a transaction, the JCRE invokes a
`JCRE internal rollback facility the next time the card is powered on to restore the
`data involved in the transaction to their pretransaction values.
`In any case, both transient and persistent objects created during a transaction
`that fails ( due to power loss, card reset, computational error, or a program abort
`action) are deleted and their memory is freed by the JCRE.
`
`5.3.3 Nested Transaction
`
`Unlike most database transactions, transactions in the Java Card platform cannot be
`nested. There can be only one transaction in progress at a time. This requirement is
`due to the limited computing resources of smart cards.
`If JCSystem. begi nTransacti on is called while a transaction is already in
`progress, the JCRE throws a Transacti onExcepti on. An applet can discover
`whether a transaction is in progress by invoking the method JCSystem. transaction(cid:173)
`Depth. The method returns 1 if a transaction is in progress, 0 otherwise.
`
`5.3.4 Commit Capacity
`
`To support the rollback of uncommitted transactions, the JCRE maintains a commit
`buffer where the original contents of the updated fields are stored until the transac(cid:173)
`tion is committed. Should a failure occur before a transaction is completed, the par(cid:173)
`ticipating fields in the transaction are restored to their original contents from the
`commit buffer. The more operations inside a transaction block, the larger the com(cid:173)
`mit buffer needs to be to accommodate them.
`The size of the commit buffer varies from one implementation to another,
`depending on the available card memory. In general, the commit buffer allocated
`in a JCRE implementation is large enough to accommodate most applets' needs(cid:173)
`an applet typically accumulates tens of bytes during a transaction. However,
`because smart card resources are limited, it is important that only the updates in a
`
`IPR2022-01239
`Apple EX1020 Page 67
`
`

`

`TRANSACTIONS
`
`61
`
`logical unit of operations are included in a transaction. Putting too many things in
`a transaction may not be possible.
`Before attempting a transaction, an applet can check the size of the available
`commit buffer against the size of the data requiring an atomic update. The class
`JCSystem provides two methods to help applets determine how much commit
`capacity is available on a Java Card platform implementation.
`
`• JCSystem. getMaxCommi tCapaci ty() returns the total nu