Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Micro Edition >

Write OpenCard services for downloading Java Card apps

With this straightforward loading information in hand, you can load Schlumberger's CyberFlex 16K or Dallas Semiconductor's iButton

By Mike Montgomery, JavaWorld.com, 02/01/99

In prior articles, we've discussed methods for connecting smart card readers to your system so that you can use your Java Card. In this article we'll build on that knowledge, teaching you how to load Java Cards from a Web-delivery perspective.

This article assumes some knowledge of smart cards, Java Cards, and OpenCard. See the Resources section below for links to prior Java Developer columns that have covered these subjects.

Little programs that load card apps directly from a PC are a dime a dozen. These programs are uninteresting, however, because they require you to download files, then start up programs, and so on. Our approach is to allow files on Web pages containing interesting Java Card applications to be fed directly onto your personal Java Card.

We've been focusing on using PC/SC, the C standard for loading and managing cards on WIN32 machines, and OpenCard, the Java based standard. As a developer you have three choices for developing dynamically loadable Java Card applications for mass markets: cook your own for each combination of different cards and readers; use PC/SC and follow Microsoft; or use OpenCard, which leverages PC/SC when possible yet allows you to extend and have equivalent functionality on Windows platforms.

The best choice is OpenCard, because PC/SC doesn't work on a lot of platforms that OpenCard works on -- such as computers smaller than PalmPilots, set-top boxes, and network computers, to name a few. Additionally, PC/SC doesn't support dynamic and flexible automatic loading of services to communicate with an inserted iButton or smart card as part of the standard. Writing your own loading application only works if you can afford to do so in terms of support and maintenance. And it doesn't leverage the efforts of others, which means you'll have to supply the different program's plumbing yourself.

Why OpenCard?

Java Cards are small, personal, secure storage devices with a tamper-resistant architecture. This makes Java Cards ideal for storing important personal information and for financial applications, generally any application where authentication, Integrity, and secrecy are desired. Java Cards are accessed through special devices that attach to your computer or are already on your computer, much like ATM cards are accessed through ATM machines and scanners. Some potential users of Java Cards are concerned about writing applications that work the same on all the various entrance ramps to the Internet, intranet and extranet. OpenCard provides a solution to the problem of interfacing different devices for reading cards to these platforms.

The following are some of the advantages of using OpenCard:

  • OpenCard allows you to write your own services while standardizing on some simple concepts. Ideally, as developers write to OpenCard, we can reuse terminals (smart card readers) and services written by others.

  • OpenCard was developed with the Web in mind, and it is very easy to add dynamic downloading over the Web to OpenCard. So if the market demands it, billions of cards can be programmed routinely on traditional and nontraditional platforms.

  • Users can load Java Cards directly. This means custom applications can be added to the card. Many of the current smart card development environments only work on Windows, which is unacceptable to many developers who use Linux or Solaris for software development. (After all, who can afford an hour or so of reboot time every day, as required when using Windows?)


We were able to develop and load an application for the Java iButton on systems that support Java only. The folks at iButton started with a 100-percent-Java development environment over two years ago, so when using iButtons, you never have to pop into an application written in C. (Nothing against C, but C applications are often not portable due to the user interface bindings.) We didn't realize we could do this with any smart card out there until Schlumberger Engineering Specialist Mike Montgomery told us this was actually relatively easy. We also wanted to be able to use OpenCard and write one application that would load any Java Card as long as the specific implementation was available.

In this article, we'll show you how to load Java Cards with OpenCard services that implement the specific protocol for each of the devices. We'll cover two devices: Dallas Semiconductor's Java iButton and Schlumberger's CyberFlex 16K card. In each case you'll need some information from the card manufacturer on how to load the card. Some manufacturers, like Schlumberger, provide this information with sample programs, others just list the protocol without samples, and others do not even make it available. Eventually Sun and OpenPlatform will resolve this issue by providing converters and security to ensure that cards are loaded easily and safely with trusted programs.

We'll take two off-the-shelf cards and readers and provide the source code for loading specific Java Card devices as an OpenCard service. We're concentrating here on the process of putting the program onto the card. We're at very low level here -- kind of like writing individual sectors to a disk. Eventually you can execute the copy command, but how does the copy command really work? It moves every datum from the source to the destination. Smart cards require the same, in addition to wanting the data to be trusted and verified.

The complete cycle: creation, conversion and secure loading

One of the challenges for credit card companies and banks is defining card ownership. All sorts of business issues come into play here, given the widespread functionality of the cards. Java Cards can support multiple applications, however, this isn't quite like putting a file on your disk drive. If you read your credit card agreement, you'll see that you don't own the card. Which means legally you may not be entitled to put more apps on your Java Card without permission. Suppose a card-owning business entity decides to allow other companies -- possibly competing companies -- to put applications on its cards?

1 | 2 | 3 | 4 |  Next >
Resources
  • OpenCard home page http://www.opencard.org/
  • CyberFlex home page http://www.cyberflex.slb.com
  • Java iButton home page http://www.ibutton.com/
  • Visa Open Platform starting point http://www.visa.com/cgi-bin/vee/nt/suppliers/open/press.html?2+0
  • Java Plug-in http://java.sun.com:80/products/plugin/index.html
  • Selected Java Developer columns:
  • How to write a CardTerminal class for simple and complex readers in an OpenCard environment http://www.javaworld.com/javaworld/jw-01-1999/jw-01-javadev.html
  • How to write OpenCard card services for Java Card applets http://www.javaworld.com/javaworld/jw-10-1998/jw-10-javadev.html
  • Restricted-channel multicast in Java http://www.javaworld.com/javaworld/jw-09-1998/jw-09-javadev.html
  • Understanding Java Card 2.0 http://www.javaworld.com/javaworld/jw-03-1998/jw-03-javadev.html
  • Listing of previous Java Developer articles http://www.javaworld.com/topicalindex/jw-ti-javadev.html