Java 2 Platform Micro Edition

Peeter Paal Helsinki University of Technology Telecommunications Software and Multimedia Laboratory opaal@cc.hut.fi

Abstract The third generation mobile devices will provide more and more features and as well, more and more security considerations. Sun Microsystems has announced their platform for such devices: Java 2 Micro Edition. J2ME provides portable application environment for the customer and embedded systems, including mobile devices. A user having a J2ME mobile device can download applications from open network and run them on his/her mobile device. A open network is also untrusted network. What happens if a user downloads a malicious application that reads all the users personal data and sends it to a specied network server. Is this possible in the J2ME environments? This paper represents the new environments and discusses security risks related to them. Keywords: Java 2 Micro Edition (J2ME), Java 2 Security, Conguration, Prole, SecurityManager, Sandbox, CLD, CLDC, MIDP

1 Introduction
Due to the large of range devices, Sun has split the Java 2 Platform in three. Java 2 Micro Edition (J2ME) is the newest edition in the Java 2 family. J2ME is targeted at consumer and embedded systems. The mobile device manufacturers are the rst advantage of the J2ME rst. This paper analyses the J2ME security features and suitability for the mobile devices.

1.1 Structure of this paper

This paper consists of four parts. In the rst, which consists of chapter 2, the basic security concepts of Java 2 Standard Edition platform are discussed. The second part is chapter 3, where the J2ME and its main features are introduced. The third part represents the J2ME security feature changes compared to the J2SE. In the fourth part of the paper the J2ME security and its suitability for mobile devices are analysed. The fourth part consists of chapters 5-7. In the end there is a conclusion chapter, where the results of this paper are summarized.

HUT TML 2000

Tik-110.501 Seminar on Network Security

Table 1: The general elements of Java 2 Platform Security Model. Element Description Real computer system resources Protected computer system resource, e.g. le system and networking. Permission objects The Permission objects represent access rights to the computer system resources. Each protected computer system resource has a corresponding Permission class. E.g. le permissions are represented with the FilePermission class. The default Permission classes are specied in the [1]. ProtectionDomains For each set of classes, whose instances are granted the same set of permissions, their own ProtectionDomain is created. SecurityManager SecurityManager class can be used for backward compatibility. AccessController AccessController enforces specied security policy. Security policy Represents a system security policy. Security management tools JDK consists of tools which can be used to manage keys and certicates, to create security policies and to digitally sign Java archives and verify such signatures.

2 JDK 1.2 Security Architecture

The JDK 1.2 security architecture provides application verication and location based access control management. In the previous version of JDK (JDK 1.1), the applications were classied as trusted or not trusted. The JDK 1.2 security architecture provides more sophisticated methods to manage security. In JDK 1.2 each Java class has a set of access rights to computer system resources based on the signer of the Java class and the location the Java class is fetched from. The access rights are specied by the security policy. The security policy can specify its own set of access rights to each signer and location combination. The security policy itself can be specied for example in a le, database or other information resource. The general elements of JDK 1.2 security architecture are presented in (Table 1).

2.1 Managing Security at the User Level

The J2SE security model includes the concept of security policy. The security policy is dened by a user. By default, in J2SE the security policy is dened in a specic ASCII le. The policy le format and location are specied in [1] and a brief example is given in this section. The policy le consists of the policies as an access control list. The access control list con2

HUT TML 2000

Tik-110.501 Seminar on Network Security

sists of combinations of CodeSource classes and Permission subclasses. A CodeSource class consists of information about the URL where its class was loaded from, and a set of cryptographic certicates that indicate the signatures that the class has. Each application class has a corresponding CodeSource class. Each entry in the policy le is specied in the following format:
grant [SignedBy signer_names] [, CodeBase URL] { permission permission_class_name [ target_name ] [, action] [, SignedBy signer_names]; permission ... };

