Protecting Network Data - Beginning J2ME: From Novice to Professional - page 338

HTTPS Is Almost Everything You Could Want
The Generic Connection Framework has always been flexible enough to allow MIDP imple-
mentations to include support for HTTPS, which is HTTP over a secure connection like TLS
or SSL. Support for HTTPS is built into the MIDP platform. (See Chapter 10 for the skinny on
HTTPS and its supporting APIs.)
TLS provides server authentication and an encrypted data connection between client and
server. The security provided by TLS is sufficient for most applications. There are only a handful of
reasons you might want to implement cryptographic solutions beyond what's available from
TLS, including the following:

• Client authentication : TLS provides server authentication, usually via an RSA certificate.

But although TLS will support client authentication, the APIs in MIDP 2.0 don't allow
you to take advantage of this feature. A technique for using password or passphrase
authentication is presented later in this chapter (see the section “Protecting Passwords
with a Message Digest”). If you're looking for something stronger, a scheme based on
client certificates and signatures is described at http://developers.sun.com/techtopics/
mobility/midp/articles/security3/ .

• Stronger encryption : TLS usually results in encryption using 128-bit keys that are valid

for a particular session. (Although you can't control which cipher suites are accepted
on the client, you will probably have control of the server and will be able to configure
acceptable cipher suites there.) For many applications, 128-bit session keys provide
plenty of data security. However, if your application deals with especially sensitive or
valuable data, you might want something stronger.

• Message-driven applications : HTTPS only provides encryption for channels. Some appli-

cations work by sending encrypted messages over insecure transport like HTTP or sockets.
Here the MIDP APIs are insufficient and you'll need to do your own cryptography.

As we said, HTTPS support in MIDP is all you need for many applications. Read on if you
need something stronger, or if you're just curious.
More information about HTTPS and TLS in MIDP is at http://wireless.java.sun.com/
midp/articles/security2/ .

The Bouncy Castle Cryptography Package
In the J2SE world, Sun provides support for cryptography through the Java Cryptography
Architecture (JCA) and the Java Cryptography Extension (JCE). The problem, of course, is that
the JCA and JCE are too heavy for the MIDP platform. MIDP's HTTPS support is very useful, but
it's definitely not a general-purpose cryptography toolkit.
If you're looking to move beyond HTTPS, your best bet is the Bouncy Castle cryptography
package, an open-source effort based in Australia. It's a wonderful piece of work, featuring a clean
API and a formidable toolbox of cryptographic algorithms. There are several other open source
cryptography packages around the world, but Bouncy Castle specifically offers a lightweight J2ME
distribution of their software. To download the package, go to http://www.bouncycastle.org/ ,
follow the link for latest releases, and choose the J2ME release of the lightweight API. As we write
this, the current version is 1.27.