Smart Card Application Development Using the Java Card Technology

Milan Fort∗
RWTH Aachen

Abstract less cards. Then, we discuss the different types of card ac-
ceptance devices, which are necessary to establish a phys-
Through their combination of portability and security, ical connection with the smart card. Finally, we explain
smart cards are playing an increasingly important role the smart card communication model and the development
in the rapidly developing areas of electronic commerce process of software systems based on usage of smart cards.
and online information services. After giving an overview This section serves as a solid background for the material
of smart card characteristics and usage scenarios, we presented in the next sections.
discuss the challenges in the development of smart card In Section 3, we focus our attention on the Java Card
applications. Traditionally, this has been a lengthy and technology. Java Card technology is a state of the art oper-
difficult process, requiring knowledge of inner workings ating system for smart cards, that allows application devel-
of the smart card which varied from manufacturer to opers to create and install on-card applications (Java Card
manufacturer. However, we focus our attention on the applets) on their own. We will look at the current publicly
current mainstream technology for smart card application available specification of the Java Card technology and dis-
development, the Java Card technology. Java Card tech- cuss the contents of the different parts of it.
nology provides a secure, vendor-independent, ubiquitous In Section 4, we show typical steps in the development
platform for smart cards that enables rapid development of a real-world Java Card applet.
of smart card applications. We present a comprehensive Section 5 concludes our introduction to smart card appli-
overview of Java Card technology, including concepts, cation development using the Java Card technology.
architecture and best practices. Finally, we give a brief
survey of the Java Card applet development process. 2 Overview of Smart Cards
Keywords: Smart Card, Java Card, Security, Trust A smart card (see Figure 1), or integrated circuit card
(ICC), is defined as any integrated circuitry embedded into
a flat, plastic body. The plastic substrate can have either
1 Introduction the size of a credit card, 85,6 mm x 54 mm, which is used
in most applications, or can be only 25 mm x 15 mm. The
Smart cards represent nowadays the most portable and latter form is mostly used in mobile phones and for Security
secure computing platform available. They are used es- Access Modules in terminals. Depending on the type of the
pecially in applications that require high level of security. chip, there are two different types of ICCs.
They are capable of carrying sensitive information of the
cardholder and can support security services like authenti-
cation, encryption of private data, data integrity and non-
repudiation services like signing, etc. This paper serves as
an introduction to the development of the on-card portion of
smart card enabled applications.
In Section 2, we give an overview of smart cards. First,
we look at the differences between memory cards and mi-
croprocessor cards and between contact cards and contact-
∗ Thispaper was written as part of the conference seminar ”dependable
distributed systems” which was organized by the laboratory of depend-
able distributed systems at RWTH Aachen University during winter term Figure 1. Smart card.
2005/2006.

G-1
2.1 Memory Cards and Microprocessor Cards For all these differences, in many publications, only mi-
croprocessor cards are referred to as being really “smart”.
Depending on whether the ICC contains a microproces- For the purpose of our paper, we require a programmable
sor or not, we can divide smart cards into memory cards card supporting Java Card environment, so we will consider
and microprocessor cards. As the name suggests, memory only microprocessor cards under smart cards in our further
cards are equipped only with a memory chip and are only discussion.
able to store limited amount of information, such as health
insurance information of the cardholder. Its data process- 2.2 Contact Cards and Contactless Cards
ing is performed by a simple circuit capable of executing
a few preprogrammed instructions. Depending on the se- To communicate with the smart card (see Section 2.4 for
curity requirements of the stored data, the memory access more information on the smart card communication model),
can be protected. For example, the memory of a prepaid the host computer has to establish a connection to it. This
phone card is protected against unauthorized reloading. The can be done through the contacts on the card (see Figure 2)
advantage of memory cards lies in the simple technology. or via wireless (“contactless”) transmission.
Therefore, they are favored in applications where low cost Contactless smart cards are preferable in situations re-
is a priority. They are typically used as prepaid cards for quiring fast transactions. Examples are public transport sys-
various services sold against prepayment, e.g. the afore- tems and access control for buildings.
mentioned prepaid phone cards. Contact smart cards are the more common type of smart
Microprocessor cards, as the name implies, contain a cards. They have to be inserted into the card reader in the
processor. Such a smart card is actually a small, portable, right way and with the right orientation. Unfortunately, the
tamper-proof computer, with a CPU and memory. The CPU contacts are occasionally the cause of failures if they are
can be an inexpensive 8-bit processor, but high-end cards damaged, worn from excessive use, or just not sufficiently
contain nowadays a 16-bit or even a 32-bit processor. There clean.
are usually three types of memory available on a micropro- A contact smart card has eight contact points; their func-
cessor card: tional assignments are shown in Figure 2. Part 2 of ISO
ROM Read Only Memory, is used to store the cards op- standard 7816 [6] specifies the position, the minimal size,
eration system routines and applications. This content and the usage of the contacts:
is written during production of the card and cannot be
changed after the card is manufactured. No power is Vcc GND
required to keep the content stored in ROM.
RST Vpp
EEPROM Electrical Erasable Programmable Read Only
Memory, like ROM, can preserve data content even if CLK I/O
the smart card is unpowered. Unlike ROM, the content
of this kind of memory can be modified after the card
is manufactured. RFU

