Java Card

1
Java Card

• Erik Poll
• University of Nijmegen
• http//www.cs.ru.nl/erikpoll

2
Contents

• Java Card architecture
• Java vs Java Card
• ISO 7816, APDUs
• transient and persistent data
• transactions

3

• 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

4
old vs new smartcards

• one program (applet)
• written in machine-code, specific to chip
• burnt into ROM

• Applet written in high-level language (mainly
  Java Card)
• compiled into bytecode
• stored in EEPROM
• interpreted on card
• multi-application several applets on one card
• post-issuance adding or deleting applets on card

5
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

6
Java Card architecture
applet
applet
applet
Java Card platform
Java Card Virtual Machine
Java Card API (mini OS)
smartcard hardware
7
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 Javas)

8
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.

9
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 bs1
• // not ok, compiler complains
• s (short)(bs1)
• // not ok, converter complains
• s (short)(b(short)(s1)) // ok

10
(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

11
the Java Card API

• A subset of Javas 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

12
Java Card API packages

• java.lang
• Object, Exception, ...
• javacard.framework
• ISO7816, APDU, Applet, JCSystem
• javacard.security
• KeyBuilder, RSAPrivateKey, CryptoException
• javacardx.crypto
• Cipher

13
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

14
ISO 7816

• Standard describing the protocol for
  communication between smartcard and terminal
  (some parts downloadable at http//www.cardwerk.co
  m/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.

15
Java Card I/O with APDUs
OS selects applet and invokes its process method
command APDU, incl. applet ID
applet
applet
applet
applet
Applet sends response APDU
applet executes
Java Card platform
terminal
smartcard hardware
16
Command APDU

• CLA class byte
• INS instruction byte
• P1,P2 parameters
• Lc length of data block
• Data Lc bytes of data
• Le length of expected response optional

obligatory
optional
17
Response APDU

• Data Le bytes of data (optional)
• SW1, SW2 status word (obligatory)

18
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

19
APDUs

• See the process methods of the Applet.java
  examples on the course webpages (section smart
  cards) on how APDUs methods are typically
  processed

20
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

21
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

22
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

23
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

24
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.

25
persistent vs transient data

• public class MyApplet
• byte t, p
• short balance
• SomeObject o
• // persistent array p and persistent object o
• p new byte128
• o new SomeObject()
• // transient array t
• t JCSystem.makeTransientByteArray((short)128,
• JCSystem.CLEAR_ON_RESET)

26
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

27
transient array example

• public class MyApplet
• boolean keysLoaded, blocked // persistent state
• private RSAprivateKey priv
• //_at_ invariant keysLoaded gt priv ! null
• byte protocolState // transient session state
• ...
• protocolState JCSystem.makeTransientByteArray((
  short)1,
• JCSystem.CLEAR_ON_RESET)
• // automatically reset to 0 when card starts up
• ....

28
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.

29
transactions example

• private int balance
• private int log
• //_at_ invariant ( logn is previous balance )
• ...
• // update log
• n
• logn balance
• // update balance
• balance balance amount

what if a card tear occurs here ?
30
transactions example

• private int balance
• private int log
• //_at_ invariant ( logn is previous balance )
• ...
• JCSystem.beginTransaction()
• // update log
• n
• logn balance
• // update balance
• balance balance amount
• JCSystem.commitTransaction()

31
more APIs

• Global Platform
• addition to the Java Card API to support
  downloading of (digitally signed) applets onto a
  card
• Open Card Framework (OCF)
• API for building terminal applications
• see example Terminal.java on course webpages
  (section smart cards)