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