For example if we grant the code that is signed by Duke and loaded from http://applications.dukecompany.com/ read and write le permission to the les which are under the temp-directory, we specify the entry the following way:
grant codeBase http://applications.dukecompany.com/* signedBy Duke { permission java.io.FilePermission /temp/*, read,write; };

The permission classes are always represented with full Java class name notation. For backward compatibility, the SecurityManager class can be used. The SecurityManager that should be used by the Java Virtual Machine (JVM) is specied on the command-line argument the following way:
java -Djava.security.manager=com.company.security.SecurityManager JavaApplication

In order to use the default SecurityManager, the command-line arguments are given the following way:
java -Djava.security.manager JavaApplication

2.2 Managing Security at the Application Level

At runtime, when an application tries to access a protected computer system resource, the general elements in enforcing specied security policy are AccessController and ProtectionDomains classes. ProtectionDomains enclose a set of Java classes whose instances grant the same set of permissions. In the current implementation of JDK this means that for each policy le entry its own ProtectionDomain is created. So all classes which belong to the same policy le entry, belong to the same ProtectionDomain as well and that ProtectionDoman encloses the set of permissions which are granted by the corresponding policy le entry. A ProtectionDomains implies method can be used to check if the ProtectionDomain has a specied permission. The implies method takes a Permission object as its argument and returns a boolean value, indicating that the ProtectionDomain has or does not have the specied permission. The AccessController class enforces the specied security policy at runtime. When a user

HUT TML 2000

Tik-110.501 Seminar on Network Security

Figure 1: The gure illustrades the execution chain between user application, the management code of a prodected resource and the AccessControllor.

application tries to access a protected resource, the protected resource management code invokes AccessControllers checkPermission method. The checkPermission method takes a Permission object as its argument. The AccessController object checks through the execution stack so that each class in the execution stack must have a permission that implies to the given permission. If each class in the execution stack has a permission that implies to the given permission, the checkPermission method returns normally. If a class which has no permission, that implies to the given permission, is found from the execution stack, an AccessControlException exception is thrown, indicating that the requested access is not allowed. The checkPermission method takes advantage of ProtectionDomains implies method. The execution chain is illustrated in Fig. 1.

3 Java 2 Micro Edition

Understanding that one size does not t all, Sun Microsystems launched summer 1999 the new edition of their Java 2 Platform, Java 2 Micro Edition (J2ME). With the new edition, Java is going to the software environment where it was rst meant to be, the consumer and embedded systems. J2ME seems to be the rst real step toward the embedded systems during the whole Java history. This does not mean that laundry machines are powered by Java in the near future but it might mean that we are running 3rd party Java applications in our mobile phones or PDAs in the following years. The rst prototypes have already been implemented in the mobile device industry. The technology behind the J2ME is a very

HUT TML 2000

Tik-110.501 Seminar on Network Security

Figure 2: Java 2 platform editions and their target devices [5].

small Java virtual machine named KVM and only minimum amount of Java application programming interface (Java API) libraries included it. The letter K, in the J2ME Java virtual machine name, means kilo, indicating that the J2ME runnable environment virtual machine size is measured in tens or hundreds of kilobytes, not in megabytes. This virtual machine is used only in the smallest devices. Nevertheless, a Java virtual machine, that is fully compliant with the J2SE one, is used in devices, which provide more memory and advanced operating system. How these two environments are specied and how they distinguish from each other will be described in the following subsections.

3.1 J2ME Congurations: CDC and CLDC

The Java 2 platform editions and their target devices are illustrated in Fig. 2. Fig. 2 illustrates the large range of different type devices that the J2ME platform covers. Devices like TV set-top boxes, Internet TVs and high-end communicators have a large range of user interface capabilities and memory budgets in range of 2 to 16 megabytes as well. On the other hand devices like simple mobile phones, pagers and personal organizers have very simple user interfaces and low level memory budgets. Due to the large range of different type devices in the J2ME market place, Sun has split the J2ME in congurations. Congurations dene virtual machines features, Java language features and Java API classes for each conguration environment. J2ME supported device manufacturers must implement all the Java platform features which are specied by the corresponding conguration. To avoid fragmentation, Sun has introduced only two congurations which are: 5

