80
`
`Java Card for E-Payment Applications
`
`smart card and its applications. These are discussed in detail in later sections
`of this chapter.
`Java Card is characterized by the following major benefits:
`
`• Platform independence. Java Card applications written in accordance
`with the specifications are intended
`to run on any Java Card-com(cid:173)
`pliant smart card. This feature was thought to ensure a high degree
`of portability of Java Card applications. Unfortunately, individual
`smart card manufacturers
`frequently
`introduce their own packages
`with a manufacturer-dependent
`API
`( especially security-related
`APis) or still support different versions of Java Card. This signifi(cid:173)
`cantly decreases the portability of Java Card applications.
`
`• Multiple-application support. More than one application can be run
`on a Java Card technology smart card. Furthermore, the data of each
`application is securely protected from any other application run on
`the same card.
`
`• Power of Java. Java Card inherits many benefits of the Java program(cid:173)
`ming language. In the particular case of smart cards, such benefits
`are object-oriented
`programming
`and
`language-level security.
`However, some limitations on Java introduced
`in Java Card (see
`Section 8.2) frequently lead to a style of programming that is differ(cid:173)
`ent from conventional Java. Another advantage of Java Card is that
`its applications can be developed using any development tool or
`environment for standard Java.
`
`The Java Card architecture is illustrated in Figure 8 .1. As can be seen, it
`looks very similar to traditional Java. The smart card operating system (OS)
`is layered on top of a smart card microcontroller and is aimed at providing
`common services like file and data management, communication, and com(cid:173)
`mand execution. From the communication point of view, Java Card is fully
`compliant with ISO/IEC 7816. In particular, Java Card supports communi(cid:173)
`cation protocols 1 and commands
`in accordance with ISO/IEC 7816-3 and
`ISO/IEC 7816-4, respectively.
`The Java Card run-time environment QCRE) is layered on top of the
`smart card operating system and consists of the Java Card Virtual Machine
`0CVM), the Java Card API, also referred to as the framework, and native
`
`I. T == 0 and T == I protocols.
`
`IPR2022-01239
`Apple EX1022 Page 52
`
`

`

`Java Card Basics
`
`81
`
`Java Card API
`
`Java Card virtual
`machine
`
`-
`
`-
`
`-~~----
`
`-"
`
`Native methods
`
`Java Card Runtime Environment
`
`Smart card operating system
`
`Smart card microcontroller
`\
`'
`,,
`\
`~------------------------------~
`Figure 8.1 Java Card architecture.
`
`-------------
`
`I
`I
`
`/
`
`;/
`
`methods. Native methods are needed to implement certain special platform(cid:173)
`dependent operations like 1/0 operations or cryptographic operations in a
`compact and efficient way. That is why the implementation of such opera(cid:173)
`tions interacts directly with the smart card operating system and is usually
`done in languages other than Java (typically, C or Assembler). The Java Card
`API is formed by a number of packages containing classes dedicated to vari(cid:173)
`ous purposes (see Chapter 1 I). In addition to the standard Java Card API,
`particular JCRE implementations frequently contain some manufacturer(cid:173)
`specific extension APis. On the one hand, they provide some additional
`functions, but on the other, they decrease the cross-platform portability of
`Java Card applications.
`Java Card applications, called card applets or simply applets, written in
`the Java programming language are located on the topmost level of the Java
`Card architecture. More than one applet can be run on a card. Each applet
`on a card is uniquely identified by its AID. Chapter 10 of this book addresses
`security issues involved with the Java Card's multiple-application support.
`The main task of the JCVM is to execute an applet bytecode on a card
`and to provide the Java language support. The core difference between the
`JCVM and the conventional Java Virtual Machine is that the first one is
`actually split into two independent parts. One part of JCVM, called the Java
`Card Converter, is executed off-card, for instance, on a personal computer.
`
`IPR2022-01239
`Apple EX1022 Page 53
`
`

`

`82
`
`Java Card for E-Payment Applications
`
`The second part ofJCVM is run on-card and is capable of applet code exe CU-
`tion, managing classes, and providing interapplet security mechanisms. In
`contrast to Java, the lifetime of the on-card JCVM is limited only by the life(cid:173)
`time of a smart card. In other words, the on-card JCVM cannot be stopped
`and then started new again-it always runs on a card and is merely temporar(cid:173)
`ily paused when power is removed from the card.
`The Java Card Converter is a software tool that prepares a card applet
`files put into one package) for uploading to a
`bytecode (all applet class
`card. This preparation includes verification of classes to be loaded, various
`checks for Java Card-specific restrictions and violations, allocation and crea(cid:173)
`
`tion of the applet data structures, and resolution of symbolic references to
`the applet data structures. The result of the conversion is a convened applet
`(cap) file containing a complete image of the applet prepared and optimized
`for an execution on a card.
`Figure 8.2 illustrates the principle described above and shows the main
`steps of card applet development. A card applet code can be written and
`compiled using any Java development tool and environment. Debugging and
`testing is a different case-because of the specifics of Java Card and the use of
`manufacturer-specific packages, this can be done in most cases only with the
`help of development tools provided by the smart card manufacturer.
`After compilation of all source j ava files related to the applet, the
`resulting class files are passed to the Java Card Converter, which generates
`the applet cap file as an output. The applet cap file then can be uploaded to
`a card. Java Card specifications do not define exactly how the applet cap ftle
`is uploaded to a card-this also remains a manufacturer-specific issue.
`
`Any Java
`development tool
`t
`j ava files
`
`',
`
`Java compiler
`t
`class
`
`files
`
`....
`,,..-
`
`Java Card
`technology smart
`card
`
`cap file
`
`.H
`
`Java Card
`converter
`' '
`
`C
`
`Figure 8.2 Java Card applet preparation.
`
`IPR2022-01239
`Apple EX1022 Page 54
`
`

`

`Java Card Basics
`
`83
`
`A few words must be said about how an applet is uploaded to a card.
`Any Java Card technology smart card contains a special application called the
`installation program that is capable of loading an applet cap file and storing
`it on the card. Thus, there is no need for J CVM to take care of loading the
`applet-this
`is accomplished by the installation program. From an architec(cid:173)
`tural point of view, the installation program can be seen as an ordinary Java
`Card application layered on top of JCVM and implementing an applet cap
`file upload over certain format APDUs sent to the card by a terminal.
`Note that, in order to increase applet uploading security, certain JCRE
`implementations allow the applet cap file to be uploaded in a digitally
`signed and encrypted manner. In this case, the applet is uploaded successfully
`only if the applet' s digital signature is successfully verified on the card.
`Another remarkable feature of Java Card is that it does not provide
`ISO/IEC 7816-4 file system support on-card. In other words, the Java Card
`API has no means of working with files in terms of creating, writing, reading,
`and so forth. All functions related to file representation and handling should
`be implemented within an applet. Although this looks like a restriction, it
`gives more flexibility and allows implementation of only those file support
`features that are really needed by an applet.
`Initially, the plan was to provide file system support on Java Card.
`Even the previous version of Java Card, Java Card 2.0, contained a set of
`classes dedicated to operations on files. It is said that manufacturers could
`not come to an agreement on an underlying API and therefore file system
`support was left out of Java Card 2.1.
`A practical object-oriented implementation of a Java Card file system is
`demonstrated in Part IV of this book.
`JCVM, JCRE, and the Java Card API are defined by Sun Microsystems
`Inc. specifications [1-3], which are available online. 2 As of February 2001,
`not all existing Java Card implementations were based on Java Card 2.1. For
`instance, iButton from Dallas Semiconductor and Schlumberger Cyberflex
`follow the Java Card 2.0 specification.
`In May 2000, the Java Card 2.1.1 specification was released [ 4]. In
`comparison with Java Card 2.1, Java Card 2.1.1 contains a number of minor
`improvements and pays more attention
`to some aspects of Java Card
`implementation.
`
`2. http://java.sun.com/ products/javacard.
`
`IPR2022-01239
`Apple EX1022 Page 55
`
`

`

`84
`
`Java Card for E-Payment Applications
`
`8.2 Differences from Java
`
`A smart card is a resource-constrained device. It cannot provide the amounts
`of memory and high performance
`that are available on modern computer
`architectures. That is why it is impossible to implement the standard Java
`platform in a one-to-one manner on a smart card. The decision was made,
`therefore, to implement Java Card as a subset of standard Java, omitting
`some features and adding some restrictions.
`First of all, because of the resource constraints and limited CPU per(cid:173)
`formance, Java Card does not support multithreading. Second, Java Card does
`not support dynamic class loading, for an obvious reason: It is very problem(cid:173)
`atic and almost impossible to ensure loading of additional classes to the card
`during applet execution. Object cloning is also not supported by Java Card.
`All objects once created by an applet will exist as long as the applet
`exists, that is, until the applet is deleted from the card. This means that all
`objects3 created by the applet are persistent, that is, their values are preserved
`when power is removed from the card. Therefore, Java Card does not need
`and does not support garbage collection. As a consequence, the method
`is not supported. This feature also increases applet safety:
`finalize
`()
`References to nonexistent objects are avoided because objects cannot be
`destroyed during an applet' s lifetime. On the other hand, implementation
`of garbage collection could be quite useful in that it could prevent a loss of
`memory occupied by a dynamic object that leaves the applet' s scope. Some
`Java Card implementations,
`like iButton from Dallas Semiconductors, sup(cid:173)
`port garbage collection.
`The following sections discuss in detail certain differences between Java
`Card and Java.
`
`8.2.1 Primitive Data Types and Arrays
`
`Like Java, Java Card supports such primitive data types as byte, short, and
`boolean. A byte is an 8-bit signed number with values that can range from
`-128 to 127. A short is a 16-bit signed number with values that can range
`from -32,768 to 32,767. A boolean value is represented internally by a byte.
`In contrast to Java, Java Card does not support such data types as float,
`is optional; that is, some par(cid:173)
`long, and char at all. Data type int
`double,
`ticular Java Card implementations may support it, some not. A summary of sup(cid:173)
`ported and unsupported Java Card primitive data types is given in Table 8.1.
`
`3. Except transient objects that are created in a special manner and whose value is resec
`upon certain Java Card system events.
`
`. -
`
`IPR2022-01239
`Apple EX1022 Page 56
`
`

`

`Java Card Basics
`
`85
`
`►
`
`r
`..
`
`Table 8.1
`Supported and Unsupported Primitive Data Types in Java Card
`
`Data Type Width (bits) Supported?
`
`byte
`
`short
`
`boolean
`
`int
`
`char
`
`float
`
`long
`
`double
`
`8
`16
`8
`32
`16
`32
`64
`64
`
`Yes
`Yes
`Yes
`Optional
`No
`No
`No
`No
`
`Java Card supports only one-dimensional arrays, not multidimensional
`arrays. This limitation is also because of the limited resources available on a
`Java Card technology smart card. As in Java, elements of an array may be of
`any supported primitive data type or objects. The following example demon(cid:173)
`strates valid declarations of arrays:
`
`= new byte[3];
`byte byte_array[]
`= {O, 1, 2} ;
`byte
`states[]
`= new PIN[3];
`PIN app_pins[]
`II references
`to PIN objects
`
`II array
`
`containing
`
`3
`
`The following array declarations are invalid because they declare multidi(cid:173)
`mensional arrays:
`
`byte a [] [ ] = new byte [ 3] [ 3] ;
`= new boolean[5]
`boolean
`flags[][]
`
`[5];
`
`As in Java, Java Card arrays are represented by objects. This means that
`methods of the class Object
`can be applied to them. For instance, an equal(cid:173)
`ity of two array references can be checked using the method equa 1 s ( ) of
`class:
`the Object
`
`( states.equals(byte_array)
`. . .
`
`if
`
`}
`
`) {
`
`IPR2022-01239
`Apple EX1022 Page 57
`
`

`

`86
`
`Java Card for E-Payment Applications
`
`The method returns a boolean value indicating whether the array references
`are equal or not. More advanced operations on arrays (copying, comparing,
`etc.) can be performed with the help of static methods of the class Util
`which is a member of the Java Card framework classes.
`
`)
`
`8.2.2 Operations and Type Casting
`
`Java Card supports all arithmetic, logical, and bit-wise operations defined
`in Java. However, typecasting rules used in Java Card are slightly different
`from rules defined in Java. The main typecasting rule of Java Card states that
`results of intermediate or unassigned operations must be explicitly cast to
`a type of a desired value. An intermediate calculation is part of a complex
`expression involving a number of operations on a number of values. A result
`of an unassigned operation is not assigned to any variable. An example of an
`unassigned operation could be an array index calculation.
`The reason behind the explicit typecasting rule is that, in Java, results
`of intermediate or unassigned operations are cast to the type int by default.
`However, Java Card supports the type int only optionally, which implies
`that not all Java Card implementations will have it. Hence, casting either to
`the types short or byte must be specified explicitly. The following exam(cid:173)
`ple demonstrates correct explicit casting of results of intermediate or unas(cid:173)
`signed operations:
`
`byte byte_array[]
`byte b;
`shorts;
`b = byte_array[(byte}
`b = (byte}
`( (byte}
`
`= new byte[3];
`
`(s-1)];
`(s+6} *2 } ;
`
`// unassigned
`//
`intermediate
`
`operation
`operation
`
`The example below demonstrates erroneous typecasting:
`
`b = byte_array[s+l];
`b = (byte}
`( (s+6} *2 } ;
`
`Typecasting errors related to Java Card restrictions are reported by the Java
`Card Converter.
`
`8.2.3 Exceptions
`
`In principle, Java Card supports all Java mechanisms for exception han(cid:173)
`try, catch,
`dling. Card applets may contain
`and finally
`statements.
`
`IPR2022-01239
`Apple EX1022 Page 58
`
`

`

