Abbreviations

3GPP    Third Generation Partnership Project
JCP    Java Community Process
JNI    Java Native Interface
JSR    Java Specification Request
JVM    Java Virtual Machine
API    Application Programming Interface
AWT    Abstract Windowing Toolkit
CDC    Connected Device Configuration
CLDC    Connected Limited Device Configuration
CVM    C Virtual Machine
GCF    Generic Connection Framework
GUI    Graphical User Interface
HTTP    Hypertext Transfer Protocol
HTTPS    Hypertext Transport Protocol Secure
KVM    Kilobyte Virtual Machine
MExE    Mobile Execution Environment
MID    Mobile Information Device
MIDlet    MIDP Application
MIDP    Mobile Information Device Profile
OEM    Original Equipment Manufacturer
PDA    Personal Digital Assistant
PNG    Portable Network Graphics
RMI    Remote Method Invocation

Java Me

In today’s mobile phones, wireless services using WAP and other micro browsing protocols are available. These techniques, however, depend on more or less constant network availability, and allow only a very limited script-based programming of the devices. On the other hand, personal digital assistants (PDAs) grow more popular as service platforms, one of the reasons being, that they are programmable and open for third party solutions. For a long time, this has been kind of a taboo in the world of mobile phones, as manufacturers have been too afraid of third party programs causing their phones to fail. Furthermore, programming for mobile phones has been possible only using proprietary libraries and code, linking the applications tightly with the rest of the phone software and making them vendor and model specific. Now, there is a solution moving into this space. The solution is called Java Me . Java Me is an implementation of the common Java language, optimized for very limited devices. It could be described as an effort to enable 80% of the functionality of standard Java, using only 20% of the resources.

1. Java environments

The capabilities and needs of different computers, devices and systems are very diverse. To accommodate for this, the Java environments come in several different flavors called editions. They all have different targets but are still part of the same Java family and use the same Java language. Figure 1 below gives an overview of the main current Java environments. The PersonalJava and EmbeddedJava environments are not included, as they are for specific setups only and are being gradually replaced by Java Me environments. Environments within the Java Platform

The differences between the environments are in the virtual machines used, as well as in the classes included. The classes define objects with different sets of functions. These classes are then combined into class libraries or APIs. Each Java edition includes a specific set of APIs. Classes or APIs not found in these editions may be distributed through the Java extension mechanism as optional packages [3]. The Java 2 Standard Edition (J2SE) contains a basic set of APIs, which satisfy the needs for normal home or office computers. Servers normally use the Java 2 Enterprise Edition (J2EE), which adds some APIs necessary for running Internet related business server solutions. The embedded and consumer space ranging from small commodities such as pagers or mobile phones to more powerful appliances like set-top boxes, is covered by the Java Me (Java Me). As the diversity in constraints and limitations on device capabilities is large, Java Me has been designed to be even more flexible than the other editions while at the same time maintaining language compatibility and upward scalability. This is made possible through a concept of Configurations and Profiles (see Figure 2 below), which enables the Java Me platform to fit into different device types without defining a new environment for each setup. A Configuration defines a minimum basis for a family or class of devices, whereas a Profile addresses specific demands of a device category or market segment. The Configurations and Profiles are defined by the Java Community Process (JCP) [4]. The JCP is an open pseudo-standards collaborative organization consisting of Java developers and licensees, and whose charter is to develop and revise Java technology specifications. It was originally created by Sun Microsystems, the inventor of Java, but has evolved into a formalized process overseen by representatives from many organizations across the Java community. Java Me hierarchy

What makes Java optimal for mobile phones, is the so called Java sandbox model, which enables mobile phone vendors to let third party programmers run applications on their handsets without having to worry about the programs crashing their devices, as they would have to with languages like C or C++. An application in a sandbox can access only those resources that reside, or have interfaces inside that specific sandbox. This means, that applications are much more controllable, and in case of an error, can be shut down without harming the rest of the system. As opposed to conventional phone software that needs to be installed at specific service centers, Java Me offers features for dynamically downloading programs to the devices. Bug fixes and updates can thus be installed on the fly. Applications written in the Java programming language are compiled into byte code, which is run by a Java Virtual Machine (JVM). Because the byte code is not directly object or machine code but interpreted by the JVM at runtime, it is operating system and processor independent. This makes it possible for developers to use the same code for more than one platform or device. As writing programs in Java is easy and programmers skilled in the Java language are available, application development should be fast. Programmers must understand, however, that they are not programming for the fast processors and huge memory available in normal desktops. Mobile phones are a very constrained in those matters.

