This chapter is from the book
This chapter is from the book
This chapter is from the book
J2ME Security Architecture
The Java 2 Micro Edition (J2ME) is designed to deliver the benefits of Java technology on microdevices and embedded systems with limited constraints on their resources, such as memory size, display size, processing power, network bandwidth, and battery life. The J2ME platform provides the runtime environment and API technologies to support a broad range of consumer electronics, embedded devices, and personal mobile devices such as cellular phones, personal digital assistants (PDAs), TV set-top boxes, telematic systems, electronic appliances, and so forth. J2ME offers a rich graphical user interface, storage, networking, security, and other capabilities that include browsing Web applications and running mobile gaming applications. J2ME is also designed to produce portable code and to establish portability of applications across device groups such as PDAs and smartphones. With its security and portability benefits, today J2ME is widely adopted as a core platform for building customized services on a variety of devices and for running mobile applications.
In general, J2ME is a slimmed-down version of J2SE. To enable J2ME applications to meet the device resource constraints and to run efficiently, many API components have been removed from the core Java platform. Figure 3-3 illustrates the J2ME platform architecture and its elements.
)
Figure 3-3 J2ME platform architecture and core elements
J2ME defines the notion of configurations and profiles to represent the characteristics of supported devices. These configurations and profiles are developed by the industry groups participating in the Java community process.
J2ME Configurations
A J2ME configuration defines Java runtime and API technologies that satisfy the needs of a broad range of devices. Configurations are defined based on the device limitations and the characteristics of memory, display, processing power, network connectivity, and so forth.
The current J2ME specification defines two types of configurations: Connected Device Configuration (CDC) and Connected Limited Device Configuration (CLDC).
CDC
CDC targets high-end consumer devices with TCP/IP network connectivity and higher bandwidth. It requires at least 2Mb memory available for the Java platform. It defines a full-featured JVM that includes all the functionality of a Java runtime environment residing on a standard desktop system. The low-level interfaces for calling native code (JNI), connecting to debuggers (JVMDI), and profiling code (JVMPI) are optional. Vendors may adopt them based on device requirements.
)
Figure 3-4 J2ME platform configuration and profiles
CDC provides a full-featured Java security model and associated mechanisms of a J2SE environment:
- All code runs in a sandbox without exposing the user's system to risk. All classes are loaded with full byte-code verification and Java language features.
- Signed classes verify the integrity and originating source of the Java classes when the JVM attempts to load it.
- Security policy provides fine-grained access control over the resources using a user-defined set of permissions and policies.
- Support for Java cryptography to secure programs, data, communication, and retrieval is provided.
In short, CDC offers all the security benefits leveraging a standard J2SE environment and gives architects and developers the flexibility to use different Java security API capabilities for building secure applications. J2ME runtime implementations built on the CDC may utilize the standard JVM bundled with the J2SE or the Compact Virtual Machine (CVM) depending on the size of the device for which the implementation is being developed.
CLDC
CLDC targets low-end consumer devices, with only 128–512 kilobytes of memory required for the Java platform and running applications. It features a subset of a standard JVM with limited API and supporting libraries.
When compared to the J2SE implementation, J2ME differs as follows:
- Limited security model
- New class verification mechanism
- No user-defined class loaders
- No support for thread groups or daemon threads
- No support for weak references
- Limited error handling
- No finalization
- No reflection support
- New connection framework for networking
CLDC runs on top of Sun's K Virtual Machine (KVM), which is a JVM designed specifically for supporting resource-limited devices. KVM is the core component of the J2ME platform for CLDC devices. CLDC defines two levels of security: Low-level KVM security and application-level security.
Low-level KVM security: An application running in the KVM must not be able to harm the device in any way. Such security is guaranteed by a pre-verification process that rejects invalid class files and ensures that a class does not contain any references to invalid memory locations. The preverify tool is responsible for the verification process, and it inserts some special attributes into the Java class file. After pre-verification, the KVM does an in-device verification process, which ensures that the class is pre-verified. Figure 3-5 illustrates a CLDC verification process.
)
Figure 3-5 Pre-verification process–KVM low-level security
Application-level security: The KVM defines a sandbox model that is quite different from the J2SE sandbox model. The sandbox requires that all Java classes are verified and guaranteed to be valid Java applications. It limits all but a predefined set of APIs from becoming available to the application as required by the CLDC specifications and supporting profiles. The downloading and management of applications take place at the native code level, and application programmers cannot define their own classloader or override the classloader or system classes and associated packages of the KVM. Application programmers also cannot download or add any native libraries that contain code and functionality that are not part of the CLDC supported libraries.
J2ME Profiles
J2ME profiles define a broader set of Java API technologies that are suited to a specific device class or a targeted class of devices. Profiles are built on top of J2ME configurations and define API libraries that enable specific types of applications that are suitable for the target devices. Each J2ME configuration supports one or more J2ME profiles. For the smallest of devices, the Mobile Information Device Profile (MIDP) is one such profile that is built on top of the CLDC configuration. The other class of devices based on CDC configuration use the Foundation Profile. The Foundation profile and its API libraries are based on J2SE 1.3.
Understanding MIDP and MIDlets
MIDP is designed for the family of limited computing devices that have wireless network connectivity and mechanisms for user input and display. The MIDP combined with the CLDC provides the execution environment and application functionality, which includes the user interface, application management, network connectivity, local data storage, and application life-cycle management. The CLDC and MIDP are packaged as a standardized J2ME runtime environment along with the API libraries and are deployed on the native operating system of the device. The OEM-specific classes are provided by the device manufacturer.
A MIDlet is a J2ME application designed to run on a mobile device. In simple terms, a MIDlet is a Java applet, except that it runs on a mobile device rather than in a Web browser. The mobile device provides an Application Management utility that is responsible for installing, executing, and removing MIDlet suites. The Java 2 Micro Edition Wireless Toolkit (J2ME WTK) provides a MIDlet development environment for creating and testing MIDP applications. Aside from the basics of building and packaging MIDlet suites, it includes tools for setting MIDlet security permission attributes, cryptographically signing MIDlet suites, and working with MIDP protection domains. The J2ME toolkit download is available for free from http://java.sun.com/j2me.
A MIDlet suite consists of one or more MIDlets packaged together as a JAR file. A packaged MIDlet will generally consist of compiled and pre-verified Java classes and other files, including images and application-related data. In addition to those files, a manifest file (manifest.mf) is also stored as part of the JAR file. The manifest file stores the MIDlet name, version, and MIDlet vendor-specific attributes. When running the JAR utility, it is important to use the -m option along with the manifest file in the arguments. Example 3-31 shows a manifest file.
Example 3-31. MIDlet JAR–manifest file
MIDlet-1: SecMidlet, /icons/csp.png, com.csp.SecMidlet MMIDlet-Description: Example Manifest file illustration MIDlet-Name: Example Secure Midlet MIDlet-Permissions: MIDlet-Vendor: Coresecuritypatterns.com MIDlet-Version: 2.0 MicroEdition-Configuration: CLDC-1.0 MicroEdition-Profile: MIDP-2.0
In addition to a JAR file, a Java Application Descriptor (JAD) file is also required to be available as part of the MIDlet suite to provide information about the MIDlet(s) bundled in the JAR file. The JAD file provides information to the mobile device's application manager about the contents of the JAR file and also provides a way to pass parameters required by the MIDlet(s). The application manager requires that the JAD file have an extension of .jad. Example 3-32 shows an example of a JAD file.
Example 3-32. JAD file
MIDlet-1: SecMidlet,/icons/csp.png, com.csp.SecureMidlet MMIDlet-Description: Example Manifest file illustration MIDlet-Jar-URL: SecureMidlet.jar MIDlet-Name: Example Secure Midlet MIDlet-Permissions: MIDlet-Vendor: Coresecuritypatterns.com MIDlet-Version: 2.0 MicroEdition-Configuration: CLDC-1.0 MicroEdition-Profile: MIDP-2.0 MIDlet-Jar-Size: 19250
Use the ktoolbar GUI tool provided with the J2ME WTK to load the JAD file and the JAR file containing the MIDlet suite from a local filesystem.
MIDlet Security
The MIDP 1.0 specification introduced the basic security feature that restricts all MIDlet suites to operate within a sandbox-based security model. This was primarily done to ensure that MIDlets prevent access to sensitive APIs and functions of devices, and to avoid any risks to the device resources.
The MIDP 2.0 introduced the notion of trusted MIDlets to provide a flexible and consistent security model with access-control mechanisms defined by a domain policy. The device enforces access control on a MIDlet suite as trusted MIDlets in accordance with the defined domain policy. A MIDlet suite is identified as untrusted when the origin and integrity of the MIDlet suite's JAR file cannot be verified and trusted by the device. The MIDP 2.0 also specifies how MIDlet suites can be cryptographically signed so that their authenticity and originating source can be validated.
Trusted MIDlets
The MIDP defines a security model for trusted MIDlets based on a notion referred to as Protection Domains. Each protection domain associates a MIDlet with a set of permissions and related interaction modes, which allows a MIDlet to access the domain based on the permissions granted. A protection domain contains allowed and user permissions.
- The allowed permissions define a set of actions that should be allowed without any user interaction.
- The user permissions define a set of permissions that require explicit user approval. The MIDlet is bound by the protection domain and will allow or deny access to functions after prompting the user and obtaining their permissions.
In the case of user permissions, a MIDlet needs permission at the first time of access and asks the user whether the permission should be granted or denied. The user permission is defined to grant allow or deny permissions to specific API functions with the following three interaction modes.
- Blanket: The MIDlet is valid for every invocation until its permission is revoked by the user or the MIDlet is deleted from the device.
- Session: The MIDlet is valid for every invocation of the MIDlet suite until it terminates. It prompts the user for every initiated session on or before its first invocation.
- Oneshot: The MIDlet is valid for a single invocation of a restricted method and prompts the user on each such invocation.
All user permission has a default interaction mode with an optional set of available interaction modes. These interaction modes are determined by the security policy. A policy consists of the definitions of domains and aliases. Each domain consists of the definition of granted permissions and user permissions. Aliases permit groups of named permissions to be reused in more than one domain and help keep the policy compact. Aliases may only be defined and used within a single policy file.
A domain is defined with a domain identifier and a sequence of permissions. The domain identifier is implementation-specific. Each permission line begins with allowing or denying user permissions and indicates the interaction modes, such as blanket, session, and oneshot for the specified list of permissions that follow. Example 3-33 shows a policy file.
Example 3-33. MIDlet policy file
domain: O="MIDlet Underwriters, Inc.", C=US
allow: javax.microedition.io.HttpConnection
oneshot(oneshot): javax.microedition.io.CommConnection
alias: client_connections
javax.microedition.io.SocketConnection,
javax.microedition.io.SecureConnection,
javax.microedition.io.HttpConnection,
javax.microedition.io.HttpsConnection
domain: O=Acme Wireless, OU=Software Assurance
allow: client_connections
allow: javax.microedition.io.ServerSocketConnection,
javax.microedition.io.UDPDatagramConnection
oneshot(oneshot): javax.microedition.io.CommConnection
domain: allnet
blanket(session): client_connections
oneshot: javax.microedition.io.CommConnection
To request permissions for executing a MIDlet suite, we will make use of attributes such as MIDlet-Permissions and MIDlet-Permissions-opt in a JAD descriptor file that signals a MIDlet suite's dependence on requiring certain permissions. These special JAD attributes represent the MIDlet suite and provide a device at installation time with access control information about which particular operations the MIDlet suite will be attempting. For example, suppose the MIDlet suite will attempt to make an HTTP connection and optionally make socket connections. The attributes in the JAD descriptor file would look like this:
MIDlet-Permissions: javax.microedition.io.Connector.http
MIDlet-Permissions-opt:
javax.microedition.io.Connector.socket
If a device attempts to install a MIDlet suite into a protection domain that doesn't allow the required permissions specified in the MIDlet suite's JAD file, the installation fails automatically. Thus, the trusted MIDlet provides the mechanisms that protect the device from poorly or maliciously written Java code that can render a device inoperable.
Signed MIDlet Suite
Since MIDP 2.0, a MIDlet suite can be cryptographically signed and its authenticity and originating source can be validated as trusted. This is an enhanced security model for MIDP applications, which is handled via digital signatures and PKI support. As with any PKI authentication, it requires zero or more root CA certificates that are used to verify other certificates. Signing a MIDlet suite is quite similar to signing applets that involve a signer and public key certificates. The signer of the MIDlet is responsible for distributing and supporting the MIDlets. The signer needs to have a public key certificate that can be validated by one of the protection domain root certificates on the device. A signed MIDlet suite usually includes a certificate issued by a well-known certificate authority. It is important to note that signing a MIDlet suite isn't useful unless client devices can verify the signature.
From a developer standpoint, signing a MIDlet suite is the process of adding the signer certificates and the digital signature of the JAR file to a JAD file. Signing a MIDlet suite adds new attributes to the JAD file, represented using Base 64 encoded values.
MIDlet-Certificate: <Base64 encoded value of certificate> MIDlet-Jar-RSA-SHA1: <Base64 encoded value of signatures>
The J2ME Wireless Toolkit enables a signer to either sign a MIDlet suite with an existing public and private key pair obtained from a certificate authority or with a new key pair that can be generated as a self-signed certificate for testing purposes only. Each key pair is associated with a certificate. Assigning a security domain to the certificate designates the level of trust that the certificate holder has to access protected APIs and the level of access to those APIs.
The JADTool is a command-line interface provided with the J2ME toolkit for signing MIDlet suites. The JADTool only uses certificates and keys from J2SE keystores, discussed earlier in this chapter. As we discussed previously, the J2SE bundle provides key management tools for managing keystores.
The JADTool utility is packaged in a JAR file. To run it from the command line interface, change your current directory to {j2metoolkit-dir}\bin, and execute the following command:
java –jar JADTool.jar <command-options> <JAD file>
Example 3-34 would add the certificate of the key pair from the given J2SE keystore to the specified JAD file.
Example 3-34. Adding a certificate to a JAD file
java –jar JADTool.jar -addcert -keystore <mykeystore>
-storepass <storepassword> -alias <alias>
-inputjad <input_jadfile>
-outputjad <output_jadfile>
Example 3-35 adds the digital signature of the given JAR file to the specified JAD file.
Example 3-35. Adding a digital signature to a JAD file
java –jar JADTool.jar -addjarsig -jarfile <jarfile>
-keystore <mykeystore> -storepass <storepassword>
-alias <alias>
-inputjad <input_jadfile>
-outputjad <output_jadfile>
Example 3-36 displays a list of certificates in a given JAD file.
Example 3-36. Displaying list of certificates for a given JAD file
java –jar JADTool.jar -showcert
-inputJAD <input_jadfile>
If you don't wish to use the JADTool command-line utility, the J2ME toolkit also provides a GUI-based utility (Ktoolbar) that enables you to complete the entire signing process without having to use the command-line options. Finally, you may also choose to use the Ktoolbar tool to publish and then directly install the MIDlet suite in the device using Over-The-Air (OTA) provisioning techniques commonly adopted in wireless service deployment. The OTA provisioning mechanisms allow deploying applications wirelessly, the same way they send and receive messages or browse the Internet.
The J2ME platform [J2ME] also provides mechanisms for using cryptographic algorithms and securing network communication using SSL/TLS protocols as well as ensuring source authentication, integrity, and confidentiality. This will be discussed in Chapter 4. "Java Extensible Security Architecture and APIs."