J2MEWith the large number of financial applications that are available for Java-enabled devices, security is of paramount importance. Java 2 Micro-Edition Connected Limited Device Configuration (J2ME CLDC) is the platform of choice when it comes to running mobile applications on resource constrained devices (cell phones, set-top boxes, etc.). The large deployment of this platform makes it a target for security attacks. The intent of this article is to provide some insight into J2ME security and the common mistakes when developing such applications.

J2ME has fewer features than Java and has a smaller and efficient Java engine designed for small devices. We could divide the security of J2ME into three categories:

  • Compile/Runtime Security
  • Database
  • User awareness

Compile/Runtime Security. Java compiler and runtime environment through the provision of non-customizable classloaders, pre-verified midlets, protection domain policy and limited/no access to native/reflection API ensures the safety of the mobile devices.

One of the key improvements over the few years in MIDP is to allow only the trusted application to call the protected API. All trusted API’s would be signed. The trusted store in the mobile phone is usually populated with certificates of manufacturer’s choice and not all known CA’s root certificates are part of the store. The J2ME permission class cannot be inherited to customize the need. Also the permissions are not really atomic to allow finer control. Once permission is obtained by the application from the user the application is allowed to use the resource however necessary.

Database Security. One of the most ignored parts of the J2ME is the RMS database. The database is a simple byte-level file that stores the contents on the local phone. The security of this file is left to the manufacturers and the application developers. Most of the time the application developers are under the belief that RMS database file is safe to use and it’s well protected. This is not the case. A simple example would be to install the application on a memory card and later on mount the memory card in a computer. You could see almost all the files including the RMS file. Application developers need to realize that nothing is as secure as or more secure than their application. Application-level encryption is a must to protect the local data in the RMS database.

User Awareness. Another factor that J2ME developers should be aware of is the knowledge level of the user base. The mobile phone user is not aware of all the computer-related functionality. The fundamental difference in the user base demands a security at higher level which is less complicated. The current basic security that is implemented in all J2ME application is the certificates. The expectation that an average user in the market would understand a certificate and invalid application is questionable. As an average phone user, the trust of an application comes from his interaction with it. This interaction should be simple enough for the end user to understand. A better user interface design could help the end user understand the messages that he sees on the screen. Companies should take special initiatives to spread the security measures.

Bottom line, one should understand that a mobile phone is not better than a laptop; it’s pretty much the same in the hackers’ view. Beware and be Secure