Smart cards have been getting a lot of buzz lately on the Web, at the JavaOne conference last April (four sessions dealt with the technology), on the big network news stations, and on CNN. In this article we'll bring the smart card to life with a real-world smart-card example. The techniques presented here will allow you to start building Java applications that are smart-card enabled.
We'll focus on two types of smart cards: memory smart cards, which can be viewed as minuscule removable read/write disks with optional security; and processor cards, which can be viewed as miniature computers with an input and output port. Future articles will cover processor cards in greater depth.
As the meat of the article, we'll develop a simple prototype for reading and writing data to a smart card. We will discuss a drug prescription card, which keeps a list of all your prescriptions and tracks your insurance, prescription plans, and other useful info. Later articles will expand on the idea of the prescription card.
You'll notice that a recurrent theme that runs throughout this series on smart cards is the need for a security framework to prevent rogue plug-ins, ActiveX components, and so on from getting at your personal and/or corporate info-goodies. To this end, the demonstration of how to read and write data to a smart card included in this article will provide you with persistent, secure (and portable) storage.
What is a smart card?
You can think of the smart card as a "credit card" with a "brain" on it, the brain being a small embedded computer chip. This card-computer can be programmed to perform tasks and store information, but note that the brain is little -- meaning that the smart card's power falls far short of your desktop computer.
Smart cards currently are used in telephone, transportation, banking, and healthcare transactions, and soon -- thanks to developers like you -- we'll begin to see them used in Internet applications. Smart cards are already being used extensively in Japan and Europe and are gaining popularity in the U.S. In fact, three significant events have occurred recently in the smart card industry in this country:
Microsoft and several other companies introduced PC/SC, a smart card application interface for communicating with smart cards from Win32-based platforms for personal computers. PC/SC does not currently support non-Win32-based systems and may never do so. We will discuss this in greater detail later on.
OpenCard is an open standard that provides inter-operability of smart card applications across NCs, POS, desktops, laptops, set tops, and so on. OpenCard promises to provide 100% pure Java smart card applications. Smart card applications often are not pure because they communicate with an external device and/or use libraries on the client. (As a side note, 100% pure applications could exist without OpenCard, but without it, developers would be using home-grown interfaces to smart cards.) OpenCard also provides developers with an interface to PC/SC for use of existing devices on Win32 platfroms.
JavaCard was introduced by Schlumberger and submitted as a standard by JavaSoft recently. Schlumberger has the only Java card on the market currently, and the company is the first JavaCard licensee. A smart card with the potential to set the overall smart card standard, JavaCard is comprised of standard classes and APIs that let Java applets run directly on a standard ISO 7816 compliant card. JavaCards enable secure and chip-independent execution of different applications.
Although this article focuses on smart cards, it is important to note that you are not limited to these kinds of devices. Personally, I prefer the "Ibuttons" device being produced by Dallas Semiconductor. It is small and portable like a credit card, but so much handier. Why? You don't have to dig out your wallet in search of a card; Ibuttons is right there, on your finger. Yes, it's a ring!
While contactless versions of the smart card do exist (see below for more information on this), I think the Ibuttons, functional-jewelry type of device could be quite profitable. For more information on Ibuttons, see the Resources section. By the way, the Java Commerce Team demonstrated a "JavaRing" at Java Internet Business Expo (JIBE) in New York last August. You can read about this in the article in Fortune magazine (again, see the Resources section).
Why use a smart card?
What are the advantages of using a smart card? Well, a smart card:
- is more reliable than a magnetic stripe card
- currently can store a hundred times more information than a magnetic stripe card
- is more difficult to tamper with than mag stripes
- can be disposable or reusable
- can perform multiple functions in a wide range of industries
- is compatible with portable electronic devices such as phones, personal digital assistants (PDAs), and PCs
- is constantly evolving (after all, it incorporates a computer chip)
Types of smart cards
As mentioned above, this article will focus on two types of smart cards -- memory and process. In all, there are five types of smart cards:
- memory cards
- processor cards
- electronic purse cards
- security cards
Smart cards are a personal piece of hardware that must communicate with some other device to gain access to a display device or a network. Cards can be plugged into a reader, commonly referred to as a
, or they can operate using RF radio frequencies.
Smart cards can communicate with a reader or receiver (see the section on readers below for more on these two terms) in one of two forms:
Contact smart cards -- The connection is made when the reader contacts a small gold chip on the front of the card.
Contactless smart cards -- These can communicate via an antenna, eliminating the need to insert and remove the card by hand. With a contactless card, all you have to do is get close to a receiver, and the card will begin communicating with it. Contactless cards can be used in applications in which card insertion/removal may be impractical or in which speed is important.
Some manufacturers are making cards that function in both contact and contactless modes.
Create a development environment for building smart card apps
In order to develop smart card applications, you need a few things, namely: a smart card reader; software to communicate with the reader as well as some software to communicate with the card that has been plugged into the reader; and, of course, smart cards and smart-card hardware.
Smart card reader
To communicate with a smart card or develop an application that is smart-card capable, you must have a reader. The reader provides a path for your application to send and receive commands from the card. There are many types of readers on the market, the most prevalent being the serial, PCCard, and keyboard models. (Keyboard models pop up here and there; expect them to be directly available from the large PC makers by June 1998.)
This article uses serial readers to support the devices. A serial reader connects to a computer's serial port. Note that the code provided also supports a PCCard reader; most laptops come with PCCard slots built in.
Each manufacturer provides a different protocol for speaking to a reader. Once you can communicate with the reader, there is one protocol for communicating with a smart card: Communication with a smart card is based on the APDU format. (The APDU format is discussed below.) For information on purchasing your own reader, see the "Gemplus smart card readers" heading in the Resources section.
Software for communicating with the reader
A number of object-oriented classes are needed for the smart card example included in this article. These are:
- ISO command classes for communicating with 7816 protocol
- Classes for communicating with the reader
- Classes for converting data to a manufacturer-specific format
- An application for testing and using the cards for the purpose for which the application was designed
Smart cards and smart card hardware
As noted at the beginning of the article, in order to develop the smart card application here, you need smart card hardware and some smart cards. You can purchase smart card development kits from a number of companies, including Gemplus and Schlumberger.
For those of you who already have readers, you should be able to use your reader by supplying an implementation of an interface class that we will discuss later. As mentioned above, before we can communicate with the card, we must be able to communicate with the reader, and just as there are many different cards, there are many different readers.
Important smart card standards
An important piece of the smart card application development puzzle is the standard protocols. Basically, the application communicates with the reader, which in turn talks to the smart card using a standards protocol -- in our case, the International Standards Organization (ISO) 7816 protocol.
As with any new technology, there are so many standards for smart cards that you may find yourself discouraged and overwhelmed. Achieving a basic understanding of the following standards will enable you to develop applications with the confidence that you are not ignoring something basic to using smart cards. For some systems, however, special standards come into play. I have broken the whole standards thing down into "horizontal" and "vertical" standards: Horizontal standards can be used by all applications, while vertical standards are specific to a system.
ISO 7816 -- describes the lowest-level interface to a smart card. It is at this level that data bytes are transferred between card reader and card.
PC/SC -- the standard for communicating with smart cards connected to Win3.1/Win95/NT machines.
OCF -- an all-Java interface for communicating with smart cards from a Java environment. (Soon OCF will allow developers to write to OCF and perform the translation, so there'll be no need to write to PC/SC.)
- JavaCard -- describes the JavaCard and what it supports.
Mondex -- digital cash that uses smart cards only. The Mondex approach does not allow cash to exist outside of the card.
VisaCash -- debit card that keeps track of the cards on the server.
Proton -- another form of E-cash.
- MPCOS-EMV -- general-purpose card that lets you implement your own type of currency or token.
I am always amazed that such a small piece of plastic could require so much documentation reading and demand so much knowledge on the part of the developer!
Because such a high level of expertise is necessary with smart cards, there is a market for developers to supply Beans-capable products that implement a vertical standard using the horizontal standard for the market you're looking to sell to. This means that you could develop beans that use various combinations of the horizontal standards, like OpenCard, to implement a specific application using some other industry standard for commerce or any other application.
Communicate with smart cards from a Java applet or application
You know what you need to connect up all the hardware. Now we need to understand how to use some APIs that will allow us to send commands from an application to a reader. (The reader, in turn, communicates with the card, thereby acting as the intermediary before sending the data to the card.) The smart card reader wiggles the gold contact points and transfers the data. The card will do something with the data and return it to the reader, which will then return the data to the application. So where are all these bytes as they are moving from your application to the card?
As mentioned above, the application communicates with the reader, which in turn talks to the smart card using the standards discussed above. Basically, as smart card technology developed, a smart card standard was proposed by ISO. The standard defined mechanical and electrical characteristics as well as the protocol for communicating with the card. Pointers to the relevant ISO documents are listed in the Resources section. Unfortunately, the ISO group was unable to provide a standard for communicating with the reader. So, in order to send a command to a card, first you need to find the command that the card supports, wrap this command in an ISO command packet, and then wrap this new command in the wrapper required for the reader in question. The example application provided here performs all of this layering for you.
Application Protocol Data Units (APDUs)
The basic unit of exchange with a smart card is the APDU packet. The command message sent from the application layer, and the response message returned by the card to the application layer, are called an Application Protocol Data Units (APDU). Communication with the card and the reader is performed with APDUs. An APDU can be considered a data packet that contains a complete instruction or a complete response from a card. To provide this functionality, APDUs have a well-defined structure that is defined in a number of ISO documents belonging to the 7816 specification family.
APDUs consist of the following fields:
Command APDU Format
Response APDU Format
The following are some of the classes provided for transporting APDUs and the classes' functions: