Download Lecture 6

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





Small primitive data types:
boolean, byte, short
One-dimensional array
Java packages, classes,
interfaces, and exceptions
Java object-oriented
feature: inheritance, virtual
methods, overloading and
dynamic object creation,
access scope, and binding
rules
The int keyword and 32-bit
integer data type support
are optional
Unsupported Java feature








Large primitive data type:
long, double, float
Characters and strings
Multidimensional arrays
Dynamic class loading
Security manager
Thread
Object serialization
Object cloning
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
Class
files
CAP
file
interpreter
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
RuntimeException
ArithematicException
ArrayIndexOutOfBoun
dsException
ArrayStoreException
NullPointerException
ClassCastException
SecurityException
IndexOutOfBoundsException
NegativeArraySizeException
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)
Resource Identifier
PIX (0-11 bytes)
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
Step 1:
Java
files
export
file(s)
Java Card
converter
CAP
file(s)
Step 4:
class
files
Java Card
simulator
Step 2:
Step 3:
Java
compiler
Java Card
emulator
export
files
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