19.1.3 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 password-based encryption protects on-device information.

19.2 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 chapter, I discuss third-party J2ME cryptography toolkits. Those toolkits let us implement flexible solutions meeting the above requirements.

Those toolkits prove crucial to the mobile phone platform, since standard CLDC and MIDP do 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 might have an inefficient implementation. So, for high-end J2ME devices, lightweight toolkits also prove essential.

19.2.1 General Requirements

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

• Fast: Mobile devices are personal devices that must be responsive. However, 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

  - Password-based encryption

  - Public key encryption

  - Digital signatures

• 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 too 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.

19.3 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 BC (v1.16) J2ME download package contains the implementation of the BC lightweight API as well as two core Java classes not supported in CLDC: java.math.BigInteger and java.security.SecureRandom.

19.3.1 The Power of Open Source

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 wide 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 1/40 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.

19.3.2 Things to Watch Out For

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 highend 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 timeframe.

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.

19.4 The IAIK ME JCE

The Institute for Applied Information Processing and Communications (IAIK) is a leading Java Crypto/Security solution provider based in Austria. It is one of the best known third-party commercial JCE/JCA providers with more than five years of excellent tracking record.

IAIK's J2ME product is its JCE-ME toolkit (v3.0). The single Java binary runs on all J2ME platforms (PersonalJava, CDC, and CLDC) as well as JDK v1.1 or above. It is a free download for evaluation purposes. The IAIK JCE-ME is very small: only 100 KB memory footprint for the fully featured JAR file. The size can be further reduced at packaging/deploy time if you do not need all the features.

