CHAPTER 11
`Java Card Platform Security
`
`Secure processing is the fundamental reason for using smart cards. So security con(cid:173)
`siderations are paramount for smart card developers. This chapter centers on secu(cid:173)
`rity in the Java Card platform. It is organized in three sections. Section 11.1
`describes the security features in the Java Card platform. Section 11.2 discusses how
`these security features are enforced through a variety of mechanisms. Section 11.3
`highlights the security considerations
`in designing and implementing Java Card
`applets.
`This chapter is not intended to be a security specification. Rather, it aims at
`helping you to understand the overall security capabilities of the Java Card plat(cid:173)
`form. It also serves as a summary chapter of the topics that have been discussed in
`Part 2.
`Security must be considered from the point of view of an overall system. The
`Java Card platform is built on top of the smart card platform, which consists of the
`smart card hardware and native operating system, and the host system with which
`the card communicates. Smart card platform security is not within the scope of
`this book. Readers can find related discussions in smart card books, such as Smart
`Card Handbook by Rankl and Effing[l], Smart Card Developer's Kit by Guthery
`and Jurgensen[2], and Smart Card Security and Applications by Hendry[13].
`
`11.1 Java Card Platform Security Features
`
`The security features of the Java Card platform are a combination of the basics of
`Java language security and additional security protections defined by the Java Card
`Platform.
`
`151
`
`IPR2022-00413
`Apple EX1049 Page 153
`
`

`

`152 CHAPTER ll JAVA CARD PLATFORM SECURrrY
`
`11.1.1 Java Language Security
`
`The Java Card platfonn supports a subset of the Java programming language and
`virtual machine specifications appropriate for smart card applications. Therefore,
`the Java Card platfonn inherits the security features built into the supported subset
`of the Java language (as characterized in the following list). Java language security
`fonns the foundation of Java Card platform security.
`
`• The Java language is strongly typed. No illegal data conversions can be done,
`such as converting integers to pointers.
`
`• The Java language enforces boundary checks on array access.
`
`• The Java language has no pointer arithmetic. Thus, there is no way to forge
`pointers to allow malicious programs to snoop around inside memory.
`
`• Variables must be initialized before they are used.
`
`• The level of access to all classes, methods, and fields is strictly controlled. For
`example, a private method cannot be invoked from outside its defining class.
`
`11.1.2 Additional Security Features of the Java Card Platform
`
`In the very security-conscious world of smart cards, card issuers desire a secure
`computing platfonn to meet the special requirements of the smart card system. Fol(cid:173)
`lowing are additional security features defined in the Java Card platform:
`
`the Java Card platform, objects are
`• Transient and persistent object models-In
`stored by default in persistent memory. For security and perf onnance reasons,
`the Java Card platform allows temporary data, such as session keys, to be
`stored in transient objects in RAM. The lifetime of such objects can be de(cid:173)
`clared to be either CLEAR_ON_RESET or CLEAR_ON_DESELECT. The contents of a
`transient object are set to the object's default value (zero, fa 1 se, or nul 1) ei(cid:173)
`ther when the card is reset or when the currently selected applet is deselected.
`
`the Java Card platform, data are stored in
`• Atomiciry and transactions-In
`objects in persistent memory. Failure or power loss could occur during write
`operations on the data. To ensure data integrity, three security features are
`defined in Ja a Card technology. First, the Java Card platfonn guarantees that a
`single update to a field of a persistent object or a class will be atomic. When an
`error occurs during update, the platform ensures that the content of the field will
`be restored to its previous value. Second, the method arrayCopy in the class
`
`IPR2022-00413
`Apple EX1049 Page 154
`
`

