Programming Wireless Devices with the Java2 Platform

4.2 CLDC Architecture, Application Model, and Security

4.2.1 Architectural Overview

The high-level architecture of a typical CLDC device is illustrated in Figure 4.1. At the heart of a CLDC implementation is the Java Virtual Machine, which, apart from specific differences defined later in this chapter, is compliant with the Java™ Virtual Machine Specification and Java™ Language Specification. The virtual machine typically runs on top of a host operating system that provides the necessary capabilities to manage the underlying hardware. As explained in Section 3.4.3, "Software Requirements of CLDC," the CLDC Specification makes minimal assumptions about the capabilities of the host operating system.

On top of the virtual machine are the Java libraries. These libraries are divided broadly into two categories:

Libraries defined by the Connected, Limited Device Configuration are discussed in Chapter 5. Libraries defined by profiles are outside the scope of the CLDC Specification. The libraries supported by the Mobile Information Device Profile are discussed in Chapters 8 through 20.

4.2.2 The Concept of a Java Application

Connected, Limited Device Configuration is not targeted to any specific device category. Many of the target devices may have an advanced graphical user interface, some target devices may be operated from a textual, character-based user interface, while some other target devices may not have any visual user interface or display at all. To cater to such a broad variety of devices, the application model defined in the CLDC Specification is intentionally very simple.

In the CLDC Specification, the term Java application is used to refer to a collection of Java class files containing a single, unique method main that identifies the launch point of the application. As specified in the Java™ Virtual Machine Specification (JVMS) Sections 5.2 and 2.17.1, the method main must be declared public, static, and void, as shown below:

public static void main(String[] args)

A virtual machine conforming to CLDC starts the execution of a Java application by calling the method main.

J2ME profiles such as MIDP define alternative application models that extend or override the basic application model defined by the CLDC Specification.

4.2.3 Application Security

The total amount of code devoted to security in the Java 2 Platform, Standard Edition far exceeds the total memory budget available for CLDC. Therefore, some simplifications are necessary when defining the security model for CLDC applications. Basically, the security model of CLDC can be examined at three different levels:

• Low-level security (also known as virtual machine security). Ensures that the applications running in the virtual machine follow the semantics of the Java programming language, and that an ill-formed or maliciously encoded class file does not crash or in any other way harm the target device.

• Application-level security. Means that a Java application running on a device can access only those libraries, system resources, and other components that the device and the Java application environment allows it to access.

• End-to-end security. Refers to a model that guarantees that any transaction initiated on a device is protected along the entire path from the device to/from the entity providing the services for that transaction (e.g, a server located on the Internet). Encryption or other means may be necessary to achieve this. End-to-end security is outside the scope of the CLDC Specification.

Below we take a more detailed look at low-level security and application-level security requirements.

Low-level security

A key requirement for a Java virtual machine in a mobile information device is low-level security. An application running in the virtual machine must not be able to harm the device in which the virtual machine is running, or crash the device. In a standard Java virtual machine implementation, this constraint is guaranteed by the class file verifier, which ensures that the bytecodes and other items stored in class files cannot contain illegal instructions, cannot be executed in an illegal order, and cannot contain references to invalid memory locations or memory areas that are outside the Java object memory (the object heap). In general, the role of the class file verifier is to ensure that class files loaded into the virtual machine do not execute in any way that is not allowed by the Java™ Virtual Machine Specification.

As will be explained in more detail later, the CLDC Specification requires that a Java virtual machine conforming to the CLDC standard must be able to reject invalid class files. This is guaranteed by the class file verification technology presented in Section 4.4.2, "Class File Verification."

Application-level security

Even though class file verification plays a critical role in ensuring the security of the Java platform, the security provided by the class file verifier is insufficient by itself. The class file verifier can only guarantee that the given program is a valid Java application and nothing more. There are still several other potential security threats that will go unnoticed by the verifier. For instance, access to external resources such as the file system, printers, infrared devices, native libraries, or the network is beyond the scope of the class file verifier. By application-level security, we mean that a Java application can access only those libraries, system resources, and other components that the device and the Java application environment allows it to access.

In CLDC, application-level security is accomplished by using a metaphor of a closed "sandbox." A CLDC application runs in a closed environment in which the application can access only those libraries that have been defined by the configuration, profiles, optional packages, and other classes supported by the device. Java applications cannot escape from this sandbox or access any libraries or resources that are not part of the predefined functionality. The sandbox ensures that a malicious or possibly erroneous application cannot gain access to system resources.

More specifically, the CLDC sandbox model requires that:

• Class files must be properly verified and guaranteed to be valid Java applications. (Class file verification is discussed in more detail in Section 4.4.2, "Class File Verification.")

• The downloading, installation, and management of Java applications on the device takes place in such a way that the application programmer cannot modify or bypass the standard class loading mechanisms of the virtual machine.

• A closed, predefined set of Java APIs is available to the application programmer, as defined by CLDC, profiles, optional packages, and manufacturer-specific classes.

• The set of native functions accessible to the virtual machine is closed, meaning that the application programmer cannot download any new libraries containing native functionality or access any native functions that are not part of the Java libraries provided by CLDC, profiles, optional packages, or manufacturer-specific classes.

For security reasons, the CLDC Specification also defines some additional requirements related to the interplay between system classes and application classes. For instance, a CLDC implementation is required to ensure that the application programmer cannot override, modify, or add any classes to system packages such as java.*, javax.microedition.*, or profile-specific packages, or manipulate the built-in class file lookup order in any way. Class file lookup order is discussed in more detail in Section 4.4.3, "Class File Format and Class Loading."

In addition, it is required that a CLDC application can load application classes only from its own Java Archive (JAR) file. This restriction ensures that Java applications on a device cannot interfere with each other or steal data from each other. Additionally, this ensures that a third-party application cannot gain access to the private or protected components of the Java classes that the device manufacturer or a service provider may have provided as part of the system applications. JAR files and applications representation formats are discussed in more detail in Section 4.4.3, "Class File Format and Class Loading."

J2ME profiles such as MIDP may define additional security solutions on top of those provided by CLDC. MIDP security will be discussed in detail in Chapter 16, "Secure Networking" and Chapter 18, "Security for MIDlet Suites."

4.2.4 Application Management

Many small, resource-constrained devices do not have a file system or any other conventional mechanism for storing dynamically downloaded information on the device. Therefore, a CLDC implementation does not require that Java applications downloaded from an external source are stored persistently on the device. Rather, the implementation might just load the application and discard it immediately after execution.

However, in many potential CLDC devices, it is beneficial to be able to execute the same Java applications multiple times without having to download the applications over and over again. This is particularly important if applications are being downloaded over a wireless network, and the user could incur high downloading expenses. If a device implementing CLDC is capable of storing applications persistently, we assume that the device implementing has capabilities for managing the applications that have been stored in the device. At the high level, application management refers to the ability to

• download and install Java applications,

• inspect existing Java applications stored on the device,

• select and launch Java applications, and

• delete existing Java applications.

Depending on the resources available on the device, a CLDC system may allow multiple Java applications to execute concurrently or can restrict the system to permit the execution of only one Java application at a time. It is up to the particular implementation to decide whether the execution of multiple Java applications is supported by utilizing the multiprocessing capabilities (if they exist) of the underlying host operating system or by instantiating multiple logical virtual machines to run the concurrent Java applications.

Due to significant variations and feature differences among potential CLDC devices, the details of application management are highly device-specific and implementation-dependent. The actual details of application management are outside the scope of the CLDC Specification. Application management issues in the context of the Mobile Information Device Profile are discussed in Section 19.2, "MIDP System Software."