TS-20-v2

Java Card 3 Platform 

Peter Allenbach 

Sun Microsystems, Inc.

Agenda 

From plastic to Java Card 3.0 

Things to know about Java Card 3.0 

Introducing Java Card 3.0 

Java Card 3.0 vs. Java SE 

Java Card 3.0 vs. Java ME 

Java Card 3.0 vs. Java EE 

More About Web Applications 

Reference Implementation (RI) 

Say Hello using Java Card 3.0 RI 

Q & A 

Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. 2

From Plastic to Java Card 3.0 

The Beginning 

Plastic cards 

• Introduced in the 50's 

• Cardholder identification and authentication 

• Signature, then magstripe and PIN codes 

Smart cards 

• Introduced in the 80's 

• Local authentication server, stored value 

• On-card PIN verification 

• Storage of sensitive information 

• Later, cryptography 

Original photo by Mitek 

http://www.flickr.com/photos/mikek/40737702/ 



The Smart in the Card 

A single chip in every card 

Very limited resources 

• In particular, RAM 



Java Card 2 

Introduces applications to smart cards 

• Interoperability of platforms, portability of applications 

• Multiple applications, with security guarantees 

• Dynamic application management 

Runs on low-end smart cards 

• Less memory (4-8K of RAM and 32-64K of EEPROM) 

• 8 Bit Processors (Slow) 

Widely used technology for a decade 

• It is the dominant smart card technology today 

Very limited subset of Java 

• Partial support of basic types (8/16-bit values, no float, no String) 

• Very small subset of the APIs 

• Specific and pre-processed binary file format (CAP file) 

• Single threaded, no garbage collection 



Java Card 3.0 

Major evolution of Java Card 2 

• Same principles: interoperability, security, multiple applications 

• Exploitation of new hardware features 

• More memory, more processing power, enhanced communication 

New capabilities for new use cases 

• A true personal Web server for enhanced user interaction 

• Possibility to initiate an action for more flexibility 

• Enhanced application model for more collaboration 

Two editions 

• Classic Edition 

• Supports only Classic Applets 

• Basically, Java Card 3.0 Classic is an evolution of Java Card 2 

• Connected Edition 

• New and improved model, and the topic of this talk 


Most Important Thing About Java Card 

Security is Paramount 

“Web Server in the Street” 


Things to know about Java Card 

Java Card is a Server 

VM never exits 

Two heaps 

Persistent Objects 

Firewall between applications 

Inter Application Communication 

Atomicity and Transactions 



Java Card is a server 

• Process incoming requests, and send response back to client 

Communication Protocols 

• APDUs (serial) is the traditional card-specific protocol 

• HTTP(S) for Java Card 3.0 Connected Edition using high speed 

interfaces like USB 

Two major communication interfaces 

• Contactless 

• Just put the card close to the reader 

• Contacted 

• Inserted into card reader 

• USB 



VM Never Exits 

“Card Initialization” happens only once 

• This is when the VM initialization happens 

• All required static data structures are created at this time 

• Card starts listening for Incoming requests 

“Card Reset” happens every time the card loses power 

• If card is taken out (card tear) – everything stops 

• When card is inserted again into card reader 

• RAM heap is lost 

• System ensures that data is consistent across tears 

• Card starts listening for incoming requests 



Two Heaps 

Unlike standard Java, Java Card has two heaps 

• All Session Objects created in Volatile Memory 

• Objects that are reachable from root of persistence will be in Non- 

Volatile Memory 

Non-Volatile Heap Volatile Heap 


Session Objects 




public class PersistenceExample { 

} 

void aMethod() { 

} 

Vector v = new Vector(); 

v.addElement(new String(“1111”)); // String s1 


someRootObject.addObject(v); // v is promoted 






} 


} 






v 





} 


} 






v 

s1 





} 


} 






v 

s2 

s1 





} 


} 

s2 





s1 

v 

G Garbage 


G 

G 

G 



Firewall between applications 

All applications run in the same VM, and exist in the same 

heap 

• Objects created by one application cannot be accessed by another 

application 

• Every object access is checked by the firewall 

• SecurityException is thrown if access is not permitted 

App1 Objects 

Firewall Check 

App2 Objects 



Inter Application Communication 

Applications can communicate with each other using Shared 

Interface Objects (SIO) 

• App1 defines and implements a Shareable Interface 

• App1 allows App2 to access this SIO 

• Firewall allows App2 to access the SIO object 

App1 Objects 

SIO of App1 

Firewall Check 

App2 Objects 



Atomicity and Transactions 

Card Tear may happen at any time 

• Card can be pulled out of the card reader at any time 

• Java Card must guarantee the integrity of user data 

Individual persistent writes are atomic 

• Every write into Non-Volatile memory is atomic 

Transaction Facility 

• Transactions may be used to group persistent writes 

• The application specifies the start and end of transactions 

• Unfinished or aborted updates will be rolled back 



What's New 

Runs on recent (high-end) smart cards 

• More Memory (Approx 24K of Volatile and 128K of Non-Volatile) 

• 32 bit Processor (Fast) 

Full Java Language Support 

• All data types except float and double 

• Multiple Threads 

• Extensive API support (java.lang, java.util, GCF, ...) 

• Handles class files directly, with all loading and linking on card 

