Securing wireless J2ME

Eavesdrop on this discussion of the current crop of security challenges and solutions for J2ME-based mobile commerce applications. In particular, J2ME developers Michael Yuan and Ju Long focus on the challenges of application development for MIDP, the most commonly used -- and least secure -- of the J2ME profiles. Included is an overview of the advantages of J2ME over thin clients (such as WAP) and native applications, as well as a balanced discussion on both the benefits and shortcomings of J2ME's current and future security framework. Learn more, too, about the emergence of Web services as a dominant component in the Internet topography, and how this new technology may impact your J2ME development strategy.

As mobile commerce becomes less of a buzzword and more of a reality, transaction security is becoming an important concern for mobile users and wireless application developers alike. The overall security of a network is only as strong as its weakest link, and in a mobile-commerce network the weakest link is the client-side device. The interceptable nature of wireless signals and the limited memory and computing power of most handheld devices leaves wireless systems dangerously vulnerable to data theft.

But the client isn't the only weak link in the mobile-commerce network. As Web services technology becomes an increasingly important component of the Internet topography, wireless networks will encounter a whole new set of vulnerabilities. Web services use open communication protocols and run outside the corporate firewall, which poses a very real security threat when these systems are deployed in the enterprise. (See the article sidebar for a definition of Web services.)

Solutions are emerging, albeit slowly. In particular, Web services themselves can be used to provide security solutions. New Web services specifications propose to standardize and integrate leading security solutions (such as Kerberos authentication and authorization, digital certificates, digital signatures, and public/private key encryption) using XML messaging. Interoperable Web services can make those security solutions available to product and service providers as a kind of utility. But even with such promising solutions on the horizon, the choice of development platform will always play a big role in how effectively you can secure your wireless applications and the networks on which they will run.

In this article, we'll focus on both the advantages and the compromises of developing on the Java 2 Platform, Micro Edition (J2ME). We'll start with a brief overview of the basic concepts and benefits of J2ME. Next, we'll closely examine the potential security advantages of J2ME-based applications over other wireless alternatives such as WAP and native applications. We'll explain the current application security models available on the J2ME platform, as well as the platform's suitability to some predictable future trends. As part of this discussion, we'll suggest some potential ways to enhance network and data security for J2ME applications. In closing, we'll summarize the feasibility of developing advanced secure applications for the smallest wireless devices using J2ME technologies. Throughout the article we will focus mostly on both the current and upcoming (2.0) MIDP specification, given that MIDP is the most widely used J2ME profile.

Because Web services promise to play a big role in the evolution of mobile commerce and wireless security, we will discuss the technologies that comprise Web services throughout the article. We will devote some time to exploring the impact of Web services on your J2ME development strategy. We will not, however, go into much depth on this topic. To learn more about the relevance of Web services to wireless application programming and security, see the Resources section.

J2ME basics
The biggest benefit of using the Java platform for wireless device development is that you're able to produce portable code that can run on multiple platforms. But even with this advantage, wireless devices offer a vast range of capabilities in terms of memory, processing power, battery life, display size, and network bandwidth. It would be impossible to port the complete functionalities of an application running on a sophisticated set-top box to a cell phone. Even for similar devices such as PDAs and advanced smart phones, establishing portability between the two often poses a strain to one device and underutilization of the other. Real portability can only be achieved among groups of similar devices. Recognizing that one size does not fit all, J2ME has been carefully designed to strike a balance between portability and usability.

What are Web services?
Web services are self-contained, self-described, dynamically discovered applications with Internet-based interfaces. Web services are driven by remote method calls wrapped in standard, XML-based messages and encoding, such as Simple Object Access Protocol (SOAP). Web services define their programming interfaces using WSDL (Web Services Definition Language) and advertise themselves through UDDI (Universal Description, Discovery, and Integration) registries. Web services communicate with clients and each other over the open Internet through the HTTP protocol. This XML-over-HTTP model works to decouple service interfaces by adding an open, robust, human-readable abstraction layer between them. Web services are loosely coupled, platform-neutral, reusable, distributed software components. The key to their success is open standards and interoperability among service providers.

