|IBM home | Products & services | Support & downloads | My account|
|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 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
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
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.
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.
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
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
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
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
Several XML security protocols have been proposed to support communication data security in XML applications. Among them are the following:
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.
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.