Wireless Java Security

Print-friendly Version

By Qusay Mahmoud
Release 1.0
January 2002

The Mobile Information Device Profile (MIDP), which is built on top of the Connected Limited Device Configuration Profile (CLDC), allows you to develop wireless Java applications that can be downloaded over the air from open networks. Once downloaded, they can run on the user's device. Should the user be worried about security issues, such as corrupting the cellular phone, deleting data from the device, or transferring data to a remote server? This article explains wireless Java security issues and solutions.

The Java 2 Standard Edition (J2SE) security mechanisms are not suitable for the CLDC/MIDP mainly due to the memory required by these mechanisms. This article presents a brief overview of the J2SE and applet sandbox security model, then it:

• Discusses the CLDC/MIDP security model
• Explains the CLDC/MIDP sandbox security model
• Explains what compromises have been made to achieve security
• Discusses the Java features that have been eliminated from CLDC/MIDP
• Discusses the difference between the conventional sandbox security model and the CLDC/MIDP sandbox security model
• Provides a brief overview of wireless security and encryption to provide end-to-end security solutions. However, note that cryptography is outside the scope of this article.

Overview of J2SE Security

The Java security model is composed of three layers:

1. The Java language itself
2. The Java compiler and runtime system
3. The SecurityManager

At the language layer, Java achieves its safety in different ways. First, Java strictly defines that all primitive data types are of a specific size, and independent of the machine architecture. Second, pointer arithmetic and forging access to objects cannot be done. Third, Java provides array-bound checking. Therefore, an attempt to index an out-of-bound item of an array will throw an exception. Finally, Java ensures that casting one object to another is a legal operation.

The Java compiler and runtime system security layer provides the necessary features to ensure that the system is not subverted by invalid code. It provides a simple secure environment consisting of the class file verifier, downloading classes and checking libraries at runtime, and an automated garbage collector. In other words, the role of the class file verifier is to ensure that class files do not execute in any way that is not allowed by the JVM¹ specification.

The first two layers ensure that the Java system is not subverted by invalid code, however, they do not provide any mechanism to protect against malicious instructions in a client-server application. The JDK1.0 introduced the SecurityManager class to implement a customized security policy that states what code can and cannot do, that will be installed when executing untrusted code or applets.

The Conventional Sandbox

The three layers are used together to provide a restricted environment known as a sandbox, in which untrusted code or applets can be run. The basic idea of the sandbox is that local code is trusted and can have full access to the underlying file system, and downloaded remote code is untrusted and can access only limited resources provided inside the sandbox. This model is illustrated in Figure 1.

Figure 1: The Conventional Sandbox Security Model

For example, when you visit a homepage with an applet embedded into it, the applet gets downloaded to your machine and runs in the sandbox on your machine. In other words, having applets run in the sandbox means that they cannot read/write local valuable resources (such as your files). Other constraints can be imposed, such as applets cannot establish network connections with hosts other than the ones they are downloaded from. To understand how the SecurityManager works, consider the following snippet of code:

public boolean Operation(Type arg) { SecurityManager sm = System.setSecurityManager(); if (sm != null) { sm.checkOperation(arg); } }

This means when a public method call invokes the system security manager, the system determines whether the operation Operation is allowed. In other words, security managers can be installed by applications, and operations will be checked before they are performed. The SecurityManager class provides several check operations. For example: checkRead, checkDelete, and many others. Please refer to the SecurityManager class for the complete list of operations.

Later releases of Java (e.g. JDK1.1 and above) introduced the concept of signed applets and protection domains. Protection domains are used to provide fine-grained access controls by allowing you to implement security policies that state what permissions you want the code to have. A security policy, which can be defined by the user who wants to run the code, is a text file with several grant clauses. The SecurityManager class is kept in J2SE for backward compatibility. For more information on J2SE security please see Sun's Java Security, which provides documentation and user guides for present and future Java Security APIs.

Security of Wireless Java Applications

The J2SE security mechanisms are not suitable for CLDC/MIDP devices due to the amount of memory required by these mechanisms. Therefore, some compromises have been made when defining the security model for CLDC/MIDP. The guideline followed is to keep things simple. The focus is on two areas: (1) low-level KVM security and (2) application-level security.

Low-level KVM Security

In this area, a MIDP application downloaded to the device and executed by the K Virtual Machine (KVM) must not do any harm to the device in which it is running. This can be guaranteed by the Java class file verifier that ensures that the Java class file cannot contain references to invalid memory locations.

The Class Verifier

In the J2SE Java virtual machine, the class verifier is responsible for rejecting invalid class files. A JVM¹ supporting CLDC must be able to reject invalid class files as well, however, the class verification process is expensive and time consuming; therefore, not ideal for small, resource-constrained devices. The KVM designers decided to move most of the verification work off the device and onto the desktop, where the class files are compiled or onto a server machine from which applications are being downloaded. This step (off-device class verification) is referred to as preverification. The device is simply responsible for running a few checks on the preverified class file to ensure that it was verified and is still valid. The KVM rejects any classes that are either invalid or not preverified. The verification process is shown in Figure 2. Please note, for the sake of clarity, we have omitted the process of JAR'ing and JAD'ing.

