Java Card Technology for Smart Card's Architecture and Programmer's Guide (Zhiqun Chen)

Part 1 JAVA Card Technology

Chapter 2 Java Card Technology Overview

Java card technology enables programs written in Java programming language to run on smart cards and other devices with limited resources.
This chapter briefly describes the Java Card Technology-system architecture and its components.
 
3.1 Architecture Overview
Smart Cards represent the smallest computing platform currently in use. The smart card memory configuration can be 1 k ram, 16 K
EEPROM, and 24 k rom. The biggest challenge of Java card technology design is: to put Java System software on a smart card,
At the same time, you must reserve sufficient space for the application. The solution to this problem is to support only the subset of Java language features and
Out-of-mode Java virtual machine.
 
The Java card virtual machine is divided into two parts: one part runs on the card, and the other part runs on the card. Many are not limited
Processing tasks, such as class loading, bytecode verification, address determination and link, and optimization.
It is processed by external virtual machines, where resources do not need to be concerned.
 
Smart Cards differ from desktop computers in many ways. In addition to supporting the Java language, the Java card technology also defines a runtime
This environment supports Smart Card storage, communication, security, and application execution mode. Java card runtime environment conforms to intelligence
Neng Card International Standard ISO 7816.
 
The most important feature of the Java card runtime environment is to clearly separate the Smart Card Operating System from the application. The running environment will
The underlying complexity and the details of the smart card system are encapsulated. Applications request system services and
Resources.
 
Therefore, the Java card technology essentially defines such a platform: on this platform, applications written in Java programming language
Able to run on smart cards and other devices with limited resources. (The application written for the Java card platform is called applets .). Because points
From the perspective of time and space, the platform is distributed between smart cards and desktops. Java card technology consists of three parts
Is defined in a specification.
 
Z Java card 2.1 Virtual Machine (JCVM) specification: defines a Java programming language subset and is suitable for Smart Card Applications
Virtual Machine definition.
Z Java card Runtime Environment (JRE) specification: precisely describes the runtime behavior of the Java card, including storage management,
Applet management, and other runtime features.
Z Java card 2.1 application programming interface (API) specification: Describes the core of programming Java card applications and extensions Java package
And class.
 
3.2 Java card language subset
Because of its small storage space, the Java card platform can only support a carefully selected and customized Java language feature.
Subset. This subset includes features that are very suitable for programming for smart cards and other small devices, while keeping Java Coding
The object-oriented capability of Cheng language. Table 3.1 highlights some important and unsupported Java language features.
 
It is strange to omit the keywords of unsupported features. Many advanced Java cards provide failover
The metadata collection mechanism makes it possible to delete objects.
 

Appendix A provides A detailed description of the Java card language subset. For Java cards applets that need to store and operate on large numbers,
Chapter 14 provides programming tips for handling large numbers without using large basic data types.
 
Table 3.1 supports and not only supports Java features
Supported Java Features Unsupported Java Features
• Small basic data types: boolean, byte, short
• One-dimensional array
• Java packages, classes, interfaces, and exceptions
• Java object-oriented features: inheritance, virtual machines, overloading and
Dynamic Data Object creation, access domain, and constraint rules
• Int keyword and 32-bit integer data types are supported
Is optional.
 
• Big basic data types: long, double, float
• Characters and strings
• Multi-dimensional array
• Dynamic class loading
• Security Manager
• Garbage collection and finalization
• Thread
• Object serialization
• Object cloning
 
3.3 Java card Virtual Machine
A major difference between a Java card Virtual Machine (JCVM) and a Java Virtual Machine (JVM) Is that JCVM acts as two separate
As shown in Figure 3.1. The card on the Java card Virtual Machine includes the Java card bytecode interpreter. Java card
The converter runs on a PC or workstation. The converter is the external part of the VM card. Both the card and the outside of the card enable the entire virtual machine.
Function, package
 
 
Figure 3.1 Java card Virtual Machine
 
