Browse DevX
Sign up for e-mail newsletters from DevX


Harden Your Wireless Apps with MIDP 2.0 Protection Domains : Page 3

Security has always been central to the MIDP specification, but the new MIDP 2.0 goes well beyond the first version's sandbox method. Find out how to use the new protection domains in 2.0.

Requesting Permissions
A MIDlet may request permissions by declaring them in the application descriptor, using either MIDlet-Permissions or MIDlet-Permissions-Opt. Multiple permissions can be specified and are separated by commas. If a permission is declared in MIDlet-Permissions, then the MIDlet suite must be granted access to a protection domain with this permission.

If the MIDlet cannot gain access to an appropriate protection domain, the installation is aborted. However, if the permission is declared in MIDlet-Permissions-Opt, and the MIDlet suite fails to gain access to an appropriate protection domain, the installation can continue but the suite will not have access to the requested permission. So, if your MIDlet suite depends on having a permission, and cannot operate without it, this permission should be requested in MIDlet-Permissions. If your application can live without a specific permission, but would make use of the feature if access is granted, you should request the permission using MIDlet-Permissions-Opt.

The following is an example of requested permissions in a JAD file. The MIDlet suite is indicating it must have access to HTTP and HTTPS and would like to have access to the PushRegistry, VideoControl.getSnapshot, and SMS. However, if the latter three are denied, the suite can adjust and still provide value to the user.

MIDlet-Permissions: javax.microedition.io.Connector.http,

MIDlet-Permissions-Opt: javax.microedition.io.PushRegistry,
In this example, HTTP and HTTPS are not requested as optional. Because the application has indicated it cannot function without these resources, if the device is unable to grant these permissions on installation, the installation will abort.

Gaining Trusted Status Using X.509 Certificates
Although the MIDP 2.0 specification does not dictate how a MIDlet gains trusted status on a device, it does mandate the support of using X.509 certificates as at least one of the mechanisms. The way this works is a device manufacturer will define a protection domain on the device and bind it to an X.509 root certificate. A MIDlet suite is then signed using public key certificate that validates to the root certificate on the device.

Figure 2. Dialog for Declaring Permissions: Permissions are requested by adding them to the appropriate list. Permissions can be declared as required or optional.
Figure 3. Requesting Network Access: This dialog indicates access to HTTP is required but HTTPS is optional.

Signing may be done by the developer or by another party who is distributing the MIDlet suite. The JAR file of the MIDlet suite is digitally signed using the private certificate key and follows the EMSA-PKCSI-v1_5 encoding method of PKCS #1 version 2.0 standard [RFC 2437]. For a deep dive into this encryption standard take a look at http://www.ietf.org/rfc/rfc2437.txt. The certificate and signature are then added to the application descriptor as attributes. When the application is installed on the device, the signature in the application descriptor is compared to the digital signature of the JAR file. If the two do not match, the installation is aborted.

The device must also validate the certificate(s) against the root certificates that exist on the device. Listing 1 contains examples of a certificate and signature attributes added to a JAD file.

If a MIDlet suite contains X.509 certificate information in the application descriptor, the installer attempts to authenticate the MIDlet suite. If the authentication succeeds, the suite can be trusted and is bound to the appropriate protection domain. However, if the authentication fails, the installation is aborted. MIDlet suites that fail to authenticate cannot even be installed with untrusted status.

Trying It Out
The best way to get a feel for how to set up MIDP 2.0 security is to use the J2ME Wireless Toolkit. There are a number of command line tools involved in getting a MIDlet suite signed with a certificate, key-pair, etc. The toolkit hides most of this complexity and makes the process much easier.

Figure 4. MIDlet Suite Signing Tool: This tool from the J2ME Wireless Toolkit allows a MIDlet suite to be signed using an X.509 certificate.

Start by declaring the permissions you would like your application to acquire. This is done by clicking "Settings" and choosing the "Permissions" tab (see Figure 2). From this window, click "Add" and select the permissions as needed. Figure 3 shows that we absolutely need HTTP and we would like to have HTTPS if we are granted permission.

Next you can try your hand at code signing. The toolkit comes with a key already generated for you, but you can generate other key pairs for testing things out as well. To sign a MIDlet or generate new key pairs, choose "Project | Sign" from the main menu. The dialog shown in Figure 4 will display. Simply click "Sign MIDlet Suite" and the JAR file will be signed and the signature and certificate are added as JAD attributes.

To test the installation process and get a feel for what happens when an application is downloaded over-the-air (OTA), you can run the application in OTA mode from within the wireless toolkit. Select "Project | Run via OTA." The device emulator will appear with an "Install Application" option. Use this to "download" and install your application using the same sequence of events a real device must use to validate and authenticate a MIDlet to a trusted domain.

Thanks for your registration, follow us on our social networks to keep up-to-date