J2ME is divided into several different configurations and profiles. Configurations contain Java language core libraries for a range of devices. Currently there are two configurations: Connected Device Configuration (CDC) is designed for relatively big and powerful devices such as high-end PDAs, set-top boxes, and network appliances; Connected Limited Device Configuration (CLDC) is designed for small, resource-constrained devices such as cell phones and low-end PDAs. CDC has far more advanced security, mathematical, and I/O functions than does CLDC.

On top of each configuration rest several profiles. Profiles define more advanced, device-specific API libraries, including GUI, networking, and persistent-storage APIs. Each profile has its own runtime environment and is suited for a range of similar devices. Java applications written for a specific profile can be ported across all the hardware/OS platforms supported by that profile. The Mobile Information Device Profile (MIDP) and the and PDA Profile are two of the more significant profiles for the CLDC. The Foundation Profile and the Personal Profile are two important profiles for the CDC.

The Personal Profile is built on top of the Foundation Profile to run on high-end PDAs. The Personal Profile is equipped with a complete Java 2-compatible virtual machine implementation. Personal Profile applications can leverage all the Java 2, Standard Edition (J2SE) domain-based security managers, as well as the extensive set of cryptography and security libraries available for J2SE applications. Overall, the Personal Profile offers mature security solutions that are similar to those for J2SE applications. (To learn more about J2SE security, see the Resources section.)

Implementing secure MIDP applications is much harder, due to the CLDC configuration's limited mathematical functionalities and the scant processing power of many of the underlying devices. MIDP devices are, however, the most widely used wireless devices, so enabling secure applications on those devices is very important. In this article, we'll mainly focus on the security challenges and solutions currently available or in development for MIDP applications.

J2ME vs. WAP
It is our experience that both native apps and J2ME apps have much more to offer than those built under the Wireless Application Protocol (WAP), in terms of both features and security. Whereas WAP is a thin-client development protocol, J2ME is a development platform specifically for smart applications. Regardless of whether the application is built using J2ME or a native technology, smart applications offer the following security advantages over WAP applications:

Without a WAP gateway in the middle, smart applications can provide scalable end-to-end security from the back end to wireless devices. This will become especially important as the back end evolves into a message-driven Web-services framework.
Smart applications can store and process data locally, thereby reducing network traffic. Not only does this conserve precious wireless bandwidth and reduce latency, it reduces the likelihood that crucial information will be intercepted or interrupted (e.g., by denial-of-service attacks).
Smart applications utilize device processing power efficiently. Instead of encrypting everything with the same key strength regardless of needs, rich clients can establish a comprehensive differentiating security policy based on the content.

Because smart applications can do much more than WAP pages, running smart applications does increase the risk of software crashes and/or virus attacks. Next, we will discuss the processing and security advantages of J2ME applications over those of device-native applications.

J2ME vs. native platforms
As we have mentioned, compared with the native platforms, the main strength of the Java platform is that it allows us to write portable applications. The Java platform's portability stems from its execution model. Specifically, it stems from the use of the JVM to process Java bytecode into machine code at runtime, providing a compatibility layer on top of the hardware. The Java platform's execution model also introduces some important security benefits that are lacking in device-native applications. These benefits are as follows:

The JVM verifies all classes in class loaders and ensures that applications do not perform any dangerous operations. Because runtime class verification is computationally expensive for MIDP VMs, MIDP has a special two-step bytecode verification scheme. We'll address this scheme in a later section.
The JVM has a monitoring mechanism to safeguard runtime application errors. A good example is the garbage collector. The JVM can clean up application memory heaps automatically at runtime. This helps to avoid memory leaks, which are the major cause of crashes among native applications.
The JVM can provide a security manager or sandbox for applications. Viruses and other hostile code accidentally downloaded from the Web can pose serious security risks. On the Java platform, entire applications (i.e., JAR files) can be digitally signed. The JVM security manager grants the signed application privileges to access specific APIs (domains) based on the trust level of the signer. We'll discuss domain-based mobile code security in more detail in a later section.

