Introduction to Java
Card
Smart Cards
• The evolution of
– smartcards,
– smartcard operating systems
– smartcard programming languages
is similar to that of other computers, but a lot
faster.
• Java Card is a new generation smartcard OS &
programming language
2
Old vs New smartcards
• one program (applet) • Applet written in high-level
language (mainly Java Card)
• written in machine-code,
• compiled into bytecode
specific to chip
• stored in EEPROM
• burnt into ROM • interpreted on card
• multi-application: several
applets on one card
• post-issuance: adding or
deleting applets on card
3
Java Card
• dialect of Java for programming smartcards
• subset of Java (due to hardware constraints)
– no threads, doubles, strings, garbage collection, and
very restricted API
• with some extras (due to hardware peculiarities)
– communication via APDUs or RMI
– persistent & transient data in EEPROM &RAM
– transaction mechanism
4
Java Card architecture
applet
applet
applet
Java Card Java Card API
Java Card
Virtual Machine
platform
(mini OS)
smartcard hardware
5
Java Card vs Java
• Java Card applets are executed in a sandbox,
like applets in a web browser.
(In fact, Java Card sandbox rules are more restrictive
than Java’s)
6
The Java Card language
• JC is a subset of the Java language:
– no reals, doubles, strings, multi-dim arrays
– no threads
– garbage collection only optional
• JC uses 16 bit arithmetic, not 32.
• JC uses an optimized form of class files, called
cap-files.
7
16 bit arithmetic
JC code contains many(short)casts.
In particular, all intermediate results (which are of type
int) must be cast to short
short s; byte b;
s = b+s+1;
// not ok, compiler complains
s = (short)(b+s+1);
// not ok, converter complains
s = (short)(b+(short)(s+1)) // ok
8
(un)signed bytes
• Bytes in Java and Java Card are signed
Ie. for any byte b
b Є {-128, ..., 127}
• To interpret byte as unsigned value
b & 0x00FF Є {0, ..., 255 }
9
The Java Card API
• A subset of Java’s API
– no need for most standard I/O classes
• plus some extras for
– smartcard I/O with APDUs using ISO 7816
– persistent and transient data
– transactions
10
Java Card API packages
• java.lang
Object, Exception, ...
• javacard.framework
ISO7816, APDU, Applet, JCSystem
• javacard.security
KeyBuilder, RSAPrivateKey, CryptoException
• javacardx.crypto
Cipher
11
Card-terminal communication
Two ways
• communication via APDUs, as defined in
ISO7861
• RMI (Remote Metohd Invocation)
– since JavaCard version 2.2
– this is what you should use
12
RMI
• dealing with APDUs very cumbersome
• JavaCard 2.2 introduced RMI(Remote Method
Invocation):
– terminal invokes methods on applet on the
smartcard
– platform translates this method invocation into
APDUs
13
RMI Model
Network and Distributed
Objects
My Machine Remote
Machine
Local
Remote
Objects
Objects
Architecture
Client Server
Stub Skeleton
s s
Remote Remote
Reference Reference
Transport
APDU (ISO-7816)
• Standard describing the protocol for
communication between smartcard and
terminal (some parts downloadable at
http://www.cardwerk.com/smartcards)
• Messages are called APDUs (Application
Protocol Data Units), which are sequences of
bytes in a certain format
• Terminal sends command APDU to card, card
sends a response APDU back, etc.
16
Java Card I/O with APDUs
OS command
selects
Appletapplet
sends
applet
applet
applet
applet
APDU,
appletits
and invokes
response
incl. applet ID
executes
process
APDU
method
Java Card platform
terminal
smartcard hardware
17
Command APDU
CLA INS P1 P2 Lc ...Data .... Le
• CLA class byte
• INS instruction byte obligatory
• P1,P2 parameters
• Lc length of data block
optional
• Data Lc bytes of data
• Le length of expected response optional
18
Response APDU
Data ... SW1 SW2
• Data : Le bytes of data (optional)
• SW1, SW2 : status word (obligatory)
19
APDU coding conventions
• Some conventions for CLA, INS etc. given in
ISO 7816-4
• Conventions for status word SW1 SW2
– normal processing 61xx, 9000
– warning processing 62xx, 63xx
– execution error 64xx, 65xx
– coding error 67xx, 6Fxx
20
Smartcard hardware
• ROM
– program code of VM, API, and pre-installed applets
• EEPROM
– persistent storage of the data, incl. objects with their
fields, and program code of downloaded applets
• RAM
– transient storage of data, eg stack
21
EEPROM vs RAM
• data stored in EEPROM is persistent, and is
kept when power is lost
• data stored in RAM is transient, and is lost as
soon as power is lost
22
Smartcard power supply
• The power supply of a smartcard can be
interrupted at any moment, by a so-called card
tear.
• To cope with this, the API offers support for
– persistent or transient allocation of fields
– transactions
23
Persistent vs transient data
By default, fields of Java Card objects are
stored in EEPROM.
The API offers methods that allow fields that
are arrays to be allocated in RAM.
24
Persistent vs transient data
public class MyApplet {
byte[] t, p;
short balance;
SomeObject o;
// persistent array p and persistent object o
p = new byte[128];
o = new SomeObject();
// transient array t
t = JCSystem.makeTransientByteArray((short)128,
JCSystem.CLEAR_ON_RESET);
25
why use transient arrays ?
• “scratchpad” memory
– RAM is faster & consumes less power
– EEPROM has limited lifetime
• automatic clearing of transient array
– on power-down, and
– on card reset or applect selection
can be useful
26
transient array example
public class MyApplet {
boolean keysLoaded, blocked; // persistent state
private RSAprivateKey priv;
//@ invariant keysLoaded ==> priv != null;
byte[] protocolState; // transient session state
...
protocolState = JCSystem.makeTransientByteArray((short)1,
JCSystem.CLEAR_ON_RESET);
// automatically reset to 0 when card starts up
....
27
Transactions
• The API offers methods to join several
assignments to fields into one atomic action,ie.
atomic update of the EEPROM, called a
transaction.
If the power supply stops halfway during a
transaction, all assignments of that transaction are
rolled back/undone.
28
Transactions example
private int balance;
private int[] log;
//@ invariant (* log[n] is previous balance *);
...
what if a card
// update log tear occurs here
n++; ?
log[n] = balance;
// update balance
balance = balance – amount;
29
Transactions example
private int balance;
private int[] log;
//@ invariant (* log[n] is previous balance *);
...
JCSystem.beginTransaction();
// update log
n++;
log[n] = balance;
// update balance
balance = balance – amount;
JCSystem.commitTransaction();
30