`

`JAVA CARD PLATFORM SECURITY MECHANISMS
`
`153
`
`javacard. framework. Uti l guarantees atomicity for block updates of multi(cid:173)
`ple data elements in an array. Here, atomicity means that either all bytes are
`correctly copied or the destination array is restored to its previous byte val(cid:173)
`ues. Third, the Java Card platform supports a transaction model in which an
`applet can atomically update several different fields in different persistent
`objects. Either all updates in the transaction must take place correctly and
`consistently, or all persistent fields are restored to their previous values .
`
`• Applet firewall-The
`security and integrity of the system (the JCRE) and of
`each applet residing on a Java smart card are protected by the applet firewall.
`The applet firewall enforces applet isolation and separates the system space
`from the applet space. In the firewall scheme, each applet runs within a con(cid:173)
`text (object space). Applets cannot access each other's objects unless they are
`defined in the same package (and thus share the same context) or through
`well-defined and secure object-sharing mechanisms supported by the plat(cid:173)
`fmm.
`
`• Object sharing-Object
`sharing in the Java Card system is achieved in the
`following ways. First, the JCRE is a privileged user that has full access to
`applets and to objects created by applets. Second, an applet gains access to
`JCRE services and resources through JCRE entry point objects. Third, applets
`in different contexts can share objects that are instances of a class implement(cid:173)
`ing a shareable interface. Such objects are called shareable interface objects.
`Finally, applets and the JCRE can share data through global arrays.
`
`• Native methods in applets-Native methods are not executed by the Java Card
`virtual machine and so are not subject to the security protections of the Java
`Card platform. Therefore, postissuance applets (applets that are downloaded
`to the card after the card has been issued) are prohibited from containing
`native methods. ROM applets and preissuance applets that are controlled by
`card issuers are allowed to have native methods. The interface to native code
`from such applets is the proprietary technology of card vendors.
`
`11.2 Java Card Platform Security Mechanisms
`
`Security is a chain, and a single weak link can break it. The Java Card security fea(cid:173)
`tures are enforced through a number of mechanisms that are addressed at every level
`from the applet development process and the installation procedure to the runtime
`enforcement.
`
`IPR2022-00413
`Apple EX1049 Page 155
`
`

`

`1.54 CHAPTER JI JAVA CARD PLATFORM SECURITY
`
`11.2.1 Compile-Time Checking1
`
`An applet consists of one or more Java files. The Java code is compiled by using any
`tandard Java development environment, such as Sun's JDK or Symantec's Cafe.
`The binary files produced by the compiler from source code are called class files.
`The Java compiler performs extensive and stringent compile-time checking so
`that as many errors as possible are detected by the compiler. The Java language is
`trongly typed. Unlike C or C++, the type system has no loopholes. For example:
`
`• Object cannot be cast to a subclass without an explicit runtime check.
`
`• All references to methods and variables are checked to make sure that the
`objects are of the appropriate type.
`
`• The compiler checks that access controls (such as referencing a private vari(cid:173)
`able or method from another class) are not violated.
`
`• Integer cannot be converted into objects. Objects cannot be converted into
`integer .
`
`trictly ensures that a program does not access the value of an
`• The compiler
`uninitialized local variable.
`
`11.2.2 Class File Verification and Subset Checking
`
`tru rworth compiler can ensure that Java source code does not violate
`Although
`afety rule , clas files could come from a network that is untrustworthy. In the Java
`environmen~ all class files loaded in are checked by a verifier-a component in the
`Java virtual machine-before
`the are executed. The class file verifier goes through
`in se e.ral passe to ensure that they have the correct format and that their
`clas fil
`bytecodes adhere to a set of structural constraints. In particular, class files are
`checked LO en ure 1the following:
`
`• There are ino violanons of memory management and no stack underflow or
`erliow .
`
`• A ce
`re triolions are enforced: for example, private methods and fields can·
`not be aooessed outside their defining class.
`
`1 From Fin Ye'.llio ·s PfPCI" ""Lov.•-t.e-.d Secwiry in Ja a'l 15 ].
`
`IPR2022-00413
`Apple EX1049 Page 156
`
`