Smart, usability-focused design and the Java platform's built-in execution model give J2ME applications significant performance and security advantages over both WAP and native applications. But J2ME isn't perfect. In the section that follows, we'll examine both the strengths and the weaknesses of J2ME's security framework, particularly as it applies to MIDP applications. We'll start with a look at application security, then move on to discuss network and data security.

Bytecode verification
As we have discussed, the JVM serves to prevent malicious code from entering an enterprise system. The bytecode verification process guarantees that an application cannot access memory spaces or use resources outside of its domain. Bytecode verification also prevents an application from overloading the Java language core libraries, a method that could be used to bypass other application-level security measures.

Due to the high computational overhead of this operation, however, MIDP VMs do not perform complete bytecode verification at runtime. Instead, the application developer must preverify the classes on a development platform or staging area before deploying the application into mobile devices. The pre-verification process optimizes the execution flows, creates stackmaps containing catalogs of instructions in the application, and then adds the stackmaps to the pre-verified class files. At runtime, the MIDP VM does a quick linear scan of the bytecode, matching each valid instruction with a proper stackmap entry.

Because MIDP lacks a complete security model, some J2SE features are disabled in MIDP to minimize potential security risks. For example, to prevent illegal overloading of core classes, MIDP VMs do not allow user-defined class loaders. MIDP also does not support the Java Native Interface (JNI) or reflection. Even with these security measures in place, not all code that passes bytecode verification should be allowed to run. Code signing is the next essential element in J2ME's application security policy.

Code signing
For an excellent example of high-level mobile-code security, we need look no further than Java applets, which use digital signatures and the security sandbox to ensure code safety over the Web. Here's a rough outline of how applet security works:

Prior to transmission, the applet server signs an applet JAR file using its digital certificate.
Upon receipt, the browser-side Java security manager verifies the signature and decides whether the origin and integrity of the application can be trusted.
If the digital signature cannot be verified, the runtime exits with an error. If the signature can be verified, the security manager uses the digital certificate to determine the permission domain for that entity, either by querying the client or by using a table to look up permissions for trusted entities.
Once the verification process has been successfully completed, the application code is delivered to the client.

Note that each permission domain contains a set of rules to access specific APIs. For example, an application from a lesser known source might not be allowed to read/write local storage devices or make arbitrary network connections.

J2ME/CDC-based mobile code can be signed and delivered in the same way as Java applets. In theory, MIDP applications could be secured by the same methods. Due to limited processing power and memory, however, a domain-based security manager is not yet available in the MIDP 1.0 specification. The current MIDP VMs can only provide a minimum security sandbox. For example, a MIDlet suite can only access persistent record stores created by itself.

The upcoming MIDP 2.0 specification will require support for the domain security model, including a domain-based security manager, application code signing, and digital certificate verification functionality. To better support secure mobile code provision, MIDP 2.0 will also formally include an over-the-air (OTA) provisioning specification. The MIDP 2.0 OTA specification describes who has the authority to install and delete wireless applications; what operations must be confirmed by the user versus which ones can be done automatically; what alerts must be presented to the user; and what data is shared when updating applications.

Network and data security
Network and data security can be guaranteed by establishing point-to-point secure connections. Security protocols such as SSL/TLS (Secure Socket Layer/Transport Layer Security -- SSL hereafter) allow us to open secure sockets between Internet hosts. At a connection handshake, SSL utilizes public key algorithms and digital certificates to establish trust between parties that haven't met before and exchange private keys for the current session. SSL parties then use fast private key algorithms to encrypt and decrypt communication data. SSL protocols support authentication, data integrity, and confidentiality. Among electronic commerce applications, SSL-based secure HTTP (HTTPS) has become the standard protocol for transferring sensitive data.

