Java Mobile Edition Security : Configurations, Profiles, and JSRs

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire

Standards Development

Unlike some other mobile platforms, such as Windows Mobile and iPhone, JME is not a full operating system (OS). Rather, it is a collection of standards that defines a runtime and API set. If an operator wants their device to run JME applications, they implement the required standards and verify that their implementation passes the published compatibility tests. The standards abstract or deny access to most of the hardware functionality because JME runs on many different devices, and each of those devices has wildly different capabilities.

New standards are defined through the Java Community Process (JCP), a framework for companies and individuals to work together and define common Java functionality. The process is similar to that used by the IETF and W3C when creating industry standards. Once a standard has been ratified, it is published as a Java Specification Request (JSR). All Java editions, not just Mobile, go through this process. Each JSR includes a reference implementation that can be licensed for a nominal fee. Companies may end up writing their own implementations, especially in the mobile space where memory and speed come at a premium. For example, BlackBerry has its own Java virtual machine (JVM) that can run JME applications and applications that use BlackBerry-specific extensions. The most important point to remember is that every implementation of the standard may vary in quality and behavior. This author has done his best to highlight known differences, but there are so many phones that knowing how each one behaves is impossible. The fractured world of JME implementations poses a sizable security issue when it comes to testing and verifying the security of any application. For truly sensitive applications, security verification may need to be performed on a device-by-device basis.

Configurations, Profiles, and JSRs

Lots of different JSRs make up JME; in fact, even using the term JME is a bit ambiguous because there are so many different ways that blocks of functionality can be put together. Intermixed through all of the standards are a couple of key ones that define configuration and profiles. Configuration standards define the minimum capabilities, such as memory and speed, of a Java device. They are tightly scoped so that they can apply to as many devices as possible, and to the user they are not very valuable on their own. Profiles extend capabilities and add functionality that targets a device for a certain use. The difference between Profiles and Configurations is similar to the difference between kernel mode and user mode. The kernel is general purpose, but only supports raw functionality that is unwieldy and difficult to write applications with. User mode APIs abstract this raw functionality and make it usable. In JME’s case, Connected Limited Device Configuration (CLDC) is the general-purpose configuration for small-memory devices, and Mobile Information Device Profile (MIDP) is the profile that introduces much of the functionality that makes JME devices useful as a mobile device development platform.