`

`JAVA CARD PLATFORM SECURITY MECHANISMS 155
`
`• Methods are called with appropriate arguments of the appropriate type .
`
`• Fields are modified with values of the appropriate type .
`
`• Objects are accessed as what they are. For example, an APDU object is always
`used as an APDU object, never as anything else .
`
`• No pointers are forged .
`
`• No illegal data conversions are done, such as converting integers to pointers .
`
`• Binary compatibility rules are enforced.
`
`Unlike the Java virtual machine, the Java Card virtual machine has a split
`architecture that consists of two parts: the converter running off card on a PC or a
`workstation and the interpreter running inside a card. The converter is the front
`end of the virtual machine and talces class files as input. During conversion, the
`class files of an applet are subject to the same level of rigorous verification as they
`would be by the Java virtual machine with its class file verifier at class-loading
`time. The converter can incorporate the verifier component of the Java virtual
`machine, or it can implement its own class file verifier.
`Because Java Card technology defines a subset of the Java language, the con(cid:173)
`verter must check class files further to ensure that only features in that subset are
`used. This step is called subset checking. During this step, the converter checks
`that the applet does not violate the following subset rules:
`
`• No unsupported data types are used (for example, variables of type char,
`long, double, and fl oat). Data of type int are used only if the Java Card in(cid:173)
`terpreter supports them.
`
`• No unsupported Java language features are used. For example, an applet
`should not have threads or multidimensional arrays.
`
`• Usage of certain Java operations are within limited ranges. The ranges of such
`operations on the Java Card platform are smaller than those of the Java plat(cid:173)
`form. For example, a package can have no more than 255 public classes· and
`interfaces, and an array can hold a maximum of 32,767 fields.
`
`• No potential overflow or underflow can occur that might cause arithmetic re(cid:173)
`sults to be computed differently than they would be on the Java platform (see
`Chapter 14).
`
`t
`
`IPR2022-00413
`Apple EX1049 Page 157
`
`

`

`J 56
`
`CHArTER I I JAVA CARD PU.TFORM SECURITY
`
`11.2.3 CAP File and Export File Verification
`
`The classes of an applet make up one or more packages. The converter talces all
`classes m· a package and converts them into a CAP file. The CAP file is then
`loaded onto a Java smart card and executed by the interpreter. In addition to creat(cid:173)
`ing a CAP file, the converter generates an export file representing the public APis
`of the package being converted. The export file is not used directly by the inter(cid:173)
`preter. It is used later to convert another package that imports classes from the
`package represented in the export file. The information in the export file is used
`for linking and external reference checking.
`The CAP file in the Java Card platform is of equal importance to the class file
`in the Java platform. It is an interoperable binary format for loading a Java pack(cid:173)
`age onto a Java smart card.
`In practice, there is no guarantee that a CAP file generated from verified class
`file by a trustworthy converter will immediately be loaded onto a Java smart card
`in a secure environment. Thus, the correctness and integrity of a CAP file cannot
`be taken for granted. It is the job of the CAP file verifier to ensure that the CAP
`file plays by the rules. Due to the limited memory space and computing power of
`a smart card, the CAP file verifier runs off card. The verifier performs static
`check on a CAP file before it is loaded onto a Java smart card.
`Because of the analogous role of class files and CAP files, the CAP file veri(cid:173)
`fier has a function similar to that of the class file verifier. That is, it ensures that a
`CAP file has the correct format and that the bytecodes in it adhere to a set of struc(cid:173)
`tural constraints. In particular, it checks the CAP file to ensure the following:
`
`• There are no violations of memory management and no stack underflows or
`overflows.
`
`• Access restrictions are enforced: for ex.ample, private methods and fields can-
`not be accessed outside the object
`
`• Methods are called with appropriate arguments of the appropriate type.
`
`• Field are modified with alues of the appropriate type.
`
`• Objects are accessed as what they are. For example, an APDU object is always
`used as an APDU object, never as anything else.
`
`• No pointers are forged.
`
`• No illegal data conversions are done. such as converting integers to pointers.
`
`• Binary oompatibility rules are enforced.
`
`IPR2022-00413
`Apple EX1049 Page 158
`
`