J2SE provides excellent and transparent support for HTTPS in its Generic Connection Framework. All J2ME/CDC applications have access to HTTPS functions, but HTTPS support is not officially required in the MIDP 1.0 specification. Given the obvious importance of HTTPS in mobile commerce, many MIDP device vendors have added support for HTTPS to their own MIDP runtime implementations anyway. Sun Microsystems also added HTTPS support to its J2ME Wireless Toolkit from version 1.0.2 forward. HTTPS support will become an official requirement in the upcoming MIDP 2.0 specification.

Securing content, not connections
Although HTTPS/SSL protocols are popular and powerful, they are designed for the old wired-Internet topography. A number of serious problems can crop up when we begin to apply SSL to the new generation of dynamic wireless applications, as you can see:

Peer groups and subscription-based multicast applications will be a major model for the smart wireless applications of the future. Being a one-to-one protocol, SSL does not support multicast applications very well.
SSL is a point-to-point protocol that secures direct connections between hosts. The emerging Internet topography, however, is based on Web services. As such, it will require multiple intermediaries to help process and deliver XML-based service requests. The need for an end-to-end security solution is on the horizon.
SSL indiscriminately encrypts all data with the same key strength, which can be unnecessary or even undesirable for some applications. The computational overhead for setting up and running SSL connections is simply too high for some wireless applications.

The currently emerging problems with SSL will only become more pressing as the mobile commerce network expands. To resolve these issues, we need an end-to-end security model with flexible encryption schemes to meet a range of different requirements. We need to focus on securing content rather than connections. We'll close this discussion with a look at several up-and-coming content formats, security protocols, and tools for implementing end-to-end wireless security.

The XML advantage
J2ME applications can communicate with back-end servers and each other using XML data formats over the HTTP protocol. Unfortunately, all those extra tags make XML a rather heavy format for the limited wireless bandwidths. Despite this, XML offers some very important advantages. XML is a very robust, human-readable message format. It is also the communication data format of choice for the new generation of open, interoperable Web services. As such, J2ME-powered wireless devices must have the capability to handle XML in order to access the world of Web services. At this point, the advantages of using XML far outweigh its bandwidth overhead.

Supporting XML on MIDP-based applications is difficult due to the limited string functions in CLDC base classes. Fortunately, several third-party, lightweight XML parsers are available for MIDP applications. The kXML package (developed by Enhydra) offers both Simple API for XML (SAX) and limited Document Object Model (DOM) capabilities. Package kXML also contains a special utility, called kSOAP, for parsing SOAP messages for Web services. Built-in lightweight XML parsing support was originally planned for the MIDP 2.0 specification, but the plan has recently changed. The JSR 118 expert group has decided to include XML parsing support in the upcoming JSR 172 J2ME Web Services Specification (see Resources), which will also include XML-based Remote Procedure Call (RPC) APIs for both CDC and CLDC applications.

Secure content through secure XML
XML is our format of choice for data communications between J2ME wireless applications and back-end services. To provide end-to-end security, we need to secure XML documents. For this, we need special XML standards to associate security meta information with individual documents.

Several XML security protocols have been proposed to support communication data security in XML applications. Among them are the following:

Security Assertion Markup Language (SAML) is a protocol to transport authentication and authorization information in an XML message. It could be used to provide single sign-on Web services.
XML digital signatures define how to digitally sign part or all of an XML document to guarantee data integrity. The public key distributed with XML digital signatures can be wrapped in XML Key Management Specification (XKMS) formats.
XML encryption allows applications to encrypt part or all of an XML document using references to pre-agreed symmetric keys.
The Web Services secure XML protocol family (WS-Security), endorsed by IBM and Microsoft, is a complete solution to provide security to Web services. It is based on XML digital signatures, XML encryption, and an authentication and authorization scheme similiar to SAML.

All of the above security protocols can bind to Web services messaging protocols. For example, we can embed a SAML segment in a SOAP message header to authenticate and authorize the access to the requested services. We can also embed an XML Digital Signature segment in a SOAP header to authenticate a credit card number in that message.