HUT TML 2000

Tik-110.501 Seminar on Network Security

Figure 3: Relationship between J2ME congurations and Java 2 Standard Edition. [5]

Connected Device Conguration (CDC) CDC covers all the devices which have a large range of user interface capabilities and the memory budgets in range of 2 to 16 megabytes. Devices like TV set-top boxes, Internet TVs and high-end communicators are served by the CDC. CDC is intended to be used by devices requiring a complete implementation of the Java virtual machine, and an API set that may, via the addition of proles, include the entire Java 2 Platform, Standard Edition API. The proposed Java API classes for CDC can be found in [4]. Connected, Limited Device Conguration (CLDC) CLDC covers the devices which have very simple user interface and low level memory budgets as well. Devices like simple mobile phones, pagers and person organizers are served by the CLDC. The CLDC requires 160 kB to 512 kB of total memory budget. To t Java runnable environment into such small and resource-constrained devices, a lot of cut downs must have been made. The security related cut downs are discussed in later sections. The CLDC specication and Java API classes can be found in [3]. The relationship between CDC, CLDC and Java 2 Standard Edition is illustrated in Fig. 3. As shown in the gure, the main functionality in CDC and CLDC is inherited from the J2SE. All the classes which are inherited from the J2SE are precisely the same or a subsets of the corresponding classes in the J2SE and the classes which are outside the J2SE environment may not use the java.* class names. Thus, upward compatible is achieved between the different editions of Java 2 platforms. All features implemented in the CLDC are also implemented in the CDC to achieve upward compatible between J2ME congurations as well. Thus, all applications implemented for the CLDC platform can be run in the CDC platform as well.

3.2 J2ME Proles

As mentioned in the previous section, due to the large range of devices, the J2ME platform has been split into two congurations. Still, a conguration might cover devices intended to totally different intentions, like mobile phones and washing machines. The mobile phone and washing machine could belong to the same conguration but it is obvious that a mobile phone application is not expected to run on the washing machine or vice

HUT TML 2000

Tik-110.501 Seminar on Network Security

versa. Thus, the J2ME framework provides the concept of a prole to achieve application environment portability. A prole denes the J2ME environment in the application level, as a conguration denes the J2ME environment in the virtual machine level. Thus applications are written for a specic prole and proles are build for a specic conguration. Both proles and congurations dene a set of Java API classes which can be used by the applications. A device, that is designed to support a prole or several proles, agrees to implement all features and Java API classes which are specied by the prole(s) and corresponding conguration. At the current time only one prole is specied, which is the mobile information device prole (MIDP). The JCP [8] specication for the MIDP can be found in [7]. The MIDP is designed to operate on top of the CLDC which have at least e.g. simple le system and twoway networking capabilities. The potential devices which support MID prole could be e.g. advanced mobile phones and communicators. The MIDP denes an application model for the MIDL applications. The MIDL applications are called MIDlets. All MIDlets consists of the main class which extends the javax.microedition.midlet class. The usage of the MIDlet class is quite similiar to the Applet class. The javax.microedition.midlet class methods are represented in Table 2. Table 2: javax.microedition.midlet.MIDlet class methods. Method Description protected MIDLet () Class constructor for subclasses. protected abstract void Signals MIDLet to terminate. A MIDLet destroyApp (boolean should peform all resource releasing methods unconditional) and save persistent data in this method. public final String Gets application properties from the midlet getAppProperty (String application management software. key) public final void Noties the MIDLet management application notifyDestroyed () that the MIDLet has exceeded to the exit state. public final void Noties the MIDLet management application notifyPaused () that the MIDLet has not to be in the active state. protected abstract void Signals the MIDLet to pause and release all pauseApp () shared resources. public final void Noties the MIDLet management application resumeRequested () that the MIDLet is interested in returning to the active state. protected abstract void Signals the MIDLet that it is started and has startApp () entered the active state.

