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 (http://jcp.org/en/home/index).
Configurations
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
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.
