Smart cards, Java cards and security

The addition of Java to smart card applications provides new advantages, but there are still technical reasons for caution.
Posted January 19, 1998

Gary McGraw

First off, a disclaimer. Asking if smart cards are secure is very much like asking whether a computer or a bank is secure. There really is no answer to the question since the term "smart card" is used for an entire family of technologies. Nevertheless, smart cards are currently being touted as a partial solution to open problems in e-commerce security. So what are they anyway? What's special about Java-based smart cards? And what impact can they have on e-commerce security?

What is a smart card?

A smart card looks just like a credit card only with a chip embedded into its plastic. Imagine replacing the hologram on a standard credit card with a similarly thin chip, and you get the idea. Most smart card chips are about the size of a dime (only thinner) and can be recognized by their distinctive gold terminals. A smart card chip is actually a complete little computer with non-volatile memory, storage, a card operating system (COS) and accompanying communication protocols. The most advanced smart cards on the market have the processing power once found in an IBM-XT (with less memory, of course). There are lots of different kinds of smart cards: security cards (used to identify the carrier), electronic wallet cards (with stored value), processor cards (which carry out proprietary calculations in a black box fashion), memory cards and even cards with virtual machines to run Java applets!

Unlike traditional computers, smart cards do not have a built-in power supply. Instead, they require a terminal to work. Such a terminal is usually called a smart card reader. The card is inserted into a reader which is then powered up and sets up the card to receive software commands. There are many custom command sets for smart cards, but most are based around the ISO 7816 family of specifications. ISO 7816 defines commands in great detail and lays out communication protocols used by smart cards.

Smart cards have long been associated with security since they provide a partial solution to the need for personal identification and non-repudiation. To the extent that a card is tamper-resistant, it can be used to store important secrets such as DES keys or RSA private keys.

What about Java cards?

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. Since few developers were familiar with card-application languages, 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.0.

A Java card is a smart card that is able to interpret Java byte code, similar to the way Java-enabled browsers can. Card Java is a stripped-down version of Java based on a subset of the Java API (plus some special-purpose card commands). To be capable of running Card Java, a smart card must have at least 16K of read-only memory, 8K of EEPROM and 256 bytes of random access memory. Given a virtual machine on a smart card, the number of possible new applications is mind-boggling. With an off-the-shelf (or off-the-Net) application development environment for Card Java, thousands of Java developers will be able to program smart cards. Of course, the memory and interface constraints of smart cards will deeply affect programming style.

Card Java has many features familiar to Java developers: packages, dynamic object creation, virtual methods, interfaces and exceptions. Elements of Java that are not supported include: dynamic class loading, a security manager, threads, cloning, garbage collection and finalization. There are also a number of limitations imposed on runtime cardlet behavior. The "Java Card 2.0 Language Subset and Virtual Machine Specification," a Sun Microsystems document available at, describes the smart card version of Java in more detail.

In the current Card Java system, applets live on a card forever once they are installed. Access to applets is controlled by the Java Card Runtime Environment (JCRE). The JCRE is made up of the Virtual Machine and the core classes of the Java Card API. It keeps track of applets that are selected and currently active.

To the extent that a Java card will have important private information stored on it somewhere (like many PCs today), Java security will be as critical as ever.

How will smart cards be used in electronic commerce?

Smart cards are an excellent medium for carrying password-protected personal data. Private information such as medical records or secret crypto keys can be stored on a card in a form accessible only to the card carrier. Smart cards can also store value. Card carriers can decide with whom to share data and transact business with and use their cards only with those vendors they choose to trust.

The most common form of smart card for commerce is the register-based, stored-value card. Somewhat ironically, one of the most unfortunate consequences of this kind of smart card is that secret keys on the card are known only to the issuing bank and must remain secret from the owner. If card owners can somehow retrieve a secret key, they can "mint" electronic cash.

What are the risks of using a smart card?

Losing value
If a stored-value smart card is lost or stolen, the value stored is lost. Losing that kind of smart card is like losing cash, and it can happen to the best of us. Debit cards with liability limitations (such as are commonly found today) may present a more attractive alternative to some consumers. Of course, there is no anonymity with debit cards as there can be with certain kinds of stored-value cards.
Key compromise
Many e-commerce cards carry secret crypto keys (usually DES or RSA private keys). If these keys are compromised, they can be used to load value onto the card, change card parameters, or bilk consumers by adjusting the card balance. Extreme care must be taken to guard crypto keys. To the extent that cards are tamper resistant, keys can be protected. (See both "Physical attacks" and "Protocol attacks" below.) Many researchers believe that giving a potential attacker a card with secrets on it that need to be protected from the attacker is a fundamentally flawed approach.
Physical attacks
The most obvious and direct attack on a smart card is a physical attack on the card itself. In the case of a stored-value card, this sort of attack may even be carried out by the owner of a card. Physical attacks attempt to reverse engineer the card and determine the secret key(s). Such attacks have been demonstrated in practice against commercial secure smart card chips, most notably by Ross Anderson of Cambridge and Marcus Kuhn of Purdue.