Including loading Java class files and execution according to specific semantics. Transformer loading and preprocessing constitute class files and inputs of Java packages
The CAP (converted applet) file. Then, load the CAP file into the Java smart card and execute it with an interpreter. Besides
In addition to the CAP file, the converter also generates an output file indicating the public APIs of the packet to be converted to north.
 
The Java card technology only supports a subset of the Java language. Correspondingly, the Java card Virtual Machine only supports
Required features. The converter deletes unsupported language features used in the applet.
 

3.3.1 CAP and Export files
 
Java card technology introduces two new binary file formats, which allow the Java card software platform to develop and release independently
And execution. A cap file contains the executable binary representation of classes in a Java package. Use the JAR file format as the CAP
File container format. A cap file corresponds to a JAR file containing a set of its components, each of which is
A file in the JAR file. Each component describes one aspect of the CAP file content, such as class information, executable bytecode,
Link information, verification information, and so on. The format of the CAP file is for small-sized devices, using a compact data structure and Limited
Is indirectly optimized. It defines a bytecode instruction set, which is based on the Java bytecode Instruction Set and
Optimized.
 
The character of the Java program "write once, run everywhere" may be the most important feature of the Jav platform. In Java technology,
Class files are the central part of the Java architecture and define the binary compatibility standard of the java platform. Because Java Card System
The distributed feature of the system architecture. The CAP file establishes a standard file format for binary compatibility of the Java card platform.
The CAP file format is to load the software to the java card. For example, the CAP file can be moved after the card is completed
Load the applet Class. This is why the CAP (converted apple) file is named.
 
Export files are not mounted to a smart card and are not directly used by the interpreter. They are generated by the converter and used for verification.
Certificate and link process. The Export file can be considered as the header file in the C programming language. An export file contains the public
A total of APIs. It defines the access domain and signature of the class and the name and method, as well as the class domain (fields ).
An export file also contains the resolving link information for the compartment on the card.
 
The export file does not contain any implementation information, that is, it does not contain bytecode. Therefore, an export file can be used by the applet
Developers can freely publish the applet to potential users without disclosing internal implementation details.
 
3.3.2 Java card Converter (Converter)
 
Unlike a Java Virtual Machine (processing a class at a time), the conversion unit of a converter is a package. The compiler is generated by the source code.
Class file, and then the converter preprocessing forms all class files of a java package, and converts this package into a CAP file.
 
During the conversion process, the converter executes the tasks completed by the Java Virtual Machine during class loading in the desktop environment:
 
Z. Verify that the loading image format of the Java class is correct.
Z check whether Java card language subset is illegal
Z initializes static variables
Z resolves symbolic references to classes, methods, and domains into a more compact form that can be effectively processed on the card
Z optimizes bytecode using the information obtained during class loading and linking
Z allocates storage space and creates virtual machine data structures that represent classes
 
The converter not only uses the class file as the input for conversion, but may also contain one or more export files. In addition
In addition to CAP files, the converter also generates an export file about the converted package. Figure 3.2 shows how a package is
Converted. The converter loads all classes in a Java package. If the package inputs a class from another package, the converter also loads
Export files of some packages. The output of the converter is a CAP file and an export file of the package being converted.

Figure 3.2 convert a package
 
3.3.3 Java card Interpreter (Interpreter)
 
The Java card interpreter provides runtime support for the Java language model. Therefore, the applet code is allowed to be independent of hardware. Interpreter
Perform the following tasks:
Z executes the bytecode command and finally executes applets
Z controls storage allocation and object Creation
Z plays an important role in ensuring runtime Security
 
So far, the Java card virtual machine has been described as composed of a converter and interpreter. However, in our current definition
Java card virtual machine is defined as the card part of the Virtual Machine-interpreter. This habit has been used in many early days
Java card publications. Therefore, the subsequent sections of this book will use both the "Java card interpreter" and "Java card virtual machine"
Unless otherwise stated. However, when comparing the Java platform and the Java platform, the reader should know that
The functions of the component are completed by both the converter and the interpreter.
 
3.4 Java card Installer and out-of-card Installer
The Java card interpreter itself does not load the CAP file. It only executes the code found in the CAP file. In Java card
Technically, the mechanism for downloading and installing CAP files is included in a part called installer.
 
The Java card installer resides in the card and works with an installer outside the card. The installation program outside the card passes the card
The receiving device (CAD) sends executable binary code in the CAP file to the installer running on the card. Installer Sets
Write the code into the smart card memory, link it to other classes that have been placed on the card, and create and initialize
Any data structure used internally in the runtime environment of the card. Installer and how they work with the rest of the Java card Platform
Partially associated with Figure 3.3.
 
The splitting of the interpreter and the CAP file installer makes the interpreter smaller and provides the flexibility of the installer.
For more information about the installer, refer to the installation of the applet in the later part of this chapter.

PC or Workstation
 
Figure 3.3 Java card installer and out-of-card Installer
 
3.5 Java card Runtime Environment
The Java card Runtime Environment (jcres) is composed of some Java card system components running on smart cards. Jcres
Chip resource management, network communication, applet Execution, and security of the card system and applet. Therefore, it actually acts as a smart card
Operating System role.
 
As shown in Figure 3.4, JRE is located on the top of the smart card hardware and native systems. JRE is a Java card Virtual Machine (bytecode
INTERPRETER), Java card application architecture class (APIs), industry-specific extensions, and some JRE System Classes. Jcres are good.
The dedicated technologies of applets and Smart Card vendors are isolated, and standard system and API interfaces are provided for applets. Therefore,
Applets is easy to write and port on different Smart Card architectures.
 
The underlying layer of JRE includes Java card Virtual Machine (JCVM) and some native methods. JCVM executes bytecode and Controls Memory
The storage device allocates, Manages objects, and ensures execution security, as described above. The native method provides
Class support. They are responsible for processing low-level communication protocols, storage management, and cryptographic support.
 

Applets
 
 
 
Jcres
 
 
 
 
 
 

 
 
 
 
Smart card hardware and Native System
 
Discount app wallet app certification app
Industry-specific extended installer architecture (APIs)
Applet management thing management I/O network communication other services
Java card Virtual Machine
(Bytecode Interpreter)
Native METHOD

Figure 3.4 architecture of the Card System
 
The system class is used as the JRE executable program. These classes simulate the core of the operating system. System Management
Host application 1
Communication with the Java card applets, and control the creation, selection, and deselection of the applet. Is
To complete these tasks, the system class generally needs to call the native method.
 
The Java card application architecture defines the application programming interface. This architecture consists of four core API packages and one extended API package group.
. These APIs are compact and customized for the development of smart card applets. Main advantages of this architecture
It makes it easy to create an applet. Therefore, the main focus of applet developers is
But not the details of the smart card system infrastructure. Applets accesses JRE services through APIS.
 
Various industries can provide extended libraries to provide additional services or improve security and system models. For example, Open Platform Extension
The jcres service was introduced to meet the special security requirements of the financial sector. In many append features, the card issuer is forced
And defines the standard command set for card personalization.
 
The card installation program ensures that the software and applets can be securely stored after the card is produced and released to the cardholder.
To the card. The setup program on the card and the off-board installer work together to complete the binary content of the CAP File
Download task. The installation program on the card is an optional JRE component. When the program is installed without a card, all the cards
CHIP software (including applets) must be written to the memory of the card during the card manufacturing process.
 
Java card applets is a user program on the Java card platform. Of course, applets is a subset of the Java programming language.
Compiled and controlled and managed by jcres. Applets can be loaded to the card after the Java smart card is created.
 

3.5.1 JCRE Lifecycle
 
In a PC or workstation, a Java virtual machine runs as an operating system process. Data and objects are created in RAM
. When the OS process is terminated, Java applications and their objects are automatically discarded.
 
In Java smart card, Java card virtual machine runs in Java card runtime environment. Jcres are initiated at card initialization.
. During the entire card lifecycle, JRE is initialized only once. In this process, JRE initializes the Virtual Machine and creates
Provides the JRE service and manages applets objects. When installing applers, JRE creates an applet instance, while
Applets creates an object for data storage.
 
