Java Card programming interfaces

Java Card programming interfaces include a set of specialized classes that are designed to program smart card applications in accordance with the model defined in the ISO 7816 standard. These APIs include three basic packages and one extension package. Basic packages – java.lang, javacard.framework and javacard.security. The extension package is called javacardx.crypto.

Developers who are familiar with the Java platform may notice that many classes of this platform are not supported by Java Card programming interfaces. For example, Java platform classes are not supported for organizing graphical user interfaces, as well as for servicing network and local I/O subsystems. These functions are not needed, because smart cards do not have an information display device and they use specialized network protocols and their own file system. In addition, many Java platform utility classes are not supported. This is due to the small amount of available memory.

Java Card programming interface classes are implemented compactly and concisely. They include Java platform classes adapted to provide support for the Java language and cryptographic services. There are also classes specifically designed to support the ISO 7816 smart card standard.

java.lang package

The java.lang package of the Java Card platform is an abbreviated subset of the java.lang package of the Java platform. The Object and Throwable classes are supported, as well as some exception classes related to the operation of the virtual machine. The composition of the package is shown in Table 3.2. Many Java methods are not available in the supported classes. For example, the Object class of the Java Card platform contains only the default constructor and the equals method.
The java.lang package provides basic Java language support. The Object class defines the initial vertex of the Java Card class hierarchy, and the Throwable class is the progenitor of all exceptions. Supported exception classes provide the necessary means of handling errors that occur due to violations of the rules of the Java language. For example, both the Java Virtual Machine and the Java Card Virtual Machine generate a NullPointerException exception when trying to use an uninitialized reference.

Javacard package.framework

javacard.framework is one of the main packages of the platform. It includes base classes and interfaces that provide the basics for the functioning of Java Card applets. It is very important to note that this package defines the base class Applet, which defines the model of the functioning of the applets and their interaction with JCRE during the lifetime of the applets. The value of this package in JCRE can be compared with the role that the Java Applet class performs in the Web browser of the host system. Custom applet classes should extend the base Applet class. To ensure the functioning of the applet, its methods must override the methods of the Applet class.

Another important class of the javacard package.framework – APDU class. APDU packets are exchanged at the transport protocol level. There are two standardized transport protocols: T=0 and T=1. The APDU class ensures the independence of applications from transport protocols. In other words, this class allows you to hide from applet developers the details of the implementation of protocols T=0 and T=1, as well as the differences between them. The methods implemented in the APDU class can significantly simplify the processing of APDU commands. The applets will work correctly regardless of the lower-level protocol supported by the platform. Chapter 8 explains in detail the use of the APDU class.

The java.lang.System class of the Java platform is not supported. The Java Card platform implements the javacard class.framework.JCSystem, which provides an interface with the system. The JCSystem class of the Java Card platform includes a set of methods that control the execution of applets, resources, transactions, as well as the sharing of objects by different applets.

Other classes included in the javacard package.framework, provide PIN-code processing, execution of utility functions and exception handling. PIN is an abbreviation of “personal identification number” (personal identification number). Most often, the PIN code is used as a password to authenticate the owner of the smart card.

javacard.security package

The javacard.security package provides support for cryptographic functions of the Java Card platform. It is designed based on the java.security package.
The javacard.security package defines the KeyBuilder class for generating encryption keys, as well as various interfaces representing cryptographic keys that are used in symmetric (DES) or asymmetric (DSA and RSA) data encryption algorithms. In addition, this package supports the abstract base classes RandomData, Signature and MessageDigest, which are designed to generate random data, as well as to calculate digests and digital signatures of messages.

javacardx.crypto package

The javacardx.crypto package is an extension package. It includes cryptographic classes and interfaces that are regulated by US export laws. The javacardx.crypto package defines an abstract Cipher base class that supports encryption and decryption functions.

The javacard.security and javacardx.crypto packages define programming interfaces that can be used by applets to perform cryptographic functions. However, they do not provide any implementation. Classes that provide the implementation of basic and additional interfaces inherited from the abstract classes RandomData, Signature, MessageDigest and Cipher should be implemented by JCRE developers. Usually smart cards have a special coprocessor for cryptographic calculations. Chapter 10 discusses the cryptographic functions of the javacard.security and javacardx.crypto packages available for applets.

Java Card

Java Card applets should not be confused with Java applets because of the common name. The Java Card applet is a Java program conforming to certain conventions that guarantee its compatibility with the Java Card runtime environment. Java Card applets are not designed to work in a Web browser environment. The reason why Java Card client applications are called Java Card applets is that they can be loaded into the Java Card runtime environment after the card is released. Similarly, Java applets are loaded into the client system during a session with a Web browser. Thus, unlike many embedded systems, applets do not have to be written to permanent memory during the production of smart cards. On the contrary, they can be loaded into the map at any time after its release.

The applet class must inherit from the javacard class.framework.Applet. The Applet base class is a superclass for all Java Card applets. An applet class is a template that defines the variables and methods of an applet. When we say that an applet is executed on the map, we mean that an instance of the applet class is executed. Like all other permanent objects, after creation, the applets are valid for the entire duration of the smartcard’s operation.

The Java Card runtime supports having multiple applications on the card. Multiple applets can co-exist on the same Java smartcard, and each applet can have multiple instances. For example, one instance of the “electronic wallet” applet can handle transactions in US dollars, and another in British pounds.

If the reader is familiar with the Java platform, then he knows that packages and programs on this platform have a unique identifier in the form of a Unicode string, and the naming scheme is based on the Internet domain name system. In the case of the Java Card platform, a unique application identifier (AID) is used to identify and select each applet instance.