2. Configurations

A Configuration defines the core Java Me runtime environment for a broad category of devices with similar requirements on networking capabilities, memory size and processing power. It defines the capabilities of the java virtual machine and the basic classes that must be implemented, as well as the security and installation features supported. There are currently two Configurations defined: the Connected Device Configuration (CDC) and the more constrained Connected Limited Device Configuration (CLDC). Some target devices and constraints for these configurations are shown in Table 1 below. Table 1 – Overview of Java Me Configurations Configuration Typical Devices Memory requirements Virtual machine Connected Limited Device Configuration Mobile phones, PDAs, two-way pagers • 160KB to 512KB available for the Java runtime KVM Connected Device Configuration residendial gateways, Digital Televisions, set-top boxes, organizers, high-end smart phones and communicators

• 512KB minimum ROM

• 256KB minimum RAM CVM

Fundamentally, a Configuration specifies the lowest common denominator in terms of Java platform features and classes, which developers can expect to always be available in the devices that conform to the configuration. In the actual implementation, the java virtual machine and other features are customized to the underlying host operating system, and may be more advanced than required or include optimizations, as long as the user-level semantics remain the same as defined by the configuration specification. The classes specified in a Java Me Configuration are either a subset of J2SE classes, or specific Java Me classes. The Java Me specific classes are named using the javax.microedition.* namespace according to the java standard extension specification [3]. Although not all classes are inherited from J2SE, a less comprehensive Configuration must be a subset of a more comprehensive, to ensure upward compatibility. Accordingly, as shown in Figure 3 below, the CLDC classes are a subset of those included in the CDC. As a last point, the configuration is only the fundament of the Java environment, and do not i.e. provide components for building a user interface. For most applications, additional features defined in a profile or OEM extension are required. As configurations specify the common ground or bases for Java Me applications, they cannot include any optional features. Any features that are to be optional must be defined in a profile.

2.1. Connected Limited Device Configuration

The Connected Limited Device Configuration (CLDC) [5] is the most basic configuration currently available for the Java Me. It defines a standard, portable minimal Java environment for small, resource-constrained mobile devices. Although applicable to the full range of consumer devices, it focuses on battery-operated appliances with a total memory capacity ranging from as little as 160 to 512 KB. Both 16-bit and 32-bit processors are supported, but no demands are placed on minimum performance. Typical CLDC devices are mobile phones, PDAs and two-way pagers, which have at least occasional connectivity to a network of some kind, often wireless and with limited bandwidth. The Java virtual machine of the CLDC specification is very compact, yet designed to be as compliant as possible with the standard JVM. With a memory budget measured in hundreds of kilobytes, however, some adjustments are needed. Apart from memory issues, also security issues have had influence on the changes made. The main limitations of the CLDC are as follows:

• No support for floating point data types (float and double).

• No support for the Java Native Interface (JNI).

• No Java-level, user-defined class loaders.

• No reflection features.

• No support for thread groups or daemon threads.

• No support for finalization of class instances.

• No weak references.

• Simplified in-device class verification process (see Section 2.1.2)

• Potentially non-compacting garbage collector. (Prior to CLDC version 1.0.2)

• Limitations on error handling.

• Limited debugging interfaces.

Many of the above modifications have been made to compensate for the fact that CLDC does not include a complete set of standard Java libraries nor implement the standard Java security model. The J2SE security model is too memory consuming to be added as such, and has been simplified in CLDC. The absence of floating point data types is due to the fact that most of the CLDC designated devices lack hardware support for floating point operations. Some of these features like floating point operations and improved error handling may be reintroduced in a following CLDC version. The fact that the garbage collector is non-compacting in CLDC versions prior to 1.0.2 means, that subsequent memory allocation and freeing cause the memory to become fragmented. A reference implementation of the CLDC JVM called Kilo VM (KVM) has been provided by Sun, but device manufacturers are free to develop their own, as long as they adhere to the specification.

2.1.1. Generic Connection Framework