RAM Random Access Memory, is a transient memory

which keeps the data only as long as the card is pow- Figure 2. Mechanical contacts of a smart card.
ered.
A typical smart card can have nowadays around 32 kB of Vcc is used to supply the power to the chip. In general, the
ROM, about the same size of EEPROM, and up to 4 kB of voltage is between 4.5V and 5.5V. In mobile phones,
RAM, which is the most expensive and (physically) largest smart cards have typically around 3V Vcc voltage.
type of memory.
Optionally, the card can contain a cryptographic copro- RST is used for the reset signal to reset the address counter
cessor that increases the performance of cryptographic op- and the microprocessor. This is called a warm reset.
erations. A cold reset occurs when the power supply voltage is
Such smart cards offer much higher security and func- turned off and on again, e.g. by taking the card out of
tionality than simple memory cards. All cryptographic op- the reader and reinserting it again.
erations are performed on the card, so that the sensitive in- CLK is used to supply the external clock signal, from
formation, like cryptographic keys, never leaves the card. which the internal clock is derived.
The card can be designed for a specific application, or sup-
port multiple functionality and be used by many different GND is used as reference voltage; its value is considered
applications. to be zero voltage.

G-2
Vpp is optional and is used only in older cards to supply 2.4.1 APDU Protocol
voltage necessary to program the EEPROM memory
The top layer is the APDU (application protocol data units)
in these cards.
protocol, which is specified in ISO 7816-4. This protocol
I/O is used to transfer data between the smart card and the defines two types of messages, the command APDU and
reader in a half-duplex mode, i.e. data can be transmit- the response APDU. The first one is used by the host ap-
ted in only one direction at any particular time. plication to send commands to the card, the other is used
by the card to send responses back to the host application.
RFU points are reserved for future use. In this way, a command APDU is always paired with a re-
sponse APDU. Their structures are depicted in Figure 3 and
2.3 Card Acceptance Device Figure 4, respectively.