3.3 The main building block of CLDC: K Virtual Machine (KVM)

The KVM is a Java virtual machine that is developed for small, resource-constained devices such as mobile phones, pagers and personal organizers. The KVM implements all the features which are specied by the CLDC. The size of the KVM is just about 40 kilobytes 7

HUT TML 2000

Tik-110.501 Seminar on Network Security

to 80 kilobytes depending on the target platform and the compilation options. The KVM is implemented in the C programming language to allow easy portability to different types of platforms for which a C compiler is available.

4 J2ME Platform Security Changes Compared to J2SE

4.1 CDC Security Changes Compared to J2SE
As mentioned in the previous section, the CDC requires a fully completed Java virtual machine and an API set that may, via the addition of proles, include the entire Java 2 Platform, Standard Edition API. At the current time there are no prole denitions for the CDC. The CDC itself denes the java.security and java.security.cert packages, which are subsets of the corresponding packages in the J2SE. The J2SE security related packages, which are not dened in the CDC at all, are represented in Table 3. Table 3: The J2SE security related packages, which are not dened in the CDC at all. Package Description java.security.acl The classes and interfaces in this package have been superseded by classes in the java.security package. java.security. Provides interfaces for generating RSA (Rivest, Shamir interfaces and Adleman AsymmetricCipher algorithm) keys as dened in the RSA Laboratory Technical Note PKCS#1, and DSA (Digital Signature Algorithm) keys as dened in NISTs FIPS-186. java.security.spec Provides classes and interfaces for key specications and algorithm parameter specications.

The impact of the J2SE security classes which are undened in the CDC is discussed in section 5.

4.2 CLDC Security Changes Compared to J2SE

J2SE provides a very comprehensive security model consisting of the permissions, security policy, protection domains and access controller. Nevertheless, the advanced security model provided by the J2SE is too memory-consuming to be included in CLDC devices. The security model, which is provided in the CLDC devices, is the so called sandbox model. In the sandbox model, the applications are run in a closed environment in which the application can only access not secure-sensitive resources. The sandbox model, which is known from the previous versions of JDK and is widely used by the world wide web browsers, takes advantage of the concept of a security manager. A security manager is called whenever Java application or Java applet tries to access protected resource. The sandbox model that is dened by the CLDC does not take advantage of a security manager. The closed environment, where Java applications can be run securely, is achieved by restricting a specied Java language features. The Java language features, which are 8

HUT TML 2000

Tik-110.501 Seminar on Network Security

Figure 4: The verication process for the CLDC Java application.

dened in the J2SE but not enabled in the CLDC, are listed in the following sections. [3, 1]

4.2.1

Bytecode Verier

The bytecode verier, which is specied in [2], ensures that the Java bytecode and other items stored in the Java classle cannot harm the Java virtual machine. However, this kind of sophisticated bytecode verier is too large for the CLDC devices. Therefore, a more compact and efcient bytecode verication solution has been specied in [3]. The bytecode verication for a CLDC Java application is done in two phases. The rst phase is executed in the Java 2 Standard Platform or higher environment. The rst phase is called pre-verication. The second phase is executed in the CLDC device. The second phase is called in-device verication. Both pre-verication and in-device verication are introduced in the following sections and the whole verication process is illustrated in Fig. 4.

4.2.2

Pre-verication

A pre-verication tool is used for pre-vering Java class les. The pre-verication tool removes a specied set of Java bytecodes. The bytecodes, which are removed by the preverication phase, are specied in [3]. The methods, containing these set of bytecodes, are replaced with semantically equivalent bytecode. After the bytecode replacement phase, the pre-verication tool inserts a special attribute named stack map into the pre-veried Java class le. The pre-veried Java class le is still a valid Java 2 Platform class le. The

HUT TML 2000

Tik-110.501 Seminar on Network Security

