Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

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

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
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.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
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