Before the communication between the computer and the Header(required) Body(optional)
smart card can take place, it is necessary to establish a phys- CLA INS P1 P2 Lc Data Le
ical connection with the smart card. In case of contact cards,
the smart card has to be inserted into the card acceptance Figure 3. Command APDU structure.
device. There are two types of card acceptance devices:
• Smart card readers Each command APDU contains [2]:
• Smart card terminals • A class byte (CLA). It identifies the class of instruction
of the command.
A smart card reader is essentially a connector between the
computer communicating with the card and the smart card. • An instruction byte (INS). It determines the specific
It can be attached to the serial, parallel, or USB port of a command.
computer. Other reader types are integrated with the key-
board or fit into the PCMCIA slot. A smart card reader • Two parameter bytes P1 and P2. These are used to pass
has usually one slot for a smart card. However, there are command specific parameters with the command.
readers with more than one slot; they are used for a special • A length byte Lc (“length command”). It specifies the
type of applications, where one smart card is required for length of the optional data sent to the card with this
authorization before reading the data from another card. In APDU.
addition to the card slot and the computer interface, a smart
card reader can have also a display and a PIN-pad. • Optional data.
In contrast, a smart card terminal is a computer on its
own. It integrates a smart card reader as one of its compo- • A length byte Le (“length expected”). It specifies the
nents. Smart card terminals are used nowadays mostly in expected length of the data returned in the subsequent
stores for payments and credit card transactions. Another response APDU.
form of terminal is a bank ATM. An ATM, if it accepts CLA, INS, P1, P2 form the header of the command APDU.
smart cards, can be used for example to load money to an This header is mandatory. Lc, optional data, and Le form
electronic purse, to check the actual balance, to change a the optional body of the command APDU. This body can
password, etc. have several variations, which we won’t discuss here in de-
For our further discussion, we will assume a normal tail. For more information, please refer to [1].
smart card reader connected to a computer. However,
most of the discussion, especially about the communication
Body(optional) Trailer(required)
model in the next section, applies to applications running Data SW1 SW2
inside a smart card terminal as well.
Figure 4. Response APDU structure.
2.4 Smart Card Communication Model

The communication between the host computer and the A response APDU contains:
smart card is half-duplex; i.e. the data can either be sent • Optional data.
from the host to the card or vice versa, but not in both di-
rections at the same time. • Two status word bytes SW1 and SW2. They contain
The protocol stack used for communication has two lay- the status information as defined in ISO 7816-4. In
ers, which we discuss in the following subsections. case of successful execution, they contain 0x9000.

G-3
The length of the optional data in the response APDU is Current smart card operating systems enable application
determined by the Le byte in the corresponding command developers to create and install on-card applications on their
APDU. Should an error occur, no optional data might be own. The mainstream technology in this area is the Java
returned despite of the specified length. Card technology, which we cover in the next section.

2.4.2 TPDU Protocol 3 Introduction to Java Card Technology

The next lower layer is the transport protocol, specified in
In 1997, Sun Microsystems realized the potential of
ISO 7816-3. APDUs are transmitted by this protocol in
smart cards, and defined a set of specifications for a sub-
data structures called transmission protocol data units, or
set of Java technology to create applications for them, Java
TPDUs. The protocols T=0 and T=1 are the two most-used
Card applets. This brought the main advantages of Java
variations of the transport protocol. The T=0 protocol is
to smart card application development. Additional secu-
byte oriented, which means that each byte is transmitted
rity mechanisms allowed multiple applications from differ-
separately, whereas the T=1 protocol is block-oriented; i.e.
ent vendors to run on the same card without compromising
a single unit of transfer between a card and a host is a block,
each other’s security.
consisting of a sequence of bytes. Most modern smart card
The Java Card technology specification, currently in ver-
readers support both T=0 and T=1 protocols. The transport
sion 2.2.1, consists of three parts:
protocol supported by the card is discovered from the ATR,
which is a sequence of bytes that the smart card returns to • The Java Card Virtual Machine (JCVM) specification,
the reader immediately after it is powered up. In addition to which defines a subset of the Java programming lan-
the protocol information, the ATR contains data identifying guage and a virtual machine for smart cards.
the type of the card. The ATR is defined in ISO 7816-3.
• The Java Card Runtime Environment (JCRE) specifi-
cation, which further defines the runtime behavior for
2.5 Smart Card System Development Process
Java enabled smart cards.
A smart card system is a distributed system that consists • The Java Card Application Programming Interface
of the following two parts: (API) specification, which defines the core and exten-
sional Java packages and classes for smart card appli-
• Host (off-card) application cation development.
• On-card application
3.1 Java Card Language Subset
The host application is the part that resides on the computer
connected to the smart card through a smart card reader de- The Java Card Virtual Machine supports only a restricted
vice. Such application typically recognizes a specific card subset of the Java programming language, yet it preserves
and handles the communication with the card by exchang- many of the familiar features including objects, inheritance,
ing a predefined set of APDUs with the card. Host appli- packages, dynamic object creation, virtual methods, inter-
cation is usually written in a high-level programming lan- faces, and exceptions. The JCVM specification drops the
guage, such as Java or C++. For Java development, the de support for a number of language elements that would use
facto standard framework, that supports host application de- too much of a smart card’s limited memory [4]:
velopment, is the OpenCard Framework (OCF)1 . Unfortu- • Dynamic class loading, security manager, threads, ob-
nately, the development of host applications is out of scope ject cloning, and certain aspects of package access
of this paper, so we refer readers interested in Java develop- control are not supported.
ment using OCF to [2].
The development of the on-card application has been tra- • Keywords native, synchronized, transient,
ditionally a lengthy and difficult process, requiring knowl- volatile, strictfp are not supported.
edge of inner workings of the smart card and usage of pro-
prietary toolkits and low-level assembly languages. Such • There is no support for char, double, float, and
application development has been done by the card operat- long, or for multidimensional arrays. Support for
ing system developers. The code was then integrated into int is optional.
the mask for the ROM of the smart card before the card was • The Java core API classes and interfaces (java.io,
manufactured. java.lang, java.util) are unsupported except
1 Sun Microsystems has recently initiated JSR 268, whose objective is for Object and Throwable, and most methods of
to add a smart card I/O API to Java Platform, Standard Edition (Java SE). Object and Throwable are not available.

