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?
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.
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 http://www.javasoft.com/products/javacard/index.html, 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.
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.
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.
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.
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.
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.
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.