`

`JAVA CARD PLATFORM SECURITY MECHANISMS
`
`157
`
`that these checks are identical to those of the class file verifier. In addition the
`Note
`.
`'
`CAP file verifier enforces rules that are special to the CAP file structure and the Java
`Card environment.
`
`. The package and each applet defined in the package must have a valid AID
`that is between 5 and 16 bytes in length. The package AID and the applet
`AIDs must share the same RID number (the first 5 bytes in the Aills) .
`
`• An applet must define an i nsta 11 method with the correct signature so that
`instances of the applet can be appropriately created on the card .
`
`. The order of class and interface definitions in a CAP file must follow the rules
`that interfaces appear ahead of classes and superclasses appear ahead of sub(cid:173)
`classes. This ensures that the CAP file-loading and linking process can be
`handled sequentially on the card.
`
`, Toe ; nt flag is set if the int type is used in the CAP file. This check allows a
`Java Card implementation that does not support the int type to reject the CAP
`file during loading by simply checking the int flag.
`
`During verification (Figure 11.1 ), the CAP file verifier ensures that a CAP file
`~ internally consistent, is consistent with the export files it imports, and is consis(cid:173)
`tent with the export file that represents its APL The verifier also examines whether
`
`►
`
`verifier
`
`reject
`
`accept
`
`export file of
`this package
`
`CAP file of
`this package
`
`- -
`
`export files of the
`imported packages
`
`Figure 111 • CAP file verification
`
`IPR2022-00413
`Apple EX1049 Page 159
`
`

`

`J58 CHAPTER JI JAVA CARD PUTFORMSECUR/1l'
`
`the Java Card version rules, including those imposed for binary compatibility,
`2
`have be.en followed.
`If export files used during verification are not trustworthy, they should also be
`verified. Export file verification checks an export file both internally and against
`its corresponding CAP file to ensure that it is wellfonnatted and satisfies the con(cid:173)
`straints required by the Java Card virtual machine specification.
`
`ll.2.4 Installation Checking
`
`AP file installation i achieved through the cooperation of the off-card installation
`program and the on-card installer. Together, they load a CAP file, and, if the CAP
`fiJe define any applets, they create one or more applet instances. 3
`In tallation security consists of two levels. At the first level are the standard
`ecurity protection enforced by the installer and the JCRE, and at the second
`level are the ecurity policies dictated by the issuers. Together they protect against
`the fol]owing:
`
`,I
`ti ,.
`
`• In tallation data conuption
`
`• In tallation data tampering
`
`• In ompatibility between the CAP file and on-card resources
`
`• Illegal a cc s from outside the CAP file
`
`• In uffi aent resoaroes and other errors during installation and initialization
`
`• ln onsi tent st:ate due to card tearing or power loss during the process of in(cid:173)
`tall tion
`
`The mre me and integrity of a CAP file are verified off-card. The Java
`Card in taller does oot perform most of the traditional Java verifications at
`clas~..J ding rune. Before an data are written on the card, the installer first
`lhe card can support the CAP file. For example, the
`oho ~ m
`t.da
`
`1J1be b\'i Cw~
`
`t.nar,, oompanbiliry rules are defined in lheJava Card 2.1 Vinual Mac/tull
`
`!UlSD.'llcr imp\PIDCDDlioo. applet creacion can also be perf onned al a la1tf s!J&C. .
`-loading lime are perf onned by the class verifier as described ID
`'ffll.lttcalCl(i)D,li Al
`
`IPR2022-00413
`Apple EX1049 Page 160
`
`

`

