Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Micro Edition >

Data security in mobile Java applications

Learn how to select and use third-party security toolkits

By Michael Juntao Yuan, JavaWorld.com, 12/20/02

The recent release of MIDP (Mobile Information Device Profile) features a major improvement over version 1.0. Version 2.0 includes enhanced mobile code and application security through a well-defined security manager and provisioning process. On the data and communication security front, MIDP 2.0 makes HTTPS support mandatory. HTTPS is currently the most widely used data security protocol in PersonalJava and J2ME/CDC (Java 2 Platform, Micro Edition/Connected Device Configuration) applications.

Although HTTPS proves sufficient for most of today's Internet commerce applications, future mobile applications demand more flexible, customizable, and better-optimized security schemes. In this article, I discuss the security requirements of future mobile commerce and how third-party J2ME tools can help developers meet those requirements.

I begin by discussing advanced mobile commerce security requirements and why HTTPS alone is not sufficient.

Content-based security

HTTPS, SSL, (Secure Socket Layer), and TLS (Transaction Layer Security) are connection-based security protocols. The basic idea is to secure communication channels and hence, secure everything that passes through those channels. This approach has several problems:

  • Direct connection between client and server must be established: If our application has multiple intermediaries to provide value-added services, multiple HTTPS connections must be piped together. That not only opens potential security holes at connecting nodes, but also creates a public key certificate management nightmare. Figure 1 illustrates an example mobile transaction involving multiple intermediaries.

  • Figure 1. A mobile transaction involving multiple intermediaries

  • All content is encrypted: In some application scenarios, such as broadcasting stock quotes or getting multilevel approval of a transaction, parts of the communication should be open. Yet we still want to verify the authenticity of those quotes and approval signatures. Connection-based security is no use here. Unnecessarily encrypting all content also introduces more processing overhead.
  • HTTPS is inflexible for applications that have special security and performance requirements: It lacks support for custom handshake or key exchange mechanisms. For example, HTTPS does not require clients to authenticate themselves. Another example is that any minor digital certificate-formatting problem causes the entire HTTPS handshake to fail. The developer has no way to specify what errors can be tolerated.


Other connection channel-based security technologies, such as Virtual Private Network (VPN), have similar problems. For future mobile commerce applications, we must secure content rather than channels.

Distributed access control

Mobile applications often interact with multiple backend servers, pull information from them as needed, and assemble personalized displays for users. Each information service provider might have its own user authentication and authorization protocols. It is a major inconvenience for mobile users to sign on to each backend server manually.

1 | 2 | 3 | 4 | 5 |  Next >
Resources