BUY IT!
Securing Java

Previous Page
Previous Page
Java Card Security: How Smart Cards and Java Mix
CHAPTER SECTIONS: 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8

Section 3 -- Why Put Java on a Smart Card?

Next Page
Next Page

As we mentioned earlier, one obstacle blocking widespread use of smart cards in U.S. markets has been the large number of incompatible and often obscure development languages available for writing smart card applications. Regardless of the ISO 7816 specifications, programming languages for smart cards have traditionally amounted to special-purpose assembly languages. Few developers were familiar with card application languages, the upshot being that only a handful of people could develop smart card code. As cards become computationally more powerful, new application languages are being designed and put into use. One of the most interesting new systems is Java Card 2.x (see www.javasoft.com/products/javacard/index.html).

The problem of multiple, noninteroperable platforms is not limited to smart cards, of course. A major part of Java's appeal is that it was designed as a cross-platform solution. Developers have always wanted a solution to the platform problem (other than the adoption of one single proprietary platform controlled by a monopoly). Java is one good way of addressing the platform problem on smart cards.

A Java card is a smart card that is able to execute Java byte code, similar to the way Java-enabled browsers can. But standard Java with all of its libraries (especially in the Java 2 guise) is far too big to fit on a smart card. A solution to this problem is to create a stripped-down flavor of Java. Card Java is just such a flavor. It's based on a subset of the Java API plus some special-purpose card commands.

Besides providing developers with a more familiar development environment, Card Java also allows smart cards to have multiple applications on them. For the most part, existing smart card products (especially in the financial arena) have only one application per card. This application is automatically invoked when power is provided to the card or the card is otherwise reset. The one-application-per-card paradigm doesn't scale well, to say the least. Who wants to carry 20 credit cards around? Card Java can solve this problem by allowing multiple applications, potentially written by different organizations, to exist on the same card. The idea of multiple applications running on the same VM by potential competitors raises a number of security issues, which we address later in the chapter.

Previous Page
Previous Page


Search Help
Next Page
Next Page


Menu Map -- Text links below

Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Front -- Contents -- Help

Copyright ©1999 Gary McGraw and Edward Felten.
All rights reserved.
Published by John Wiley & Sons, Inc.