`es•-
`
`Java Card Basics
`
`87
`
`Obviously, exceptions related to unsupported features, like multithreading
`or dynamic class loading, are not supported. Moreover, the constrained
`resources of a smart card also have an impact, resulting in the following three
`features of Java Card exception handling:
`
`1. Not all of the Java exception classes are supported.
`
`2. Descriptive string messages in exceptions are not supported.
`Instead, a reason code of the type short
`is used.
`
`instances of exception classes is not recommended.
`3. Creating
`Instead, static J CRE instances of exception classes should be used.
`
`We now discuss each aspect of this list in detail. All Java Card
`exceptions are subclasses of a superclass Throwable. Exception classes are
`stored in two core packages of the Java Card framework, j ava. lang and
`j avacard.
`f rarnework. Exceptions contained in the first package repre(cid:173)
`sent erroneous situations related to Java language programming. Table 8.2
`gives a general overview of exceptions contained in the j ava. lang package.
`
`Table 8.2
`j ava. lang Package Exceptions
`
`Exception
`
`Description
`
`Ari thmeticException
`
`ArrayindexOu tOfBoundsException
`
`ArrayStoreException
`
`ClassCastException
`
`NegativeArraySizeException
`
`NullPointerException
`SecurityException
`
`Indicates a certain arithmetic run-time
`error. An example could be the
`division-by-zero error.
`Indicates that an array index is outside of
`the array boundaries.
`Indicates that there was an attempt to
`store an object of an incorrect type in an
`array.
`Indicates an incorrect attempt to cast an
`instance of one class to another class.
`Indicates an attempt to create an array with
`a negative size.
`Indicates a null reference access.
`Indicates a violation of access rights for a
`certain object.
`
`IPR2022-01239
`Apple EX1022 Page 59
`
`

`

