Scribd
Upload
35 views

563.11.1 Java Card Programming

This document provides an overview of Java Card programming including: - Features of Java Cards and their restricted resources like RAM, ROM, and EEPROM. - The message passing model between Java Cards and terminals using APDUs. - The development cycle for Java Card applets including compiling, converting to CAP files, and installing. - An example game of Battleship that uses the terminal's memory to overcome the card's limited storage.

Uploaded by

sriram5102
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
35 views

563.11.1 Java Card Programming

This document provides an overview of Java Card programming including: - Features of Java Cards and their restricted resources like RAM, ROM, and EEPROM. - The message passing model between Java Cards and terminals using APDUs. - The development cycle for Java Card applets including compiling, converting to CAP files, and installing. - An example game of Battleship that uses the terminal's memory to overcome the card's limited storage.

Uploaded by

sriram5102
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 20

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 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 terminals memory
2

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
3

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

Java for Java Cards Features


Supported
Small primitive data types: boolean, byte, short. One dimensional arrays. Object oriented features: inheritance, virtual methods, dynamic object creation, overloading, scope.

Not Supported
Large primitive data types: long, double, float. Characters, strings. Multidimensional arrays. Dynamic class loading. Garbage collection. Threads. Object Cloning. 6

Developing a Java Card Applet


1. Write the Java source 2. Compile your source 3. Convert the class files into a Converted Applet (CAP) file (binary representation of classes and interfaces) 4. Verify that the CAP is valid (structure, valid bytecode subset, inter-package dependencies) 5. Install the CAP file
7

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
9

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 ... }
10

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.

11

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

12

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

13

A Challenge in Java Card Programming


Java Cards have very restricted resources
Limited Memory Limited Computing Power

Can we use terminals resources to overcome the restriction provided that the terminal is potentially untrusted? At Penn we used terminals memory to overcome the first restriction

14

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

15

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

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 terminals memory to store the tables of random numbers and hashes To request a services from the terminal we have two types of respond APDUs
The result A request from the card to perform an operation (store or retrieve data)
17

Terminals Structure
Terminal Application
request respond

Service Layer
request service service service repond1 service repond2 respond request1 request2

Java Card
18

Data Flow and the Structure of an Applet


Terminal
Request

Java Card

Service Request 1

Service Respond 1 Service Request 2 Service Respond 2 Respond

process(apdu){ ..... switch(message){ .... caseRequest: ..... sendServiceRequest1; break; ..... caseServiceResponde1: ..... send ServiceRequest2; break; ..... case ServiceResponde2: ..... send Respond; }
19

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
20

You might also like