Java Card 3: Classic Functionality Gets a Connectivity Boost

Print-friendly Version

The smart cards that were introduced in the 1980s had a single chip in every card, with very limited resources (especially RAM). The dominant smart card technology today runs on 4 to 8 Kb of RAM and 32 to 64 Kb of EEPROM, using slow 8-bit processors, and uses a very limited subset of Java that provides

• Partial support of basic types (8/16-bit values, no float, no String)
• Small subset of Java ME APIs
• Specific, pre-processed binary file formats
• Single threading (no garbage collection)

Figure 1: The smart chip in a card

Java Card 3 extends the Java Card 2 support for classic applets into improved connected features targeting less resource-constrained devices and including new network-oriented features.

So let's start by going over the basics about Java cards.

There are two main basic features: security and communication.

Security Is Foremost
The most important thing is security, always. Java Card 3.0 will maintain the security specifications of the current release.

VM Never Exits The Virtual Machine (VM) never exits. Card initialization happens once, and all required static data structures are created at this time. The card starts listening for incoming requests. Card reset happens every time the card "loses power"; that is, when the card is taken out (also called a card tear). After removal, when the card is reinserted into the reader, the RAM heap is lost and the system ensures that data is consistent between tears. Then the card starts listening for incoming requests again.

Two Heaps Unlike standard Java, Java Card has two heaps. All session objects are created in Volatile Memory. Persistent objects are created in Non-Volatile Memory.

Firewall between Applications All applications run in the same VM and exist in the same heap. But objects created by one application cannot be accessed by another application. Every object access is checked by the firewall. A SecurityException is thrown if access is attempted that is not permitted.

Inter-Application Communication Applications can communicate with each other using Shared Interface Objects (SIO). Say the first application, App1, defines and implements a Shareable Interface. App1 allows App2 to access this SIO. The firewall allows App2 to access the SIO object.

Atomicity and Transactions A card can be pulled out of the card reader at any time, so Card Tear may happen at any time. Java Card must guarantee the integrity of user data by ensuring that:

• Individual persistent writes are atomic. That is, every write into Non-Volatile memory is atomic.
  
  
• Transaction facility exists:
  • 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

It's a Web Server
A Java card is your embedded web server on the street, so to speak. It processes incoming requests and send a response back to the client. The traditional communication protocol is APDU (serial).

The most exciting change is that Java Card is now web-enabled — sort of a Mini-Me to, say, the Java EE web server. This opens it up to the wonderful world of servlet applications and to communication that uses the standard protocols. Java Card 3 supports APDU, but also HTTP(S) for high-speed interfaces, such as USB. There are two possible types of communication: contactless (card is held close to the reader) and contacted (card is inserted into the reader).

It supports the following application models:

• Classic Applets (Java Card 2 limitations apply for these applications)
  • Communication using APDU protocol
  • Backward compatibility
  
  
• Extended Applets
  • Communication using APDU protocol
  • Similar to Classic Applets, and can use all the new APIs, like Threads, Strings, and GCF (Generic Connection Framework)
  
  
• Servlet Applications
  • Based on Servlet 2.4 API
  • Communication using standard HTTP/ HTTPS protocol

The following figure shows the high-level architecture for Java Card 3.

Figure 2: Java Card 3 architecture

When deploying web applications, Java Card deployment is the same as the standard web application format, with no lib folder.

Java Card 3 runs on the recent high-end smart cards, which have more memory (approximately 24K of Volatile and 128K of Non-Volatile) and a fast 32-bit processor.

Java Card 3 also offers full Java language support, including support for

• All data types except float and double
• Multiple threads
• Extensive API support (java.lang, java.util, GCF, and so on)
• Direct handling of class files, with all loading and linking on card
• All new Java language syntax constructs, like enums, generics, enhanced for loops, auto boxing/unboxing, and so on
• Automatic garbage collection

The new connectivity layers and protocol stack features promise support for the emerging technology in the coming years, as shown in Figure 3.

Figure 3: Connectivity layers and protocol stack

You may be a Java developer who is familiar with Java SE, ME, or EE, but not with the Java Card Platform. If so, the following comparisons will be very useful.