Figure 2: The CLDC/MIDP Verification Process

As Figure 2 illustrates, the new class file verification is a two-phase process:

• Pre-verification: The preverify tool is responsible for inlining all subroutines and adding special stack map attributes into class files to facilitate runtime in-device verification. The preverifier inserts special attributes into Java class files. These attributes are ignored by conventional J2SE class file verifier and therefore these class files are still valid J2SE classes. Note that preverified class files with the special attribute are approximately 5% larger than the original, unmodified class files.
• In-device verification: The in-device verification is carried out by the KVM class file verifier, which utilizes the information generated by the preverify tool. The verification process is quite involved, and therefore if you are interested we recommend that you refer to the CLDC Specification.

Application-level Security

The type of security provided by the class verifier is limited to validating that a given Java class is a valid class but not more. Security threats, such as access to external resources (e.g. the file system), infrared devices or network will go unnoticed by the verifier. In J2SE, access to external resources is controlled by the SecurityManager and other Java 2 mechanisms including access controllers and security policies. But as mentioned earlier, this model is too memory-consuming for inclusion in CLDC/MIDP devices. So, now we will see how the new sandbox security model addresses application-level security issues.

The CLDC/MIDP Sandbox

The KVM provides a sandbox security model that is different from the conventional Java sandbox model in the sense that it does not control access through the SecurityManager or security policies. Instead, this sandbox security model (according to the CLDC Specification) means that:

• Java class files are properly verified and they are valid Java classes.
• Only a limited, predefined set of APIs available to the application programmer as discussed later.
• The downloading and management of Java applications on the device takes place at the native code level inside the KVM, and developers are not allowed to override the class loader or define their own.
• Developers cannot download any new libraries containing native functionality or access any native functions that are not part of the Java libraries provided by CLDC and MIDP.

In summary, the sandbox security model defined by the CLDC does not take advantage of a SecurityManager. Wireless Java applications can be run securely in a closed environment (the sandbox) achieved by eliminating features of the Java language that would pose security problems in the absence of the full Java security model. The eliminated features related to security are:

• No Java Native Interface (JNI) : A JVM¹ supporting CLDC does not implement the Java Native Interface (JNI) mainly because of security reasons and implementing JNI is considered expensive given the memory constraints of the CLDC target devices.
• No User-defined class loaders: A JVM¹ supporting CLDC has a built-in class loader that cannot be overridden or replaced by the user. This is mainly for security reasons.
• No support for Reflection: No reflection features are supported, and therefore there is no support for RMI or object serialization.
• No Thread groups or daemon threads: While a JVM¹ supporting CLDC implements multithreading, it will not have support for thread groups or daemon threads. If you want to perform thread operations for groups of threads, collection objects should be used to store the thread objects at the application level.
• No weak references: No application built on a JVM¹ supporting CLDC will require weak references.

For a more detailed list of the features that have been eliminated, please see the article The J2ME Platform: Which APIs come from the J2SE Platform.

Overriding System Classes

One of the CLDC and MIDP requirements is the support for dynamic downloading of Java applications to the KVM. One security hole in the KVM would be exposed if the downloaded applications could override the system classes provided in the package java.* and javax.microedition.*. The KVM, or any other CLDC supporting JVM¹, must ensure that the developer cannot override the classes in these protected system packages. One simple solution to this is to require system classes to always be searched first when performing a class file lookup. The system must also ensure that the developer cannot manipulate the class file lookup order.

Wireless Network Security

The question that may come to mind, what has Java done in term of securing the data traveling over the wireless link. The short answer is this is not a Java security problem.

This is a major problem, however, if and when mobile commerce takes off. Transferring sensitive data (such as personal information or credit card numbers) over wireless links is not a good idea. An interceptor may be able to capture that data, but if the data captured is encrypted then it would be of little use to the interceptor unless the malicious user knows how to decrypt it. Therefore, one solution for this is to use cryptography, which is the science of secrecy and scrambling data. The idea is to encrypt the data before you transfer it over the wireless link. The receiver receives the encrypted data and decrypts it (provided that s/he knows the decryption key). Currently, e-commerce applications are successfully using the Secure Socket Layer (SSL) developed by Netscape. SSL works nicely with e-commerce and hopefully it will be used for m-commerce as well. Cryptography is outside the scope of this article, however, if you are interested in encrypting data over wireless links, I recommend that you take a look at the Bouncy Castle open source project for Lightweight Cryptography APIs for J2ME. A tutorial on Bouncy Castle APIs is Chapter 12 Protecting Network Data of Jonathan Knudsen book on Wireless Java.

Conclusion

The Java platform has already proved that it is safe, reliable, and secure for both distributed systems and downloaded applications (applets) into browsers. The safety of the Java platform is important for protecting mobile devices from malicious code. Wireless Java applications are secure since the Java features that pose security problems have been eliminated from the CLDC/MIDP APIs as discussed in this article.

More Information

• J2ME
• CLDC
• MIDP
• CLDC Next Generation
• MIDP Next Generation
• Java Security
• Java Virtual Machine¹ Specification
• SSL 3.0 Specification
• Bouncy Castle Lightweight Crypto APIs

¹ As used in this document, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.