ith MIDP applications streaming into the marketplace, security is becoming more of a concern. What assurance does a user of a MIDP-capable device have that what they download will not harm their device, steal personal information, or unknowingly cost them money? Before MIDP 2.0, application developers were rather restricted as to the potential damage they could do. MIDlets could not share RecordStore data, initiate phone calls, or automatically start in response to network activity. MIDP 2.0, on the other hand, can do all of these things and more.
In this article I’ll discuss how MIDP 2.0 allows developers greater access to data and services on devices while providing security mechanisms to govern how this data is accessed.
Who’s Interested in Security?
Because most MIDP 2.0 devices have some type of network connectivity and the applications can be downloaded over the network, the three parties interested in security are the manufacturer, the carrier, and the user.
The manufacturer is interested in, and responsible for, ensuring installed applications cannot harm the device or access sensitive resources without providing sufficient evidence that the application can be trusted. The carrier is interested in keeping the network secure. Often MIDP applications must go through some type of carrier-specific verification before they can be made available to the public. The user is interested in security because he may have sensitive personal, financial, or business information on the device. Also, because users pay for network data services, knowing when they will be charged money for using these services becomes important as well.
| What You Need |
| You’ll need the Wireless Toolkit 2.1. Download it at http://java.sun.com/products/j2mewtoolkit/download-2_1.html. |
Version 1.0: Security by Isolation
Security has always been a primary focus of MIDP. In MIDP 1.0, however, security is mostly addressed by removing the ability to perform sensitive operations. This is often referred to as the sandbox security model. MIDP 2.0 comes with enhanced security features that open up more capabilities of devices to developers without compromising security. It’s important to understand that writing an application using MIDP 1.0 doesn’t necessarily mean it is less secure than writing the same application using MIDP 2.0. Rather, the difference has more to do with the fact that MIDP 2.0 offers access to a lot more features. Providing access to these features require the device to exercise more security precautions.
A Matter of Trust
Providing greater access to data and services on a device requires a level of trust to be established between the application, the device, and the user. MIDP 2.0 accomplishes this using protection domains. A protection domain defines a collection of Permissions that can be granted to a MIDlet suite. A MIDlet suite is bound to a domain by establishing trusted status. One way to establish trust uses X.509 certificates, which allow a MIDlet suite to be signed using a public key (PKI). This key is then used to authenticate the MIDlet suite with the device upon installation and bind it to an appropriate protection domain.
 | |
| Figure 1. Prompting the user for permission: The first option is granting blanket permission, the second grants oneshot permission. |
MIDP 2.0 identifies two basic security domains: trusted and untrusted. However, vendors may provide additional domains and permissions as needed. The untrusted domain is essentially the sandbox security model of MIDP 1.0. A MIDlet suite granted untrusted status has the least amount of freedom on the device. This is because less is known about the MIDlet suite and the suite did not attempt to establish a higher trust level at installation time.
If a MIDlet suite gains trusted status on a device, the suite is given more freedom as more is known about it, including where it came from and who wrote it. A trusted MIDlet suite is bound to a protection domain at installation time. Each protection domain is associated with a security policy that governs behavior of how permissions are granted. These behaviors are referred to as interaction modes.
Interaction Modes
Interaction modes are divided into two categories: allowed and user. Allowed permissions have established a level of trust between the device and the MIDlet suite sufficient to allow access to the requested resource. If a permission has the allowed interaction mode, the user is not prompted before granting access to the resource.
In user interaction mode the user must explicitly grant access to the MIDlet suite to a protected resource, otherwise no access is provided. Typically, the user is prompted the first time a MIDlet suite attempts to access a protected resource. The user responds to the request by providing one of the following interaction modes as a response. In the case permission is not granted, a java.lang.Security exception is thrown.
blanket | The user grants permission to access the resource for as long as the MIDlet suite remains installed. The user never sees another prompt to grant access to this permission. |
session | The user grants permission to access the resource for as long as the MIDlet suite is running. The user never sees another prompt to grant access to this permission until the suite is exited and restarted. |
oneshot | The user is prompted to grant permission to the resource each time the MIDlet suite attempts to use the resource. |
Figure 1 shows an example of how a user may be prompted to grant access to a resource.
Note that MIDP implementations must provide a way for the user to change or reverse these decisions. This is often provided by the MIDP implementer through a menu option on the device.
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,
javax.microedition.io.Connector.https
MIDlet-Permissions-Opt: javax.microedition.io.PushRegistry,
javax.microedition.media.control.VideoControl.getSnapshot,
javax.wireless.messaging.sms.receive,
javax.wireless.messaging.sms.sendIn 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. |
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.
Detecting Permissions at Runtime
So far, I’ve covered how you go about setting up permissions and authenticating to a valid protection domain. But how do you know when a resource is not available to you? You could just wait and see if a SecurityException is thrown when your code attempts to use the resource. After all, you should be handling this condition gracefully anyway. Or, you could be a bit more proactive and check to see if you have the permission before you attempt to access the protected resource or make a feature available to the user.
The MIDlet class in MIDP 2.0 includes a method checkPermission() that allows you to pass the permission name as a parameter. An int is returned indicating the status of the permission.
Value | Description |
0 | The permission is denied |
1 | The permission is allowed |
-1 | The permission status is unknown |
In some cases, the device may not support an API capable of providing the resource indicated by the permission. An example would be asking for permission to capture photo image input using javax.microedition.media.control.VideoControl.getSnapshot when the device does not support the necessary multimedia APIs to do this. In this case, 0 would be returned, indicating permission has been denied. An unknown status (-1) is returned in the case where a user must be prompted to grant the permission. Where user interaction is concerned, the status of the permission will not be known until the MIDlet attempts to access the resource and the user is prompted, in which case a SecurityException may be thrown.
The security enhancements of MIDP 2.0 provide an environment that breaks MIDP out of the sandbox security model and opens access to some of the more sensitive operations on a device. In some cases, permission must still be granted explicitly by the user. In other cases, such as when a MIDlet suite is signed and can gain trusted status on a device, some sensitive operations can be allowed without any user interaction. You should note, however, that these security precautions are designed to make the manufactures and the carriers more comfortable about running your code.
In order to fully secure your application, you will need to consider how you move data over the network and how you keep it safe on the device and so forth. Much of this is considered to be application-level security and is left as an exercise for the developer.