`88
`
`Java Card for E-Payment Applications
`
`One important fact must be mentioned: Java Card specifications do
`not define J CVM behavior for the case in which a certain exception is
`thrown and is not caught by a card applet. As a first consequence of an
`uncaught exception, JCVM will halt, that is, card applet execution will be
`stopped. What will happen then depends on the particular Java Card imple(cid:173)
`mentation. For instance, the Sm@rtCafe Java Card technology smart card
`from Giesecke & Devrient, which is used to implement a sample EMV
`application later in this book, will respond to a terminal with a status word
`indicating a general card error.
`Exceptions contained in the j avacard.
`framework package repre(cid:173)
`sent smart card-specific erroneous situations that occur during a card applet
`execution. Table 8.3 gives their general description.
`Java Card does not support the object type string.
`Therefore, Java
`Card exceptions do not provide descriptive string messages. Instead, addi(cid:173)
`tional information about the reason for an exception is reported by a reason
`code. The reason code is a value of the type short. A remarkable thing about
`exception reason codes is that most exception classes, mainly smart card-spe(cid:173)
`cific exception classes, contain predefined static constants representing main
`reason codes typical of the underlying exception.
`To conclude the description of Java Card exceptions, a few words must
`be said about exception usage. First of all, it is strongly recommended not to
`create a new exception object each time an exception is thrown. Instead, all
`exception objects needed by an applet should be created during the applet
`initialization phase, the references to them stored, and the objects reused
`
`j avacard.
`
`Table 8.3
`framework Package Exceptions
`
`Exception
`
`Description
`
`APDUException
`
`ISOException
`
`PINException
`
`Sys temException
`
`TransactionException
`
`UserException
`
`Indicates errors related to APDU handling.
`Is used to issue a response APDU with a given
`status word.
`Indicates errors related to PIN handling.
`Indicates errors occurring on the Java Card at
`system level.
`Indicates errors occurring during transaction
`processing.
`Is used to implement user-defined exceptions.
`
`IPR2022-01239
`Apple EX1022 Page 60
`
`

