Download Java 2 Platform Micro Edition

Java 2 Platform Micro Edition
Peeter Paal
Helsinki University of Technology
Telecommunications Software and Multimedia Laboratory
[email protected]
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 user’s
personal data and sends it to a specified 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, Configuration, Profile,
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 first advantage of the
J2ME first. 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 first, 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.
1
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. file
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. file permissions are represented with the FilePermission class. The default Permission classes are
specified 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 specified security
policy.
Security policy
Represents a system security policy.
Security management tools
JDK consists of tools which can be used to
manage keys and certificates, 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 verification and location based access control management. In the previous version of JDK (JDK 1.1), the applications were
classified 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 specified 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 specified for example in a file, 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
defined by a user. By default, in J2SE the security policy is defined in a specific ASCII
file. The policy file format and location are specified in [1] and a brief example is given in
this section.
The policy file 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 certificates that indicate the signatures that the class has. Each application
class has a corresponding CodeSource class. Each entry in the policy file is specified 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 file permission to the files 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 specified 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 specified 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 file entry
its own ProtectionDomain is created. So all classes which belong to the same policy file
entry, belong to the same ProtectionDomain as well and that ProtectionDoman encloses the
set of permissions which are granted by the corresponding policy file entry. A ProtectionDomain’s implies method can be used to check if the ProtectionDomain has a specified
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 specified
permission.
The AccessController class enforces the specified security policy at runtime. When a user
3
HUT TML 2000
Tik-110.501 Seminar on Network Security
Figure 1: The figure 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 AccessController’s 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 fit 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 first meant to be, the consumer and
embedded systems. J2ME seems to be the first 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 first prototypes have already been
implemented in the mobile device industry. The technology behind the J2ME is a very
4
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 specified and how they
distinguish from each other will be described in the following subsections.
3.1 J2ME Configurations: 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 configurations. Configurations define virtual machines features, Java language features and Java
API classes for each configuration environment. J2ME supported device manufacturers
must implement all the Java platform features which are specified by the corresponding
configuration. To avoid fragmentation, Sun has introduced only two configurations which
are:
5
HUT TML 2000
Tik-110.501 Seminar on Network Security
Figure 3: Relationship between J2ME configurations and Java 2 Standard Edition. [5]
Connected Device Configuration (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 profiles, include the entire Java 2 Platform, Standard Edition
API. The proposed Java API classes for CDC can be found in [4].
Connected, Limited Device Configuration (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
fit 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 specification 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 figure, 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 configurations as
well. Thus, all applications implemented for the CLDC platform can be run in the CDC
platform as well.
3.2 J2ME Profiles
As mentioned in the previous section, due to the large range of devices, the J2ME platform has been split into two configurations. Still, a configuration 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 configuration but it is obvious that a mobile phone application is not expected to run on the washing machine or vice
6
HUT TML 2000
Tik-110.501 Seminar on Network Security
versa. Thus, the J2ME framework provides the concept of a profile to achieve application
environment portability. A profile defines the J2ME environment in the application level,
as a configuration defines the J2ME environment in the virtual machine level. Thus applications are written for a specific profile and profiles are build for a specific configuration.
Both profiles and configurations define a set of Java API classes which can be used by
the applications. A device, that is designed to support a profile or several profiles, agrees
to implement all features and Java API classes which are specified by the profile(s) and
corresponding configuration.
At the current time only one profile is specified, which is the mobile information device
profile (MIDP). The JCP [8] specification 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 file system and twoway networking capabilities. The potential devices which support MID profile could be
e.g. advanced mobile phones and communicators. The MIDP defines 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
Notifies the MIDLet management application
notifyDestroyed ()
that the MIDLet has exceeded to the exit state.
public final void
Notifies 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
Notifies 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 specified 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 profiles, include the entire Java 2
Platform, Standard Edition API. At the current time there are no profile definitions for
the CDC. The CDC itself defines 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 defined in the CDC at all, are represented in Table 3.
Table 3: The J2SE security related packages, which are not defined 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 defined in the RSA Laboratory Technical Note PKCS#1,
and DSA (Digital Signature Algorithm) keys as defined in
NIST’s FIPS-186.
java.security.spec Provides classes and interfaces for key specifications and
algorithm parameter specifications.
The impact of the J2SE security classes which are undefined 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 defined 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 specified Java language features. The Java language features, which are
8
HUT TML 2000
Tik-110.501 Seminar on Network Security
Figure 4: The verification process for the CLDC Java application.
defined in the J2SE but not enabled in the CLDC, are listed in the following sections.
[3, 1]
4.2.1
Bytecode Verifier
The bytecode verifier, which is specified in [2], ensures that the Java bytecode and other
items stored in the Java classfile cannot harm the Java virtual machine. However, this
kind of sophisticated bytecode verifier is too large for the CLDC devices. Therefore, a
more compact and efficient bytecode verification solution has been specified in [3]. The
bytecode verification for a CLDC Java application is done in two phases. The first phase is
executed in the Java 2 Standard Platform or higher environment. The first phase is called
pre-verification. The second phase is executed in the CLDC device. The second phase is
called in-device verification. Both pre-verification and in-device verification are introduced
in the following sections and the whole verification process is illustrated in Fig. 4.
4.2.2
Pre-verification
A pre-verification tool is used for pre-verifing Java class files. The pre-verification tool
removes a specified set of Java bytecodes. The bytecodes, which are removed by the preverification phase, are specified in [3]. The methods, containing these set of bytecodes, are
replaced with semantically equivalent bytecode. After the bytecode replacement phase,
the pre-verification tool inserts a special attribute named stack map into the pre-verified
Java class file. The pre-verified Java class file is still a valid Java 2 Platform class file. The
9
HUT TML 2000
Tik-110.501 Seminar on Network Security
attributes inserted by the pre-verification tool are ignored by the J2SE virtual machines and
so the J2ME CLDC pre-verificated Java class files are fully upward compatible.
4.2.3
In-device Verification
In-device verification is carried out in the CLDC device by the KVM. The KVM bytecode verifier utilizes the information generated by the pre-verification tool. The in-device
verification process is specified 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 definition [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 specification or MIDP specification as well.
4.2.5
User-defined Class Loaders
CLDC does not allow user-defined class loaders. The CLDC uses built-in class loader that
cannot be overridden, replaced or reconfigured by the user. [3]
4.2.6
Other Security Changes
Also the following Java language features, which are defined by the J2SE, have been eliminated in J2ME CLDC in order to achieve the sandbox model [3].
Reflection Features
CLDC does not support java.lang.reflect classes. The java.lang.reflect
package is specified 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 defined 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 profile. Since now, there are no profiles defined 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
6.1.1
Tik-110.501 Seminar on Network Security
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 Verification Model
The J2SE bytecode verification model has been found well working. Bad security bugs
have not occured. However, the J2SE bytecode verifier is too large for the CLDC devices.
It would have been too memory consuming and too low for the CLDC devices. So, new
verification model is created for the CLDC devices. The most interesting question is, if
the in-device verification phase could be cheated. However, the two phase verification
algorithms are very complex and are not discussed in this paper.
7 J2ME Suitability for Mobile Devices
Since now, only one profile, 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 user’s device and bank’s 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 fit to all even in the J2ME level, Sun has split it into
configurations. Since now, two configurations has been specified. 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 profile 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 Specification, Second Edition,
Addison-Wesley, 1999, 496p
<ftp://ftp.javasoft.com/docs/specs/vmspec.2nded.html.zip>
[3] Sun Microsystems, Inc, Connected, Limited Device Configuration, Specification
Version 1.0
<http://java.sun.com/aboutJava/communityprocess/final/jsr030/CLDCSpecification1.0.zip>
[4] Sun Microsystems, Inc, J2ME(TM) Connected Device Configuration, Proposed Final
Draft, 30.08.2000
<http://java.sun.com/aboutJava/communityprocess/first/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 Specification, API Specification, 29.06.1999
<http://www.javasoft.com/products/jdk/1.2/docs/api/index.html>
[7] Sun Microsystems, Inc, Mobile Information Device Profile, JCP Specification,
1.9.2000
<http://java.sun.com/aboutJava/communityprocess/final/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