Featured White Papers

• What Developers Want: The End of Application Redeploys

Sponsored Links

• Career opportunities at Harman- Careers That’ll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

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.