J2ME Security

Security is a concern in J2ME environments because J2ME devices tend to be handheld or otherwise mobile devices. Losing the device could be disastrous if you have sensitive or confidential data on the device. Network security is also an issue, especially in mobile devices using public wireless networks.

Network Security

The simplest way to keep your data safe is to communicate using the HTTPS or SSL protocols. Unfortunately, not all devices support one of these protocols. Those that do typically support HTTPS, not SSL — any kind of direct socket-based connection is rare to find and will certainly tend to be carrier-specific. Unless you have a specific requirement for socket-based connections, plan to tunnel your networking over HTTPS.

If HTTPS is not available, you must fallback to using HTTP. If sending data in unencrypted form is simply unacceptable, you will need to add your own encryption code to both ends of the HTTP conversation, using encryption routines from toolkits like Phoas (commercial) or The Bouncy Castle Crypto APIs (open source). Note that some platforms — especially RIM's BlackBerry handhelds — include built-in encryption APIs, so be sure to check those out. (You may still want to use a separate toolkit, though, if you need to write applications that are portable across a wide variety of devices.)

My tech tip Data Encryption for J2ME Profiles is a good place to start for more details.

Data Security

Keeping the data safe on the device also requires encryption, and for that you probably have to use a toolkit: even if HTTPS is available on your device, the encryption code probably isn't exposed.

For MIDP devices, data persistence is done through the Record Management System (RMS), which operates solely on byte arrays. The RMS doesn't know or care about what you're storing, so you're free to encode the data however you want. For safety, then, you can encrypt the data before you store it and decrypt it when you retrieve it. There will be a performance penalty, and it may be substantial for certain devices, especially those where RMS operations are slow to begin with. You'll have to run some tests to see if the penalty is acceptable.

If you encrypt the data, you'll need to prompt the user for a password. Remember that most J2ME devices do not have a full-size keyboard, so entering alphanumeric sequences can be challenging. If you do prompt for alphanumeric characters, don't use a "password field" that hides the characters as they're typed, otherwise the user will never know if they've entered the right values or not — when a keypad is used to enter alphabetic characters, each key maps to several different characters. A better approach is to use a numeric password (commonly referred to as a PIN), though it offers less security. Still, if passwords are too hard to enter then your users will curse you and turn off the security features if you've made them optional.