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:
o Symmetric key encryption
o Public key encryption
o Digital signatures
o 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.
