Moderator (MDR): MDR-Andrea

Guest Speaker (SPK): SPK-tedgoldstein and SPK-arthur coleman

MDR-Andrea: Hello and welcome to Java Live. Today we will be focused on Java^TM Card. The Java Card 2.0 Specification is now final and available for review on the main web site, be sure to take a look at it. Joining us is Chief Commerce Officer Ted Goldstein. Please feel free to begin sending in questions for Ted.

SPK-tedgoldstein: Wow. It's great to actually use Java and the Internet to have a conversation. First let me begin by telling the story of Java Card.

In developing the JECF (Java Electronic Commerce Framework), we had the opportunity to talk to various banks and financial institutions. One of the the things that the JECF offers is smartcard access interfaces. Many people asked for Java on the smartcard. My answer was typically, "Sure, how many megabytes do you have on a smartcard?"

Some friends at Schlumberger Corp (one of the largest smartcard companies) helped us make it really happen. Since then, we have had a snowball effect of getting basically all of the smartcard companies, as well as Visa and MasterCard to sign up.

tony: Can you tell us a little about the cards themselves: what kind of CPU, memory, and other components do they have?

SPK-tedgoldstein: Cards have between 4K and 32 bytes of electrically eraseable memory. The most common cards (which cost about $6) have about 16K. They have about 512 bytes of RAM. The cheapest cards are about $2 and have about 256 bytes of RAM and about 12K bytes of EEROM (eraseable memory).

Fdeza: How do the JECF and the Java Card interoprate if at all? When is the Java bytecode loaded in the card? Is it a runtime? When can we expect a cheap card with a 32-bit RISC processor?

SPK-tedgoldstein: GemPlus just announced a great new card that has a 32-bit RAM RISC chip and 20K bytes of memory. This is going to be a great Java Card platform. JECF and Java Card interoperate now. JECF has a set of classes called javax.commerce.smartcard that give ISO7816 access to cards. By the way, ISO 7816 is the International Standards Organization standard on smartcard physical, electrical, and low-level software communication. Java Card builds on this to provide a programming API on the card.

tony: What kinds of constraints do memory and CPU put on developing Java code, i.e. what does a typical application look like?

SPK-tedgoldstein: There are lots of constraints: no long, no double, no float, no collection classes. You also have to severely restrict how deep the call stack is going to become. (Much of the 256 bytes of RAM is stack). Typical apps are 512 bytes (figure three small classes) of bytecode. A large app (such as an electronic purse) will be 2K bytes in size.

Cards have a life cycle. They are created, then they are personalized (e.g. an identity such as an account number is put on them) and then they are used. Applications are loaded either at personalization time (and here is the big benefit of Java), or they can be added after they are issued. For example, as they are used, new applets are added to the card.

MDR-Andrea: Ted, maybe you'd like to explain what you mean by "electronic purse." What is it? How does it work?

SPK-tedgoldstein: An electronic purse is an applicaton that literally holds money. VisaCash, MasterCard's Mondex, and Proton are the most common examples. VisaCash and Mondex are already available in the US in NYC's upper west side.

MDR-Andrea: I'd also like to introduce Arthur Coleman, Product Line Manager for electronic commerce. Feel free to address questions to either Ted or Arthur.

calvin: When you plug a Java smartcard into a writer, how does the writer call a method in one of the running applets? Is it like RMI, or does something else happen? For example, can I set up my own writer to keep incrementing the adddollar method in my money applet?

SPK-tedgoldstein: Personal Computers (PC) and Point of Sale terminals (POS) and other card-accepting devices send messages to the cards called APDUs (application program data units—this is an ISO 7186 term borrowed from network communication). One of the messages is "application selection." The application selection message takes as an argument an AID (Application Identifier). This is a unique ID assigned by ISO.

jacobo: Could you talk about the types of applications that are being planned?

SPK-arthur coleman: There is a wide range of applications that Java Cards are uniquely qualified to handle. These applications, in order of likelihood of appearance on the market:

1. Cellular phone applications—secure user identification, message encryption, downloadable enhanced features (e.g. voicemail, call waiting that are ordered over the phone and downloaded by the customer service representative directly into the user's phone in real time).
2. Financial applications—electronic purses, stored value applications, ATM-based applications.
3. Loyalty Programs—e.g. frequent flier programs.
4. Pay-TV applications—secure access to enhanced programming.
5. Airline ticketing—ties to loyalty programs in a strong way.

SPK-tedgoldstein: Arthur, Would you speculate about what sort of applicatons might be useful for intranet purposes?

SPK-arthur coleman: Applications that might be interesting for intranet purposes include (and some of these are VERY hot right now from our customers):

1. Secure, selective logon to various network resources (e.g. workstations vs. servers).
2. Intra-departmental purchasing between companies.
3. Remote phone access (like a phone card with extra features).
4. Email signing and spam filtering.
5. Believe it or not, some people think you will do home banking from the office—where a bank puts up a virtual ATM for a company's employees and they get special services via their intranet.
6. Corporate banking applications—e.g. if a CFO wants to login directly to his or her bank's computers via a network computer to manage the company's cash.

SPK-tedgoldstein: I guess that one of the things that people need to know is that you just put the cryptographic part together with a little bit of business logic for an application on the smartcard. You don't put in any of the GUI.

Fdeza: When Java bytecode is loaded into the card it has to be converted to some optimized according to the doc of the GemPlus and Schlumberger SDK. Can this (slow?) process happen reasonably at runtime? And what about security?

SPK-tedgoldstein: Standard Java bytecode is converted to Java Card-specific bytecode prior to card loading. This process is called "customization." The little brains on smartcards can't do this. We maintain security by digitially signing the converted code. The smartcard checks the signature.

Fdeza: Can "customization" of Java bytecode to card bytecode happen at runtime? Is there any money to make in the software in the card if it is so small?

SPK-tedgoldstein: Customization can happen at any time prior to applet loading. There is going to be a lot of business for application developers to create customer loyalty apps like, "Get your tenth cappucino free" at Starbucks.

SPK-arthur coleman: Question to the audience: How would you like to use Java Cards?

Fdeza: I see a clear use for cards in security because the card is removed when the user has finished.

tony: I think it would be great if I could forget all of my various passwords and use a smart card to store that information, sound resonable? If I do this, however, what assurances do I have that the cards are secure?

SPK-tedgoldstein: Cards are responsible for one kind of security, they can protect the data that is on the card. Of course, in cases like "network passwords" or any personal preference data, it is the mission of the card to give that information out. The way to protect this kind of data is to

1. use the JECF and its signed code mechanism and
2. require a PIN to be presented from the user to the card. Once the card "validates" the pin (like an ATM machine) then it can provide the data.

SPK-arthur coleman: To follow on to Ted's comments: I want to expand it beyond passwords to other types of secure information that could cause you trouble if lost. For example, we all have heard that identity theft is a big problem today. I have become so nervous about this—and I am NOT an usually overly security conscious—but it is so easy that I have begun noting any mail that has account numbers or other personal info and shredding it. One of the fastest growing ways people steal your identity is going through the trash. Having said this—things like account numbers, social security numbers, driver's license numbers, even my home address—if they are available in some unsecure fashion, expose me to security threats (mainly theft) of one kind or another.

There are other sorts of data--equally personal, but not so risky, in terms of theft—that maybe I don't want people to know, but which are a part of my identity. I mean, let's face it, my identity is not just my password. To you my name isn't just my identity. It's all the basic charactertistics you know about me: what kind of clothes I wear, what kind of car I drive. This kind of data I want on me at all times, that can be used by various customers to serve me. I call this personal preference data (as compared to bulk data). It can be as simple as what seat I like on a plane, or what type of rental car I like. It can be the last bottle of wine I bought at your restaurant, or the last five types of clothing I bought at your store. Personal preference data is small in size (1-2 bytes), but high in amount and high in usefulness. It is natural for it to go on a smartcard. It is also something that someone could try to steal to imitate me in more subtle ways. So on the one hand, my smartcard carries all of my personal digital identity. This is dangerous, so I want to make sure it is secure and can't be tampered with. Which now gets to the original question of how secure is a smartcard? So what do smartcards provide in the way of security (final section):

1. Physical tampering prevention--the chips themselves and their packaging are created in such a way that it is nearly impossible to physically access the data on the chip.
2. Many smartcards have cryptographic coprocessors that use Triple DES, RSA, elliptic curve, and other strong crypto protocols that keep the data on the card in encrypted form.
3. On top of this, we add a security model in Java card that prevents one applet on the card from gaining access to functions or private data contained by another applet on the card without explicit permission.

Fdeza: When will the JavaStation^TM have a Java Card Reader?

SPK-tedgoldstein: The newest JavaStations have an RS232 port. You can hook up a smartcard reader to it. Do you think it would be a good idea to have a PCM/CIA reader built in?

Fdeza: Are the GemPlus and Schlumberger Card SDK the only places where I can find samples of apps for Java Card?

SPK-tedgoldstein: Currently, yes. We will be releasing some tools next quarter that will have lots of examples.

tmax: It would be great to use smartcards to hold all kinds of personal information that can be easily accessed.

SPK-tedgoldstein: Of course, one of the nice things about smartcards is that they are useful on more than just the Internet. For example, we could have a smartcard applet that set the radio stations and seat preferences on my rental car. In fact, the card itself would be the key for starting the car.

Fdeza: Considering that storage for data and code is so tiny on a card, what are the current limits of the size of the personal profile you can store on a card?

SPK-tedgoldstein: You could easily fit 2K of peronsal data on any Java Card that I know of. On some you could fit 16K of data.

MDR-Andrea: We are going to go ahead and wrap things up. For more information on Java Card go to http://java.sun.com/javacard. Thanks for joining and see you next week.