Skip to main content

When Will We Have The Ability For Secure Midlet Deployment?

1 reply [Last post]
dsuh
Offline
Joined: 2007-02-12

I an encouraged by the renewed focus on ISVs.
However, searching the web, I have seen the question developers seem most interested in:
How do I prevent someone from decompiling my Midlet/class files?
The answer of course is that you can't and the only thing you can do is try to confuse (add extra classes, etc.) and obfuscate.
In my mind obscurity is not security.
In fact both OTA and jar file deployment do not hide anything from someone with a decompiler.
What I do not understand is why this still has not been addressed, especially in embedded Java ME implementations?
The fact is that embedded Java ME implementations like wireless phones prevent any low level changes like running your own ClassLoader, so it should be capable of loading encrypted or low-level compiled Midlets.

One way would be to allow developers to encrypt jar files with a phone manufacturer's public encryption key.
(Actually, a dynamic symmetric encryption key is usually encrypted with the public key which is then used to encrypt and later decrypt the jar file)
Then, the encrypted jar file can be loaded locally through a cable or OTA and decrypted by the wireless phone using the already-stored manufacturer's private decryption key.
In this way, it is extremely difficult for anyone else to look inside your jar file.
The infrastructure is already there with some private/public key and encryption capabilities, but it has not been applied to encrypted jar or class files.

Another way to deploy would not involve encryption, but rather the tantalizing possibilities that In-Place Execution (http://java.sun.com/javame/reference/docs/cldc-hi-1.1.3-web/doc/architec...) which I believe PhoneME provides.
The premise is that most of the wireless phones in the world running Java ME run on an ARM CPU.
Why not use the converter for In-Place Execution to generate machine-level application images to deploy instead of our class files?
The application image is recognized by a magic number from the first four bytes of the file so it should be possible to even keep the .class suffix on the files.
This kind of low-level image is more difficuilt to decompile into readable code than the mid-level byte codes that the classes are in.
That way, the application loader could load these kinds of images or regular class files by the magic number it finds.

I believe if you want strong ISV support for Java ME, you need to provide a deployment mechanism that they can be confident in.
Software intellectual property is the biggest asset of the ISVs and if you can not protect that, they will stay away.
As an old movie said once:
"If you build it, they will come."

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
chris_gray
Offline
Joined: 2005-11-08

> One way would be to allow developers to encrypt jar
> files with a phone manufacturer's public encryption
> key.

Wouldn't that allow anyone with the same type of phone to decrypt the file?

For a particular application we solved this problem by building a private key into the VM executable, and decrypting encrypted bytecode at the moment it was read into memory. The built-in key is pretty well concealed in the executable, but an attacker having knowledge of the tools with which it is built could probably find it. We did this with our BSD-licensed VM, but in principle it could be done with PhoneME too - the GPL only obliges you to give source code to everyone who receives the executable, not to their mother-in-law.