Most information on a smart card must be retained even when the card is powered off. We can use permanent storage technology
To maintain data. Data and objects are created in permanent storage. JRE's
The life cycle is equivalent to the life cycle of the entire card. When power is removed, the VM is suspended. Jcres and
The object state is retained.
 
The next time the card is powered on, JRE passes
Load data and restart the Virtual Machine for execution. Here I
The subtle concept is that JRE does not just continue operations on the virtual machine from the breakpoint when the power is down. Instead, the VM is reset from
The start of the main loop. JRE reset is different from initialization because it retains the applets and objects created on the card.
During the reset period, if something has not been completed before, JRE will perform any necessary clear work to make JRE consistent
.
 
3.5.2 how does jcret work in a CAD Session?
 
The period from card insertion to card reception device (CAD) and power-on to card pulling from CAD is called a CAD Session Period
(Session ). During the CAD session, JRE operates like a normal Smart Card-it supports APDU with the host application
I/O communication (Figure 3.5 ).. APDUs (application protocol data unit) is a data packet exchanged between applets and the host application. Each
An APDU command or a response from the host to the applet or from the applet to the host.
 
After JRE is reset, JRE enters a loop and waits for the APDU command from the host. Host pass card
The serial communication interface provided by the chip input/output contacts sends the APDU command to the Java card platform.
 
 
 
Figure 3.5 apdu I/O communication

When a command arrives, JRE selects an applet or receives
Command to the selected applet. Then, the selected applet gets control and processes the APDU
.
 
At the end, the applet sends a response to the host application and returns the control to JRE. In the next command
And repeat this process. How Applets handles APDUs will be described in chapters 7th and 8th.
 
3.5.3 Java card runtime features
 
In addition to the runtime mode of the Java language, JRE also supports three additional runtime features:
 
Z Permanent and Temporary objects-by default, Java card objects are permanent and established in permanent storage. This type of object
Cross-CAD session between space and data. Applets can also be created in RAM for security and performance reasons.
Object. Temporary objects include non-permanent, non-Cross-CAD session periods
Data.
 
Z atomic operations and things-Java card Virtual Machine ensures that each write operation to an object or a domain in a class is atomic
. The modified domain or new value or restored to the original value. In addition, JRE also mentions
APIs. The Applet can place several write operations in one thing. Or all the modifications in one thing are completed,
Or (if an error occurs in this transaction) nothing is done.
 
The z Applet firewall and the sharing mechanism-applet firewall isolate applets. Each applet runs on
Within the specified space. The existence and operation of an applet does not affect other applets on the card. Applet
The firewall is forced when the Java card virtual machine executes the bytecode. Share data or access to applets
In JRE service scenarios, virtual machines use secure sharing mechanisms to meet these features.
 
3.6 Java card APIs
Java card APIs is composed of classes customized to program smart card applications in ISO 7816 mode. APIs package
Contains three core packages and one extension package. The three core packages are: java. lang, javacard. framework, and
Javacard. security. The extension package is javacardx. crypto.
 
Developers familiar with the Java platform will notice that many Java platform classes are not supported in the Java card APIs. Example
For example, classes on GUI interfaces, network I/O, and desktop file system I/O on the Java platform are not supported. Causes
Because smart cards do not have monitors, and they use different network protocols and file system structures. In addition, it does not support many
Java platform utilities to meet specific storage needs.
 
Classes in Java card APIs are compact and concise. They include some cryptographic techniques to provide Java support
Class adapted based on the Java platform. They also include some specially established to support the smart card ISO 7816 Standard
Class.
 
3.6.1.java.lang package
 
The Java. lang Package of the java card is a strict subset of the corresponding Java. langpackage on the java platform. Supported by this package
Objects, Throwable, and machine-related exception classes are supported, as shown in Table 3.2. For supported classes,
Many Java methods are not available. For example, the Java card Object class only defines the default constructor and equals

Method.
 
The java. lang Package provides basic Java language support. The class Object defines a root for the Java card class hierarchy,
Throwable provides a common ancestor for all exceptions. The supported exception classes are guaranteed in the Java language
Consistency occurs when an error occurs due to a violation. For example, when accessing an empty reference, Java Virtual Machine and Java Virtual Machine
An NullPointerException exception is thrown for all the VMS.
 