`

`Java Card Basics
`
`89
`
`each time an exception must be thrown. In this context, « reused" means that
`an exception object is created just once but thrown as many times as needed
`with a desired reason code. The reasoning behind such a practice is obvious:
`Creating new instances of exception classes will simply waste the limited card
`memory available.
`There is an even more efficient method of exception throwing. JCRE
`precreates all exceptions defined in the Java Card APL In other words, J CRE
`creates instances of all Java Card exceptions by default. This means that these
`precreated exception objects can be used instead of objects created by a card
`applet, so there is no need to create most of the exception objects at all. All
`exceptions defined in the j avacard.
`package (see Table 8.3)
`framework
`have a static method throwI
`t ( ) that throws a JCRE (a precreated) instance
`of the class.
`this principle with an example. Assume that an
`Let us demonstrate
`applet must report that the instruction
`(INS value) given in a command
`APDU is not supported. This can be achieved with the following statement:
`
`ISOException.throwit(IS07816.SW_INS_NOT_SUPPORTED);
`
`First of all, execution of this statement will throw a JCRE
`instance of
`exception class with the desired reason code. As a
`the ISOException
`consequence, this exception will force J CRE to issue a response APD U
`status word 6D 00 H defined by the static
`with the ISO 7816-4
`of the Java Card framework interface
`constant SW_INS_NOT_SUPPORTED
`IS07816.
`
`8.3 Java Card Applet
`
`The lifetime of a Java Card applet consists of a number of stages. After being
`compiled and converted to a cap file (see Section 8.1) by the Java Card Con(cid:173)
`verter, the applet is loaded to a card by the card installation program. This is
`the moment when the on-card life of the applet begins. First of all, the applet
`must be installed and registered within J CRE. If the applet registration
`is accomplished successfully, the applet becomes available for selection via
`SELECT APDU, sent to the card, and processed by JCRE. The selected applet
`is ready to receive incoming command APDUs delivered to it by JCRE, to
`process them, and to generate response APDUs that are sent out by JCRE.
`As pointed out in Section 8.1, the lifetime of a card applet is limited by
`the lifetime of the Java Card Virtual Machine, that is, by the lifetime of the
`
`IPR2022-01239
`Apple EX1022 Page 61
`
`