G-4
 • The Exception and Error subclasses that cannot After a JCRE reset, the JCRE enters a loop, waiting for
arise in the Java Card platform are omitted. APDU commands to arrive from the host. The host sends
APDU commands to the Java Card platform using the se-
3.2 Java Card Virtual Machine rial communication interface via the card I/O contact point.
When a command arrives, the JCRE either selects an applet
to run as instructed in the command or forwards the com-
The virtual machine for the Java Card platform is imple- mand to the currently selected applet. The selected applet
mented in two separate pieces. One portion resides on the then takes over control and processes the APDU command.
card itself, while the other one, which is rather a develop- When finished, the applet sends a response back to the host
ment tool, is external to the card. The purpose of this ex- application and surrenders control to the JCRE. This pro-
ternal part, which is often referred to as the Java Card Con- cess repeats when the next command arrives. For more de-
verter tool, is to load, verify, and further prepare the Java tailed description of JCRE and applet life-cycle, please refer
classes in a card applet for on-card execution. The output to [3].
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, and an export file repre- 3.3.1 Java Card Runtime Features
senting the public API of the package. The on-card part
of JCVM interprets bytecode instructions, manages classes Besides supporting the Java language runtime model, the
and objects, and enforces the runtime security model. JCRE supports three additional runtime features [3]:
Before the on-card interpreter can execute the code
found in the CAP file, it has to be loaded onto the card. • Persistent and transient objects–Java Card objects are
The process of downloading and installing a CAP file is per- persistent by default. They are created in EEPROM
formed by a unit called the installer. and retain their state even when the card is not pow-
The Java Card installer resides within the card. It coop- ered. For security or performance reasons, applets can
erates with an off-card installation program, that transmits create objects in RAM. Such objects are called tran-
the CAP file to the installer running on the card via the card sient objects and they keep their state only while the
reader device. The installer then writes the binary into the card is powered. For more information on persistent
smart card memory, links it with the other classes that have and transient objects please refer to [3, Chapter 4].
already been placed on the card, and creates and initializes
any data structures that are used internally by the Java Card • Atomic operations and transactions–The Java Card
runtime environment [3]. virtual machine ensures that each write operation to a
single field of a persistent object is atomic. It guaran-
3.3 Java Card Runtime Environment tees that the updated field either gets the new value or
is restored to its original value before the write attempt.
The Java Card runtime environment (JCRE) consists of Additionally, the JCRE provides transaction APIs, that
the Java Card virtual machine, the Java Card API classes, let the applet developer include several write opera-
and industry specific extensions. The JCRE is basically the tions in a transaction. Then, either all updates in this
smart card’s operating system; its responsibilities include transaction complete successfully, or the state of all
the card resource management, I/O communication and ap- variables affected by this transaction is restored to the
plet life-cycle management, and Java Card security model previous state. [3, Chapter 5] gives a good introduction
enforcement. to the topic of atomic operations and transactions.
The JCRE is initialized at card initialization time. Dur-
ing this process, which is performed only once during the • Applet firewall and the sharing mechanisms–On a Java
card lifetime, the JCRE initializes the virtual machine and Card enabled smart card, multiple applications from
creates objects for providing the JCRE services and manag- different vendors can coexist securely. JCRE provides
ing applets. Thus, these objects live for the whole lifetime the applet firewall mechanism, that isolates applets
of the JCVM. As applets are installed, the JCRE takes care from each other. Hence, the existence and operation
of creating applet instances, and managing their life-cycles. of one applet has no effect on the other applets on the
During the period from the time the card is inserted into card. In situations where applets need to share data,
the card reader and is powered up until the time the card the virtual machine permits such functionality through
is removed from the card reader, the JCRE operates like a a well defined secure sharing mechanisms. See [3,
typical smart card–it supports APDU I/O communication Chapter 9] for more information on applet firewall and
with a host application. the sharing mechanisms.

