C H A P T E R 4

Runtime Security

This chapter discusses the design and use of the runtime security service. The runtime security service restricts a MIDlet suite from using other MIDlet suites' classes and from using internal system-only classes.

Runtime security refers to any code in the system that protects restricted methods from unauthorized access. All internal code depends on the runtime security service.

Before you port the runtime security service, become familiar with CLDC HotSpot Implementation.

The runtime security service has the following requirements:

External MIDlet suites must be restricted from the code of other suites.

External MIDlet suites must not be permitted to call restricted internal system methods.

Internal MIDP classes must still be able to access the methods they require, across package boundaries, even if the running MIDlet is not permitted to run those methods directly.

In addition, the runtime security service includes the following goals:

Small - Security cannot be turned off to save space, unlike the Java platform.

Fast - Security cannot be turned off to improve performance, unlike the Java SE platform.

Unobtrusive - Implicit techniques, used whenever possible, keep the number of explicit security checks to a minimum.

The runtime security service is incorporated into the following components, each of which fulfills part of the subsystem requirements:

Native virtual machine (VM) startup code and MIDlet suite loader

Class loader

It also defines one object, the security token.

Design Considerations

The following sections describe aspects of the runtime security system that are important for you to know about when you port it to your device.

Native VM Startup Code and MIDlet Suite Loader

Java Wireless Client software restricts a MIDlet suite from accessing the classes of other suites by putting only that MIDlet suite's JAR file in the class path before starting the virtual machine. The MIDlet suite loader can then only load the MIDlet suite's own code when it loads the classes for running a MIDlet from the MIDlet suite.

Class Loader

The runtime security service must keep external MIDlet suites from calling restricted internal system methods. Some protection is provided by the Java programming language itself, which by default restricts access to a method or field by requiring that the caller be in the method's package or field's package. This is commonly called package-private access.

Applications in the Java Platform, Standard Edition (Java SE platform) environment circumvent package-private access by defining classes in system packages. Applications cannot be permitted to use this workaround in MIDP, as it leads to security checks between classes in the same package. The additional security checks increase the amount of security code and decrease Java Wireless Client software's performance.

To keep applications from defining classes in system packages, Java Wireless Client software modifies the system class loader so that it loads internal packages only from ROM. Because Java Wireless Client software keeps application-defined system classes from ever being loaded, even if an application defines a system class.

Security Token

Java Wireless Client software must restrict the access of an external MIDlet suite to resources intended for its use, but a permissible call from a MIDlet might result in a call to an internal class that has more access. Java Wireless Client software must enable internal classes to perform a larger set of actions than the MIDlet calling them.

Java Wireless Client software defines a security token object to enable internal classes to perform sensitive actions. At initialization time, an internal security token is created and is passed to the internal classes that need it. Restricted internal methods take a security token as an extra argument and they check it before performing their task.

Internal methods can call restricted functions because they have a security token, but external MIDlets cannot call restricted functions directly because they do not have (and cannot obtain) a security token. A MIDlet's access to restricted functionality is limited, whereas an internal method's access is not.

Using the Service

This section contains advice on writing internal classes that are protected by a security token and writing internal classes that are used by optional internal MIDlets (such as classes used by the OTA installer).

Classes Protected by Security Tokens

When you design a class that is protected by a security token, check the security token during the construction of the class rather than checking it in method calls. This minimizes the number of security checks, which improves the size and performance of your port without jeopardizing security.

To follow this advice, write methods that would normally be static as instance methods. An instance method does not require a security check because the check is done when the instance is created. In contrast, a static method requires a security check because it is called on the class and the security check in the constructor does not apply.

Classes Used by Internal MIDlets

As you port the Java Wireless Client software, you might create classes that optional internal MIDlets use. An internal MIDlet, such as the OTA installer, provides a system function. Internal MIDlets are part of the Java Wireless Client software and users do not download them.

When you design a class that an internal MIDlet uses, do not protect access by requiring a security token. Internal MIDlets do not have security tokens because they are applications, not system classes. No applications, even internal applications, have security tokens.

Instead of requiring a security token, protect access to your class by using the permission protection service. This is the same protection service that other MIDlet suites use, but you can give your internal MIDlet broader permissions. See Using Permissions for Internal MIDlets for information.