Learn to use software components to deploy applications using Java Cards

A URL-based approach for deploying smart cards on different systems

Java Cards provide a platform for the easy deployment of multifunctional smart-card applications. Smart cards are very popular in Europe but in the U.S. have failed to attract the same level of visibility. How can the U.S. catch up to Europe on smart-card use? One way is to develop applications for smart cards that provide consumers and corporate users truly convenient and secure methods to access services. With the right kind of smart-card applications, users will be able to avoid the tedious process of having to repeatedly type information on Web pages in order to do secure transactions. In some countries, smart cards have replaced the need for cash, credit cards, or debit cards. Yet in the U.S. we are still struggling with upgrading point-of-sale terminals in stores so as to accept smart cards.

Besides the inconvenience of having to navigate multiple layers of pages on the Web in order to carry out secure transactions, another example of outdated and unfriendly technology is the phone system. Often we are reduced to repeating standard information over the phone -- such as name, address, phone number -- or, worse yet, we must actually mail out that information once we've begun a transaction over the phone. Wouldn't it be nice if you could simply send the data from your smart card? (Smart cards would also solve the problem of neck and shoulder pain from having to balance the phone long periods of time!) Smart cards can provide a sophisticated means of doing secure transactions -- and in the convenient form of a personal, secure, portable storage device. Smart cards give developers the opportunity to create convenient and much-needed services to your users.

There have been many smart card trials and pilots by many forward-thinking companies and some not-so-forward-thinking companies. Yet few of these trials have generated any excitement or additional value to the consumer. The trials generally lacked integration with the Web; in other words, you could not use the card for form-filling, authentication-affinity programs. What this means is that you would still have to enter form information over and over again, prove your identity with less secure methods such as passwords or worse yet social security numbers, and, if you get a coupon, you have to print it out and take it to the store instead of just taking the digital bits of the coupon that have been magically put on your smart card.

