Java Card Technology
Ch03: Overview
Instructors:
Fu-Chiung Cheng
( 鄭福炯 )
Associate Professor
Computer Science & Engineering
Tatung University
Content
Architecture Overview
Java Card Language Subset
Java Card Virtual Machine
Java Card Installer and off Card
Installation Program
Java Card Runtime Environment
Architecture Overview
Java card technology enables programs
written in Java to run on smart cards and other
resource-constrained devices.
Smart cards represent one of the smallest
computing platforms in use.
How to fit Java system into a smart card?
(Smart cards have 1K of RAM,16K of EEPROM, 24K
of ROM)
Support only a subset of features
apply a split model to implement JVM
Architecture Overview
JCVM (Java Card Virtual Machine) is split into
:
Part that runs off-card
Part that runs on-card
Off-card process:
Processing tasks that are not constrained
to execute at runtime
Class loading, bytecode verification,
resolution and linking, and optimization
Architecture Overview
On-card process:
defines a runtime environment that
supports the smart card memory,
communication, security and
application execution model
Java Card runtime environment
conforms to the smart card
international standard ISO 7816
Architecture Overview
Java Card Technology contains:
Java Card Virtual Machine (JCVM) Specification: define
a subset of the Java Programming language and virtual
machine architecture suitable for smart card
applications
Java Card Runtime environment (JCRE): describe Java
Card runtime behavior, including memory management,
applet management and other runtime features
Java Card Application Programming Interface
Specification (APIs): describe the set of core and
extension Java package and class for programming
smart card applications
Java Card Language Subset
Support only a carefully chosen, customized
subset of feature of java language
Due to small memory footprint of Java card
Well suited for writing programs for smart
card applications
Preserving the object-oriented capabilities
Many advanced smart cards provide a
garbage collection mechanism to enable
object deletion
Java Card Language Subset
Supported Java feature Unsupported Java feature
Small primitive data types: Large primitive data type:
boolean, byte, short long, double, float
One-dimensional array Characters and strings
Java packages, classes,
interfaces, and exceptions
Multidimensional arrays
Java object-oriented Dynamic class loading
feature: inheritance, virtual Security manager
methods, overloading and Thread
dynamic object creation,
access scope, and binding Object serialization
rules Object cloning
The int keyword and 32-bit
integer data type support
are optional
Java Card Virtual Machine
Java card virtual machine(JCVM) is
implemented as two separate pieces:
The on card portion of JCVM includes the java
bytecode interpreter
The converter is the off-card piece of JCVM
which runs on a PC or workstation
The two pieces implement all the VM function
and generate some output file like CAP
(converted applet) file and export file
Java Card Virtual Machine
Converter interpreter
Class
files
CAP
file
CAP File and Export File
The converter loads and preprocess the class files and
outputs a CAP file
A CAP file contains an executable binary representation
of the class in Java package
A CAP file is a JAR file that contains a set of components.
Each component describes an aspect of CAP file content,
such as class information, executable bytecode, linking
information, verification information and so forth
The CAP file format is optimized for small small footprint
by compact data structure and limited indirection.
CAP File and Export File
Export file are not loaded onto smart card and
thus are not directly used by interpreter
Export file can be thought of as the header files
in C programming language
It contains public API information for an entire
package of classes
It defines access scoop, class name,
signature of method and fields
It contains linking information used for
resolving interpackage references on the card
Java Card Converter
The converter processed one class at a time,
the conversion unit of it is a package
The converter takes two input : class files and
export files
Java Card Converter
During the conversion, the converter performs
tasks that a JVM in a desktop environment
would perform at class-loading time:
Verifies that the load images of the java classes are
well formed
Checks for Java Card language subset violations
Performs static variables initialization
Optimizes bytecode
Allocates storage and creates VM data structures to
represent classes
Java Card interpreter
Java Card interpreter provides runtime support of
Java language model and thus allows hardware
independence of applet code
Tasks:
Executes byecode instructions and ultimately
execute applets
Controls memory allocation and object creation
Plays a crucial role in ensuring runtime security
Java Card Installer and Off-Card
Installation Program
The interpreter does not itself load CAP file.
Java card installer is the mechanism to download and
install a CAP file
The Java Card installer resides within card.
Java card installer cooperates with an off-card
installation program.
The installation program transmits the executable binary
in a CAP file to installer via card acceptance (CAD)
Then the JC installer writes the binary into memory of
card, links with other class and creates and initializes
any data structures that are used
Java Card Installer and Off-Card
Installation Program
Java Card Runtime Environment
Java card runtime environment (JCRE) consists of
a Java Card system components that run inside a
smart card
JCVM, JC APIs, industry-specific extension and
JCRE system classes.
JCRE is responsible for (JCRE == JC OS)
Card resource management
Network communication
Applet execution
On-card system and applet security
On-Card System Architecture
On-Card System Architecture
JCVM
executes bytecodes,
controls memory allocation,
manages objects, and
enforces the runtime security
Native methods:
Provide support to the JCVM and system
classes
Handle low-level communication protocols,
memory management, crytographic support
On-Card System Architecture
System classes
are analogues to an OS core
manage transactions
manage communication between the host
applications and Java Card applet
control applet creation, selection and
deseletion
On-Card System Architecture
Java Card Application framework classes
define the four core and extension API packages
This framework makes it relatively easy to create an
applet.
Applets access JCRE services through framework
classes.
Industry-specific extension
Add-on libraries to provide additional services or to
refine the security and system model
Example: Open Platform extends the JCRE services
to meet financial industries’ specific security needs.
On-Card System Architecture
Installer
Enables the secure downloading of software
and applets onto the card after the card is
made and issued to the card holder
Cooperates with the off-card installation
program
Is an optional JCRE component
Java Card applet
User applications on JC platform
Applets are downloadable
JCRE Lifetime
JCRE is initialized at card initialization time
JCRE initialization is performed only once during the
card lifetime
JCRE initialization:
initialize the virtual machine
Create objects for providing JCRE services
Manage applets
Applets installation
JCRE creates applet instance
Applets create objects to store data
CAD Session
CAD Session:
The period from the time the card is inserted
into the card acceptance devices (CAD) and
is powered up until the time the card is
removed from the CAD
During a CAD session, the JCRE operates like
a typical smart card (i.e. support APDU I/O
communication). See Fig 3.5 on page 38
APDUs are sent (Command APDUs and
Response APDUs)
CAD Session
After a JCRE is reset, the JCRE enters into a
loop, waiting for APDU commands from the host
The host sends APDU commands to the Java
Card, using the serial communication interface
via the card input/output contact point
When a command arrives, the JCRE either
selects an applet to run as instructed in the
command or forwards the command to the
currently selected applet
CAD Session
The selected applet then takes control
and processes the APDU command
When finished, the applet sends a
response to the host application and
surrenders control to the JCRE
This process repeats when the next
command arrives.
Java Card Runtime Features
Besides supporting the Java language
runtime model, the JCRE supports
three additional runtime features
Persistent and transient objects
Atomic operations and transaction
Applet firewall and the sharing
mechanisms
Java Card Runtime Features
Persistent and transient objects
By default, Java Card objects are persistent and
are created in persistent memory
The space and data of such objects span CAD
sessions
For security and performance reasons, applet can
create objects in RAM
Such objects are called transient objects
Transient objects contain temporary data that are
not persistent across CAD sessions
Java Card Runtime Features
Atomic operations and transaction
JCVM ensures that each write operation to a
single field in an object or in a class is atomic
The updated field either gets the new value or
is restored to the previous value
JCRE provides transaction APIs
An applet can include several write operations
in a transaction
Either all updates in a transaction are complete
or none of them proceeds
Java Card Runtime Features
Applet firewall and the sharing mechanisms
The applet firewall isolates applets
Each applet runs within a designated space
The existence and operation of one applet
has no effect on the other applets on the card
The applet firewall is enforced by the JCVM
as it executes bytecodes
JCVM permits shared data access through
secure sharing mechanishms
Java Card APIs
Java Card APIs consist of customized classes for
programming smart card applications according to
the ISO 7816 models
Java Card APIs contains
3 Core packages
java.lang
javacard.framework
javacard.security
One extension package
javacardx.crypto
Java Card APIs
Classes are not supported
GUI interfaces
Network I/O
Desktop file system I/O
The reasons:
No display
Different network protocol
Different file system structure
Java.lang Package
Table 3.2
Object Throwable Exception
Runtime- Arithematic- ArrayIndexOutOfBoun
Exception Exception dsException
ArrayStore- ClassCast- IndexOutOfBounds-
Exception Exception Exception
NullPointer- Security- NegativeArraySize-
Exception Exception Exception
Javacard.framework Package
javacard.framework provides framework classes
and interfaces for the core functionality of Java
Card applet
Import classes:
Applet class: provides a framework for applet
execution
APDU class: APDUs are carried by the transmission
protocol (Transmission protocol are T=0 or T=1)
JCSystem class: control applet execution, resource
management, transaction management and inter-
applet object sharing
Javacard.framework Package
Import classes:
PIN class:
Short for personal identification
number
provide the common form of
password to authenticating card
holders
Javacard.security Package
Provides a framework for cryptographic
functions
javacard.security
defines a key factory class keyBuilder and
various interfaces used in symmetric (DES)
and asymmetric (DSA and RSA) algorithms
Supports abstract base classes
RandomData, Signature, and
MessageDigest
Javacardx.crypto Package
Is an extension package
Contains cryptographic classes and
interfaces
Defines the abstract base class Clipher
Support encryption and decryption
functions
Does not provide any implementation
There is a coprocessor on smart cards to
perform crytographic computation
Java Card Applet
Java Card Applets is not the same as the
J2SE Applet
JC applet is a Java program, that adhere to a
set of conventions, and can run within the Java
Card runtime environment
They can be dynamically downloaded onto the
card
Multiple applets can coexist on a single Java
card, and an applet can have multiple
instances
Package and Applet Naming
Convention
Each applet instance is uniquely identified by
Application Identifier (AID)
Each Java package is also assigned an AID
ISO 7816 specifies AIDs to be used for
unique identification of card application and
certain kinds of files
RID (5 bytes) PIX (0-11 bytes)
Resource Identifier Proprietary Identifier Extension
Package and Applet Naming
Convention (cont.)
The AID for a package is constructed by
concatenating
the company’s RID
A PIX for that package
ISO controls the assignment of RIDs to
companies; each company has a unique RID.
Companies manage assignment of PIXs
The RID in an AID identifies an applet
provider
Package and Applet Naming
Convention (cont.)
Package AID =
Company’s RID
Package PIX
Applet AID =
Company’s RID (Applet provider’s RID)
Applet PIX
Package and Applet Naming
Convention (cont.)
The package AID and the default applet
AID for each applet defined in the
package
Specified in the CAP file
Supplied to the converter when the
CAP file is generated
Applet Development Process
Java Java class
Step 1:
files compiler files
Java Card
Step 2:
simulator
export Java Card export
Step 3:
file(s) converter files
CAP
file(s)
Java Card
Step 4:
emulator
Applet Development Process
Step 1:
A developer writes one or more Java Classes
and
compiles the source code with a Java compiler
Produce one or more class files
Step 2:
Applet is run, tested and debugged in a
simulation environment
The overall functional aspects of applet are
tested
Applet Development Process
Step 3:
Class files are converted to a CAP file
A CAD file and an export file are created for
each package
Step 4:
CAP files are loaded and tested in an emulation
environment
Runtime behaviors of applet are tested
Applet firewall
Transient and persistent objects
Applet Installation
ROM Applets
Pre-issuance or Post-issuance Applets
Post-issuance Applets Installation
Error Recovery during Applet
Installation
Installation Constraints
Applet Installation `
Masking
The process of writing the permanent
components into the non-mutable memory
of a chip
When a Java Card is manufactured, the
smart card proprietary system and Java Card
runtime environment (native methods, JCVM,
Framework APIs and libraries) are burned
into ROM.
ROM Applets
Applet classes can be masked in ROM
together with JCRE and other system
components during the process of card
manufacturing
Applet instances are instantiated in EEPROM
by the JCRE during the JCRE initialization.
Such applets are called ROM applets
ROM applet content are controlled by issuers
ROM applet are allowed to declare native
methods (not checked by JCVM)
Pre-issuance or Post-
issuance Applets
Java Card applet classes and associated class
libraries can be downloaded and written into the
mutable memory (EEPROM) after the card is
manufactured
Pre-issuance and post-issuance are downloaded
before or after the card has been issued
Pre-issuance applets are treated the same way
as the ROM applets
Post-issuance applets are not allowed to declare
native methods (security reason)
Post-issuance Applets
Installation
Applet installation refers to the process of
loading applet classes in a CAP file,
combining them with the execution state of JCRE
and
creating an applet instance to bring the applet into
a selectable and execution state
On the Java Card platform, the loading and installable
unit is a CAP file.
A CAP file consists of classes and a minimal applet is
a Java package with a single class derived from the
javacard.framework.Applet
Post-issuance Applets
Installation
To load an applet
The off-card installer takes the CAP file and
transforms it into a sequence of APDU
commands which contain the CAP file content
By exchanging the APDU commands with the
off-card installer, the on-card installer
writes the CAP file into card’s persistent
memory and
links the classes in the CAP file with other
classes reside on the card
Post-issuance Applets
Installation
The on-card installer also creates and initializes and
data that are used internally by the JCRE to support
the applet
The on-card installer create an applet instance and
registers the instance with the JCRE by using install
method
Public static void install(byte[] bArray, short offset,
byte length)
bArray: installation parameters for applet
initialization
Postissuance Applets
Installation(cont.)
The install method is an applet entry point
method, similar to the main method in Java
applications
An applet must implement the install method
The install method calls applet’s constructor to
create and initialize an applet instance
After the applet is initialized and registered with
JCRE, it can be selected and run
The install method can be called more than
once to create multiple applet instances
Error Recovery during Applet
Installation
The installation process is transactional
The installer will discard the CAP file
and any applets it had created during
installation when
Programmatic failure
Running out of memory
Card tear
Other errors
Installation Constraints
Java Card Applet installation has two points
Applets executing on the card may refer
only to classes that already exist on the
card
The order of loading must guarantee that
each newly loaded package references
only packages that are already on the card