• All new Java language syntax constructs, like enums, generics, 

enhanced for loops, auto boxing/unboxing, etc. 

• Automatic Garbage Collection 

The technology for the coming years 

Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. 20


Connectivity Layers and Protocol Stack 

New In Java Card 3.0 

Connected Edition 



High Level Architecture 



Application Models 

Classic Applets 

• Communication using APDU protocol 

• For backward compatibility 

• Java Card 2 limitations apply for these applications 

Extended Applets 

• Communication using APDU protocol 

• Similar to Classic Applets, but can use all the new API, like Threads, 

Strings, GCF, etc. 

Servlet Applications 

• Based on Servlet 2.4 API 

• Communication using standard HTTP/ HTTPS protocol 


Java Card 3.0 vs. Java SE 

Application start is not main() method 

• Java Card applications do not have main() method 

• “life cycle” model 

• Applet Container and Servlet Container 

• Application components are either Java Card Applets or Servlets 

Network programming using GCF API 

• Connector.open(“http://.....”); 

• Connector.open(“socket://host:1234”); 

Not Entire API is supported 


Java Card 3.0 vs. Java ME 

Java Card 3.0 is very close to Connected Limited Device 

Configuration (CLDC) 

Class files compiled with JDK 6 

• Class file major version is 50 

Class File Verification is same as in CLDC 

• But no preverifier, because JDK6 generates StackMapTables 

• JDK 6 Stackmaps are a little different than preverifier generated 

Stackmaps, but the purpose is same 

Not MIDlets, but Java Card Applets and Servlets 

JAD file of MIDlet suite can be compared to Java Card Runtime 

Descriptor 


Java Card 3.0 vs Java EE 

Servlet Container with full Servlet lifecycle support 

WAR file format is supported with Java Card 3.0 specific 

information, like Java Card Runtime Descriptor 

No JSP support 

• Just servlets (and static HTMLs) with listeners, filters 

Transactions using Annotations 

• @TransactionSupport(TransactionSuportType.REQUIRED) 

Per Application SSL is new in Java Card 3.0 


More about Web Applications 

Format of the deployment unit 

Same as Standard Web Application format 

No lib folder 

Some additional Java Card Specific Information 



Java Card 3.0 specific information 

Java Card Runtime Descriptor 

Manifest-Version: 1.0 

Runtime-Descriptor-Version: 3.0 

Application-Type: web 

Web-Context-Path: /hello 



Java Card 3.0 specific information 

Java Card Application Descriptor 

 

 

 

remote 

 

 

 



2Q 09 

Contents of RI 

• Card Emulator 

• Tools to build and deploy 

• Off-card installer 

• Packager 

• Converter 

• Normalizer 

• Introductory How-TO samples 

• Documentation 

NetBeans Plugin 



Source 

files 

Card 

Browser/Client 

compile/build/IDE 

Class files and 

Other resources 

(or) 

WAR file 

Off-Card Installer 

Load 

create 

delete 

unload 

Packager 

Ready to 

deploy 

Module 



HelloServlet.java 

import javax.servlet.*; 

import javax.servlet.http.*; 

import java.io.*; 

public class HelloServlet extends HttpServlet { 

public void doGet(HttpServletRequest request, 

HttpServletResponse response) { 

PrintWriter out = request.getPrintWriter(); 

out.println(“”); 

out.println(“Hello! JavaOne 2008”); 

out.println(“”); 

} 

} 



web.xml 

 

 

helloservlet 

 

HelloServlet 

 

 

 

helloservlet 

/* 

 

 



MANIFEST.MF (Java Card Runtime Descriptor) 

Manifest-Version: 1.0 

Runtime-Descriptor-Version: 3.0 

Application-Type: web 

Web-Context-Path: /hello 



Compiling Java Sources 

Use the NetBeans Module; easy way to build everything 

Use javac to compile the source code. 

• Sources must be compiled using Java Card API 

• Set bootclasspath to Java Card 3.0 API 

• javac -bootclasspath jcapi.jar *.java 

• Use provided annotation processor to detect float and double usages. 

• javac -processorpath jcapt.jar -processor 

com.sun.javacard.apt.JCAnnotationProcessor -Amode=connected *.java 

• Or - 

• Simply use the java card compiler script 

• jcc_connected.bat *.java 



Building Web Application Module 

Compiled class files and other resources need to be bundled 

together into WAR file format 

Using NetBeans makes it a click away 

Packager tool 

• can be used to create the final module file from raw WAR file or folder 

• can be used to validate pre-shipped application modules/WAR files 



Load & Create the Application Module 

Deployment is a 2 step process 

• Load – loads the module onto the card 

• Create – creates a persistent instance of loaded module 

Use off-card installer to load the Application Module 

Use off-card installer to create the instance 

Browse to the page 

• Ex: http://localhost:8019/hello/ 



Delete & Unload the Application Module 

If the application is no longer needed on the card, it can be 

removed completely 

2 step process 

• Delete – deletes given persistent instance of the application 

• Unload – completely removes all class files and related resource files 

from the card 

Use off-card installer to delete the application instance 

Use off-card installer to unload the application 


Peter Allenbach 

Sun Microsystems 

Q & A

TS-20-v2

Create successful ePaper yourself

Delete template?

Save as template?