|By C. Enrique Ortiz, May 29, 2003|
Many of the articles on the Wireless Java site focus on the J2ME platform. This two-part article will instead introduce you to another important mobile Java technology: Java Card support for programming smart cards.
Because these portable technologies are so specialized, this article covers a lot of ground. The first installment of this article will introduce smart cards, the Java Card technology, and the elements of a Java Card applet. The second installment will cover the development aspects of the Java Card technology.
Java Card technology adapts the Java platform for use on smart cards and other devices whose environments are highly specialized, and whose memory and processing constraints are typically more severe than those of J2ME devices.
Smart cards are very useful in the areas of personal security. They can be used to add authentication and secure access to information systems that require a high level of security. Information stored in smart cards is portable. With Java Card technology you can carry around valuable and sensitive personal information such as your medical history, credit card numbers, or electronic cash balances in a medium that is compact, yet very secure.
What Is a Smart Card?
Smart cards aren't new. They were introduced in Europe two decades ago in the form of (not so smart) memory cards, used to store critical phone information with the purpose of reducing thefts from pay phones.
Smart-card technology is an industry standard defined and controlled by the Joint Technical Committee 1 (JTC1) of the International Standards Organization (ISO) and the International Electronic Committee (IEC). The series of international standards ISO/IEC 7816, introduced in 1987 with its latest update in 2003, defines various aspects of a smart card, including physical characteristics, physical contacts, electronic signals and transmission protocols, commands, security architecture, application identifiers, and common data elements.
A smart card is a plastic card that contains an embedded integrated circuit (IC). A smart card resembles a credit card. When used as a SIM card, the plastic card is small - just big enough to fit inside a cellphone. Smart cards are highly secure by design, and tampering with one results in the destruction of the information it contains.
In some areas of use smart cards are just memory cards that merely provide protected non-volatile storage. More advanced smart cards have both microprocessors and memory, for secure processing and storage, and can be used for security applications that use public-key or shared-key algorithms. The non-volatile memory in a smart card is its most precious resource and can be used to store secret keys and digital certificates. Some smart cards have separate cryptographic coprocessors that support such algorithms as RSA, AEC, and (3)DES.
Smart cards don't contain a battery, and become active only when connected with a card reader. When connected, after performing a reset sequence the card remains passive, waiting to receive a command request from a client (host) application.
Smart cards can be contact or contactless. As the names imply, contact smart cards work by communicating via physical contact between a card reader and the smart card's 8-pin contact, while contactless smart cards communicate by means of a radio frequency signal, with a typical range of less than 2 feet. The radio communication of contactless smart cards is based on technology similar to Radio Frequency ID (RFID) tags used in stores to counter theft and track inventory. Figure 1 depicts contact and contactless smart cards:
|Figure 1a. Contact Smart Card|
|Figure 1b. Contactless Smart Card|
Java Card technology also exists in form factors other than smart cards, such as smart buttons and USB tokens, both illustrated in Figure 2. These can be used much as smart cards are, to authenticate users or carry sensitive information for example. Smart buttons include a battery and are contact-based, while USB tokens can be plugged directly into the USB port of a PC with no need for a contact or contactless reader. Both provide the same programming capabilities as smart cards and have tamper-resistance properties.
|Figure 2a. A Java-Powered Smart Button|
|Figure 2b. A Java-Powered USB Token|
Please refer to What is a Smart Card? for more information.
Java Card Specifications
Years ago Sun Microsystems realized the potential of smart cards and similar resource-constrained devices, and defined a set of specifications for a subset of Java technology to create applications for them, Java Card applets. A device that supports these specifications is referred to as a Java Card platform. On a Java Card platform multiple applications from different vendors can coexist securely.
A typical Java Card device has an 8- or 16-bit CPU running at 3.7MHz, with 1K of RAM and more than 16K of non-volatile memory (EEPROM or flash). High-performance smart cards come with a separate processor and cryptographic chip and memory for encryption, and some come with a 32-bit CPU.
The Java Card technology specification, currently in version 2.2, consists of three parts:
Sun also provides the Java Card Development Kit (JCDK), which includes a reference implementation of the Java Card RE and Java Card VM, and other tools to help you develop Java Card applets. The second part of this article will cover the JCDK.
Java Card Technology and the J2ME Platform
Let's compare the Java Card and J2ME platform technologies:
|Figure 3. Java Card Technology and the J2ME Platform
(click image to enlarge)
Both the CDC and CLDC configurations and their related profiles are parts of the J2ME platform, while the Java Card is a separate platform created specifically for the smart-card environment.
Elements of a Java Card Application
A complete Java Card application consists of a back-end application and systems, a host (off-card) application, an interface device (card reader), and the on-card applet, user credentials, and supporting software. All these elements together compose a secure end-to-end application:
|Figure 4. Architecture of a Java Card Application
(click image to enlarge)
A typical Java Card application is not standalone, but rather includes card-side, reader-side, and back-end elements. Let's cover each element in more detail.
The Back-End Application and Systems
Back-end applications provide services that support in-card Java applets. For example, a back-end application could provide connectivity to security systems that, together with in-card credentials, provide strong security. In an electronic payment system, the back-end application could provide access to credit-card and other payment information.
The Reader-Side Host Application
The host application resides on a desktop or a terminal such as a PC, an electronic payment terminal, a cellphone, or a security subsystem.
The host application handles communication among the user, the Java Card applet, and the provider's back-end application.
Traditionally, reader-side applications have been written in C. Recent widespread adoption of J2ME technology makes it possible to realize the host application in Java; for instance, it could run on a cellphone that supports MIDP and the Security and Trust Services API.
Smart-card vendors typically provide, not only a development kit, but also APIs to support reader-side applications as well as Java Card applets. Examples include the OpenCard Framework, a Java-based set of APIs that hides some of the details of interacting with card readers from different vendors, and two that I'll discuss later in this article, the Java Card Remote Method Invocation distributed-object model and the Security and Trust Services API (SATSA).
The Reader-Side Card Acceptance Device
The Card Acceptance Device (CAD) is the interface device that sits between the host application and the Java Card device. A CAD provides power to the card, as well as electrical or RF communication with it. A CAD may be a card reader attached to a desktop computer using a serial port, or it may be integrated into a terminal such as an electronic payment terminal at a restaurant or a gas station. The interface device forwards Application Protocol Data Unit (APDU) commands (discussed later) from the host application to the card, and forwards responses from the card to the host application. Some CADs have a keyboard for PIN entry and may have a display as well.
The Card-Side Applets and Environment
The Java Card platform is a multiple-application environment. As Figure 4 illustrates, one or more Java Card applets may reside on the card, along with supporting software - the card's operating system and the Java Card Runtime Environment (JCRE). The JCRE consists of the Java Card VM, the Java Card Framework and APIs, and some extension APIs.
All Java Card applets extend the Applet base class and must implement the
process() methods; the JCRE calls
install() when installing the applet, and
process() every time there is an incoming APDU for the applet.
Java Card applets are instantiated when loaded and stay alive when the power is switched off. A card applet behaves as a server and is passive. After a card is powered up, each applet remains inactive until it's selected, at which time initialization may be done. The applet is active only when an APDU has been dispatched to it. How an applet becomes active (selected) is described in the section " Life-Cycle of a Java Card Applet".
Communicating with a Java Card Applet (Accessing the Smart Card)
You can use either of two models for communication between a host application and a Java Card applet. The first model is the fundamental message-passing model, and the second is based on Java Card Remote Method Invocation (JCRMI), a subset of the J2SE RMI distributed-object model. In addition, SATSA lets you use either message passing or JCRMI to access the smart card through a more abstract API based on the Generic Connection Framework (GCF) API.
The Message-Passing Model
The message-passing model illustrated in Figure 5 is the basis for all Java Card communications. At its center is the Application Protocol Data Unit (APDU), a logical data packet that's exchanged between the CAD and the Java Card Framework. The Java Card Framework receives and forwards to the appropriate applet any incoming command APDU sent by the CAD. The applet processes the command APDU, and returns a response APDU. The APDUs conform to the international standards ISO/IEC 7816-3 and 7816-4.
|Figure 5. Communicating Using the Message-Passing Model
(click image to enlarge)
Communication between the reader and card is usually based on either of two link protocols, the byte-oriented T=0, or the block-oriented T=1. Alternative protocols referred to as T=USB and T=RF may be used. The JCRE APDU class hides some of the protocol details from the application, but not all of them, because the T=0 protocol is rather complex.
1. The Command APDU
The structure of a command APDU is controlled by the value of its first byte and in most cases looks like this:
|Figure 6. Command APDU|
A command APDU has a required header and an optional body, containing:
Table 1. ISO 7816 CLA Values
0x80or higher for application-specific instructions, but in many current Java Card implementations only the ones in bold are actually recognized.
INS(1 byte): This required field indicates a specific instruction within the instruction class identified by the
CLAfield. The ISO 7816-4 standard specifies the basic instructions to use for access to data on the card when it's structured according to an on-card file system as defined in the standard. Additional functions have been specified elsewhere in the standard, some of which are security functions. See Table 2 for a list of some of the ISO 7816 instructions. You can define your own application-specific INS values only when using an appropriate CLA byte value, according to the standard.
Table 2. ISO 7816-4 INS Values When CLA = 0X
P1(1 byte): This required field defines instruction parameter 1. You can use this field to qualify the
INSfield, or for input data.
P2(1 byte): This required field defines instruction parameter 2. You can use this field to qualify the
INSfield, or for input data.
Lc(1 byte): This optional field is the number of bytes in the data field of the command.
Lcnumber of bytes): This optional field holds the command data.
Le(1 byte): This optional field specifies the maximum number of bytes in the data field of the expected response.
Depending on the presence of command data, and on whether a response is required, there are four variations to the command APDU. You need to be concerned about these variations only if you're using protocol
|Figure 7. Four Possible Structures of an APDU Command
(click image to enlarge)
A typical application will use various APDU commands with different structures.
2. The Response APDU
The format of a response APDU is much simpler:
|Figure 8 Response APDU|
Like a command APDU, a response APDU has optional and required fields:
Datafield (variable length, determined by
Lein the command APDU): This optional field contains the data returned by the applet.
SW1(1 byte): This required field is the status word 1.
SW2(1 byte): This required field is the status word 2.
The values of the status words are defined in the ISO 7816-4 specification:
|Figure 9. Response Status Codes
(click image to enlarge)
ISO7816 Java interface in the Java Card Framework API defines a number of constants to facilitate the specification of return errors code.
3. Processing APDUs
Every time there is an incoming APDU for a selected applet, the JCRE invokes the applet's
process() method, passing the incoming APDU as an argument. The applet must parse the command APDU, process the data, generate a response APDU, and return control to the JCRE.
You'll find more information on command and response APDUs in the second part of this article, in the section "The
process() Method - Working with APDUs."
The Java Card RMI (JCRMI)
The second communication model relies on a subset of the J2SE RMI distributed-object model.
In the RMI model a server application creates and makes accessible remote objects, and a client application obtains remote references to remote objects, then invokes remote methods on them. In JCRMI, the Java Card applet is the server, and the host application the client.
JCRMI is provided in the extension package
javacardx.rmi by the class
RMIService. JCRMI messages are encapsulated within the APDU object passed to the RMIService methods. In other words, JCRMI provides a distributed-object model mechanism on top of the APDU-based messaging model, by which the server and the client communicate, passing method information, arguments, and return values back and forth.
The Security and Trust Services API (SATSA)
SATSA, defined in JSR 177, specifies an optional package that provides a security and trust API for J2ME. This client API provides access to services provided by a security element (such as a smart card), including secure storage and retrieval of sensitive information, as well as encryption and authentication services.
SATSA exploits the Generic Connection Framework (GCF) defined in version 1.0 of the Connected, Limited Device Configuration (CLDC) to provide a more abstract interface to the message-passing and JCRMI communication models. To support message passing SATSA defines the
apdu: URL scheme and the
APDUConnection, and to support JCRMI it defines the
jcrmi: scheme and the
SATSA comprises the following packages:
java.rmidefines a subset of the Java 2 Standard Edition
javacard.frameworkdefines the standard Java Card API exceptions that a remote method may throw:
javacard.framework.servicedefines a standard Java Card API service exception that a remote method may throw:
javacard.security- defines the standard Java Card API encryption-related exception that a remote method may throw:
javax.microedition.iodefines two connection subinterfaces,
APDUConnectionfor smart-card access based on the APDU protocol, and
JavaCardRMIConnectionfor Java Card RMI protocol.
javax.microedition.jcrmidefines classes and interfaces used by the stubs that the Java Card RMI stub compiler generates.
javax.microedition.pkidefines classes for basic management of user certificates.
javax.microedition.securityservicedefines classes to generate application-level digital signatures.
The Java Card VM
The Java Card Virtual Machine (JCVM) specification defines a subset of the Java programming language and a Java-compatible VM for smart cards, including binary data representations and file formats, and the JCVM instruction set.
The VM for the Java Card platform is implemented in two parts, with one part external to the card and the other running on the card itself. The on-card Java Card VM interprets bytecode, manages classes and objects, and so on. The external Java VM part is a development tool, typically referred to as the Java Card Converter tool, that loads, verifies, and further prepares the Java classes in a card applet for on-card execution. The output of the converter tool is a Converted Applet (CAP) file, a file that contains all the classes in a Java package in a loadable, executable binary representation. The converter verifies that the classes conform to the Java Card specification.
The JCVM supports only a restricted subset of the Java programming language, yet it preserves many of the familiar features including objects, inheritance, packages, dynamic object creation, virtual methods, interfaces, and exceptions. The JCVM specification drops the support for a number of language elements that would use too much of a smart card's limited memory:
Table 3. Summary of Java Card Language Limitations
There are also programming-model limitations. For instance a loaded library class can no longer be extended in the card; it is implicitly made
In line with the memory constraint the JCVM specification additionally defines constraints on many program attributes. Table 4 summarizes the JCVM resource constraints. Note that many of these constraints are typically transparent to Java Card developers.
Table 4. Summary of Java Card VM Constraints
In the Java Card VM, as in the J2SE VM, class files are central, but the JCVM specification defines two other file formats to further platform independence, the Converted Applet (CAP) and Export formats, which will be described in the second installment of this article, in the section "Developing a Java Card Application."
The Java Card API
The Java Card API specification defines a small subset of the traditional Java programming language API - even smaller than that of J2ME's CLDC. There is no support for
Strings, or for multiple threads. There are no wrapper classes like
Integer, and no
In addition to its small subset of the familiar Java core classes the Java Card Framework defines its own set of core classes specifically to support Java Card applications. These are contained in the following packages:
java.iodefines one exception class, the base
IOExceptionclass, to complete the RMI exception hierarchy. None of the other traditional java.io classes are included.
Throwableclasses that lack many of the methods of their J2SE counterparts. It also defines a number of exception classes: the
Exceptionbase class, various runtime exceptions, and
CardException. None of the other traditional
java.langclasses are included.
Remoteinterface and the
RemoteExceptionclass. None of the traditional
java.rmiclasses are included. Support for Remote Method Invocation (RMI) is included to simplify migration to, and integration with, devices that use Java Card technology.
javacard.frameworkdefines the interfaces, classes, and exceptions that compose the core Java Card Framework. It defines important concepts such as the Personal Identification Number (
PIN), the Application Protocol Data Unit (
APDU), the Java Card applet (
Applet), the Java Card System (
JCSystem), and a utility class. It also defines various
ISO7816constants and various Java Card-specific exceptions. Table 5 summarizes this package's contents:
Table 5. Java Card v2.2
javacard.framework.servicedefines the interfaces, classes, and exceptions for services. A service processes incoming commands in the form of an APDU. Table 6 summarizes the framework service API:
javacard.securitydefines the classes and interfaces for the Java Card security framework. The Java Card specification defines a robust security API that includes various types of private and public keys and algorithms, methods to compute cyclic redundancy checks (CRCs), message digests, and signatures:
javacardx.cryptois an extension package that defines the interface
KeyEncryptionand the class
Cypher, each in its own package for easier export control. Use
KeyEncryptionto decrypt an input key used by encryption algorithms.
Cypheris the base abstract class that all ciphers must implement.
javacardx.rmiis an extension package that defines the Java Card RMI classes. It defines two classes,
CardRemoteObjectdefines two methods,
unexport(), to enable and disable remote access to an object from outside the card.
RemoteServiceto process RMI requests.
The Java Card Runtime /p>
The JCRE specification defines the life-cycle of the Java Card VM, the applet life-cycle, how applets are selected and isolated from each other, transactions, and object persistence and sharing. The JCRE provides a platform-independent interface to the services provided by the card's operating system. It consists of the Java Card Virtual Machine, the Java Card API, and any vendor-specific extensions:
|Figure 10. Java Card Architecture and Runtime Environment|
Life-Cycle of the Java Card VM
The JCVM's lifetime coincides with that of the card itself: It begins at some time after the card is manufactured and tested, and before it's issued to the cardholder, and it ends when the card is discarded or destroyed. The JCVM does not stop when power to the card is removed, as its state is retained in the card's non-volatile memory. Starting the JCVM initializes the JCRE and creates all the JCRE framework objects, which live for the whole lifetime of the JCVM. After the JCVM has started, all interactions with the card are, in principle, controlled by one of the applets in the card. When power is removed from the card, any data contained in RAM is lost, but any state stored in non-volatile memory is retained. When power is reapplied, the VM becomes active again, at which time the states of the VM and of objects are restored, and execution resumes waiting for further input.
Each applet on a card is uniquely identified by an Application ID (AID). An AID, as defined in ISO 7816-5, is a sequence of between 5 and 16 bytes. All applets must extend the
Applet abstract base class, which defines the methods used by the JCRE to control the applet life-cycle as summarized in Figure 10:
|Figure 11. The Java Card Applet Life-Cycle Methods|
The applet life-cycle begins when the applet is downloaded to the card and the JCRE invokes the applet's static
Applet.install() method, and the applet registers itself with the JCRE by invoking
Applet.register(). Once the applet is installed and registered, it is in the unselected state, available for selection and APDU processing. Figure 11 summarizes the operation of applet methods.
|Figure 12. Using The Java Card Applet Methods
(click image to enlarge)
While in the unselected state, the applet is inactive. An applet gets selected for APDU processing when the host application asks the JCRE to select a specific applet in the card (by instructing the card reader to send a
SELECT APDU or
MANAGE CHANNEL APDU ). To notify the applet that a host application has selected it, the JCRE calls its
select() method; the applet typically performs appropriate initialization in preparation for APDU processing.
Once selection is done, the JCRE passes incoming APDU commands to the applet for processing by invoking its
process() method. The JCRE catches any exceptions the applet fails to catch.
Applet deselection occurs when the host application tells the JCRE to select another applet. The JCRE notifies the active applet that it has been deselected by calling its
deselect() method, which typically performs any clean-up logic and returns the applet to the inactive, unselected state.
The Java Card Sessions and Logical Channels
A card session is the period of time when the card is powered up and exchanging APDUs with the card reader.
Java Card 2.2 supports the concept of logical channels that allow up to 16 application sessions into a smart card to be open at one time, with one session per logical channel. As processing of an APDU in a card can't be interrupted, and each APDU contains a reference to a logical channel (in the
CLA byte), alternating APDUs can access a number of applets in the card pseudo-simultaneously. You can design an applet to be multiselectable; that is, to communicate on more than one logical channel at a time. Multiselectable applets must implement the
javacard.framework.MultiSelectable interface and corresponding methods.
In some card deployments a default applet can be defined to be automatically selected after card reset, for communication on the base logical channel (channel 0). Java Card 2.2 allows you to define default applets, but doesn't specify how; the mechanism is vendor-specific.
Applet Isolation and Object Sharing
The Java Card platform is a secure multi-application environment - many different applets from different vendors can safely coexist in the same card. Each applet is assigned to an execution context that controls access to the objects assigned to it. The boundary between one execution context and another is often called an applet firewall. It's a Java Card runtime enhancement of the Java security concept of a sandbox, and combines the functionality of the class loader,
java.ClassLoader, and the access controller,
java.AccessController. The Java Card firewall creates a virtual heap such that an object can access (public) methods and data of only those objects that are within the same firewall. A firewall may contain a number of applets and other objects, such as common secret keys. A Java Card execution context currently has package scope. When each object is created, it is assigned to the execution context of the caller.
The Java Card platform supports secure object sharing across firewalls. Figure 12 depicts applet isolation and object sharing:
|Figure 13. Applet Firewall and Object Sharing|
The typical flow, as depicted in Figure 12:
Applets in the same execution context have access to each other by default, so Applet a and Applet b don't need to follow this procedure to share objects.
Managing Memory and Objects
On a Java Card device, memory is the most valuable resource. In some Java Card implementations a garbage collector may not be available. When an object is created, the object and its contents are preserved in non-volatile memory, making it available across sessions. In some cases application data doesn't need to be persistent - it is temporary or transient. To reduce wear on a smart card's persistent memory and thus maximize its lifetime, as much as possible treat data that is frequently updated as transient.
The Java Card technology does not support the transient keyword. Instead the Java Card API (
javacard.framework.JCSystem) defines three methods that allow you to create transient data at runtime, and a fourth that lets you check whether an object is transient:
static byte makeTransientByteArray(short length, byte event)
static Object makeTransientObjectArray(short length, byte event)
static short makeTransientShortArray(short length, byte event)
static byte isTransient(java.lang.Object theObj)
You can create a transient array of
short primitive data types, or you can create a transient
Object. But keep in mind the following behavior for transient data:
null) when an event such as a card reset or applet deselection occurs.
In a Java Card environment, arrays and primitive types should be declared at object declaration, and you should minimize object instantiation in favor of object reuse. Instantiate objects only once during the applet lifetime, preferably at applet initialization, in the
install() method, which is invoked only once during the applet lifetime.
To promote reuse, objects should remain in scope or referenced for the life of the applet, and their state (values of member variables) reset as appropriate before reuse. Because a garbage collector is not always available, an application may never reclaim the storage allocated to objects that go out of extent.
The JCRE supports atomic transactions for updating one or more persistent objects safely. Transactions ensure data integrity in the event of power loss or program error. Transactions are supported at the system level, by the following methods:
In a pattern common to many transaction models, a Java Card transaction starts with a call to
beginTransaction(), and ends with a call to either
abortTransaction(). Let's look at a code snippet that uses these APIs:
... private short balance; ... JCSystem.beginTransaction(); balance = (short)(balance + creditAmount); JCSystem.commitTransaction(); ...
The update of the instance variable balance is guaranteed to be an atomic operation. If a program error or a power reset occurs, the transaction will ensure that the previous value of
balance is restored.
The JCRE does not support nested transactions.
The first installment of this article covered a lot of ground: the use of smart cards to store sensitive information and process transactions securely, and the various aspects of Java Card technology - the Java Card VM, the runtime environment, the relevant APIs, and the behavior of Java Card applets. The second part of this article will cover the development aspects of the Java Card technology.
Smart cards with Java Card technology are the most portable and secure way of carrying digital personal information and computational capabilities; a very powerful and needed technology in today's digital world.
Many thanks to Eduard de Jong and Oscar A. Montemayor, for their great contributions to this article.
About the Author: C. Enrique Ortiz, an independent wireless consultant who specializes in end-to-end wireless enterprise software. He is an active participant in the wireless Java community, and is the co-author of the Mobile Information Device Profile for J2ME published by John Wiley and Sons. Enrique holds a B.S. in Computer Science from the University of Puerto Rico and has over 13 years of industry experience.