Table 3.2 Java card java. lang Package
Object Throwable Exception
RuntimeException ArithmeticException ArrayIndexOutOfBoundsException
ArrayStoreException ClassCastException IndexOutOfBoundsException
NullPointerException SecurityException NegativeArraySizeException
 
3.6.2.javacard.framework package
 
Javacard. framework is an important package. It provides the architecture class and
Interface. The most important thing is that it defines a basic Applet Class, which is the execution of the applet and
Interaction provides a framework. In terms of the role played by JRE, it is similar to the host browser for the Applet Class.
. A user applet Class must be extended from the base class Applet, and the method in the Applet Class must be rewritten
The applet function is now available.
 
Another important class in the javacard. framework Package is The APDU class. APDUs is transmitted by the transmission protocol. Two
The standard transmission protocols are T = 0 and T = 1. The APDU class is designed to be independent of the transmission protocol. In other words, it is carefully designed
So that the applet developers do not feel the complexity of the T = 0 and T = 1 protocols and the differences between them. Applet
Developers can use the methods provided in the APDU class to easily process APDU commands. Regardless of the underlying transmission supported by the Platform
The protocol works correctly for Applets. In Chapter 8th, we will explain how to use the APDU class.
 
The Java card platform does not support Java. lang. System. The Java card platform includes a provision and system performance
Related Interface Class javacard. framework. JCSystem. JCSystem class includes controlling applet Execution and Resource Management
Management, thing management, and Java card platform.
 
