Establishing Trust for MIDlet Suites by Using X.509 PKI

The signer of a MIDlet suite might be the developer or an entity responsible for distributing, supporting, and perhaps billing for the use of the MIDlet suite. The signer is responsible for ensuring that the MIDlet suite's applications are not malicious and will not harm assets or capabilities. The signer must exercise due-diligence in checking the MIDlet suite before signing it.

The signer must have a private and public key pair. The signer uses the private key to sign the MIDlet suite, and provides the public key in an RSA X.509 certificate for the MIDlet suite's application descriptor. That certificate might be validated by another certificate, and so on, except for the final certificate in the application descriptor. The final certificate in the application descriptor is validated by a protection domain root certificate on the device.

The signature of a MIDlet suite protects only the JAR containing the manifest, the MIDlets' classes, and any additional resources. The signature does not protect the application descriptor; it is not secured. Attributes defined within the manifest are protected by the signature, but attributes in the application descriptor are not.

Because attributes defined in the application descriptor are not secured, when an attribute appears in the manifest, it must not be overridden by a different value from the application descriptor. For trusted MIDlet suites, the value in the application descriptor must be equal to the value of the corresponding attribute in the manifest. If not, the MIDlet suite must not be installed. The MIDlet.getAppProperty method returns the attribute value from the manifest if one is defined. If not defined, the value from the application descriptor, if any, is returned.

Note that the requirement for attribute values to be equal differs from MIDP 1.0 and must be used for applications that are signed and verified by these procedures. For untrusted MIDlet suites, the MIDP 1.0 rule gives priority to application descriptor attributes instead of manifest attributes.

Examples of MIDlet Suite Signing

There are many ways to structure protection domain root certificates and their associated signing policies. These examples show two possibilities.

Example 1 – Developer Owns Signing Certificate

This example covers the case where the developer owns the signing certificate and uses it to sign the application. In this case, the origin of the MIDlet suite is encoded into the application descriptor; it is the identity of the signer.

Example 2 – Protection-Domain Stakeholder Owns Signing Certificate

This example covers the case where the signer's identity (not the MIDlet suite developer) is encoded into the application descriptor.

The signer will need to be aware of the authorization policy for the target device and identify which protection domain the MIDlet suite should operate in. The domain's protection domain root certificate must be the root of the certificate chain. The signer will need to contact the appropriate certificate authority. At the time of this writing, the best place to begin to determine the correct domain and certificate authority is to contact the developer program of the network operator or the device manufacturer. The signer might need to send its distinguished name (DN) and public key (normally, packaged in a certificate request) to the certificate authority who would create a RSA X.509 (version 3) certificate and return it to the signer.

If the MIDlet suite will need to run on devices with different protection domains or protection domain root certificates, then the signer would need to use the same public key for verification but get a different signing certificate from each certificate authority. All of the signer certificates in the MIDlet suite's application descriptor must contain the same public key.

The signer should also remain aware of the certificate's status. If the certificate expires, new installs will not succeed. If the certificate is disabled or revoked, every user on every device that supports revocation will have their execution permissions revoked.

Inserting Certificates into the Application Descriptor

The certificate chain, except the root certificate, must be included in the application descriptor. The root certificate will be found on the device. Each certificate in the path is encoded (using base64 but without line breaks) and inserted into the application descriptor as:

MIDlet-Certificate-n-m: base64-encoding-of-certificate

The certificates are numbered to define the sequence in which they are examined. The number n is one (1) for the first certificate chain in the descriptor. The number n should increment by one for each subsequent certification chain. The order defines the sequence in which the certificate chains are tested to see if the corresponding root certificate exists on the device. The number m is one (1) for the signer's certificate in a certification chain and increments by one for each subsequent intermediate certificate (if any).

Creating the RSA SHA-1 Signature of the JAR

18.5.2 Authenticating a MIDlet Suite

When a MIDlet suite is downloaded, a device that recognizes MIDlet suites signed using PKI as trusted must check whether authentication is required. If the attribute MIDlet-Jar-RSA-SHA1 is present in the application descriptor, then the JAR must be authenticated by verifying the signer certificates and JAR signature. Application descriptors without the MIDlet-Jar-RSA-SHA1 attribute are not authenticated but are installed and invoked as untrusted MIDlet suites.

Verifying the Signer's Certificate

When a device verifies the signer certificate, it tries to find a certificate chain that ends with a root certificate on the device. (Root certificates may also be present in removable media such as a SIM(WIM) card or a USIM module. The device implicitly trusts these roots to verify the integrity and authentication of MIDlet suites.)

Verifying the MIDlet Suite JAR

The MIDlet suite JAR is verified to insure the integrity of the application. The MIDlet-Jar-RSA-SHA1 attribute is retrieved from the application descriptor and decoded from base64 yielding a PKCS #1 signature. The signer's public key from the signer certificate is used to verify the signature. If the signature verification fails, the MIDlet suite is rejected.

The SHA-1 hash of the MIDlet suite JAR must match the message digest in the signature. If it does not match, the device must not install the JAR or allow MIDlets from the MIDlet suite to be invoked.

Once the steps of verifying the certificate, verifying the signature, and verifying the JAR all succeed, the MIDlet suite contents are known to be intact and the identity of the signer is known.

Results of MIDlet Suite Source Verification

The authentication and authorization processes may store and transfer their results for subsequent use. The MIDP implementation must protect the cached information so that it cannot be tampered with or otherwise compromised between the time it is computed and the time the authorization information is used.

It is also essential that the MIDlet suite and security information used to authenticate and authorize a MIDlet suite (that is, the raw material for the authentication and authorization process) is not compromised. This could happen, for example, if the implementation used removable media or other MIDlet suite storage that might be corrupted.

Devices must recognize the key usage field. When the field is present, the device must verify that it has the digitalSignature bit set.

A device checks expiration and, optionally, revocation of certificates supplied in the application descriptor during the authorization procedure. A device can check for certificate expiration locally because it can get the information from the certificate itself. Certificate expiration verification is an intrinsic and mandatory part of certificate path validation.