G-5
3.4 Java Card API Cypher, each in its own package for easier export
control. KeyEncryption is used to decrypt an in-
The Java Card API specification defines a small subset of put key used by encryption algorithms. Cypher is the
the traditional Java programming language API. Due to the base abstract class that all ciphers must implement.
smart card’s strict memory restrictions, many fundamen-
• javacardx.rmi is an extension package that
tal classes like String, Thread, System or Class are
defines the Java Card RMI classes. It defines two
not supported. There is no support for wrapper classes like
classes, CardRemoteObject and RMIService.
Boolean and Integer, and the whole collections frame-
CardRemoteObject defines two methods,
work is missing as well. In addition to its small subset of
export() and unexport(), to enable and dis-
the traditional core Java classes, the Java Card API spec-
able remote access to an object from outside the
ification defines its own set of core classes specifically to
card. RMIService extends BasicService and
support Java Card applet development. These are contained
implements RemoteService to process RMI
in the following packages [4]:
requests.
• java.lang defines Object and Throwable
classes that lack many of the methods of their Java 4 Developing a Java Card Applet
SE counterparts. It also defines a number of exception
classes: the Exception base class, various runtime There are two different programming models that can be
exceptions, and CardException. None of the other employed for the development of a Java Card applet. The
traditional java.lang classes are included. first model is the fundamental message-passing model, de-
• java.rmi defines the Remote interface and the signed around the APDU protocol, which we will exam-
RemoteException class. None of the traditional ine in this section. The second model is based on the Java
java.rmi classes are included. Support for Remote Card Remote Method Invocation (JCRMI), a subset of the
Method Invocation (RMI) is included to simplify mi- Java SE RMI distributed-object model. JCRMI provides a
gration to, and integration with, devices that use Java distributed-object model mechanism on top of the APDU-
Card technology. based messaging model. For the sake of brevity, we won’t
cover development of Java Card applets using JCRMI any
• java.io defines one exception class, the base further.
IOException class, to complete the RMI excep- Developing a Java Card applet using the APDU based
tion hierarchy. None of the other traditional java.io approach is a two-step process:
classes are included.
1. Defining the command and response APDUs that serve
• javacard.framework defines the interfaces, as the interface between the host application and the
classes, and exceptions that compose the core Java applet.
Card Framework. It defines important concepts such
as the Personal Identification Number (PIN), the 2. Writing the Java Card applet itself.
Application Protocol Data Unit (APDU), the Java Card
applet (Applet), the Java Card System (JCSystem), 4.1 Defining APDU Instructions
and a utility class. It also defines various ISO 7816
constants and various Java Card-specific exceptions. The APDU instruction set supported by an applet is al-
ways domain specific. For example, a wallet applet that
• javacard.framework.service defines the in- stores electronic money may support functions like credit,
terfaces, classes, and exceptions for services. A ser- debit, verify PIN and check balance. A health insurance
vice processes incoming commands in the form of an applet may allow to access health insurance information,
APDU. coverage limits, doctors, patient information, etc. Thus, the
exact APDUs that you define depend on the functional re-
• javacard.security defines the classes and inter-
quirements of your application.
faces 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 4.2 Writing the Java Card Applet
algorithms, methods to compute cyclic redundancy
checks (CRCs), message digests, and signatures. Every applet is implemented by creating a sub-
class of javacard.framework.Applet class. The
• javacardx.crypto is an extension package that JCRE invokes the methods install(), select(),
defines the interface KeyEncryption and the class deselect(), or process(), which are defined in the

