Java Card Security
Java Card Security: How Smart Cards and Java Mix
Section 1 -- Java Security Goes Both Ways | |
There are a large and growing number of Java systems running the gamut from Java gizmos such as Java rings, through smart cards with built-in Java interpreters (the subject of this chapter), to complete Java Development Kits and Integrated Development Environments (IDEs). Java is simultaneously making in-roads on many fronts. In distributed systems, Java-based servers and servlets are becoming as common as Java clients. As with any platform meant to interact in a networked world, there are security concerns with each flavor of Java.
These concerns take on a new urgency when it comes to e-commerce. When electronic blips are money, the stakes change considerably. It may be an inconvenience to lose a Web server that amounts to fancy brochureware; it is something else entirely if the Web server and its associated backend perform all customer transactions.
The security concerns raised by e-commerce are a large enough topic in their own right that there is no way we can do them justice here. Of course, because Java is commonly used at all levels in e-commerce systems, the risks we identify have serious e-commerce implications. This is especially true for Java cards.
Counterintuitively, Java is both growing and shrinking at the same time. On one hand, the JDK, now up to Java 2, is doubling in size with each major release. Just to complicate matters, at the same time as the explosive growth of the code base is occurring, the security architecture is undergoing major reorganization. Chapter 2, "The Base Java Security Model: The Original Applet Sandbox," and Chapter 3, "Beyond the Sandbox: Signed Code and Java 2," detail the new model. On the other hand, embedded Java systems like Card Java 2.x strip Java functionality down to bare bones. The security model is not immune to this effect and has been deeply affected by Java's migration to smart cards.
These two diverse
Section 1 -- Java Security Goes Both Ways | |
There are a large and growing number of Java systems running the gamut from Java gizmos such as Java rings, through smart cards with built-in Java interpreters (the subject of this chapter), to complete Java Development Kits and Integrated Development Environments (IDEs). Java is simultaneously making in-roads on many fronts. In distributed systems, Java-based servers and servlets are becoming as common as Java clients. As with any platform meant to interact in a networked world, there are security concerns with each flavor of Java.
These concerns take on a new urgency when it comes to e-commerce. When electronic blips are money, the stakes change considerably. It may be an inconvenience to lose a Web server that amounts to fancy brochureware; it is something else entirely if the Web server and its associated backend perform all customer transactions.
The security concerns raised by e-commerce are a large enough topic in their own right that there is no way we can do them justice here. Of course, because Java is commonly used at all levels in e-commerce systems, the risks we identify have serious e-commerce implications. This is especially true for Java cards.
Counterintuitively, Java is both growing and shrinking at the same time. On one hand, the JDK, now up to Java 2, is doubling in size with each major release. Just to complicate matters, at the same time as the explosive growth of the code base is occurring, the security architecture is undergoing major reorganization. Chapter 2, "The Base Java Security Model: The Original Applet Sandbox," and Chapter 3, "Beyond the Sandbox: Signed Code and Java 2," detail the new model. On the other hand, embedded Java systems like Card Java 2.x strip Java functionality down to bare bones. The security model is not immune to this effect and has been deeply affected by Java's migration to smart cards.
These two diverse