Even a stripped-down version of Java and its accompanying VM requires a fair amount of computational power in order to work. 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 Java 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. Gemplus and Schlumberger both distribute commercial Card Java environments. Of course, the memory and interface constraints of smart cards deeply affect programming style, testing concerns, and other aspects of program development. Card Java has many features familiar to Java developers, especially those developers familiar with JDK 1.0.2. Card Java includes:
In the current Card Java paradigm, applets live on a card forever once they are installed during a process commonly called personalization. More specifically, although an applet's byte code may stay on the card forever once it is masked onto a card, an applet can be marked as unavailable and thus be permanently disabled. All applets that will be used on a card are installed at one time, before the card is issued to a consumer. These applets are selected and deselected 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. The JCRE is in this sense the card executive, receiving messages (known as APDUs) on the input lines and carrying out the appropriate activities such as selecting an applet. Only one applet can run at a time in current Card Java implementations. Future versions of Card Java are likely to allow applets to be loaded onto an existing card even after it has been issued to a consumer (much the same way that applet code is loaded into a browser's VM). This introduces a number of security risks, including the risk that downloaded applet code will behave maliciously (in the manner of the hostile applets detailed in Chapter 4, "Malicious Applets: Avoiding a Common Nuisance," and Chapter 5, "Attack Applets: Exploiting Holes in the Security Model") and the risk that poorly engineered code will disable or otherwise break the platform. Unlike VMs inside browsers, a smart card VM is not quite as easy to restart, nor are the security mechanisms as rigorous. By this point, it should be clear that Card Java has important security implications. These implications take on even more importance when smart cards are used in e-commerce systems.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