G-6
base Applet class, when it wants to install, select, or des- 4.2.4 The deselect() Method
elect the applet or to ask the applet to process an incoming
APDU command. The JCRE invokes deselect() to notify the applet that
it has been deselected. This method may be overridden to
A typical structure of a Java Card applet is shown in Fig-
provide session cleanup. The default implementation by the
ure 5. We will now look at this structure in more detail.
javacard.framework.Applet class does nothing.

4.2.5 The process() Method

import javacard.framework.*;
... Once an applet has been selected, it is ready to receive com-
public class MyApplet extends Applet { mand APDUs. Every time the JCRE receives an APDU
// Definitions of APDU-related command (from the host application via the card reader), it
// constants calls the currently selected applet’s process() method,
...
passing it the incoming command APDU as an argument.
// Constructor
The process() method then [5]:
MyApplet() {...}
// Life-cycle methods
1. Extracts the APDU’s CLA and INS fields.
install() {...}
select() {...} 2. Retrieves the application-specific P1, P2, and data
deselect() {...}
fields.
process() {...}
// Private methods 3. Processes the APDU’s data.
...
} 4. Generates and sends a response.

5. Returns gracefully, or throws an appropriate ISO ex-

Figure 5. Typical Java Card applet structure. ception.

At that point, the JCRE sends the appropriate status words

4.2.1 The Constructor back to the host application, via the card reader.
This concludes our introduction to the development of
The private constructor is called from the install() a Java Card applet. For an extensive code example, please
method; i.e., the constructor is called only once during the refer to [3, Chapter 12].
lifetime of the applet. Any objects that might be required
during execution of an applet should be preallocated in the
constructor, to ensure that the applet will never fail due to
5 Conclusions
lack of memory.
Smart cards represent nowadays the most portable and
secure computing platform available. They are used to
4.2.2 The install() Method store sensitive information and process transactions se-
curely. Java Card technology brings smart card application
The JCRE invokes install() during the applet instal-
development into the mainstream while preserving smart
lation process. This method must be implemented and
card security.
must create the applet instance by using the new oper-
In this paper, we have first given a detailed survey of
ator followed by a call to the applet’s constructor. The
smart cards and their applications. Thereafter we have
install() method must directly or indirectly call the
looked closely on the current Java Card platform specifi-
register() method to complete the installation.
cation, discussing its architecture and concepts. Finally,
we have demonstrated typical development steps of a real-
4.2.3 The select() Method world Java Card applet. Readers interested in a more de-
tailed guide should refer to [3].
The JCRE invokes select() to notify the applet
that it has been selected for APDU processing. The
select() method must return true to indicate that References
it is ready to process incoming APDUs, or false to
decline selection. The default implementation by the [1] W. Rankl and W. Effing. Smart Card Handbook. John
javacard.framework.Applet class returns true. Wiley & Sons, 3rd edition, 2004.

G-7
[2] U. Hansmann, M. Nicklous, T. Schäck, A. Schneider,
and F. Seliger. Smart Card Application Development
Using Java. Springer, 2nd edition, 2002.
[3] Z. Chen. Java Card Technology for Smart Cards.
Addison-Wesley Professional, 1st edition, 2000.
[4] C. E. Ortiz. An Introduction to Java Card Technology -
Part 1. Sun Developer Network, 2003.
[5] C. E. Ortiz. An Introduction to Java Card Technology -
Part 2, The Java Card Applet. Sun Developer Network,
2003.
[6] International Organization for Standardization.
http://www.iso.org.

G-8