attributes inserted by the pre-verication tool are ignored by the J2SE virtual machines and so the J2ME CLDC pre-vericated Java class les are fully upward compatible.

4.2.3

In-device Verication

In-device verication is carried out in the CLDC device by the KVM. The KVM bytecode verier utilizes the information generated by the pre-verication tool. The in-device verication process is specied in [3].

4.2.4

Java Native Interface (JNI)

Java Native Interface (JNI) is not implemented in the CLDC. The implementation would had been too expencive in the CLDC target devices and the native function calls would have been outside the scope of the sandbox model denition [3]. The native function calls can be implemented inside the KVM by the manufacturor but then they are not in the scope of the CLDC specication or MIDP specication as well.

4.2.5

User-dened Class Loaders

CLDC does not allow user-dened class loaders. The CLDC uses built-in class loader that cannot be overridden, replaced or recongured by the user. [3]

4.2.6

Other Security Changes

Also the following Java language features, which are dened by the J2SE, have been eliminated in J2ME CLDC in order to achieve the sandbox model [3]. Reection Features CLDC does not support java.lang.reflect classes. The java.lang.reflect package is specied in [6]. Thread groups and daemon threads CLDC supports neither java.lang.ThreadGroups nor daemon threads. To collect and manage threads in group, one must implement its own thread grouping mechanism. Finalization CLDC does not support java.lang.Object.finalize() method. In the J2SE the java.lang.Object.finalize() method is invoked by the garbage collector when it determines that there are no references to the object [6]. In the J2ME CLDC platform the java.lang.Object.finalize() method is never invoked. Weak references Weak references are not allowed in CLDC platform.

10

HUT TML 2000

Tik-110.501 Seminar on Network Security

5 CDC Security Analysis

5.1 Security Model
CDC provides all the classes which are needed by the JDK 1.2 security architecture. Therefore, the CDC security model is fully compliant with the J2SE one. The problem in the security model is, how users of CDC devices can manage the J2SE security policy. Probably, users do not even known or understand, what a security policy is or how it should be used. A security policy, which is badly managed, makes useless all the security mechanism provided by the environment.

5.2 The Impact of the J2SE Undifened Security Classes

As mentioned in the previous subsection, CDC provides all the classes which are needed by the J2SE security model implementation. However, CDC does not provide all the security features which are provided by J2SE. Sec. 4.1 lists the set of security related Java language API packages, which are not provided by CDC, and mentions as well that the CDC Java language packages java.security and java.security.cert are subsets of the J2SE corresponding packages. The classes, which are not dened in the CDC, provide mainly cryptographical functions. This means that CDC application programmers cannot write progams which utilize cryptographical security mechanisms. Therefore the next question is, how this impacts the security and usability as well. For instance, if a user runs an application that needs to send a credit card number over the untrusted network. How the application can do it without revealing a very security-sensitive information, credit card number, to all network sniffers? Should such a simple application implement all the cryptographical functions itself? Is it possible at all to run highly secure cryptographical algorithms, which are implemented with the pure Java language, in a sensible time? The last question indicates that the cryptographical algorithms are implemented at the native level even in the J2SE platforms and are used just via the Java API. A solution for the questions represented above is that the cryptographical algorithms are provided via a CDC prole. Since now, there are no proles dened for the CDC devices.

6 CLDC Security Analysis

6.1 Sandbox Model
As described in Sec. 4.2, applications in the CLDC devices are run in the sandbox model. The CLDC sandbox model restricts an extensive part of the Java language features which are related to the security sensitive issues. Thus, the application security is achieved by cutting down the Java language features. Of course, this is done to achieve small-size Java virtual machine as well.

11

HUT TML 2000

Tik-110.501 Seminar on Network Security

6.1.1

JNI

The JNI support elimination is obvious. It would be extremely insecure to allow CLDC applications to run their own native code. Also in order to provide application portability, the JNI support should not be provided. The third reason for not provide JNI support is virtual machine size. The JNI implementation would have been increase the size of KVM tremendously.