Apart from general JVM related modifications, CLDC also simplifies and generalizes some other parts of the standard Java libraries and functionality. One of these generalizations is known as the Generic Connection Framework (GCF). It is an abstract framework for handling all types of connections. The motivation for building a new framework for connections instead of relying on standard Java procedures, is to be able to support a large variety of networking and input/output capabilities using a generic structure, thus making connection handling lighter and easier extendable. The GCF constitutes of a single class and seven predefined connection interfaces with an internal hierarchy as shown in Figure 4 below. With these interfaces, six basic interface types are addressed:

• Basic serial input • Basic serial output

• Datagram oriented communications

• Circuit oriented communications

• Basic connection to a HTTP server

• A notification mechanism for a server application to be informed of client connections

2.1.2. Pre-verification

In Java, all classes must be verified before being executed, in order to confirm that the code inside the classes has correct format and can be interpreted by the JVM without an internal failure. The conventional J2SE class verification is a process that requires a lot of runtime memory and processing power. This is because it uses an iterative dataflow algorithm to verify that class files do not bypass the system types and that they are semantically correct. To be able to verify classes in the resource-constrained environment present in CDLC devices, a new verification process has been defined. The process is called pre-verification, and makes the runtime verification significantly more efficient in memory use as well as required CPU power. Essentially, the efficiency is achieved by reallocating the processing intensive duties to be completed at compile time in a way that does not compromise runtime security. Before a class file is loaded onto a device, it is validated using a pre-verification tool. This tool analyzes each method in the class file, and inserts special attributes, which enable the in-device verifier to confirm type safety by performing only a linear scan of the bytecode. The inserted attributes conform to an extension mechanism of the standard JVM specification and are therefore automatically ignored by conventional class file verifiers. This makes the solution fully compatible with J2SE technology. The extra attributes produce a size increase of approximately 5% compared to ordinary class files. Since the runtime bytecode verification guarantees type safety, even modified or broken classes cannot violate the type system of the JVM and consequently corrupt the memory. The method is secure, because the in-device verifier does not need to be able to trust the added attributes. Missing or faulty verification attributes simply cause the class to be rejected by the verifier. This way, the pre-verification process maintains the strong security of standard Java.

2.2. Connected Device Configuration

The Connected Device Configuration (CDC) [7][8] is aimed at high-end consumer devices with a total memory capacity of at least 2MB and adequate processor capacity. Typical CDC devices are Digital Televisions, car navigations appliances and high-end communicators, which require a more sophisticated set of functionality than that of CLDC. The CDC contains a fully compliant Java virtual machine called CVM and a minimal set of class files needed for system configuration and application installation, such as minimal security features and limited network and file access. Apart from the standard Java connections, the CDC also supports access through the Generic Connection Framework (GCF) defined in CLDC. Protocols supported through the GCF are file and datagram. The CDC is intended to be used together with the Foundation Profile [9], which provides the rest of the basic J2SE classes and libraries with the exception of the Abstract Windowing Toolkit (AWT), which is used to create Graphical User Interfaces (GUIs). For applications that need a GUI, an additional profile must be used. Although the CDC together with the Foundation Profile form an environment fully compatible with J2SE version 1.3, one notable change has been done. To downsize the libraries, most deprecated classes and methods have been removed. The word deprecated is used to denote that the functionality of a class or method has been replaced with a cleaner or more correct one, and that programmers should use the new means provided. The result of the deprecated API removal is, that applications produced with Java versions older than 1.3 are not supported by the CDC and Foundation Profile combination. In the far majority of cases, however, this is not a real problem, as applications are likely to be re-engineered for use in embedded devices. As a standard feature, when compiling software using the J2SE Java compiler, a warning is given if deprecated methods are used. The CDC virtual machine, the CVM has also undergone some optimizations to become suitable for consumer and embedded devices. The optimizations have resulted in a size reduction of approximately 40% compared to the standard JVM, and 17% compared to PersonalJava [7]. Further optimizations include support for executing preloaded bytecode out of ROM, which can provide better startup time and less fragmentation. The code must first be pre-linked using a special tool called JavaCodeCompact.

3. Profiles

In the Java Me hierarchy, Profiles are positioned on top of the Configurations and further detail the set of APIs available for a particular family of consumer devices. A Profile has access to all the classes provided by the underlying Configuration. The definition of a Profile states the minimum configuration to be used, and a profile can also embed another profile within its specification. This makes the Profile the most describing part of Java Me for users and application designers. An application written for a certain profile is portable to any device that implements the profile. Devices can be compliant with more than one profile. Like the configurations, also profiles are defined by the Java Community Process (JCP). Each profile is developed by an expert group, which is formed after the submission of a Java Specification Request (JSR). Although this process is required for official certification, a few proprietary profiles exist, which have been defined outside the JCP by private corporations. Some of the profiles that are available or under development have been listed in Table 2 below along with their basic features. In the following sections, each profile will be presented in brief, grouped by their target configurations.