The IAIK ME toolkit supports all standard symmetric ciphers (AES, DES, RC2, RC4, and IDEA), message digests (MD and SHA), public key algorithms (RSA and DSA), ASN.1 encoding/decoding, X.509 digital certificates, and key management (key generation, PKC S#8 and #12, and IAIK key stores). However, password-based encryption is only supported through an experimental API as of the v3.0 final release. For J2SE and CDC platforms, IAIK offers alternative OS-native implementations for long integer operations, which could drastically improve performance.

In general, IAIK JCE-ME has good performance. For RSA and DSA algorithms, it outperforms the BC library. However, without native integer enhancements, public key tasks still take seconds on MIDP devices.

19.4.1 Porting Existing JCE Applications

The IAIK API is designed to be similar to the standard JCE but without the complexity of abstract algorithm and abstract provider interfaces. A brief list of IAIK JCE classes and their JDK KCE counterparts are listed in Table 19.1.

For a complete list of IAIK JCE-ME API classes and their corresponding standard JCE classes, please refer to the porting guide distributed with the download package (see "Resources").

19.5 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 chapter, I focus on the Phaos Micro Foundation (MF, v1.2) 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.

19.5.1 The Phaos Micro Foundation

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; and password-based encryption schemes (PBES), such as PKCS #5 and PKCS #12. Phaos MF also supports X.509 certificate parsing, ASN.1 encoding, and efficient memory pooling.

Phaos PBES implementations used in my examples perform worse than their Bouncy Castle and IAIK counterparts. For RSA and DSA algorithms, the Phaos library is better optimized than Bouncy Castle 1.16 and has comparable performance to the IAIK pure Java library.

However, even for IAIK and Phaos, the performance of public algorithms is only barely acceptable for MIDP cell phones. In fact, no matter how much optimization you do, those classic PKI algorithms might just prove too heavy for the smallest devices. Novel algorithms and approaches are needed. NTRU and a startup company called B3 Security provide such solutions.

19.6 NTRU jNeo for Java Toolkit

NTRU PKI algorithms include an encryption algorithm NTRUEncrypt and a signature algorithm NTRUSign, invented and developed by four math professors at Brown University. In my sample programs, NTRU algorithms perform 5 to 30 times faster than other public key algorithms with similar cryptographic strength. NTRU algorithms are published and on their way to becoming IEEE and IETF standards. NTRU patented the algorithms to protect their business interests. NTRU algorithm patents have been licensed by a variety of mobile software, smart card, and DSP (Digital Signal Processor) chip vendors, including Sony and Texas Instruments.

Cryptographic algorithms are scrutinized and improved repeatedly before considered mature and ready for general public adoption. Although NTRU algorithms have been inspected many times by both academic and business worlds, they are still relatively new. Security weaknesses were identified in NTRUEncrypt as late as May 2001. Those weaknesses do not undermine NTRU algorithm fundamentals and have since been fixed. As you should with any critical project, research NTRU security before licensing it.

19.6.1 The jNeo Package

NTRU provides an implementation of its algorithms in a Java package called NTRU jNeo (v2.2) for Java. You must work out an agreement with NTRU before you can evaluate the package. In addition to NTRU public key algorithms, jNeo for Java also includes an implementation of the AES Rijndael symmetric key algorithm. The jNeo package runs on CLDC, CDC, and J2SE platforms. It has a memory footprint of 37 KB without signature key-generation classes, which have a footprint of 35 KB.

The jNeo API is simple and easy to use. In fact, it might be too simplistic. For example, the block encryption method requires users to divide plaintext data into blocks themselves.

Using jNeo, NTRUEncrypt key pairs can be generated quickly from pass phrases. The same pass phrase always produces the same key pair. For that reason, jNeo does not provide a password-based key store facility. NTRUSign keys, however, are slow to generate and require floating-point support. The jNeo package provides a floating-point emulation class, which can support NTRUSign key generation on a CLDC device. But on-device NTRUSign key pair generation takes a long time to complete. Generating and distributing NTRUSign keys from a server computer is a better approach. Fortunately, a signature key can sign thousands of messages before it needs replacement.

19.7 B3 Security

B3 Security is a San Jose, California, startup that specializes in developing new, lightweight security infrastructures that minimize the current overhead associated with PKI. Its flagship products are B3 Tamper Detection and Digital Signature (B3Sig) SDK and B3 End-to-End (B3E2E) Security SDK. Both are available for J2ME (both CDC and CLDC). The B3E2E SDK (still in beta) provides features equivalent to SSL in the PKI world, but with a shorter handshake, faster session key establishment, and less management overhead, especially for pushed messages.

19.7.1 How Does B3 Work?

The B3 digital signature scheme is based on keyed hash (HMAC, or keyed-Hashing for Message AuthentiCation) technology, which has been around for many years and has proven security. B3 uniquely uses HMAC properties instead of more computationally intensive public key algorithms, such as large integer factoring, to form a B3 tamper-proof block of bytes and digital signature. In a mobile enterprise application setting, it works like so:

• In its preferred operation mode, the B3Sig SDK uses two pairs of shared and non-shared secrets. Analogous to the PKI world, a shared secret acts like a public key with targeted distribution scope, and a non-shared secret acts like a private key. Each user knows her own password in an existing enterprise identity management system. The system only stores a hash (e.g., MD5) of the password. No clear text password is stored anywhere. The B3 SDK uses that hash as the first shared secret. The first non-shared secret comes from a different hash (e.g., SHA-1) of the same password.

• B3 software on a device generates a private root key and the corresponding shared secret. They form the second pair of secrets, which ensures stronger authentication. The second shared secret can be used for third-party verification. A B3 protocol can also use the second pair to efficiently reset a forgotten password.

• Non-shared secrets are used together with the message (or transaction) itself and user ID to generate a unique signing key for every message.

• A B3 algorithm then generates a digital signature containing three interrelated parts.

• A B3 algorithm can verify message and user ID integrity with shared secrets. The receiving party can query the password system to verify the sender's authenticity.

19.7.2 Advantages

B3 scheme has the following advantages:

• Speed: Cryptographic hash and HMAC algorithms can run 1,000 times faster than public key algorithms.

• Seamless integration with existing enterprise authentication infrastructure: Various password-based identity management systems are already widely deployed in enterprises (the simplest example is a password file). Utilizing existing password-based identity management systems avoids the expensive overhead of digital certificate management associated with PKI digital signature.

• Strong two-factor authentication: Only the person who has access to the specific device and knows her application password can generate the correct shared and non-shared secrets to sign messages. That also helps to prevent password guessing and dictionary attacks.

• Tamper detection: B3Sig SDK has a conservative design: It assumes that no algorithm is permanently secure, including its own. In case of a successful crypto attack on B3 signature and verification algorithms, the sender can still prove that he did not send the forged message. Part of the B3 signature is linked to the non-shared secrets through well-established non-B3 one-way algorithms (HMACs).

B3 solutions do not dictate complete replacement of the current PKI infrastructure. Rather, B3 solutions can coexist and interoperate with the current system. For example, we can use HTTPS as well as B3E2E SDK to pass shared secrets during setup. The application can add delegated PKI signatures on top of the B3 signatures if desired. To use B3 signatures without an existing identity/password management system, we also need to set up a B3 shared secrets store. To learn more technical details about B3 solutions, please contact B3 directly for white papers and evaluation SDKs.

Leading security experts in the financial services industry, such as Larry Suto, FTCS co-chair at Wells Fargo Bank, and Jim Anderson, a VP of information security at Visa, have agreed to be references for the B3 solutions. If B3 does deliver on its promises, it could become one of the most important security solutions for mobile enterprise applications. However, B3 is still a young company, and its approach has not been tested in large-scale, real-world environments. I recommend you investigate the feasibility of B3 solutions yourself.

19.8 Device-Specific APIs

MIDP device vendors (e.g., Motorola iDEN phones) also provide device-specific cryptography API extensions. Those packages utilize device-native cryptography libraries and special hardware features. Thus, they likely have good on-device performance.

However, applications using vendor-specific APIs are no longer portable to other devices. That causes J2ME platform fragmentation and defeats one of Java's greatest advantages. We do not discuss those APIs in detail here. Interested readers can refer to their device manufacturers' developer manuals.

19.9 Standardization of J2ME Security APIs

Vendor-specific security APIs often offer good performance at the cost of application portability. 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 provide their own implementations.

The upcoming CDC Foundation Profile v1.1 specification (JSR 219) will include a "Security API optional package." The optional package supports subsets of the J2SE v1.4 Java Secure Socket Extension (JSSE), Java Cryptography Extension (JCE), and Java Authentication and Authorization Service (JAAS) APIs. Most algorithms in the javax.crypto package will be supported. It is not clear, however, whether this optional package can be used in conjunction with the CLDC and MIDP.

The "Security and Trust Services API for J2ME" (JSR 177) is an optional package for both the CLDC and CDC. It supports access to embedded security elements, including SIM cards in GSM phones and UICC cards in 3G phones. Those security cards not only store user keys and personal information but also perform certain cryptography algorithms. At the time of this writing, the JSR 177 expert group is still debating whether to include a lightweight cryptography API in this optional package.