A Java Card Primer: Part 1—Introduction to the Java Card Environment
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
This series of two articles discusses the Java Card environment. The first article begins with a brief presentation, leveraging your knowledge of other Java platforms and describing the differences with the Java Card specification.
In the second article, "A Java Card Primer: Part 2—A Java Card Example," you will see a simple yet complete example of a Java Card applet development.
Introduction
The differences between the other Java environments (mainly the nearest one, J2ME) are in the hardware limitations and a completely different lifecycle from the usual interactive applications—both in development and in execution. Another reason for this difference is the required compatibility with the pre-existing ISO 7816 standard for smart cards.
The memory configuration of a smart card can be in the order of 1KB of RAM, 16KB EEPROM, and 24KBof ROM. Of these resources, the Java Card Runtime Environment (JCRE) occupies a good part of the ROM. The remaining types of memory are left to Java Card applications, known as applets, because of their capability to be downloaded and executed even after the card has been issued (that is, its ROM memory has been written out).
The main features that the Java Card specification supports are the following:
Three small primitive data types only (boolean, byte, short)
Optional support for integer (int) primitive data type.
One-dimensional arrays
Java packages, classes, interfaces, and exceptions
Object-oriented features
Conversely, the main unsupported Java features are the following:
All large primitive data types (long, double, float)
Primitive char types and strings (String class)
Multidimensional arrays
Dynamic class loading (the whole System class is absent)
Security Manager
Garbage collection
Serialization
Object cloning
Multiple threads
Another difference is in the standard libraries supported. Given the peculiarity of the card environment, standard libraries were completely rewritten. The system libraries available for a standard Java Card Runtime Environment (JCRE) are the following:
java.lang package. This package is a little subset of its counterpart for the Java 2 platform. Only a few classes are present, and they are heavily shortened. The Object class provides only the default constructor and the equals method. Other classes in this package include Throwable and Exception; and there are nine subclasses, including NullPointerException.
javacard.framework package. This package provides core functionalities for Java Card applets (for example, the JCSystem class that substitutes the System class in other Java platforms). Most used classes of this package are the Applet class, from which all applets must subclass; APDU, which is discussed later; and PIN, which is an equivalent of the password used to authenticate card holders (PIN is an acronym for personal identification number).
javacard.security and javacardx.crypto packages. These packages are intended to be used together to provide cryptographic services to card applets. They don't provide concrete implementations; they are done by the JCRE manufacturer, with the help of the underlying card vendor's implementations.
Another remarkable difference is in the naming convention for packages and applets, which needs to be compliant with the mentioned ISO 7816 standard for smart cards. This naming convention requires applets and packages to be identified by an application identifier (AID) sequence of bytes. Intuitively, these byte strings look similar to IP addresses, in that groups of these addresses are assigned by an external committee, and the companies specify the exact addresses within their assigned namespace. The first five bytes represent the company id, and are assigned by the ISO external authority. A variable number of bytes (from zero to 11) are then defined internally by the company to name its products.