Other classes supported in the javacard. framework Package are PIN, utility, and exceptions. PIN is the personal ID
(Personal identification number. It is the most common password used in a smart card to authenticate the cardholder.
Format.
 
3.6.3.javacard.security package
 
The javacard. security Package provides the architecture of the password function supported on the Java card platform. It is designed based on the package
Java. security.
 
The javacard. security Package defines a key factory class keyBuilder and description for symmetric (DES) or asymmetric
(DSA and RSA) cryptographic key interfaces in algorithms. In addition, it also supports abstract base class RandomData,
Signature, and MessageDigest, which are used to generate random number data and calculate the packet summary and Signature.
 
3.6.4.javacardx.crypto package

The javacardx. crypto package is an extension package. It contains cryptographic technology and interfaces that are subject to the requirements of U.S. export regulations.
The javacardx. crypto package defines the abstract base class Cipher that supports encryption and decryption.
 
The javacard. security and javacardx. crypto packages define the API for applets to call the cryptographic technology service.
Interface. However, they do not provide any implementation. A jre provider needs to provide classes for these key interfaces and inherit
Like RandomData, Signature, MessageDigest, and Cipher. Generally, a card has an independent coprocessor.
To complete password-related computing. Chapter 10th explains how to use the javacard. security Package and javacardx. crypto
Supports the Password Technology in applets.
 
3.7 Java card Applets
Do not confuse the Java cards applets and Java applets because they are both called applets. A Java
The card applet is a Java program that complies with a set of constraints and only allows it to run in the runtime environment of the Java card. One
Java card applet does not run in a browser environment. The reason for naming the Java card app applet is that
After being created, the Java card applets can still be loaded into the runtime environment of the Java card. That is, unlike many embedded
In the system, you do not need to burn applets into the ROM during the manufacturing phase. Instead, they can be dynamic at some point in the future.
Download to the card.
 
An applet Class must be extended from the javacard. framework. Applet Class. Base-class Applet is resident in
All applets superclasses in the Java card. This applet Class is a template that defines variables and methods in an applet. One
The applet running on the card is an Applet instance-an object of the applet Class. Like any permanent object 1
Once an applet instance is created, it will survive permanently on the card. Java card Runtime Environment supports multiple application rings
Environment. Multiple applets can coexist on the same Java smart card, and one applet can have multiple instances. For example,
You can create a wallet applet instance to support the dollar, and create another instance to support the pound.
 
3.8 package and Applet naming conventions
The packages and programs on the Java platform you are familiar with use Unicode strings and the naming scheme based on Internet domain names.
Unique identifier. However, on the Java platform, each applet instance is uniquely identified by an Application Identifier (AID ).
And selected. In addition, each Java package is assigned an AID. When you load the package to a card, you can use them
The AID links it to other packages on the card.
 
ISO 7816 specifies the applications used to uniquely identify a card and APIs for certain types of domains in the card file system. An AID
Is a byte array, which can be interpreted as two different parts, as shown in Figure 3.6. The first part is a 5-byte value,
It is called the RID (source identifier ). The second part is a variable length value, called the PIX (dedicated identifier extension ). Length of the PIX
Degrees can be from 0 to 11 bytes. Therefore, the total length of an AID can be 5 to 16 bytes.
 
RID (5 bytes) PIX (0-11 bytes)

Figure 3.6 Application ID (AID)
 
Each company has a unique RID. Companies manage their own AIDs
PIXs allocation. This section only briefly describes AIDs. For details, see ISO 7816-5, AID Registration
Format of category D.
 
On the Java platform, the AID of a package is composed of the company's RID and the PIX link of the package.

The AID of an applet is constructed in a way similar to the package AID. It is the RID Of the applet provider and
The URL of the applet's PIX. The AID of an applet must not be used with AID of any package or any other applets
The value of AID is the same. However, because the RID in an AID identifies the applet provider, the package AID and
The AID (s) of applets must have the same RID. Package AID and the default applet for each applet defined in the package
AID indicates in the CAP file. When you generate CAP files, provide them to the conversion program.
 
3.9 Applet download process
Java card applet development starts with any other Java program. Developers write one or more Java classes
Compile the source code with a Java compiler to generate one or more class files. Figure 3.7 demonstrates the applet development process.
 
Then, run, test, and debug the applet in the simulated environment. The simulator simulates a Java card on a PC or workstation.
Runtime Environment. In the simulated environment, the applet runs on the Java Virtual Machine, and therefore the class file of the applet is executed.
. In this way, the simulator can use many Java development tools (virtual machines, debugger, and other tools) and allow
Developer
 
Figure 3.7 Applet Development Process
 
Test the applet behavior and quickly view the applet Execution results without going through the conversion process. In this step
The entire function is tested. However, some Java card Virtual Machine runtime features, such as applet firewall and Object
Temporary and Permanent behaviors cannot be checked.

Then, the Java card conversion program is used to convert the applets class file that constitutes a Java package into a CAP.
File. The input of the Java card Conversion Program contains not only the converted class file, but also one or more export files. Transfer
When changing the applet package, the conversion program also generates an export file for the package. A cap file or an export
The file represents a Java package. If an applet consists of several packages, create a CAP file and
An export file.
 
In the next step, load the CAP file (probably more than one) representing the applet to a simulation environment and
Environment. The simulator also simulates the runtime environment of a Java card on a PC or workstation. However, the simulator is
A more complex test tool. It includes the implementation of a Java card virtual machine. The execution behavior of the Applet in the simulator should be
The behavior in the actual card is the same. In this development phase, not only can the applet be further tested, but also the applet
The runtime behavior of is also tested.
 
Most Java card simulators and Simulators have debugging programs (debugger ). This debugging program allows developers to set disconnections.
Click or one-step execution program to view the modified execution status of the applet In the runtime environment of the simulated or simulated Java card.
 
Finally, when the applet is tested and ready to be downloaded to the actual card, the applet (composed of one or more
Is loaded and installed to the Java smart card.
 
3.10 install Applet
When creating a Java smart card, the dedicated system of the smart card and its runtime environment (including the local (native)
Methods, Java card virtual machines, API classes, and libraries) are burned into the ROM. This will write some fixed components to the chip
The process of memory that is not easy to change is called masking ). Mask Technology is a specialized technology for smart card manufacturers.
Further discussion.
 
3.10.1 ROM Applets
 
During card manufacturing, the Java card applet Class can be masked to the ROM together with JRE and other system components.
During JRE initialization or a later time, JRE will instantiate the Applet instance into the EEPROM. Such
Some applets are called ROM applets.
 
ROM applets is the default applets, which is provided by the card issuer and submitted along with the card. Because ROM applet
The content is controlled by the publisher. Java card technology allows ROM applets to declare native methods.
The implementation is written in other programming languages (such as C or assembly code. Local methods are not secured by card virtual machines.
Detection ..
 
3.10.2 issue Applets beforehand or afterwards
 
In addition, after card manufacturing, Java card applet classes and related class libraries can also be downloaded or written to Java Smart Card
. Such applets can be further classified as pre-release or post-release
Applets. The prefix and Postfix terms are determined based on the fact that applets was downloaded before or after the card was released. Things
The previously released applets are handled in the same way as ROM applets, both of which are controlled by the issuer.
 
Unlike ROM applets or applets released beforehand, applets released afterwards cannot declare local methods. Original
Because JRE cannot control the content of the applet. Allowing the downloaded applets to contain local code is detrimental
Java card security. The following sections focus on the installation of the Post-Release applet. Generally, the applets released in advance is

It is loaded using the same mechanism as the applets released later, but the Java card technology leaves the decision to the card issuer.
 
3.10.3 install the Applet released later
 
Applet installation means to load the applet Class to a CAP file, and load these classes and the runtime environment of the Java card.
The execution status is combined and an applet instance is created to make the applet a State that can be selected for execution.
 
On the Java platform, the unit for loading and installation is a CAP file. A cap file consists of a Java
Package class composition. The smallest applet is a class that only inherits from the javacard. framework. Applet Class.
. A more complex applet with many classes can be organized into one or a group of Java packages.
 
To load an applet, the off-card installer uses the CAP file as the input and converts it to The APDU command sequence,
The command sequence carries the content of the CAP file. By exchanging the APDU command with the out-of-card installer
The content of the CAP file is written to the permanent memory of the card, and the classes in the CAP file and other
Class. The installer also establishes and initializes any data internally used by JRE to support applet. If the applet
You need to run several packages and load each corresponding CAP file to the card.
 
As the last step of applet installation, the installer creates an applet instance and forwards the instance to JCRE3
Register.
To do this, the installer calls the install method:
 
Public static void install (byte [] bArray, short offset, byte length );
 
The install method is an applet entry point method, similar to the main method in a Java application. An applet is required
The install method must be implemented. In the install method, it calls the applet constructor to create and initialize the applet instance.
The bArray parameter of the install method provides the installation parameters for applet initialization. These installation parameters are included in the CAP file.
Send to card. The applet developer defines the content and format of the installation parameters.
 
After the applet is initialized and registered with JRE, it can be selected to run. Using AID (application identifier)
Identifies a running applet. The applet can be used to find the default AID in the CAP file, or select another
The same AID registers itself with JRE. You can use the installation parameters to provide an additional AID.
 
The install method can be called multiple times to create multiple applet instances. Each applet instance is assigned a unique AID
Id. In the Java card environment, an applet can be written and executed without knowing how to load its classes. In security
During the installation process, the only responsibility of an applet is to implement the install method.
 
3.10.4.error recovery during applet Installation

The installation process is transactional. In the case of an error, such as a procedural fault, the running range exceeds the memory size,
Card unplugging, or other errors, the installer must discard the CAP file and any
Applet and restore the space and the previous status of JRE.
 
3.10.5. Installation restrictions
 
Readers should know that applet installation is different from dynamic class loading during runtime, which is a Java virtual

Supported on the proposed machine. Java card applet installation only means that after the card has been created, the installation process downloads
.
 
Therefore, Java card applet installation has two details. First, the applets running on the card only indicates that it already exists on the card.
On-Chip classes, because classes cannot be downloaded during normal applet code execution.
 
Second, the order of loading must be ensured: Each newly installed package only references the packages already on the card. For example, for an applet
For example, the javacard. framework package must be in the card, because all applet classes must
Javacard. framework. Applet is extended. If Package A and Package B are repeatedly referenced, the installation process will fail.