One way to avoid such fragmentation yet still take advantage of native performance is to develop standard J2ME cryptography API specifications and allow device vendors to plug in their own implementations. The CDC/FP/PP device vendors can implement native JCE providers. However, at the time of this writing, no MIDP compatible lightweight crypto API JSR (Java Specification Request) is being developed in the Java Community Process.
Overview of examples
The sample applications accompanying this article illustrate how to incorporate cryptographic functionalities into your application. They demonstrate how to use symmetric key encryption, public key encryption, digital signature, and password-based encryption. However, due to space limitations, I only discuss the source code for digital signature.
The zip archive, which you can download from Resources, contains three sample applications—each demonstrates API usage of a crypto package (Bouncy Castle, Phaos, and Neo for Java). Inside each sample application, the most important class is CryptoEngine, which stores keys and provides thin wrappers over API methods. CryptoEngine sports a monolithic single class design not optimized for code reuse. Do not consider it a best-practice example. Instead, the examples are designed to get you started with working code quickly. Each CryptoEngine method demonstrates a complete application task (for example, to encrypt a message using RSA).
The CryptoEngine's constructor constructs pregenerated keys from files in the JAR's keys/ directory (work/res/keys directory in the build system). CryptoEngine also has methods to support key generation on mobile devices.
All the toolkits used in the sample applications run on both CLDC and CDC platforms. But to evaluate their performance in the most restricted environment, I provided user interface (UI) drivers for MIDP. Those MIDlets are in the MIDlets package. They measure time spent on each task. Classes in directory work/keygensrc pregenerate keys and serialize them to files in directory work/res/keys before MIDP suite packaging.
Building and running the sample applications is easy. You simply change the parameters in the build.xml file to reflect your system settings and run Ant tasks package and run. I bundled Bouncy Castle 1.16 in the BC sample. For other toolkit samples, you must contact vendors to obtain their software and evaluation licenses. You need to un-JAR the toolkit files into the work/classes directory.
Note: Phaos secure number generator
The Phaos MF for CLDC package is not shipped with random generator classes. You must supply your own generator, which implements the com.phaos.micro.crypto.RandomBitsSource interface using secure random facilities provided by the device vendor. For testing purposes, I supplied SecureRandom and SecureRBS classes in my example package com.enterprisej2me.PhaosMobile.security. Class SecureRandom is based on the Bouncy Castle implementation of java.security.SecureRandom, and SecureRBS implements the com.phaos.micro.crypto.RandomBitsSource interface.
Digital signature examples
Digital signature can guarantee message integrity and authenticity in an open network. To generate a signature, you first calculate a hash (also called digest) of your message. Then you encrypt that hash with your private key to generate a signature. The party at the receiving end first decrypts your signature into a hash using your public key. Then she calculates the hash from your message. If the two hashes match, the message is indeed from you and unaltered.
If someone altered the message during its transmission and generated a new hash based on the modified message, public key algorithms guarantee that he cannot produce a matching signature without knowing your private key. The two parties must share four pieces of information: the message itself, its digital signature, hash and signing algorithms, and the public key.
Figure 4 shows the example application's digital signature MIDlet user interface.