Profile Features of targeted devices Brief description Base Specification Kitty Hawk Profile N/A Deprecated predecessor to MIDP. Used in some LG Telecom i-book mobile phones. CLDC Sun DoJa Profile N/A Resembles MIDP. Designed by NTT DoCoMo for their i-mode Java phones. Apparently based on KittyHawk. CLDC NTT DoCoMo

Mobile Information Device Profile

• 128 KB non-volatile for MIDP components

• 8 KB nonvolatile memory for persistent data

• 32 KB volatile memory for the Java runtime

• Connectivity to some type of network Profile intended for two-way pagers, mobile phones etc. with possibly intermittent connections limited bandwidth CLDC JSR 37

PDA Profile

• 512 KB total memory (ROM + RAM) available for Java runtime and libraries, and no more than 16 MB Profile for use in any handheld device that serves as Personal Digital Assistant (PDA) CLDC JSR 75

Foundation Profile

• 1 MB minimum ROM

• 512 KB minimum RAM

• Connectivity to some type of network Profile used to extend CDC functionality to the full set of J2SE classes (with the exception of deprecated classes and AWT). CDC JSR 46

Personal Basis Profile

• 2 MB minimum ROM

• 1 MB minimum RAM

• Robust connectivity to some type of network Provides basic GUI functionality needed by commodities like digital televisions and automobile services. Is also intended to be a basis for the Personal Profile. Foundation Profile (CDC) JSR 129

Personal Profile

• 2.5 MB minimum ROM

• 1 MB minimum RAM

• Robust connectivity to some type of network For use in devices that needs a high degree of Web compatibility like the ability to run standard Java applets. Designated as a next generation for current PersonalJava environments. Foundation Profile (CDC) JSR 62

RMI Profile

• 2.5 MB minimum ROM

• 1 MB minimum RAM

• TCP/IP network connectivity Provides RMI capabilities. Foundation Profile (CDC) JSR 66 Game Profile N/A Provides a common ground for developing games on a Java Platform. Foundation Profile (CDC) or J2SE JSR 134

3.1. CLDC Based Profiles

The profiles written for the Connected Limited Device Configuration are generally rather constrained, as they are intended for use in very resource-limited environments. It is important to note, however, that because CLDC uses a subset of CDC classes, any profile written for CLDC will work equally well in CDC.

3.1.1. Mobile Information Device Profile

The Mobile Information Device Profile (MIDP) [10] is currently considered the most important profile for mobile phones. A Mobile Information Device (MID) is the device everybody has in his or her pocket. It can be a mobile phone, a PDA or even a simple two-way pager. Typically, a MID has a relatively small screen and runs on battery power. The MID Profile was defined through the JCP from JSR number 37 by an expert group with members including most major mobile phone and PDA vendors. It details a set of Java APIs that enables development of applications for mobile devices. The main features of MIDP are libraries for building GUIs, basic networking and storage, as well as a model for controlling and installing applications. The applications are called MIDlets and are conceptually similar to Java applets, but very limited. As opposed to applets, MIDlets stay resident in the device after installation and can be reused without subsequent downloading. What makes MIDP particularly interesting is the capability of downloading and installing applications over the air [11].

3.1.2. PDA Profile

The PDA Profile [12] is being defined in a JCP expert group lead by Palm. Other members of the expert group include Sharp, Sony and IBM. The basis for the work is Java Specification Request number 75 submitted in August 2000. It is intended to be used in handheld devices such as PDAs, which are typically battery operated and with a total memory of between 512 KB and 16 MB. Furthermore, the devices are required to have a pointing device, a way of producing character input as well as a display resolution of at least 20000 pixels, which for a square shaped screen would be equivalent to slightly more than 140x140 pixels. The profile should enable a standard way to develop application for PDAs using the Java language. The MIDP, which is currently available for the Palm platform, is considered by the expert group to be too limited for PDAs. The PDA Profile will have persistent storage facilities and a display toolkit suitable for small screens. Unlike the MIDP, the user interface will be based on a subset of the J2SE Abstract Windowing Toolkit (AWT). However, it might include MIDP UI components layered on top of AWT.