[co: The following paragraph would benefit from an introductory sentence, a lead-in from the previous paragraph to this one in order to keep the reader apprised of where you're going with your ideas.]

In order to deploy Java Card-capable platforms, you need to be able to load an application on the card and write an application for the card that works with some network-based service. Smart cards can also be used for offline transactions, which is how the Digital Satellite receiver demonstrated in this article works. The material from this article allow you to build both.

Here we provide fully coded, tested examples of three services for the Smart Card UPI, an architecture developed at Sun Labs and discussed in last month's installmentJavaWorld's Java Developer column. See the Resources section for links to general smart-card information.

In this article we will go into great detail about how you implement an end-to-end solution using Java Card technology, via documented code examples. Examples are provided for the Schlumberger card, however the techniques are general and have been applied to Dallas Semiconductor Java iButtons, GemPlus GemExpresso cards, smart cards from De La Bull Information Systems cards, and even Mondex cards (which are issued by banks that have licensed the Mondex technology) to name a few, and could easily be applied to any Java Card-compliant smart card. For more information on using the Smart Card UPI to deploy digital cash solutions, take a look at the Resources section. For details on the CyberFlex Access Card loading process, see the Loading A CyberFlexAccess Card. The CAP file format sidebar is also important to read since in the future all Java Card-compliant smart cards will support the CAP file format.

Let's get started on how to deploy a a general-purpose Java Card-based technology that provides you with the ability to build applications that may require strong authentication, secure personal storage, virtual ATM, and micro/macro payments. Current payment options on the Web are very unsophisticated. There is no widespread deployment of services of different payment options such as pay as you go, daily, weekly, subscription, and so on. Current payment systems are to heavy weight and require so many transactions that charging someone a few pennies is not economically feasible. Micro payments refer to small payments ranging from a few cents to less than a 1.00. Macro payments refer to larger payments like 19.95.

First, we will discuss how to write an OpenCard service, followed by two specific examples with fully documented Java source code, followed by the source code for the Java Card applet that implements the services needed by SecureTokenHandler on the smart card. Before going into the source code the following three high level summaries list the functionality provided by the SecureTokenHandler, JavaCardLoaderHandler, and CorporateCard.

The SecureTokenHandler supports the following UPI:

  • GetId -- Card number of the current card (card numbers are assigned by application).
  • GetPurse -- Currencies and/or tokens supported.
  • GetInfo -- General information about the card.
  • CheckPin -- Give an pin a Message Digest based on SHA1 or XOR, and so on, is returned.
  • VerifyPin -- Given a digest the digest is verified, usually done with a server.
  • ChangeSetPin -- Change or modify user PINs.
  • ValueTransfer -- Perform a value transfer (requires a server "SecureTokenHandler").
  • Decrypt -- Decrypt the input data, with optional type
  • ValueTransfer -- Enrypt the input data, with optional type

The JavaCardLoaderHandler supports the following UPI:

  • LoadJavaCardFromURLThe given URL is used to get information to load an applet onto a card. See the sidebar for more information on load file format.

  • CardType Query the handler for type of card, for example GemExpresso, Java iButton, and so on.

  • EndLoad Tell loader to quit posting status.

  • StatusInteractive status of load.

The CorporateCard applet, which can be loaded on to any Java Card compliant smart card, provides the following services via APDUS. A specific APDU command is built by the JavaCardCCProxyService, which implements PurseCardService. The more important methods are listed below. Consult the source listing for more detail.

    String purseId() throws OpenCardException;
    void purseQuantities(Hashtable result) throws OpenCardException;
    void purseInfo(Hashtable result) throws OpenCardException;
    byte[] purseCheckPin(String pin, byte[] challenge,
                         String digestType) throws OpenCardException;
    byte[] purseVerifyPin(byte[] purse, byte[] challenge, String digestType,
                          byte[] signature) throws OpenCardException;
    void purseValueTransfer(Hashtable args,
                            Hashtable result) throws OpenCardException;
    public byte[] hash(byte data[], String hashType) throws OpenCardException;
    public byte[] decipher(byte data[],
                           String cipherType) throws OpenCardException;
    public byte[] encipher(byte data[],
                           String cipherType) throws OpenCardException;
    boolean canChangePersonalCode() throws OpenCardException;
    void changePersonalCode(String oldCode,
                            String newCode) throws OpenCardException;
    String getLockState() throws OpenCardException;
    void setPersonalCode(String newCode) throws OpenCardException;
    byte[] readCC() throws Exception;
    void storeCC(byte[] bcData) throws Exception;

Writing an OpenCard service

Let's try to break down the functionality we need into software components that we can connect together to get our system built. First, we will describe this functionality, then we will provide some code that realizes the functionality described.

  • The ability to put Java Card applets onto a user's personal Java Card using a browser: This functionality will require a loader OpenCard service to manage the details of loading. You don't just copy applications onto smart cards. Installing an application on a smart card often requires the use of a very specific protocol. We have described this in the two sidebars, a specific example for Schlumberger and the future direction in this area, using the CAP file format.

  • A Java Card applet that implements the needed functionality such as authentication, secure personal storage, micro/macro payments, signature services, encryption/decryption services.

  • A proxy for this Java Card applet that runs on the user's host computer. The proxy communicates with the applet-sending and -receiving data in the specific APDUs for the card. This proxy is best realized as an OpenCard service. The Resources section offers an example from previous JavaWorld articles.

  • A UPI handler that takes requests from a user's browser and maps the requests to methods in the proxy, which then communicates with the applet running on the smart card. This technology was described briefly in last month's Java Developer. Suppose, for example, you wanted to have the card generate a signature for some data that you want to send it and then you would like to use some other card to verify this data. The two URLs we are discussing look like this:

    Sending the following URL:



    produces the following results, which are returned as name value pairs:




    What the smart card has done is sign the following 64-byte block:

    0000:  4A 61 76 61 4F 6E 65 2B 01 02 03 04 05 06 07 31 JavaOne+.......1
    0010:  30 30 30 32 30 30 30 33 30 30 30 34 30 30 30 80 000200030004000.
    0020:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    0030:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F8 ................

    The server or other party can verify the identity by performing the following operation with its own local SecureTokenServices handler.




    The server generates the same block of data and generates a digest. If the two digests match, then it's clear the data was generated by a user possessing a smart card with the secret and the signature algorithm. This example is meant to be introductory. To gain a better understanding of the concepts, look at the Network Security sub-section in the Resources section.

In prior JavaWorld articles on the Java Card, we discussed how to write OpenCard services. A very quick overview of the process of writing a service follows for those of you who have some knowledge of it. In order to refresh your memory, here is a simple service for sending ADPs to a card and getting a response: PassThrough.html.

The OpenCard CyberflexAccess loader service

Schlumberger provides the necessary APDUs to load a Java Card application on the card. The process of writing the application consists of a few steps that have been discussed in the past for earlier versions of the card. These are also listed in the Resources section. The loader service for the CyberFlex access card is provided here: loader.html.

Once an application is loaded onto a card, it must communicate with some proxy service on the host, as shown in the figure below. [co: What figure?] We have adopted a convention of calling the host program a proxy service and the applet that runs on the card the card applet. Here's the source code for JavaCardCCProxy service: proxyservice.html.

The card applet

The card applet contains the methods that the proxy can communicate with via the OpenCard Card terminal. The card applet we are supplying is rather large, and we hope that some of you will take useful things from it and produce new card applets from it. In order to provide a concise example, however, we are going to focus on a limited set of functionality. Here's the link to the source code for the corporate card applet: CorporateCard.html.

The SecureTokenServices handler

As stated at the outset of this article, the best use for an application that we can load onto the card is to implement parts of your architecture that smart cards are very good at: for storing secrets and providing portability.

Of course, you would be required to develop additional applications -- to communicate with the card. One of the primary advantages of the UPI is that once you have an application loaded onto a card, you can easily communicate with this Java Card application by using either passthrough, which we discussed earlier, or by coding a simple handler that takes URLS and maps them to transactions to be performed with the Java Card.

1 2 Page 1
Page 1 of 2