defined by ISO 7816, a string used to uniquely identify card applications and certain types of files in card file systems. An AID consists of two distinct pieces: a 5-byte RID (resource identifier) and a 0 to 11-byte PIX (proprietary identifier extension). The RID is a resource identifier assigned to companies by ISO. The PIX identifiers are assigned by companies.
A unique AID is assigned for each package. In addition, a unique AID is assigned for each applet in the package. The package AID and the default AID for each applet defined in the package are specified in the CAP
file. They are supplied to the converter when the CAP
file is generated.
within the context of this document, a Java Card applet, which is the basic unit of selection, context, functionality, and security in Java Card technology.
the mechanism that prevents unauthorized accesses to objects in contexts other than currently active context.
see library package.
the logical channel on which the applet instance is either the active applet instance or will become the active applet instance.
an operation that either completes in its entirety or no part of the operation completes at all.
property in which a particular operation is atomic. Atomicity of data updates guarantees that data are not corrupted in case of power loss or card removal.
an acronym for Answer to Reset. An ATR is a string of bytes sent by the Java Card platform after a reset condition.
logical channel 0, the only channel that is active at card reset. This channel is permanent and can never be closed.
in a Java Card system, a change in a Java programming language package results in a new CAP
file. A new CAP
file is binary compatible with (equivalently, does not break compatibility with) a preexisting CAP
file if another CAP
file converted using the export file of the preexisting CAP
file can link with the new CAP
file without errors.
an acronym for Card Acceptance Device. A CAD can integrate a card reader and is the device in which the card is inserted. Sometimes the CAD is called the card reader.
the CAP
file is produced by the Converter and is the standard file format for the binary compatibility of the Java Card platform. A CAP
file contains an executable binary representation of the classes of a Java programming language package. The CAP
file also contains the CAP
file components (see also CAP file component). The CAP
files produced by the converter are contained in Java Archive (JAR) files.
a Java Card platform CAP
file consists of a set of components which represent a Java programming language package. Each component describes a set of elements in the Java programming language package, or an aspect of the CAP
file. A complete CAP
file must contain all of the required components: Header, Directory, Import, Constant Pool, Method, Static Field, and Reference Location.
The following components are optional: the Applet, Export, and Debug. The Applet component is included only if one or more Applets are defined in the package. The Export component is included only if classes in other packages may import elements in the package defined. The Debug component is optional. It contains all of the data necessary for debugging a package.
a card session begins with the insertion of the card into the CAD. The card is then able to exchange streams of APDUs with the CAD. The card session ends when the card is removed from the CAD.
the constant pool contains variable-length structures representing various string constants, class names, field names, and other constants referred to within the CAP
file and the Export File structure. Each of the constant pool entries, including entry zero, is a variable-length structure whose format is indicated by its first tag byte. There are no ordering constraints on entries in the constant pool. One constant pool is associated with each package.
There are differences between the Java platform constant pool and the Java Card technology-based constant pool. For example, in the Java platform constant pool there is one constant type for method references, while in the Java Card constant pool, there are three constant types for method references. The additional information provided by a constant type in Java Card technologies simplifies resolution of references.
protected object space associated with each applet package and Java Card RE. All objects owned by an applet belong to context of the applet's package.
a piece of software that preprocesses all of the Java programming language class files that make up a package, and converts the package to a CAP
file. The Converter also produces an export file.
the Java Card RE keeps track of the currently selected Java Card applet. Upon receiving a SELECT FILE command with this applet's AID, the Java Card RE makes this applet the currently selected applet. The Java Card RE sends all APDU commands to the currently selected applet.
a new component added to the CAP
file. The new component must conform to the general component format. It is silently ignored by a Java Card virtual machine that does not recognize the component. The identifiers associated with the new component are recorded in the custom_component
item of the CAP
file's Directory component.
an applet that is selected by default on a logical channel when it is opened. If an applet is designated the default applet on a particular logical channel on the Java Card platform, it becomes the active applet by default when that logical channel is opened using the basic channel.
a file produced by the Converter that represents the fields and methods of a package that can be imported by classes in other packages.
the process by which a Java virtual machine (VM) allows an unreferenced object instance to release non-memory resources (for example, close and open files) prior to reclaiming the object's memory. Finalization is only performed on an object when that object is ready to be garbage collected (meaning, there are no references to the object).
Finalization is not supported by the Java Card virtual machine. There is no finalize()
method to be called automatically by the Java Card virtual machine.
see applet firewall.
a type of persistent mutable memory. It is more efficient in space and power than EEPROM. Flash memory can be read bit by bit but can be updated only as a block. Thus, flash memory is typically used for storing additional programs or large chunks of data that are updated as a whole.
the set of classes that implement the API. This includes core and extension packages. Responsibilities include applet selection, sending APDU bytes, and managing atomicity.
the process by which dynamically allocated storage is automatically reclaimed during the execution of a program.
a common pool of free memory usable by a program. A part of the computer's memory used for dynamic memory allocation, in which blocks of memory are used in an arbitrary order. The Java Card virtual machine's heap is not required to be garbage collected. Objects allocated from the heap are not necessarily reclaimed.
the on-card mechanism to download and install CAP
files. The installer receives executable binary from the off-card installation program, writes the binary into the smart card memory, links it with the other classes on the card, and creates and initializes any data structures used internally by the Java Card Runtime Environment.
the off-card mechanism that employs a card acceptance device (CAD) to transmit the executable binary in a CAP
file to the installer running on the card.
Java Card Platform Remote Method Invocation
a subset of the Java Platform Remote Method Invocation (RMI) system. It provides a mechanism for a client application running on the CAD platform to invoke a method on a remote object on the card.
Java Card Runtime Environment (Java Card RE)
consists of the Java Card virtual machine, the framework, and the associated native methods.
Java Card Virtual Machine (Java Card VM)
a subset of the Java virtual machine, which is designed to be run on smart cards and other resource-constrained devices. The Java Card VM acts as an engine that loads Java class files and executes them with a particular set of semantics.
Java Card RE entry point objects
objects owned by the Java Card RE context that contain entry point methods. These methods can be invoked from any context and allow non-privileged users (applets) to request privileged Java Card RE system services. Java Card RE entry point objects can be either temporary or permanent:
temporary - references to temporary Java Card RE entry point objects cannot be stored in class variables, instance variables or array components. The Java Card RE detects and restricts attempts to store references to these objects as part of the firewall functionality to prevent unauthorized reuse. Examples of these objects are APDU objects and all Java Card RE-owned exception objects.
permanent - references to permanent Java Card RE entry point objects can be stored and freely reused. Examples of these objects are Java Card RE-owned AID instances.
a Java programming language package that does not contain any non-abstract classes that extend the class javacard.framework.Applet
. An applet package contains one or more non-abstract classes that extend the javacard.framework.Applet
class.
as seen at the card edge, works as a logical link to an application on the card. A logical channel establishes a communications session between a card applet and the terminal. Commands issued on a specific logical channel are forwarded to the active applet on that logical channel. For more information, see the ISO/IEC 7816 Specification, Part 4. (http://www.iso.org
).
refers to embedding the Java Card virtual machine, runtime environment, and applets in the read-only memory of a smart card during manufacture.
implements the javacard.framework.MultiSelectable
interface. Multiselectable applets can be selected on multiple logical channels at the same time. They can also accept other applets belonging to the same package being selected simultaneously.
an applet instance that is selected and, therefore, active on more than one logical channel simultaneously.
a method that is not implemented in the Java programming language, but in another language. The CAP
file format does not support native methods.
normalization (classic applet)
the process of transforming and repackaging a Java application packaged for the Java Card Platform, Version 2.2.2, for deployment on the Java Card 3 Platform.
the process of removing unnecessary "." and ".." segments from the path component of a hierarchical URI.
a software tool that allows Java applications programmed for the Java Card Platform, Version 2.2.2, to be deployed on both the Java Card 3 Platform, Connected Edition and on the Java Card 3 Platform, Classic Edition. It also allows Java applications packaged for Version 2.2.2 to be transformed through the normalization process and then repackaged for deployment on both the Connected and Classic Editions.
the applet instance within the currently active context when the object is instantiated. An object can be owned by an applet instance, or by the Java Card RE.
persistent objects and their values persist from one CAD session to the next, indefinitely. Objects are persistent by default. Persistent object values are updated atomically using transactions. The term persistent does not mean there is an object-oriented database on the card or that objects are serialized and deserialized, just that the objects are not lost when the card loses power.
temporary working space for storing and modifying data. RAM is non-persistent memory; that is, the information content is not preserved when power is removed from the memory cell. RAM can be accessed an unlimited number of times and none of the restrictions of EEPROM apply.
a fully functional and compatible implementation of a given technology. It enables developers to build prototypes of applications based on the technology.
an interface which extends, directly or indirectly, the interface java.rmi.Remote
.
Each method declaration in the remote interface or its super-interfaces includes the exception java.rmi.RemoteException
(or one of its superclasses) in its throws
clause.
In a remote method declaration, if a remote object is declared as a return type, it is declared as the remote interface, not the implementation class of that interface.
In addition, Java Card RMI imposes additional constraints on the definition of remote methods. These constraints are as a result of the Java Card platform language subset and other feature limitations.
an object whose remote methods can be invoked remotely from the CAD client. A remote object is described by one or more remote interfaces.
an acronym for Remote Method Invocation. RMI is a mechanism for invoking instance methods on objects located on remote virtual machines (meaning, a virtual machine other than that of the invoker).
memory used for storing the fixed program of the card. A smart card's ROM contains operating system routines as well as permanent data and user applications. No power is needed to hold data in this kind of memory. ROM cannot be written to after the card is manufactured. Writing a binary image to the ROM is called masking and occurs during the chip manufacturing process.
an interface that defines a set of shared methods. These interface methods can be invoked from an applet in one context when the object implementing them is owned by an applet in another context.
a card that stores and processes information through the electronic circuits embedded in silicon in the substrate of its body. Unlike magnetic stripe cards, smart cards carry both processing power and information. They do not require access to remote databases at the time of a transaction.
a Card Acceptance Device that is typically a computer in its own right and can integrate a card reader as one of its components. In addition to being a smart card reader, a terminal can process data exchanged between itself and the smart card.
the basic unit of program execution. A process can have several threads running concurrently each performing a different job, such as waiting for events or performing a time consuming job that the program doesn't need to complete before going on. When a thread has finished its job, it is suspended or destroyed.
The Java Card virtual machine can support only a single thread of execution. Java Card technology programs cannot use class Thread
or any of the thread-related keywords in the Java programming language.
an atomic operation in which the developer defines the extent of the operation by indicating in the program code the beginning and end of the transaction.
the state of transient objects do not persist from one CAD session to the next, and are reset to a default state at specified intervals. Updates to the values of transient objects are not atomic and are not affected by transactions.