Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Secure data files embedded in MIDP applications

Protect your MIDP applications from copyright theft

By Simon Ru, JavaWorld.com, 05/02/05

As OTA (over-the-air) technology continues to mature, a new market has opened to software developers. Today, savvy cell phone users can purchase a J2ME MIDP (Mobile Information Device Profile) application from Handango.com and download it into their phones in seconds. In just couple of years, the wireless software industry has leaped from ring-tones to games to full-fledged applications.

Many consumers have yet to realize how much they can do with their phones; they often associate J2ME applications with frivolous games. However, as consumers upgrade to new generations of phones, a new breed of knowledge-based MIDP applications with practical uses are getting noticed. The list of Handango's best selling J2ME software is full of knowledge-based applications, such as multilingual dictionaries, vocabulary trainers, Bibles, trivia, and even cocktail recipes. A dictionary program listed less than a year ago has already received close to 26,000 downloads! Considering that thousands of wireless subscribers are willing to pay for a ring-tone, the market potential for practical J2ME applications is enormous.

Unlike games, the value of knowledge-based applications lies in the data. Due to the hardware-imposed simplicity of a MIDP application, if the data file is compromised, one can easily come up with a competing application. Although a client-server model, where the data resides in a backend server, can address this concern, such a model proves impractical for most wireless applications. Until the cost of wireless data comes down and wireless connections become more reliable and ubiquitous, embedding the data file into the MIDP JAR is the only option. Therefore, protecting the data file from copyright thefts becomes imperative.

A common solution to this issue is to encrypt the data file. In fact, several Java Specification Requests (JSRs) are underway to provide a standard set of APIs for encryption and decryption. However, cryptography computation is CPU intensive even for a desktop computer running J2SE. Not to mention that it will be a couple of years before all new phones support such APIs. Moreover, code based on the new APIs will not be backwards compatible with all current phones. This creates a gray period where an application may run on some phones, but fail on others. An alternative is to use third-party cryptography libraries supporting J2ME. One popular open source implementation is Bouncy Castle's lightweight crypto API. But, there is a catch: the library is more than 400 KB. Given that most Nokia Java phones in the market have a 64-KB JAR size limitation, this solution is again not viable.

I propose a simple solution to the problem. It adds one extra line of code, and the JAR size penalty is negligible. It has two phases. First, clean up and compress the data file. Second, obfuscate the compressed file so it can't be easily decompressed.

• Clean up the data file: Many Windows-based editors escape new lines with \n\r. This is especially the case if you export the data from Excel. The "\r" is redundant since "\n" alone is sufficient to indicate a new line. Removing "\r" and unused spaces before the line break will save you a couple thousand bytes, depending on how many lines are in the data file.
  
  

  Note that not all text editors can detect "\r"; UltraEdit is one editor that works. If the data file is large, break it into smaller files to promote quick searches. But keep in mind that smaller text files don't compress as well as larger ones.