Installing a MIDlet Suite

One of the first places a user encounters security issues is during MIDlet suite installation. At a minimum, the user should always be presented with the trust level of the MIDlet suite before the suite is installed, as shown in Screenshot. In addition, the MIDlet must be assigned to a protection domain and, depending on the needs of the MIDlet suite and the protection domain's permissions, the user may be asked to grant permissions during the installation.

Screenshot Trust Level on Confirmation Screen during Installation

Communicating a MIDlet Suite's Level of Trust

A user should be asked for confirmation before a MIDlet suite is installed. This would typically be done after the JAD file is downloaded but before the JAR file is downloaded. In MIDP 2.0, the Confirmation screen should also include any information on the trust level of the MIDlet suite. One place that trust information can be found is in any certificate used to sign the MIDlet suite. Screenshot shows a mock-up of a Confirmation screen with some security information.

MIDP Implementors

Strongly Recommend: Include information about the trust level of the MIDlet suite in the Installation Confirmation screen. Users should know what they are installing before they install it.

Consider: If the MIDlet suite is signed, include relevant information from the certificate, such as its organization, country, and subject.

Strongly Recommend: If the MIDlet suite being installed is updating an existing MIDlet, and the existing MIDlet had a digital signature, the installation can only continue if the new MIDlet suite is also signed.

Authenticating a MIDlet under a Protection Domain

During installation, a MIDlet suite authenticates under a particular protection domain. That is, each protection domain has a different entry criterion. One protection domain might be for MIDlets signed by a particular entity, another might be for MIDlets from a particular web site, and so on. A MIDlet that meets the entry criterion for a domain is said to authenticate under that protection domain. MIDlets that cannot authenticate under any of the device's trusted protection domains (but have no other problems with their MIDlet suite packaging and could otherwise be installed) are assigned to the untrusted protection domain.

MIDP Implementors

Recommend: Work with operators to ensure that your implementation authenticates MIDlet suites under the correct protection domains. For example, an operator may want MIDlet suites signed by different entities to be authenticated under different domains, or may want MIDlet suites on its portal to authenticate under a particular domain, and so on.

Protection domains may not be an issue for MIDlet suites that do not use protected functions. These MIDlet suites can run in the same way whether they are in a trusted or an untrusted domain. Other MIDlet suites, though, must be installed in a domain that can grant them access to the protected functions they require.

app Developers

Recommend: If your MIDlet suite requires protected functions, ask operators and MIDP implementors how to get your MIDlet suite onto their devices in a trusted domain. For example, you might be able to get your MIDlet suite shipped with the device, or made available from the operator's portal. You might have to have the MIDlet signed by a certain entity so that the MIDlet can be installed on the device.

Authorization

Trying to grant permissions, whether by the device or the user, is called authorization. If permission is granted, it is a successful authorization. One of the times that a MIDlet suite is authorized is during installation. If the authorization is not successful, the MIDlet cannot be installed. Authorization during the installation process occurs after the MIDlet suite is authenticated under a domain. The MIDP implementation can then check the permissions requested by the MIDlet suite against the permissions that the protection domain could grant. So that it can be authorized, a MIDlet suite should specify its needs for protected APIs in its JAR manifest or JAD file. (See Programming Wireless Devices with the Java 2 Platform, Micro version [17] for more information on these files.) In these files, a MIDlet suite can specify that certain permissions are required and that others, while nice to have, are not required.

app Developers

Strongly Recommend: Specify that a permission is required if your MIDlet cannot function without it. For example, if your MIDlet enables users to browse an online catalog, it couldn't function without HTTP. Specify that a permission is nice to have, but not required, if your MIDlet can operate with or without it. (The functionality available without the permission is permitted to be at a lower level than if the permission were granted.) For example, if your MIDlet is a game that allows its users to save their scores on a server, users could still play the game without using HTTP; they just couldn't publish their scores.

MIDP Implementors

Strongly Recommend: If the MIDlet suite requires a permission that your security policy cannot grant, do not install the MIDlet suite. If the MIDlet suite requests, but does not require, permissions that the device cannot grant, continue installing the MIDlet suite.

Recommend: If a MIDlet suite cannot be installed because it is untrusted and it requires protected functions, display a message that explains the situation in user-friendly terms, as the message in Screenshot does.

Screenshot Untrusted MIDlet Suite Requiring Protected Functions