`JAVA CARD PLATFORM SECURITY MECHANISMS
`
`159
`
`installer checks whether the card's available memory resources are sufficient for
`the CAP file. And if the card does not support the int type, the installer checks
`whether the CAP file contains any int usage; that is, it checks whether the int
`flag in the CAP file is set.
`When the CAP file is read in, it can be linked either on the fly or after the
`entire CAP file is loaded. The linking process includes resolving both internal and
`external references. The installer ensures that internal references are in fact local
`to the package's memory,5 and external references are linked to accessible loca(cid:173)
`tions of other packages and the JCRE. In addition, the installer ensures that the
`CAP file is binary compatible with the existing software on the card.
`Unlike the Java platform, the loading unit on the Java Card platform is a
`package (a CAP file). The installer ensures that the CAP file references only
`packages that are already on the card, because loading new classes incrementally
`is not supported.
`If the CAP file defines any applets, the installer can create instances of applets
`by calling their i nsta 11 methods. When an applet instance is created, a context is
`assigned to the applet instance. Multiple instances of the same applet and
`instances of multiple applets defined in the same package share one context,
`referred to as the group context.
`The installation process is transactional. If an error, card tearing, or power
`loss occurs during installation, the installer discards the CAP file and any applets
`it had created during installation and recovers the space and the previous state of
`theJCRE.
`Beyond the minimum security requirements defined in the installer and the
`JCRE, Java Card technology does not standardize the installation policy. Issuers
`have the flexibility of configuring the card to allow installation of applets from
`several sources, possibly engaging different levels of protection for applets from
`different sources.
`The simplest form of protection is to authenticate the off-card installation pro(cid:173)
`gram by using a PIN-thus providing a measure of trust to the CAP file provider
`and the content of the CAP file. A more sophisticated scheme can use digital sig(cid:173)
`nature and data encryption. The next section provides such examples.
`
`5 Because the CAP file is verified off-card, the installer may not verify the consistency of internal
`references.
`
`/4
`
`IPR2022-00413
`Apple EX1049 Page 161
`
`

