The Neo for Java 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.
Using Neo for Java, NTRUEncrypt key pairs can be generated quickly from pass phrases. The same pass phrase always produces the same key pair. For that reason, Neo for Java does not provide a password-based key store facility. NTRUSign keys, however, are slow to generate and require floating-point support. The Neo for Java 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.
B3 Security
B3 Security is a San Jose, Calif. 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. 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.
I tested the B3Sig SDK, which runs on the J2ME/CLDC platform. 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 nonshared secrets. Analogous to the PKI world, a shared secret acts like a public key with targeted distribution scope, and a nonshared 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 (for example, MD5, or Message Digest 5) of the password. No clear text password is stored anywhere. The B3 SDK uses that hash as the first shared secret. The first nonshared secret comes from a different hash (for example, SHA-1, or Secure Hash Algorithm-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.
* Nonshared 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.
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 nonshared 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 nonshared 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 whitepapers and evaluation SDKs.
Leading security experts in the financial services industry, such as Larry Suto, FTCS cochair 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.
Device-specific APIs
MIDP device vendors (for example, 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.
But 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. I do not discuss those APIs in detail here. Interested readers can refer to their device manufacturers' developer manuals.
