Lightweight Mobile Cryptography Toolkits
To take advantage of advanced security technologies, mobile developers must have programmatic access to cryptographic algorithms. Here we discuss third-party J2ME cryptography toolkits. Those toolkits let us implement flexible solutions meeting the aforementioned requirements. They prove crucial to the Connected Limited Device Configuration (CLDC) MIDP platform because standard CLDC/MIDP does not provide any cryptography APIs. High-end J2ME platforms such as profiles based on CDC (or PersonalJava) can optionally support the java.security package in Java Cryptography Architecture (JCA) but not the javax.crypto package. As a result, crucial security APIs such as encryption/decryption ciphers are missing from all of 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. Here are the general requirements for a toolkit suitable for mobile commerce:
- 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 megabytes of storage space; however, an 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. Therefore, 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 record of accomplishment. In addition, 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.
Bouncy Castle Lightweight API
Get your grade
or your money back
using our Essay Writing Service!
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 as a stand-alone, with minimum dependence on other J2SE classes. The BC 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 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 Rivest-Shamir-Adleman (RSA) encryption is only one-fortieth of what it used to be.
- Because 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.
- Best of all, it is free.
- 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 difficult to learn. Some developer-friendly API features are missing. For example, although BC provides full support for Abstract Syntax Notation.1 (ASN.1), it lacks a set of ready-to-use general-key serialization APIs.
- The community support via mailing list often works well; however, 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 is nearly 1 MB, but 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 postprocessing tools and IDEs (e.g., 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.
However, the ad hoc development model also brings some problems:
Always on Time
Marked to Standard