Due to the lack of both XML and cryptographic APIs, the current MIDP 1.0 specification does not support secure XML standards. In fact, even MIDP 2.0 will not include generic cryptographic APIs. That leaves developers to rely on third-party libraries (such as the Bouncy Castle lightweight cryptography package) to support secure XML in MIDP applications. JSR 177 proposes APIs for security and trust services using SIM cards for CDC and CLDC devices. Together with SAML or WS-Security, the new APIs could support automatic identification and single sign-on Web services.

Wrap up
Although the terrain is complex, we conclude that J2ME does indeed offer many benefits, including security advantages, over WAP and native application development alternatives. At the high end, the CDC's Personal Profile brings the full power of J2SE to wireless applications, including, in most cases, the ability to implement sophisticated applications with strict security requirements.

The current MIDP 1.0 specification does not provide enough in the way of security APIs. But with the help of third-party libraries and vendor support, we have found that we can use MIDP 1.0 to implement secure applications. Furthermore, and as we have shown, the upcoming MIDP 2.0 spec promises to provide a set of core security APIs that should allow us to create mobile commerce applications with more advanced and flexible security features.

One of the most important factors to consider when developing applications for mobile commerce is how they will fit into the Web services domain. Web services technologies are fast evolving, and with them the entire Internet topography. We have devoted some time to discussing Web services technologies as they apply to J2ME-based application development. We encourage you to further study this topic, starting with some of the references in the Resources section.

Resources

Just getting started with J2ME? Download the J2ME Wireless Toolkit.
To learn more about J2ME, start with the official J2ME Web site.
You might also want to take the J2ME development tutorial, from the developerWorks Java technology zone. (Shari Jones and Steven Gould, June 2001)
To learn more about MIDP, visit the official MIDP Web site.
For a look at what's coming up in MIDP, see the proposed MIDP 2.0 specification.
If you're interested in developing with MIDP, check out "The MIDlets advantage," a developerWorks tutorial on MIDP application development. (John Muchow, March 2002)
Also see Michael Yuan and Ju Long's article "Build database-powered mobile applications on the Java platform." (JavaWorld, January 2002)
The Wireless Java Developer Network is a compendium of J2ME resources.
For up-to-the-minute programming tips and resources, visit the Java security discussion board, from the developerWorks Java technology zone.
Web services will be an important part of your J2ME development efforts in the near future. Start preparing now, with a look at the joint IBM/Microsoft whitepaper, "Security in a Web Services World: A Proposed Architecture and Roadmap." (April 2002)
To learn more about the upcoming J2ME Web Services Specification see the Java Community Process JSR page.
IBM is a leader in the evolution of Web services technology. To stay on top of the latest developments in this area, see the IBM Web services home page.
Also explore the developerWorks Web services zone.
Learn about code signing for wireless applications in the developerWorks Wireless zone's security column "Securing the Air: In code we trust." (Kim Getgen, March 2002)
The Bouncy Castle Crypto API includes a lightweight cryptographic API for CLDC/MIDP.
The kXML parser package supports CLDC/MIDP.
Michael Yuan discusses the importance of XML digital signatures and the digital signature APIs of the Bouncy Castle cryptography package in the upcoming developerWorks article "Securing your J2ME/MIDP apps" (Editor's note: this article is targeted for publication on the developerWorks Java technology zone on June 18, 2002).
JSR 177 Security and Trust Services API for J2ME proposes APIs for security and trust with SIM cards.

About the authors
Michael J. Yuan is a Ph.D. candidate at the University of Texas at Austin. He is interested in using Java technology to facilitate science education and research. You can contact Michael at juntao@mail.utexas.edu.

Ju Long is a Ph.D. candidate at the University of Texas at Austin. She is interested in mobile commerce and using wireless technology in marketing research. You can contact Ju at ju@ruby.bus.utexas.edu.

developerWorks > Wireless | Java technology

About IBM | Privacy | Terms of use | Contact