Using the PIM API for Java ME, Part 3 - Security Considerations

Print-friendly Version

Mobile handsets such as cellphones typically have an address book to keep track of people we like to stay in touch with, a calendar to keep track of important events, and a to-do list to keep track of items we don't want to forget. This type of personal information is one of the most important functions found in a handset, just second to voice. You can use the PIM API for Java ME to enable your mobile Java applications to read and write to/from the locally stored personal information databases. You can even write synchronizers to keep your handset PIM data in-sync with remote PIM data stores. This article, part 3 of this series on using the PIM API for Java ME, covers security considerations when using the PIM API for Java ME on top of the Mobile Information Device Profile version 2.

Handling personal data has privacy and security implications-no one wants their personal information to be accessed by unauthorized people. Because the PIM API for Java ME provides access to personal and possibly sensitive information, there are security concepts to understand, and considerations to keep in mind, such as the impact to the user experience, the application development, and deployment.

The PIM API for Java ME does not define a security mechanism, but instead uses the underlying platform's security framework. On some platforms, such as the Mobile Information Device Profile (MIDP) version 2, the security framework is based on an authorization model that is based on the concepts of trust, permissions that protect access at the API level, and protection domains that define groupings of related permissions (and their related access and user-interaction policies) that are granted as a group to MIDlet suites that bind to such protection domain. Defined protection domains include the network operator, the handset manufacturer, the identified third party applications, and the unidentified third party applications domains, the latter being the untrusted domain.

While MIDP defines the valid protection domains such as the ones enumerated above, the protection domain policies themselves or how APIs are protected on mobile handsets such as cellphones or smartphones, are typically defined by the network operator. For example, while one particular network operator may allow untrusted applications to open PIM databases only if the user grants permission, another operator may decide to only provide access to trusted/signed MIDlets, while another operator may decide to provide unrestricted access.

In the MIDP authorization model, a trusted application is one that is signed using X.509 PKI certificates, as described later in this article, and for which both its origin and integrity can be verified, and which is bound to one of the valid protection domains listed above. Trusted applications are given access to restricted APIs while avoiding the user prompts that degrade the user experience. Untrusted applications are the converse, and are applications that are unsigned, and which, upon installation, are automatically assigned to the unidentified or untrusted third party protection domain, which either doesn't get access to restricted APIs and/or users are prompted for permission when the application tries to get access to the restricted APIs.

Untrusted applications don't need to request permissions, as by default their access is limited to non-restricted APIs, and/or are always exposed to user permission prompts. Trusted applications must request permission to access restricted APIs. In MIDP version 2, permissions are requested by way of the JAD and/or the JAR Manifest, and granted (or not) by the platform or the user, as dictated by the protection domain when a particular operation is invoked. Note that for signed MIDlets, permissions must be defined in the JAR Manifest alone, or if defined in the JAD file, identical attributes entries must also be included in the JAR Manifest or the application will fail to install. This is done to prevent permissions from being changed without proper authorization. To request permission to use a specific API, the application must include the attributes MIDlet-Permissions and optionally MIDlet-Permissions-Opt, indicating the particular named permissions to request. Note that starting with MIDP3 the use of named permissions won't be allowed in favor of class-based permissions using the J2SE-style java.security.Permission class and sub-classes, where instead of indicating named permissions in the JAD or JAR Manifest, the appropriate permission class names are specified.

The following table, taken from the MIDP 2.0 recommended practices for using the PIM APIs within MIDP 2 JSR 118 security models addendum, summarizes the valid PIM Permissions and Protected APIs:

File	Type File Suffix
Get names for, or open contact lists in read mode: javax.microedition.pim.ContactList.read	openPIMList(PIM.CONTACT_LIST, PIM.READ_ONLY) openPIMList(PIM.CONTACT_LIST, PIM.READ_WRITE) openPIMList(PIM.CONTACT_LIST, PIM.READ_ONLY, java.lang.String) openPIMList(PIM.CONTACT_LIST, PIM.READ_WRITE, java.lang.String) listPIMLists(PIM.CONTACT_LIST)
Open contact lists in write mode: javax.microedition.pim.ContactList.write	openPIMList(PIM.CONTACT_LIST, PIM.WRITE_ONLY) openPIMList(PIM.CONTACT_LIST, PIM.READ_WRITE) openPIMList(PIM.CONTACT_LIST, PIM.WRITE_ONLY, java.lang.String) openPIMList(PIM.CONTACT_LIST, PIM.READ_WRITE, java.lang.String)
Get names for, or open calendar event lists in read mode: javax.microedition.pim.EventList.read	openPIMList(PIM.EVENT_LIST, PIM.READ_ONLY) openPIMList(PIM.EVENT_LIST, PIM.READ_WRITE) openPIMList(PIM.EVENT_LIST, PIM.READ_ONLY, java.lang.String) openPIMList(PIM.EVENT_LIST, PIM.READ_WRITE, java.lang.String) listPIMLists(PIM.EVENT_LIST)
Open calendar events lists in write mode: javax.microedition.pim.EventList.write	openPIMList(PIM.EVENT_LIST, PIM.WRITE_ONLY) openPIMList(PIM.EVENT_LIST, PIM.READ_WRITE) openPIMList(PIM.EVENT_LIST, PIM.WRITE_ONLY, java.lang.String) openPIMList(PIM.EVENT_LIST, PIM.READ_WRITE, java.lang.String)
Get names for, or open to-do lists in read mode: javax.microedition.pim.ToDoList.read	openPIMList(PIM.TODO_LIST, PIM.READ_ONLY) openPIMList(PIM.TODO_LIST, PIM.READ_WRITE) openPIMList(PIM.TODO_LIST, PIM.READ_ONLY, java.lang.String) openPIMList(PIM.TODO_LIST, PIM.READ_WRITE, java.lang.String) listPIMLists(PIM.TODO_LIST)
Open to-do lists in write mode: javax.microedition.pim.ToDoList.write	openPIMList(PIM.TODO_LIST, PIM.WRITE_ONLY) openPIMList(PIM.TODO_LIST, PIM.READ_WRITE) openPIMList(PIM.TODO_LIST, PIM.WRITE_ONLY, java.lang.String) openPIMList(PIM.TODO_LIST, PIM.READ_WRITE, java.lang.String)

Note that all the above methods are from the PIM class.

In summary, getting the names of, or opening a PIM list in read mode, requires read permissions to be requested via the JAD or JAR Manifest file. To open the list in write mode requires the write permissions to be requested. To open a list in read-write mode requires both read and write permissions to be requested.

Attempting to access PIM resources without the proper permission will result in a java.lang.SecurityException being thrown.

The following code snippet shows how to request EventList read-and-write permissions in the JAD or JAR Manifest file:

MIDlet-Permissions: javax.microedition.pim.EventList.read, javax.microedition.pim.EventList.write

As previously mentioned, for signed MIDlets, permissions must be defined in the JAR Manifest alone, or in both the JAD file and the JAR Manifest, to prevent permissions from being changed without proper authorization.

Once the appropriate permissions have been requested as shown above, the application can use the PIM API, as illustrated in the following code snippet, which is attempting to open the default event list:

:
EventList el = null;
try {
    // Open the event list
    el = (EventList) pim.openPIMList(PIM.EVENT_LIST, PIM.READ_WRITE);
    :

} catch (SecurityException se) {
    ... // Access to PIM API was denied
} catch (PIMException pe) {
    ... // PIM list type not supported, or other error while calling the API
} finally {
    if (el != null) {
        try {
            // Close the event list.
            el.close();
        } catch (PIMException ignore) {
            // ignore
        }
    }
}

Note how the above code snippet performs a try/catch for PIMException and SecurityException. The latter should not happen if the application is properly signed and permissions are properly requested.

Next, let's briefly describe the major steps for signing a MIDlet suite. Signing a MIDlet is a four step process. Note that the low-level details of how to generate the digital certificates and signatures are outside the scope of this article:

1. Create the RSA X.509 (version 3) Signing Certificates that correspond to the root certificate in your handset, which are used to authenticate the MIDlet suite
   
   
2. Generate the MIDlet suite JAR file RSA SHA-1 signature, which is used to verify the integrity of the JAR
   
   
3. Insert the X.509 Certificates into the JAD file using base64 encoding by adding one or more MIDlet-Certificate JAD attributes as appropriate
   
   
4. Insert the JAR RSA SHA-1 digital signature into the JAD file using base64 encoding by adding a MIDlet-Jar-RSA-SHA1 JAD attribute

Once the MIDlet suite is properly signed, and has been authenticated and verified during provisioning and installation, it is considered a trusted application. By properly requesting permissions, it not only gives the MIDlet suite access to restricted APIs, but also enhances the user experience by avoiding user permission prompts.

• PDA Optional Packages for the J2ME Platform
• Sun Java Wireless Toolkit
• Internet Mail Consortium Personal Data Interchange vCard and vCalendar web site

Many thanks to Kevin Lym, Vasily Isaenko, and Alexander Glasman for all their feedback and helping improve this article.

C. Enrique Ortiz is a mobile technologist, software architect and developer, and a writer and blogger. He has been author or co-author of many publications, and is an active participant in the Java mobility community and in various Java ME Expert Groups. Enrique holds a B.S. in Computer Science from the University of Puerto Rico and has more than 17 years of software engineering, product development, and management experience.