563 11 1 java card programming overview
Sponsored Links
This presentation is the property of its rightful owner.
1 / 20

563.11.1 Java Card Programming: Overview PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

563.11.1 Java Card Programming: Overview . Presented by: Raman Sharykin PISCES Group: Soumyadeb Mitra, Sruthi Bandhakavi, Ragib Hasan, Raman Sharikyn University of Illinois Spring 2006. Overview. Java Cards Java Card/Terminal System Features of Java for Java Cards compared to Java

Download Presentation

563.11.1 Java Card Programming: Overview

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

563.11.1 Java Card Programming: Overview

Presented by: Raman Sharykin

PISCES Group: Soumyadeb Mitra, Sruthi Bandhakavi, Ragib Hasan, Raman Sharikyn

University of Illinois

Spring 2006


  • Java Cards

  • Java Card/Terminal System

  • Features of Java for Java Cards compared to Java

  • Java Card Applets: Developing Cycle

  • Structure of Applets and Messages

  • On approach to overcome the issue of restricted resources on card

  • Game of Battleship: Using terminal’s memory

Java Card Features

  • Receives clock and power from terminal

  • Three types of memory:

    • Random Access Memory (RAM)

    • Read-Only Memory (ROM)

    • Erasable Read-Only Memory (EEPROM)

  • Restricted Resources

    • Slow and simple microprocessor (8-bit)

    • RAM ~1Kb

    • ROM ~64Kb

    • EEPROM ~16-64Kb

  • Restricted Version of Java

The use of Java Cards

  • SIM cards in cell phones

  • Identity cards (government, health-care)

  • Financial cards supporting online and offline transactions

  • Smart tickets for mass transit

Java Card/Terminal System

APDU = Application Protocol Data Unit

An introduction to Java Card Technology

Small primitive data types: boolean, byte, short.

One dimensional arrays.

Object oriented features: inheritance, virtual methods, dynamic object creation, overloading, scope.

Large primitive data types: long, double, float.

Characters, strings.

Multidimensional arrays.

Dynamic class loading.

Garbage collection.


Object Cloning.

Java for Java Cards Features


Not Supported

Developing a Java Card Applet

  • Write the Java source

  • Compile your source

  • Convert the class files into a Converted Applet (CAP) file (binary representation of classes and interfaces)

  • Verify that the CAP is valid (structure, valid bytecode subset, inter-package dependencies)

  • Install the CAP file

Message-Passing Model

An introduction to Java Card Technology

APDU Structure

  • CLA, INS define the command

  • P1, P2 – parameters

  • Lc – data field lentgh

  • Le – maximum response length

  • SW1, SW2 – response status

An introduction to Java Card Technology

Applet Structure

  • import javacard.framework.*

  • ...

  • public class MyApplet extends Applet {

    • // Definitions of APDU-related instruction codes

    • ...

    • MyApplet() {...} // Constructor

    • // Life-cycle methods

    • install() {...}

    • select() {...}

    • deselect() {...}

    • process() {...}

    • // Private methods ...

  • }

Important Methods: Install

  • install()

    called when a new applet is being installed

    public static void install

    ( byte[] bArray, short bOffset, byte bLength) {

    new myApplet(null);


    • Must call register() to let JCRE know that a new applet has been installed.

Important Methods: Select/Deselect

  • select()

    • when we want to use an applet

    • is called when SELECT APDU is received

  • deselect()

    • is called when another SELECT APDU is received

Important Methods: Use

  • process()

    • when an APDU is received and applet is selected its method process is called to process the APDU

    • the selected applet parses the APDU and perform whatever it needs to perform

    • normally the body of process() method is a big switch with code for each INS value defined

A Challenge in Java Card Programming

  • Java Cards have very restricted resources

    • Limited Memory

    • Limited Computing Power

  • Can we use terminal’s resources to overcome the restriction provided that the terminal is potentially untrusted?

  • At Penn we used terminal’s memory to overcome the first restriction

Game of Battleship

  • Playing Field is n by n

  • Ships are vertical or horizontal and of a fixed length

  • Players shoot in turns

  • The winner is the player who has eliminated the ships of the opponent first

How to Prevent Cheating?

  • Before starting the game players assign random numbers to each cell, compute the hash of the resulting pair and exchange the tables of hashes

  • When a player shoots, the opponent provides not only the contain of the requested cell, but also the random number assigned to it and the hash

  • This way the other player can compute the hash of the delivered data and check if it coincides with the value stored in the beginning.

Terminal Services Card

  • If we want to play the game on 10 by 10 field we need 10*10*16*2 = 3200 bytes when only ~600 is available

  • We used terminal’s memory to store the tables of random numbers and hashes

  • To request a services from the terminal we have two types of respond APDU’s

    • The result

    • A request from the card to perform an operation (store or retrieve data)

Terminal’s Structure





Service Layer











Java Card

Data Flow and the Structure of an Applet


Java Card

process(apdu) {


switch (message){


case Request:


send ServiceRequest1;



case ServiceResponde1:


send ServiceRequest2;



case ServiceResponde2:


send Respond;



Service Request 1

Service Respond 1

Service Request 2

Service Respond 2


Future Work

  • The implementation stores its data on terminal without making sure that the server does not alternate the stored data (also it can just look at it!)

  • The structure of the code on card is complicated when we need Service Requests

    • inside a function call

    • inside a loop

  • It would be interesting to know if we can use the computational power of the terminal as well

  • Login