Data security in mobile Java applications

Learn how to select and use third-party security toolkits

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.

One way to combat this problem is through the use of single sign-on services. Single sign-on servers manage user profiles and provide time-stamped access tokens, such as Kerberos tickets, to authenticated users. Service providers interact with single sign-on servers to validate tokens. Figure 2 illustrates that process. Being a one-to-one protocol, HTTPS is unfit in single sign-on schemes.

Figure 2. Sign-on process involving an authentication server

Single sign-on domains can form alliances and federations. Allied domains recognize tokens from each other. Important single sign-on alliances include Microsoft .Net Passport and Sun Microsystems' Liberty Alliance Project. Figure 3 illustrates the structure of federated single sign-on domains. To integrate into single sign-on service domains, smart mobile clients must be able to handle security tokens. Those tokens are often cryptographic hashes with attached digital signatures.

Figure 3. Federation of single sign-on domains

Device security

Mobile devices are easy to steal or lose. We must prevent nonauthorized personnel from accessing a device's sensitive data. For example, your company's financial data or private keys should not be recovered from a stolen mobile device. On-device information security is one of the most important challenges we face today.

HTTPS does not support on-device information security. Mobile clients are responsible for protecting their own data. Strong passwords usually protect on-device information.

Lightweight mobile cryptography toolkits

To take advantage of advanced security technologies, mobile developers must have programmatic access to cryptographic algorithms. So, throughout the rest of this article, I discuss third-party J2ME cryptography toolkits. Those toolkits let us implement flexible solutions meeting the above requirements.

Those toolkits prove crucial to the CLDC (Connected Limited Device Configuration)/MIDP platform since standard CLDC/MIDP does not provide any cryptography APIs. Higher end J2ME platforms such as profiles based on CDC (or PersonalJava) can optionally support the java.security package in JCA (Java Cryptography Architecture) but not the javax.crypto package. As a result, crucial security APIs such as encryption/decryption ciphers are missing from all these standard profiles. Even for APIs in the java.security package, the bundled JCA provider might not implement the proprietary algorithm we need or have an inefficient implementation. So for high-end J2ME devices, lightweight toolkits also prove essential.

General requirements

A toolkit suitable for mobile commerce must meet some general requirements:

  • Fast: Mobile devices are personal devices that must be responsive. On the other hand, they have slow CPUs, and Java is not known for its raw performance. Handling CPU-intensive cryptography tasks, especially public key algorithms, at an acceptable speed on J2ME devices is a big challenge.
  • Small footprint: Most modern comprehensive cryptography packages consume several MBs of storage space. However, a MIDP phone device might have only 100 KBs of storage space. We must balance features with footprint.
  • Comprehensive algorithm support: A cryptography package's goal is to support flexible security schemes. Such flexibility comes from the ability to choose from a range of algorithms. Important cryptographic algorithms include the following:

    • Symmetric key encryption
    • Public key encryption
    • Digital signatures
    • Password-based encryption
  • Sensible APIs: To support a wide range of algorithms through a consistent interface, cryptography package APIs often have multiple layers of abstractions and complex inheritance structures. However, a complex API will hinder its adoption.
  • Easy key identification and serialization: In a general-purpose cryptography package, keys for different algorithms must be identified and matched properly on both communication ends. The public key pair generation process is often too slow on devices. So, we must pregenerate keys on the server side and then transport keys to devices. The API should provide the means to ease and secure this process.
  • Good reputation: A security solution provider must be trustworthy and have a good track record. Also, no algorithm is secure if the implementation is poorly conceived.
  • Timely bug fixes: Security holes and algorithm weaknesses are discovered frequently around the world. The security solution provider must track this information and provide fixes or patches promptly.
Note: Secure random numbers
Cryptographic algorithms rely on truly random numbers to function securely. Most implementations provide quasi-random number generators based on the current time. To leverage truly random events, such as user typing pattern and battery voltage, secure random number generators should come from the device vendor.

Bouncy Castle lightweight API

Bouncy Castle (BC) started out as a community effort to implement a free, clean-room, open source JCE provider. BC developers developed their own lightweight API (BC lightweight crypto API) to be wrapped in BC JCE provider classes. The BC lightweight API can also be used standalone, with minimum dependence on other J2SE classes.

