Fundamentals of Java ME MIDP Programming : MIDP Security Model (part 3) - The Security Model in Practice

7. The Security Model in Practice

In this section, we go through the steps involved in producing a signed MIDlet suite. We shall illustrate this process using the tools provided by the WTK. The basic steps in producing a signed MIDlet suite are listed below:

To sign a MIDlet suite, the supplier of the suite needs to obtain a public-private key pair either by generating a new key pair or importing an existing key pair. The WTK provides tools for doing this; they can be accessed by opening your project and choosing the Project/Sign option from the main panel. Clicking the Sign button brings up the panel shown in Figure 4. To generate the key pair, click on Keystore, then New Key Pair, enter the appropriate details and click the Create button (see Figure 5).

Figure 4. Sign MIDlet Suite view of the WTK

A new key pair is generated and added to the WTK key store. The newly-generated public key is incorporated into a self-signed certificate. We use this to obtain a suitable MIDlet suite code-signing certificate from an appropriate source (such as a recommended Certification Authority, for instance, Verisign or Thawte) that can be authenticated by a root certificate that ships with the device or is contained in the WIM/SIM card. Application developers and suppliers should contact the relevant developer program of the device manufacturer or network operator to ascertain the appropriate CA.

We can then generate a Certificate Signing Request (CSR) using our self-signed certificate and the Generate CSR option in the WTK (Figure 6). This generates a file containing the CSR that can be saved to a convenient location. The contents of the CSR can then be copied into an email to the recommended CA, requesting a code-signing certificate.

Figure 5. Creating a new key pair

Figure 6. Generating a Certificate Signing Request

When we have received the certificate from the recommended CA, we need to associate this with our key pair. The Import Certificate option of the WTK associates the certificate with our key pair, identified by its alias and held in the key store. If the public key that we provided in the CSR, and now contained in the certificate, matches the public key of the key pair held in the key store, we should be notified accordingly and are now ready to sign our MIDlet suite. To sign the MIDlet suite we simply select Sign MIDlet Suite from the Action menu and choose the JAD file belonging to the MIDlet suite we wish to sign. The MIDlet suite is now ready for deployment on the target device.

The WTK also offers additional functionality to test out signed MIDlet suites. There is a default trusted key pair (and an associated root certificate) that can be used to install and bind a signed MIDlet suite to a trusted protection domain within the emulator environment. This then allows MIDlets in the signed suite to run within the WTK environment as trusted without obtaining and importing a certificate from a CA. This feature is particularly useful for ensuring that the appropriate permissions to access protected APIs have been requested in the JAD file. It is important to remember that this feature of the WTK only works in the test environment. For real devices, you must sign your MIDlet suite with a valid certificate received from a Trusted CA.

8. Untrusted MIDlets

An untrusted MIDlet suite is an unsigned MIDlet suite. It is, therefore, installed and bound to the untrusted protection domain. Untrusted MIDlets execute within a restricted environment where access to protected APIs or functions may be prohibited or allowed only with explicit user permission, depending on the security policy in force on the device. To ensure compatibility with MIDlets developed according to the MIDP 1.0 specification, the MIDP specification demands that the untrusted domain must allow unrestricted access to the following APIs:

• javax.microedition.rms

• javax.microedition.midlet

• javax.microedition.lcdui

• javax.microedition.lcdui.game

• javax.microedition.media

• javax.microedition.media.control

Furthermore, the specification requires that the following APIs can be accessed with explicit permission of the user:

• javax.microedition.io.HttpConnection

• javax.microedition.io.HttpsConnection

The full list of permissions for the untrusted domain is device-specific, however the MIDP specification does provide a Recommended Security Policy Document for GSM/UMTS Compliant Devices as an addendum (with some clarifications added in the JTWI Final Release Policy for Untrusted MIDlet Suites). Finally, if a signed MIDlet fails authentication or authorization, it does not run as an untrusted MIDlet, but rather is not installed by the AMS. For more information on the security model, see the MIDP specification.

9. Recommended Security Policy

The Recommended Security Policy defines a set of three protection domains (Manufacturer, Operator and Trusted Third Party) to which trusted MIDlet suites can be bound (and which a compliant device may support).

For a trusted domain to be enabled, there must be a certificate on the device, or on a WIM/SIM, identified as a trust root for MIDlet suites in that domain, i.e. if a signed MIDlet suite can be authenticated using that trust root it will be bound to that domain. For example, to enable the Manufacturer protection domain, the manufacturer must place a certificate on the device. This is identified as the trust root for the Manufacturer domain. A signed MIDlet suite will be bound to the Operator domain if it can be authenticated using a certificate found on the WIM/SIM and identified as a trust root for the Operator domain. A signed MIDlet suite will be bound to the Trusted Third Party protection domain if it can be authenticated using a certificate found on the device or on a WIM/SIM and identified as a trust root for the Trusted Third Party protection domain. Verisign and Thawte code-signing certificates usually fit the latter situation.

As already mentioned, the recommended security policy is not a mandatory requirement for an MIDP 2.0-compliant device. An implementation does not have to support the RSP in order to install signed MIDlet suites; it simply has to implement the MIDP security model and support at least one trusted protection domain.