`

`90
`
`Java Card for E-Payment Applications
`
`card. However, note that certain Java Card implementations may allow
`clearing of the application area of a card's EEPROM. In this way, all applets
`existing on the card and all data objects belonging to them are completely
`deleted from the card.
`The Java Card API provides handy mechanisms for card applet imple(cid:173)
`mentation. Any card applet is implemented on the basis of an abstract
`located in the j avacard.
`package. The
`base class Applet
`framework
`class Applet
`contains all methods necessary for applet installation, selec(cid:173)
`tion, and deselection, and APDU processing. Those methods and aspects
`related to them are discussed in detail in the following section.
`
`- 8.3.1 Installation and Registration
`
`After an applet has been successfully loaded to the card, it must be installed.
`The installation procedure is initiated by the INSTALL APDU sent to the
`card. Java Card specifications do not define the exact format of this APDU;
`they instead leave it up to the manufacturer. The INSTALL APDU is
`received and processed by the same card application that loaded the applet
`cap file to the card-the
`installation program.
`On receiving the INSTALL APDU, the card installation program sim(cid:173)
`ply invokes a special method of the applet that is to be installed. This method
`is called install
`and is defined in the abstract class Applet
`extended
`by any card applet. The installation program also passes to the ins tall
`method applet initialization options received with the INSTALL APDU.
`The applet install
`method is called only once (obviously, an applet is
`installed on a card only once).
`The core task of the install
`is to create an instance
`method
`of the loaded applet class and to register the instance within JCRE. Natu(cid:173)
`rally, the applet constructor is called when the applet instance is created. The
`constructor may create data objects used by the applet, and it is good pro(cid:173)
`gramming practice to create all applet objects in the applet constructor.
`The applet instance registration is mandatory: If it is not performed,
`the applet installation fails. The registration is done via invocation of the
`method of the applet. The register
`method exists in two ver(cid:173)
`register
`sions, one with parameters, the other without. The register
`method with
`parameters is used to specify an AID of the applet instance.
`Summarizing everything said above, the main steps of an applet instal(cid:173)
`lation procedure (assuming that the applet is already loaded to the card) are
`as follows:
`
`IPR2022-01239
`Apple EX1022 Page 62
`
`

`

`Java Card Basics
`
`91
`
`1. Card installation program receives INSTALL APDU and invokes
`the ins tal 1 method of the applet to be installed.
`2. An instance of the applet class is created in the ins tal 1 method.
`3. The applet instance is registered via invocation of the register
`method.
`
`If the applet is installed successfully, J CRE makes it available for selection.
`
`8.3.2 Selection and Deselection
`
`Any applet installed on a card must be explicitly selected before command
`APO Us are sent to it. An applet is selected by means of the SELECT APDU
`with the following defined format:
`
`CLA
`
`00
`
`INS
`A4
`
`Pl
`
`04
`
`P2
`
`Le
`
`Data
`
`00 AID length AID
`
`The data field of the APDU contains an AID of the applet to select. Other
`fields of the SELECT APDU are fixed and defined in accordance with
`1S0/IEC 7816-4. If JCRE finds an applet with the given AID, it marks it as
`selected and forwards it to it all further command APDUs. If no applet with
`such an AID is found, JCRE reports the fact with the respective status word
`in the response APDU.
`After a card reset, all applets on the card are in a suspended state. In
`other words, none of the applets is marked as selected. Therefore, if J CRE
`receives any4 APDU different from SELECT,
`it will answer with the
`response APDU indicating that no applet is selected (status word 69 99 H).
`Note that some Java Card implementations may allow specification of a
`default applet. A default applet is marked as selected after a card reset and
`JCRE will forward to it all received APDUs even if there was no explicit
`SELECT command. However, Java Card 2.1 specifications address no
`means for defining a default applet and leave this question up to the
`manufacturer.
`contains two methods related to applet
`The abstract class Applet
`selection and deselection. The first one is called select
`() and is invoked
`
`4. Except manufacturer-proprietary command APDUs related to card personalization and
`management, for example, applet load or install APDUs. Command APDUs of this kind
`are not considered further in this discussion.
`
`IPR2022-01239
`Apple EX1022 Page 63
`
`

`

`92
`
`Java Card for E-Payment Applications
`
`by JCRE whenever the applet becomes selected. An applet may perform
`operations needed for further processing of commands; for example, it may
`() method should return a
`change the values of internal flags. The select
`boolean value indicating whether it is ready to accept commands or not. By
`is returned.
`default, the value true
`The applet method deselect
`() is called by JCRE when a currently
`selected applet becomes deselected, that is, when another applet on the card
`is selected. Obviously, this method is not called when power is removed from
`the card.
`An interesting feature of SELECT APDU processing is that theAPDU
`is also passed to the applet after its selection by JCRE. This means that the
`applet also has possibilities of processing this APDU and answering it in a
`desired manner.
`Aspects related to the processing of command APDUs by an applet are
`addressed in the next section.
`
`8.3.3 APDU Processing
`
`Figure 8.3 demonstrates a general scheme for incoming APDU processing by
`JCRE. Applet selection mechanisms were presented in the previous section.
`The abstract class Applet extended by any Java Card applet contains the
`method process. This method is invoked by JCRE for each received com(cid:173)
`mand APDU. All operations dealing with processing the APDU, performing
`all necessary application-specific operations in response to the APDU, and
`preparing the response APDU are done in the applet process method.
`The process method has one single parameter. This parameter is an
`instance of the APDU class, another Java Card framework class located in the
`f rarnework package. This class provides a handy interface to
`j avacard.
`the communication facilities of a smart card and is designed in a protocol(cid:173)
`independent manner. Therefore, an applet developer does not have to deal
`with specifics of T = 0 or T = 1 protocols (those are the only protocols sup(cid:173)
`ported by Java Card 2.1)-all of them are "hidden" inside the APDU class
`and its methods implementation.
`A core field of the APDU class is a byte array buffer that is used
`for reading data of the incoming APDU and preparing data of the outgoing
`(response) APDU. In addition, the class APDU provides a number of meth(cid:173)
`ods for easy access to the byte buffer.
`If no exception is thrown during the process method execution,
`JCRE sends out data in the APDU buffer (if the response was constructed by
`the applet) with the success status word 90 00 H automatically attached. If
`
`IPR2022-01239
`Apple EX1022 Page 64
`
`

`

`Java Card Basics
`
`93
`
`Incoming APDU
`
`yes
`
`no Response APDU
`"no applet found"
`
`no
`
`yes
`
`no
`Response APDU ,,-<-
`"no applet selected
`
`Incoming APDU
`I
`Invoke applet's
`process method
`
`Select applet, invoke
`applet's select
`()
`method
`
`SELECT APDU
`
`ISOException
`is thrown
`
`Perform all
`operations
`
`Response APDU
`with respective SW
`
`Response APDU with SW 90 00
`or DATA and SW 90 00
`
`Figure 8.3 Command APDU processing by JCRE and an applet.
`
`(see Section 8.2.3), JCRE catches it
`the applet throws an ISOException
`and sends out a response APDU with the status word given in the exception
`reason code. If any other exception is thrown during the process method
`execution, JCRE will send out a response APDU with the status word «No
`precise diagnosis" 6F 00 H.
`The APDU class and the App 1 et calls are discussed in Chapter 11.
`
`References
`
`[I]
`
`[2]
`
`[3]
`
`[4]
`
`Sun Microsystems Inc., "Java Card 2.1 Virtual Machine Specification," Mar. 1999.
`
`Sun Microsystems Inc., "Java Card 2.1 Runtime Environment UCRE) Specification,"
`Feb. 1999.
`
`" F b
`f:
`I
`•
`•
`Sun M·
`tcrosystems Inc., "Java Card 2.1 Applicanon Programming nter ace,
`e .
`1
`999.
`
`Sun Microsystems Inc., "Java Card 2.1.1 Specifications. Release Notes," May 2000.
`
`IPR2022-01239
`Apple EX1022 Page 65
`
`

`

`Deployment of Java Oard Technology
`
`S art cards can in general be used in mobile phones, personal digital assis(cid:173)
`t:ts, set-top boxes, and other devices. Java Card technology supports plat(cid:173)
`form independence, makes it possible to implement multiple applications on
`a single card in a secure way, and allows downloading of applications after a
`card has been issued. In addition, Java is a programming language in wide(cid:173)
`spread use, which reduces the time-to-market for new smart card appli(cid:173)
`cations. All of these properties make Java Card interesting for a range of com(cid:173)
`mercial applications. The following sections give some examples of Java Card
`technology deployment.
`•
`In addition to industry and financial institutions, government agencies
`have expressed strong interest in Java Card-based products. For example,
`in 1999, Citibank1 issued multiple-application smart cards based on Java
`Card technology to General Services Administration employees. The cards
`provided a number of functions, including logical access, physical access,
`property management, e-ticketing, and e-boarding.
`
`9.1 Java Card Forum
`
`The Java Card Forum OCF)2 is an interindustry initiative to promote the
`Java Card API specification as the industry standard. It was founded by
`
`1 • http:/ /www.ciribank.org.
`2• http://www.javacardforum.org.
`
`95
`
`IPR2022-01239
`Apple EX1022 Page 66
`
`

`

`~~ .,
`.
`
`..,
`
`,t
`
`96
`
`Java Card for E-Payment Applications
`
`V
`
`Schlumberger and Gemplus in 1997 following JavaSoft's (a division by Sun
`Microsystems) announcement of the Java Card API in 1996. The member
`list includes chip manufacturers, card manufacturers, companies, and
`agencies in the financial, telecommunications, health care, transportation,
`and information technology sectors. Current work is focused on vertical
`market extensions to the core specification for GSM, banking, and informa(cid:173)
`tion technology.
`
`9.2 Card Management
`
`As soon as one starts loading and unloading applications to and from smart
`cards after they have been issued, the problem of managing a card population
`arises. This is called the card management problem.
`The Java Card Management QCM) Task Force of the JCF was initi(cid:173)
`ated in 1998 with the goal of defining a framework for a card management
`system (CMS). Specifically, the idea was to defi