`

`160 CHAPTER 11 JAVA CARD PLATFORM SECURfTY
`
`11.2.5 Cryptographically Enforced Chain Trust
`
`The Java Card applet development and installation process consists of source code
`design and implementation; code compilation, conversion, and verification; and
`CAP file installation on the card.
`During this process, several parties are involved, including developers, issu(cid:173)
`ers, terminal vendors, card vendors, and others. If the entire process is not accom(cid:173)
`plished in a physically secure environment, files may need to be transported in an
`open network. Thus, Java Card system security can be further strengthened
`through the chain of trust, in which the identity of each party involved is authenti(cid:173)
`cated and the confidentiality and integrity of data are protected.
`Modem cryptography offers powerful tools to authenticate identity and to
`ensure confidentiality and integrity. Any Java Card file (source code, class file,
`CAP file, or export file) can be encrypted for secrecy during transportation
`between development and on-card installation. The file can be digitally signed to
`en ure integrity and to prove the identity of its provider. Before a CAP file is
`in talled, the host (including the CAD) and the card should be mutually authenti(cid:173)
`cated. Once the host is authenticated, it would be safe for the card to load data in
`plaintext. Otherwise, the data decryption and verification tasks would be required
`on the card, which could be very resource demanding.
`To build nu t through such schemes, a card issuer needs to define policies
`regarding the key management (key generation and exchange) and the use of
`cryptogr phic mechani ms.
`
`11.2.6 Runtime Security Enforcement
`
`Card runtime security enforcement covers two areas: ensuring Java lan-
`The J
`gua.ge type afety and enforcing applet isolation through the applet firewall.
`The CAP file contains sufficient type information to enable thorough type
`checkin.g at runtime. Howe er, due to limited on-card computing resources, most
`JCRE implementations choose to rely on the security measures enforced by !he
`n eJter and erifiers and to rel on installation checking for detecting certain
`kinds of ill gal references. Man checks that are performed statically off-card are
`1oot R;peared at runtime. The Ja a Card interpreter performs checks that must be
`handled dyaamically. such as checking the runtime type of an object against ics
`~ type.
`l'o en.foroc me applet firewall, when an object is accessed, the Java Card in1er-
`1pmel' perfonns oheck.s 10 determine whether the access can be granted. It auo, 5
`applets in me same package ID acce s each other' objects. In situations where
`
`IPR2022-00413
`Apple EX1049 Page 162
`
`

`

`JAVA CARD PLATFORM SECURITY MECHANISMS
`
`161
`
`there is a need to support cooperative applications across the package boundaries,
`the Java Card interpreter enables object sharing through JCRE entry point objects,
`~obal arrays, and shareable interface objects.
`
`The Java Sandbox Model versus the Applet Firewall
`
`Runtime security in the Java platform centers on the idea of a sandbox model.
`An applet may play around within its sandbox but cannot reach beyond it. In the
`sandbox model, classloaders can be used
`to provide separate name spaces
`(sandboxes) for various software components. For example, a browser can load
`applets from different Web pages by using different classloaders, thus maintaining a
`degree of isolation between those applet classes. In this model, access to sensitive
`resources is controlled by the security manager and the access controller based on the
`pennissions granted to the requester[lO]. In the Java Card platform, classloaders and
`the security manager are not supported. The sandbox model is complemented by the
`applet firewall. The JCRE assigns a context for each running applet. Access to an
`object is controlled by the Java Card interpreter based on the type of the accessed
`object and whether the currently active context is the object's owning context.
`
`In addition, the Java Card runtime specification dictates a number of JCRE
`implementation requirements
`to ensure runtime security. Following are some
`notable ones.
`
`• The JCRE must properly designate and implement JCRE entry point objects
`and global arrays. For example, an applet cannot store references to tempo(cid:173)
`rary JCRE entry point objects in class variables, instance variables, or array
`fields (including transient arrays).
`
`• To prevent an applet's potentially sensitive data from being "leaked" to
`another applet via the global APDU buffer, the APDU buffer must be cleared
`to zeroes whenever an applet is selected before the JCRE accepts a new
`APDU command.
`•
`
`• The JCRE's implementation of the atomicity and transaction mechanisms
`must be in compliance with the specification to ensure data integrity. For
`example, when an applet returns with a transaction still in progress, the JCRE
`should automatically abort the transaction, thus triggering any necessary
`cleanup by the transaction system.
`
`' Runtime failures must be properly handled. For example, a lack of
`resources (such as heap space) error that is recoverable should result in a
`
`IPR2022-00413
`Apple EX1049 Page 163
`
`

`

`162
`
`CHAPTER 11 JAVA CARD PLATFORM SECURITY
`
`SystemExcepti on. Any nonrecoverable error, such as stack overflow, should
`cause the virtual machine to halt. When a nonrecoverable error occurs, a
`JCRE implementation can optionally require the card to be muted
`(blocked), thus preventing further use.
`
`11.2.7 Java Card Cryptographic Support
`
`Cryptographic mechanisms are used throughout Java Card applets and system soft(cid:173)
`ware. The Java Card cryptography APis allow for flexible use of these mechanisms,
`based on what security policy is desired and which cryptographic mechanisms are
`available on the card. Card issuers can configure the card for choices of algorithms,
`key size, and so on. Applet developers are likewise able to define their own crypto(cid:173)
`graphic policies, within boundaries set by the card issuer.
`
`11.3 Applet Security
`
`The security of any application is determined by the security of the platform on
`which it runs and by security features designed into the application itself. The Java
`Card platform is designed to ensure that applets can be built, installed, and run in a
`highly secure fashion. It also enables issuers to define further security requirements
`and policies to meet the needs of their particular industry. For example, as an indus(cid:173)
`try extension, the Open Platform enforces security rules for applet installation and
`management of applets on Java smart cards[9].
`Application-level security needs to be programmed into applets. Because
`security features are built into the platform itself, applet developers can concen(cid:173)
`trate their efforts on defining a security strategy for the applets rather than on put(cid:173)
`ting extra effort into programming the applets to compensate for an insecure
`platform.
`Applet developers should define a security strategy to prevent the kinds of
`attacks that are likely to be made against the applet. When well defined, a security
`strategy provides these security objectives in applets:
`
`to an applet's functions and data is controlled. The
`• Authentication-Access
`identity of the host application issuing commands to the applet should be au(cid:173)
`thenticated. Also, during object sharing, the server applet should verify the
`identity of a client applet before granting a service.
`
`• Confidentiality-The privacy of the applet's data must be protected: secure
`data, such as account numbers and balances, should not be accessible without
`
`IPR2022-00413
`Apple EX1049 Page 164
`
`

`

`APPLEFSECURrrY 163
`
`proper authentication. Secret data, such as PINs and private cryptographic
`keys, should never be allowed to leave the card .
`
`• Integrity-The correctness of the applet's data is defended. The applet's data
`cannot be changed without proper authentication. Data modification should
`be guarded through error checking. For example, the wallet balance cannot
`exceed its maximum limit or drop below zero.
`
`Needless to say, different applets require different levels of security. For
`example, a wallet applet requires a higher degree of security and type approval
`than a game applet. Also, security is enforced at the cost of computing resources
`(perfonnance and memory). Therefore, applet developers should evaluate the
`security requirements of an applet and choose appropriate mechanisms to protect
`its valuable assets.
`
`IPR2022-00413
`Apple EX1049 Page 165
`
`

`

`Ja a Programming Language / oRwar De ign
`
`,
`
`' Java Card"' Technology for Smart Cards £
`
`,
`
`JAVA
`
`Java ard~ te hnology provides a secure, vendor-independent,
`ubiquitou Java-platform for smart cards and other mem?ry con(cid:173)
`trained devi e . It open the mart card marketpla e to third-party
`application development and enables programmers to develop
`smart card application for a wide variety of vendors' products.
`Thi book is the comprehensive guide to developing applica(cid:173)
`lions wilh Ja a Card technology. It introduces you to the Java Card
`platform and features detailed discussions of programming con(cid:173)
`cepts. It al o provides a step-by-step Java Card applel develop(cid:173)
`ment guide to get you up and running.
`Specific lopics covered include:
`• Smart card basics
`• Java Card virlual machine
`• Persistent and transient objects
`• Atomicity and tran actions
`• Handling APDUs
`• Applet firewall and object haring
`• Java Card platform ecurily
`• A slep-by-step applel development guide
`• Applet oplimization guidelines
`• A comprehensive reference to Java Card AP ls
`With Java Card technology, mart card programming will finally
`enler the mainslream of application development. This book
`provide lhe authoritative and practical information you need lo
`enter lhis rapidly growing arena.
`Zhiqun Chen is on the engineering team that designed and
`implemented Java Card APls and is currently working on Sun's
`, ~··J , irlual machine reference implementation. She has
`la~ L'
`u I "rience writing financial applets with Java Card
`... md was involved in developing Open Platform card
`v\ondex terminal, and server applications for Java
`~,
`I le( tr•., " ( , nmerce Framework.·
`
`; Hp. java.suru.om/books/Series/
`
`Tire )m'a ™ Series
`
`The Java· Series is supported,
`endo~ed, and authored by the
`creators of the Java technology at
`Sun Microsystems, Inc. It is the
`official place to go for complete,
`expert, and definitive information
`on Java technology. The books in
`this Series provide the inside infor(cid:173)
`mation you need to build effective,
`robust and portable applications
`and applets. The Series is an indis(cid:173)
`pensable resource for anyone tar(cid:173)
`geting the Java 2 platform.
`
`. . .from tl,e Sourc~ ™
`
`over design by Simone R. Payment
`Cover art by Sara onnell
`O Text printed on recycled paper
`..,•.., ADDI SO -WESLEY
`Pearson Education
`
`I I I I 11 11f 11l11i11i11il
`9 780201 703290
`ISBN 0-201-70329-7
`$44.99 us
`
`$64.99
`
`CANADA
`
`IPR2022-00413
`Apple EX1049 Page 166
`
`