The first applications that have come out using the J2ME protocol are those games you can play on the little mobile phones. But how long do you think it will be before J2ME shows up in business applications? And when it does, it has to show up with some security, or else you're just asking for trouble if you implement those apps in your organization. This tip, which is excerpted from InformIT, discusses the security options available for J2ME.
When most developers speak of J2ME, they are usually referring to the Mobile Information Device Profile, or MIDP, as it is commonly referred to. J2ME MIDP is a profile based on the Connected Limited Device Configuration (CLDC), and both were discussed at length in other articles for InformIT.
The MID Profile defines a set of APIs and system capabilities that matches commonly used mobile devices such as PDAs, pagers, and mobile phones (thus its popularity, thanks to the worldwide explosion of these types of devices). Java developers who have built MIDP applications are well aware of its current limitations, including the lack of floating-point number support, HTTP-only communications, and the limited UI components. Although no security API is currently included in the MID Profile, a great deal of progress has been made by several companies in order to bring basic encryption to J2ME MIDP. Developers at Sun have created KSSL, a "small-footprint, client-side-only implementation of SSL v3.0 for handheld and wireless devices." KSSL includes a number of optimizations that reflect the reality of development on processor/memory-constrained devices running on low-bandwidth networks. Sun testing of KSSL over using a PDA over a CDPD network placed times for a completed SSL handshake over the network at less than 10 seconds, certainly acceptable for most applications. This flies in the face of conventional wisdom that said mobile devices' CPU/memory limitations prevented advanced encryption techniques on PDAs or mobile phones. The Phaos Micro Foundation toolkit was built for both the CDC and CLDC environments and is a 100% pure Java solution. Finally, the free Bouncy Castle crypto APIs (download includes the source code) run on everything from JDK 1.4 down to J2ME, although performance is reportedly a problem at the J2ME level.
The Connected Device Configuration (CDC) was defined for more capable (that is, more memory, better display, and so on) devices such as set-top boxes and gaming systems. The Foundation Profile (and its child, the new Personal Profile) has been defined for the CDC, and it goes quite a way beyond the capabilities of the MID Profile. Foundation Profile APIs include many of those in Java 2 Standard Edition, including java.io, java.net, java.text, and java.lang. Of interest to our security discussion are the APIs defined within the java.security package, including the following subpackages: java.security.acl, java.security.cert, java.security.interface, and java.security.spec, the combination of which allows an application to provide RSA/DSA encryption for public key infrastructure (PKI)/certificate-based security.
Because it was designed to be run on devices with respectable processor speed and memory configurations, the CDC JVM is required to support the same feature set as a Java 2 Standard Edition (J2SE) JVM, meaning that advanced Java concepts such as the Java Native Interface (JNI) for calling C-language libraries is also supported. Because of these included APIs and advanced features that go well beyond the CLDC, applications targeted for CDC devices should face no security restrictions.
To read the entire tip from which this tip comes, click over to InformIT. You don't have to register there, give your email address, or anything but get the info you need.