3.1.3. KittyHawk Profile

The KittyHawk Profile [15][16] is a predecessor to MIDP. It was developed by Sun as part of a project to integrate Java into mobile phones for the Japanese and Korean markets at a time when MIDP was still in the standardization stage. The name of the profile was apparently chosen to symbolize Japanese and American cooperation by combining the Japanese “Hello Kitty” cartoon with the U.S. hawk emblem. The profile is currently in use in LG Telecom’s i-book (also called p510) phones released in August 2000 [17], but later LG Telecom phones will use MIDP. KittyHawk has a small size (around 200 KB) and an early version the MIDP user interface toolkit. As MIDP is now available, KittyHawk has been deprecated, and is no longer available from Sun.

3.1.4. DoJa Profile

The DoJa Profile [18] a proprietary profile specified by the Japanese mobile operator NTT DoCoMo. It is used in mobile phones that extend the operators data service, called i-mode, with a Java Application Environment called i-appli. The profile resembles MIDP in many ways. Like MIDP, DoJa has support for a persistent storage mechanism, which they call “ScratchPad”, and both Low- and High-level graphics controls. Whereas MIDP version 1.0 only standardizes HTTP, the secure HTTP protocol (HTTPS) being optional, DoJa supports both HTTP and HTTPS. As an additional security measurement, DoJa allows connections only to the same server from which the application was downloaded. The application descriptor files used to download applications for the DoJa environment is also different from the one used with MIDP applications. Other notable differences compared to MIDP are, that DoJa uses the GIF format for images, whereas MIDP supports PNG and that DoJa includes capabilities for playing simple audio encoded using the MIDI standard or the DoCoMo i-Melody format. As the profile is meant for the Japanese market, the default text mode is naturally SJIS. All DoJa specific classes are defined in classes with the namespace com.nttdocomo.*. 3.2. CDC Based Profiles

Profiles for the Connected Device Configuration are targeted at consumer devices, which have enough processing power and memory to handle a little more than the absolute minimum Java setting. Currently all CDC profiles available have been developed through the Java Community Profile (JCP). Many of the profiles use the Foundation Profile as a basis.

3.2.1. Foundation Profile

The Foundation Profile [9][7] serves devices which need a rich network enabled Java environment, but do not require a graphical user interface. It has been developed in close association with the CDC. Work on the profile was started in the late 1999 and the first public review was released in July 2000. The specification was approved in March 2001. Together with CDC, it provides the full set of non-deprecated J2SE version 1.3 classes, with the exception of the Abstract Windowing Toolkit (AWT). Network accessibility of some kind is required for devices that use the Foundation Profile. Apart from all protocols defined by the CDC specification (see 2.2) it adds the HTTP protocol and TCP/IP sockets, both through standard Java implementations and the Generic Connection Framework.

3.2.2. Personal Basis Profile

The Personal Basis Profile [13] will provide basic GUI facilities to network-connected devices with relatively limited resources. It is anticipated that this kind of functionality will be needed by commodities like interactive digital televisions, information kiosks and automobile service appliances. The work on the profile has only just started in June 2001. However, one main objective of the profile is to serve as a basis for the Personal Profile, which has been under development since July 2000. As the expert group developing the profile is able to use information gathered in the Personal Profile specification process, producing the standard may not take as long as usual.

3.2.3. Personal Profile

The Personal Profile [14] is intended for devices with relatively limited resources, but with robust network connectivity. It will build on the Personal Basis Profile by adding high Internet connectivity and web functionality and is designated as a next generation upgrade to the PersonalJava platform, with the specific requirement to be able to directly run applications written for PersonalJava versions 1.1.x and 1.2.x. The profile includes a GUI with special emphasis on web fidelity, and will also be able to run normal Java applets, which are commonly used in web pages.

3.2.4. RMI Profile

The RMI Profile [19] provides the same RMI capabilities as the standard Java RMI package for devices with relatively limited resources. A notable difference to the other profiles is its requirement for a TCP/IP connection. Furthermore, other profiles have rejected RMI as too resource requiring. The JCP expert group handling the standardization released a proposed final draft in January 2001, so final approval can be expected in the near future, however it might not be implemented anytime soon, as the interest seems low.