In a paper entitled "Tamper Resistance -- A Cautionary Note," Anderson and Kuhn point out that "smart cards are broken routinely" and to the extent that their secure use requires tamper resistance, smart cards "should be treated with circumspection." The paper describes a number of smart card attacks, many of which can be carried out by amateur attackers with very limited resources. Attacks described include: voltage manipulation, temperature manipulation, chip removal (for easier probing), UV light attacks and microprobing.

More sophisticated attacks requiring professional equipment and materials involve uncovering the layers of a chip by etching, discerning chip behavior by advanced infrared probing and reverse engineering chip logic. The somewhat gloomy conclusion is that, at best, chip designers can only impose costs and delays on attackers, and never provide guaranteed security. Many businesses that rely on smart card security realize this and do all they can to manage the risks prudently. Users should do the same.

Random number generation
Electronic commerce cards require built-in cryptographic functionality. Along with (hopefully sound) implementations of well-understood cryptographic algorithms such as DES and RSA, these cards need the capability to generate random numbers. Generating pseudo-random numbers is not an easy task, and doing so with the limited resources on a smart card may be even harder. Care must be taken that generators produce quality randomness, or crypto systems can be compromised.
Protocol attacks
Prudent industries that hope to rely on smart-card security in modern systems would do well to subject their designs to independent verification and validation (sometimes called hostile reviews). I have performed several such reviews focused on communication and encryption protocol analysis. Using both formal analysis methods and attack scenarios, my colleages at Reliable Software Technologies and I subject proposed design specifications to rigorous analysis.

In addition to protocol analysis of this sort, Bruce Schneier, author of Applied Cryptography (Wiley 1996), recently identified a family of attacks based on using multiple protocols on a card to determine secret information. Many smart cards offer multiple protocols using the same secret keys. There is a risk that the multiple-protocol attack will compromise card security.

The terminal problem
Finally, smart cards must have some way of displaying information about their contents and transaction streams to card owners. This display must be unspoofable and trustworthy. Making sure a terminal presents proper and trustworthy information to a user is known as the "terminal problem." After all, how can the user of a smart card trust that the card is not doing something nefarious? In general, protection for the consumer in smart-card-based e-commerce systems is minimal. Potential smart card users should think carefully about this risk. The most commonly proposed solution is to combine the use of smart cards with trusted Personal Digital Assistants.

As smart cards move into more widespread use on PCs, PC-based interfaces will be especially susceptible to the terminal problem. An unsecure Windows-95 OS in concert with a Web browser should not be trusted to display critical information to a smart-card user.

Does Card Java add new risks?

One of the biggest problems in Java security is figuring out how to preserve type safety while at the same time allowing dynamic class loading. If you can confuse the virtual machine about the types of objects it is manipulating, you can break the security model. Along with Professor Ed Felten, I discuss this problem in the book Java Security: Hostile Applets, Holes, & Antidotes (Wiley 1996). Card Java takes care of this problem by removing dynamic class loading (making type safety easier to enforce). In this way, Card Java is less risky than regular Java.

Card Java does allow multiple applications to be resident on the same smart card. Although Card Java defines "applet firewalls" meant to protect applets from one another, there is a risk of inter-application attacks. The firewalls must be perfectly implemented to allow safe use of multiple applets. Plans are in the works for smart card applications that cooperate with each other. Imagine, for example, a card that works both as a debit card and as a frequent flyer card. Such plans may introduce more security risk than they are worth.

Another final source of risk is the JCRE. It's worth remembering that the JCRE is all-knowing; according to Sun, "The JCRE is allowed to use and modify any object on the card." This makes it an especially tempting target for attack. The JCRE must be perfectly implemented for a Java Card to be secure.


New functionality in the form of smart cards promises to help solve some tough real-world problems and address important security concerns. But with new functionality comes new risks. The security dilemma remains: what degree of risk are you willing to take, and to what benefit?

Gary McGraw, Ph.D., is a senior research scientist at Reliable Software Technologies. He holds a dual Ph.D. in cognitive science and computer science from Indiana University and a B.A. in philosophy from the University of Virginia. Dr. McGraw is a noted authority on Java security and recently completed Java Security: Hostile Applets, Holes, and Antidotes with Prof. Ed Felten of Princeton University. A second book, Software Fault Injection: Inoculating Programs Against Errors, written with Dr. Jeff Voas, was published in November. He has also written over forty technical publications. Dr. McGraw is a principal investigator on grants from the National Science Foundation, Rome Labs and the Defense Advanced Research Projects Agency.

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.