The Bouncy Castle J2ME download package contains the implementation of the BC lightweight API as well as two core Java classes not supported in J2ME/CLDC: java.math.BigInteger and java.security.SercureRandom.

BC's strength comes from its open source development model:

  • When security holes or bugs are found, they are fixed quickly.
  • BC's flexible API design and community development model allow anyone to contribute new algorithm implementations. BC supports a range of well-known cryptographic algorithms.
  • The BC community is constantly optimizing existing implementations. For example, BC 1.16 has three AES (Advanced Encryption Standard) implementations that provide a range of compromises between speed and memory usage. From BC 1.11 to 1.16, the BigInteger implementation has improved so much that the time needed for RSA (Rivest-Shamir-Adleman) encryption is only one-fortieth of what it used to be.
  • Since BC implements an open source JCE provider, you can look at the BC JCE source code to figure out how to use the lightweight API for various tasks. This provides a powerful learning tool for advanced developers.
  • It is free.

However, the ad hoc development model also brings some problems:

  • Many BC algorithm implementations come straight from textbooks. There are simply too many algorithms and too few volunteer developers to optimize everything. The lack of optimization results in relatively poor performance, especially for some public key algorithms. As of version 1.16, BC public key performance proves sufficient for only high-end phones or PDAs.
  • The BC API design is flexible but quite complex, and beginners find it hard to learn. Some developer-friendly API features are missing. For example, although BC provides full support for ASN.1 (Abstract Syntax Notation.1), it lacks a set of ready-to-use general-key serialization APIs.
  • The community support via mailing list often works well. But there is no guarantee that someone will answer your question, much less in your specified time frame.

To support so many algorithms, BC has a large footprint. The lightweight API jar file itself is nearly 1 MB. However, most mobile applications use only a small subset of BC algorithms. BC's free license terms allow you to pack and redistribute only the classes required in your application. Some J2ME post-processing tools and IDEs (for example, IBM WebSphere Device Developer) can automatically find class dependence and delete unused files from your jar file. Those tools prove handy when you develop with BC.

Note: Obfuscation for BC classes
BC provides clean-room implementations of two Java core language classes not supported in J2ME/CLDC. However, the J2ME code security model dictates that an application should not overload classes in Java core language namespaces. So, if you deploy a BC application directly to a device, it might result in a security exception. A workaround is to obfuscate your byte code. The obfuscation process replaces package, class, variable, and method names to make them shorter and less human-readable. The obfuscated package names will not collide with Java core package names.

Phaos Technology Micro Foundation toolkit

Phaos Technology is a Java and XML security solution provider. It offers toolkits for secure XML Java APIs, J2ME lightweight crypto APIs, and one of the first implementations of the SSL protocol on J2ME/CLDC. In this article, I focus on the Phaos Micro Foundation (MF) lightweight crypto API.

Phaos XML security packages do not currently work with J2ME. However, they are at a leading position to provide future secure Web services tools for mobile applications. Phaos toolkits are available for free evaluation. You must email the company to get a 30-day license key, which comes with tech support.

Phaos is a reputable security company with a good track record. The technical support staff is also very knowledgeable and responsive. All my support questions were answered via email within 24 hours.

The Phaos MF runs on both CLDC and CDC. The CDC version also runs under J2SE. The toolkit footprint is 187 KB for the CLDC version and 169 KB for the CDC version. The Phaos API is intuitive and comes with excellent documentation and code examples.

Phaos MF supports a set of frequently used cryptographic algorithms to strike a balance between performance and features. Those algorithms include symmetric ciphers, such as AES, DES (Data Encryption Standard), RC2, and RC4; PKI (Public Key Infrastructure) ciphers and signature schemes, such as DSA (Digital Signature Algorithm) and RSA; password-based encryption schemes (PBES), such as PKCS (Public Key Cryptography Standard) #5 and PKCS #12. Phaos MF also supports X.509 certificate parsing, ASN.1 encoding, and efficient memory pooling.

1 2 3 4 Page 1