3.2.5. Game Profile

The Game Profile [20] is targeting high-end consumer devices and desktops to define a set of at least nine functionality areas needed by games. The nine areas include modeling and animation in 2D and 3D, game related network communication, sound and streaming media as well as access to game controllers and other gaming related hardware. It is the intention of the standardizing expert group to collaborate with other expert groups to add the features required. If this fails, the features are to be incorporated in the Game Profile. The goal of the group is to create a standard, which is scalable across devices and provides game developers with a definite set of tools to create games for the Java platform.

4. Security

When working with mobile phones and other devices that are expected to be fail safe, security is very important, especially when applications are to be downloaded dynamically over the air and executed. Care must be taken to insure that no piece of code can damage the functionality of the main system or cause other harm to the user. One of the reasons that mobile phone vendors are so eager to support Java is the strong security enforced. Although the different configurations have differences in security features, some things are common to all Java Me devices. Except for possible implementation bugs, the low-level safety measures discussed below provide a secure environment for Java applications to run. On the system level, the Java Virtual Machine (JVM) ensures that any downloaded Java class is valid. To certify type safety, all classes downloaded to the device are required to pass a verification process before being used. Any class that does not comply is simply disregarded. This prevents malicious or erroneous code from performing operations that could corrupt memory outside the scope of the virtual machine and thus alter the functionality of the device. Furthermore, the JVM makes sure that no system classes can be overridden by applications. By altering system classes, an application could change the security related behavior of the JVM. In the Connected Limited Device Configuration environment, the full fine-grained security model of J2SE is considered to be too inefficient and memory consuming [5]. Therefore, some changes have been made in order to provide adequate security with fewer resources. As described in Section 2.1, the CLDC makes use of a partial bytecode verification system where only part of the code checking is performed at runtime and the rest in an off-device process called pre-verification. Consequently, any J2SE features that could pose a security risk in this context, such as user-defined class loaders and the Java Native Interface (JNI) for accessing native functions, have been removed from the CLDC environment. For application-level security, the CLDC incorporates the J2SE sandbox model. According to this model, each application is run in a closed environment, separated from each other as well as from the rest of the system. The application is only allowed to access resources and interfaces provided inside the sandbox. This way, personal and system information can be kept separate from potentially spurious application code, thus preventing misuse. Unlike the CLDC, the CDC supports most of the J2SE security features, with the exception of features related to code signing and certificates [8]. These features are however included in the Foundation Profile [9], which is normally used together with the CDC.

4.1. Possible threats

As opposed to the static environments of non-programmable mobile devices, the capability to run code written by third parties naturally increases the possibilities for attacks. Although the security features of Java Me provide adequate security, there are a few considerations to be made. One potential problem is related to network connections. Network security is not defined by the configurations, and is therefore under the discretion of the profiles. Because some profiles may include optional security features, the responsibility may ultimately lye on the device manufacturers implementing the profiles. As an example, the secure HTTP protocol is optional in the MIDP version 1.0 environment, making connections over the HTTP protocol potentially insecure. However, many device manufacturers will include the HTTPS protocol in their devices and the next major MIDP specification is likely to make the protocol mandatory. Device specific APIs may further add functionality to let applications dial phone numbers or send SMSs. In this case, it is up to the device manufacturers to ensure that the possibilities cannot be misused. One method (which will be used at least by Siemens) is to ask the user for permission every time such operations are requested by an application. For the applications to be usable, some problems are hard to defend against. One such problem with no real solution has its roots in the fact that the user is likely to be charged for using the network. If the user is billed by transferred data, an application could harm the user by sending or receiving large amounts of data over the network. This activity could go unnoticed by the user. To circumvent this, the devices could offer capabilities to monitor the amount of traffic over a network interface, but placing restrictions on network use could cripple the applications beyond usability. An application could also try to cause a denial of service attack, by performing processor intensive calculations or use up Java resources. This could limit the functionality of the mobile device until the user would stop the application. This is a known problem also in other environments and there is no easy way to defend against it. To limit the probability of receiving malicious code and extend the capabilities to assign different permissions to different applications, future standards should incorporate code signing and certificate handling. This was acknowledged by 3GPP when standardizing CLDC/MIDP as Mobile Execution Environment (MExE) classmark 3 [21]. Another solution could be to use an interface to the Wireless Identification Module (WIM) standardized in WAP, to perform these operations.