All profiles and configurations are defined within JSRs. Additional JSRs will define optional functionality for capabilities that only exist on certain devices (for example, camera or GPS functionality). The term optional JSRs refers to this group. All JSRs can be downloaded for free from the JCP website (


As mentioned earlier, configurations define the minimum capabilities of the Java technology required—for example, the memory footprint and the core class libraries. Modern devices will have more power than the devices that existed when the configuration was defined, and the standards may seem to require too little. But, the common baseline gives mobile developers and manufacturers a profile they can rely upon. Configurations rarely, if ever, define optional features. Therefore, configurations are an easily achievable goal for most devices. If the requirements were too hefty, the configuration wouldn’t be adopted or would be inconsistently implemented. Connected Device Configuration (CDC) and Connected Limited Device Configuration (CLDC) are the two most commonly used JME configurations. CDC is used in devices that have more processing power than those that use CLDC, and it’s very similar to J2SE. Even though mobile devices are much more powerful today, few phones implement CDC. It just doesn’t make sense because so many applications target CLDC.

Most of the time, when mobile developers refer to JME applications, they are referring to the combination of CLDC and MIDP.

CLDC is most commonly used in mobile devices. There are two versions of CLDC: 1.0 (JSR 30) and 1.1 (JSR 139). The two standards are virtually identical, except that 1.1 adds support for floating point and removes support for serialization and reflection. The “Limited” in CLDC’s name is not a misnomer, and the configuration really requires very little from the hardware. Specifically, CLDC mandates that devices must have 160KB of nonvolatile memory, and 32KB of volatile (RAM). Most of the core Java standard library has been removed, and base classes, such as those in java.lang and java.util, have been pared down significantly. The requirements are so limited that CLDC does not even require devices to have screens or network access! This makes sense, though, because CLDC may show up in unexpected places, such as the soda machine in a hotel lobby.

CLDC defines which code the Java virtual machine must support and how code will be loaded. Applications must be bundled into JAR files and contain only valid Java code. Applications may not use reflection or Java native invocation (JNI) to call into libraries or other parts of the system. These restrictions are used to enforce code security and ensure that the device is always running a constrained set of valid Java code.

The CLDC specification does not discuss applications in much depth and instead it delegates application responsibilities to any implemented profiles. Therefore, CLDC does not define many application security features. What CLDC does do is define the basic virtual machine security mechanisms and specifies that the runtime must not load malformed or unverified Java bytecode. The mechanism the runtime uses to enforce this will be addressed later.

Version 1.0 of CLDC is still in widespread use, but lots of newer devices fully support CLDC 1.1. CLDC v1.1 was released in 2003, and the most recent maintenance version was published in 2007.


Profiles define a group of technologies that targets a device for a specific use. Unlike configurations, which are meant to be general, profiles are much more specific and include a lot more functionality. Because profile specifications include so many features, not all of the profile’s functionality must be implemented. Where functionality is optional, it is clearly laid out using standard RFC keywords such as MUST and SHOULD.

Most profiles target one configuration, but they don’t have to. Just remember that when talking about a JME environment, you are almost always talking about a combination of a profile, a configuration, and some optional JSRs.

Mobile Information Device Profile (MIDP)

The majority of JME phones implement some version of MIDP. At publishing time, the most common version is MIDP 2.0 (MIDP2), which was released in 2002 and is deployed widely. MIDP 3.0 (MIDP3) is entering final draft phase and will likely be ratified and start appearing on devices within the next few years. MIDP2 is tied to the CLDC configuration and is never implemented on top of CDC. MIDP2 is defined by JSR-118.

MIDP makes it practical to write mobile applications by providing APIs and standards for graphics, sound, storage, networking, and security. More importantly, MIDP defines the application’s life cycle, the process of installing, updating, and removing applications. MIDP gives developers a reasonable amount of functionality and a path to get their software on to the millions of phones that exist in the marketplace. The application life cycle definition defines a security sandbox model because part of the installation process is helping users determine whether or not they should trust an application.

Profiles may extend configuration hardware requirements, and MIDP2 requires an additional 256KB of nonvolatile memory, 8KB of nonvolatile memory, and 128KB of volatile memory for the Java heap. These may seem like small numbers, but on a mobile device these numbers significantly increase the resources available to application writers.

MIDP applications are known as MIDlets. They can be bundled together into an MIDP suite for easy distribution or to share data. Suites and standalone application do not differ much in their behaviors.

MIDP 2.1

MIDP 2.1 is a small but important update to the MIDP2 specification and resolves many of the ambiguities found in the original MIDP2 specification. Specifically, MIDP 2.1 enables developers to require CLDC 1.1 or 1.0 at installation; requires implementations support HTTP, HTTPS, and Secure Sockets; and defines protection domains that manufacturers can implement. Phones don’t always list themselves as MIDP 2.1 compatible, even though they are, and will simply show as MIDP2 devices.

MIDP 3.0

MIDP 3.0 adds tons of functionality to MIDP and, to accommodate these new features, increases the memory requirements on implemented devices. The specification is much more complex, and most of the security features focus on removing the barriers between applications that made MIDP2 a successful security endeavor. Some of the big changes in MIDP 3.0: not constrained to CLDC or CDC, support for shared libraries (“liblets”), permissions model more similar to J2SE, multiple MIDlet suite signers, and expanded memory capabilities. It will be interesting to see how it plays out in the marketplace, but this author believes that MIDP 3.0 will have a weaker security architecture that is more difficult to model and to understand.

Optional Packages

There are JSRs that define functionality that may not exist on all mobile devices. For example, not all devices have a camera, so implementing the camera JSR might not make sense. Even if the device has a camera, the manufacturer or carrier may not want applications using it and won’t implement the JSR. Like RFCs, some JSRs are only as good as the number of supporters and implementations and some JSRs, such as JSR-0179, the PDA (a.k.a. Contacts) JSR, are so popular that they exist on almost every phone.

Remember that a given device may not implement the same set of JSRs as other devices. Also, individual manufacturers may not completely implement the JSR. When reviewing any device, make sure to check out the manufacturer’s website and keep your eye out for papers that describe how half-hearted a given implementation is. For example, at the time of this writing, Samsung’s file implementation did not support hidden files. These aren’t a security mechanism, but subtle differences such as these make it difficult to have confidence in individual devices.

  •  Programming the Mobile Web : Performance Optimization
  •  Programming the Mobile Web : Testing and Debugging (part 3) - Client-Side Debugging
  •  Programming the Mobile Web : Testing and Debugging (part 2) - Server-Side Debugging & Markup Debugging
  •  Programming the Mobile Web : Testing and Debugging (part 1) - Remote Labs
  •  Windows Phone 7 : Working with Controls and Themes - Adding Transition Effects
  •  Windows Phone 7 : Working with Controls and Themes - Understanding Frame and Page Navigation
  •  Windows Phone 7 : Working with Controls and Themes - Panorama and Pivot Controls
  •  Programming the Mobile Web : Widgets and Offline Webapps - Platforms (part 5) - Windows Mobile & BlackBerry
  •  Programming the Mobile Web : Widgets and Offline Webapps - Platforms (part 4) - Windows Mobile & BlackBerry
  •  Programming the Mobile Web : Widgets and Offline Webapps - Platforms (part 3) - webOS & Android
    Top 10
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
    - Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
    - Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
    - First look: Apple Watch

    - 3 Tips for Maintaining Your Cell Phone Battery (part 1)

    - 3 Tips for Maintaining Your Cell Phone Battery (part 2)
    programming4us programming4us
    Celebrity Style, Fashion Trends, Beauty and Makeup Tips.