Java Card 3.0 Compared with Java SE
There are three main differences between Java Card 3.0 and Java SE.

• First, Java Card applications do not have main() method, so the application start does not use main() method.
  • Java Card applications use the lifecycle model.
  • Applet Container and Servlet Container are supported.
  • Application components are either Java Card applets or servlets.
  
  
• Network programming uses GCF API as opposed to the java.net framework, which is too large for Java Cards.
  • Connector.open("http://.....");
  • Connector.open("socket://host:1234");
  
  
• Finally, Java Card does not support the entire Java SE API .

Java Card 3.0 Compared with Java ME
Java Card 3.0 is very close to the Java ME Connected Limited Device Configuration (CLDC).

• Class files are compiled with JDK 6 (class file major version is 5.0)
  
  
• Class File Verification is the same as in CLDC
  • But no preverifier, because JDK 6 generates StackMapTables
  • JDK 6 Stackmaps are a little different than preverifier-generated Stackmaps, but the purpose is same
  
  
• Java Card does not use MIDlets, but Java Card applets and servlets
  
  
• JAD file of a Java ME MIDlet suite can be compared to Java Card Runtime Descriptor

Java Card 3.0 Compared with Java EE
There are several similarities in functionality, since Java Card 3 supports a web server application model much like Java EE. For example,

• Java Card provides a servlet container with full servlet lifecycle support.
• WAR file format is supported with Java Card 3.0 specific information, like Java Card Runtime Descriptor.
• Transactions using annotations are supported by Java Card, with @TransactionSupport(TransactionSuportType.REQUIRED)
• Per-application Secure Sockets Layer (SSL) protocol support is new in Java Card 3.0
• One area that is not quite like the full Java EE is that there is no JSP support, just servlets (and static HTML) with listeners and filters.

As part of the Java Card Development Kit, a Reference Implementation (RI) will be available, with support for both classic and connected functionality. It will contain the following:

• Card emulator
  
  
• Tools to build and deploy an application or servlets:
  • Off-card installer
  • Packager
  • Converter
  • Normalizer
  
  
• Introductory how-to samples
  
  
• Documentation

A NetBeans IDE plugin will also be available at the time of the release — more about that in the following sections.

Creating the "Hello" App Using the RI
The reference implementation will include the usual "hello, world" application, as shown in the following code.

Figure 4: Reference Implementation code

Compiling and Packaging the Code
The easiest way to compile the Java source code and build the app is to use the NetBeans IDE. The manual steps from source code to putting the application on the card — the tool chain — are shown in the following figure. The NetBeans IDE automates many of these steps.

Figure 5: Packaging the application

As shown Figure 5, to compile the source code, you can use the javac compiler to compile the source code, and so on. If you use the NetBeans IDE plugin, it will handle the compilation and the packaging. The NetBeans IDE Packager tool can be used to create the final module file from a folder. It also can be used to validate pre-shipped application modules or WAR files.

Loading and Creating the Application Module
Deployment is a two-step process. First you load the module onto a card. Then you create a persistent instance of the loaded module. You can use the off-card installer to load the Application module and to create the instance. You can then use your browser to view the page.

Deleting and Unloading the Application Module
If the application is no longer needed on the card, it can be removed completely in a two-step process. Use Delete to remove any given persistent instance of the application. Then use Unload to completely remove all class files and related resource files from the card.

You can use the off-card installer to delete the application instance and to unload the application.

Java Card 3.0 enhances classic functionality with connected features that target less resource-constrained devices and include new network-oriented features, such as support for web applications — including the Java Servlet APIs — as well as support for applets with extended and advanced capabilities. For more information, please check out the Java Card 3.0 specification.

Peter Allenbach has been a developer at Sun Microsystems for over 10 years, most recently as part of the Java Card 3 engineering team. Before this latest assignment, he worked primarily on Java SE technology.

We welcome your participation in our community. Please keep your comments civil and on point. You can optionally provide your email address to be notified of replies—your information is not used for any other purpose. By submitting a comment, you agree to these Terms of Use.