6.2 CLDC Bytecode Verication Model

The J2SE bytecode verication model has been found well working. Bad security bugs have not occured. However, the J2SE bytecode verier is too large for the CLDC devices. It would have been too memory consuming and too low for the CLDC devices. So, new verication model is created for the CLDC devices. The most interesting question is, if the in-device verication phase could be cheated. However, the two phase verication algorithms are very complex and are not discussed in this paper.

7 J2ME Suitability for Mobile Devices

Since now, only one prole, MIDP, is created for the mobile phones. MIDP provides very restricted application model, named MIDlet, which is quite similar to the Applet application model. Addition to the Applet application model, the MIDlets have permission to open HTTP network connections and store data on the local memory. These two features give much more usability for the MIDlets than Applets have today. For instance a MIDlet game is allowed to save its state to the local memory store while it is stopped. Next time the game is run, it can read its state from the stored data item and a user can continue playing the game at that situation. As mentioned, MIDP provides its applications HTTP network connections. However, MIDP does not provide any methods to secure network connections. For instance, if a bank would like to allow a MIDlet application, which can be used to manage users bank accounts via CLDC device, how the secure-sensitive information is transmitted between the users device and banks server. There are no way to provide such secure information transmission over the network at application level. The secure information transmission can be provided in some level, if the protocol under the HTTP provides security mechanisms. For instance, Wireless Application Protocol (WAP) has its own security layer. But such protocols are out of Java environment scope.

8 Conclusions
Understanding that one size does not t to all even in the J2ME level, Sun has split it into congurations. Since now, two congurations has been specied. CDC is fully compliant with the J2SE platform security model. However, CDC does not provide any cryptographical function. This means that the application can be run secure way in the CDC devices, 12

HUT TML 2000

Tik-110.501 Seminar on Network Security

but they cannot communicate with other world secure way. In the scope of network applications, the elimination of cryptographical classes and functions is a disadvantage. CLDC provides a very restricted security model, a sandbox. The sandbox model is achieved by eliminating Java language features. A prole on top of CLDC, MIDP, provides application framework that is similiar to the Applet framework. MIDP provides simple data storing capabilities and HTTP network connections.

References
[1] Gong, L., Java(TM) 2 Platform Security Architecture, 2.10.1998 <http://java.sun.com/j2se/1.3/docs/guide/security/spec/security-spec.doc.html> [2] Lindholm, T. & Yellin, F., Java(TM) Virtual Machine Specication, Second Edition, Addison-Wesley, 1999, 496p <ftp://ftp.javasoft.com/docs/specs/vmspec.2nded.html.zip> [3] Sun Microsystems, Inc, Connected, Limited Device Conguration, Specication Version 1.0 <http://java.sun.com/aboutJava/communityprocess/nal/jsr030/CLDCSpecication1.0.zip> [4] Sun Microsystems, Inc, J2ME(TM) Connected Device Conguration, Proposed Final Draft, 30.08.2000 <http://java.sun.com/aboutJava/communityprocess/rst/jsr036/j2me-cdc-javadoc.zip> [5] Sun Microsystems, Inc, Java(TM) 2 Platform Micro Edition (J2ME(TM)) Technology for Creating Mobile Devices, White Paper, 19.05.2000 <http://java.sun.com/products/cldc/wp/KVMwp.pdf> [6] Sun Microsystems, Inc, Java(TM) 2 Platform, Standard Edition, v1.2.2 API Specication, API Specication, 29.06.1999 <http://www.javasoft.com/products/jdk/1.2/docs/api/index.html> [7] Sun Microsystems, Inc, Mobile Information Device Prole, JCP Specication, 1.9.2000 <http://java.sun.com/aboutJava/communityprocess/nal/jsr037/MIDPSpec_1_0.zip> [8] Sun Microsystems, Inc, The Java Community Process(SM) Program, Version 2.0, 2.6.2000 <http://java.sun.com/aboutJava/communityprocess/jcp2.html>

13