Javia blog

Since MIDP 2.0, a midlet can be unsigned or signed (in MIDP 1.0 all midlets were unsigned). A midlet which is signed can get easier access to sensible operations. For example, let’s suppose that a midlet wants to access the network (http). If it’s unsigned, the user is asked for confirmation each time the midlet does the operation. While if it’s signed, the user can choose to allow the midlet access without further confirmation. So if you write, for example, a multi-player game, you should perhaps sign it because otherwise the user will be bothered with access confirmation questions all the time.

Afterwards you sign the midlet using your private key, and you distribute the signed midlet together with your public key and the certificate. When the midlet is installed on the device, the signature is checked. This insures that the midlet was not modified since you signed it (integrity). Afterwards, the certificate which accompanies your public key is checked, by having it’s signature verified. As you remember, the certificate was signed by the CA. In order to verify this signature, the device needs the public key of the CA. The public key of the CA should normally be already installed on the device, in a so-called “Root Certificate”.

The idea is that there are a few well-known CAs, which are generally trusted by everybody; and you’d expect that the public keys of these well-known CA to be on installed on the device as Root Certificates. For example, well-known CA are Verisign and Thawte.

So all you need to do, in order to be able to sign your midlets, is to obtain a certificate from a CA. The problem is that it’s costly for a freeware developer: a certificate costs 200$/year from Thawte, and 400$/year from Verisign. Afterwards comes the second problem: not every phone has both Thawte or Verisign installed as root certificates. So you may, for example, buy a (costly) certificate from Verisign, only to find out that it doesn’t work on your target device. The recommended practice is to buy a few (2-3) certificates from different CAs, in order to improve phone root-certificate coverage.

An alternative to Thawte and Verisign is JavaVerified, a commercial initiative which verifies that your midlet is well-behaved and signs it afterwards with their (JavaVerified) certificate. This way you don’t need to buy your own certificate, and what’s more the JavaVerified root certificate is generally very well supported on phones. The downside is that with JavaVerified you have to pay many hundred $s (more likely in the thousands) for every midlet that you want certified, so this ends up being significantly costlier than the first solution. JavaVerified works by delegating the work (midlet verification) to four partner companies, which set their own prices; you are allowed to choose one of the four companies for verifying your midlet.

One of the JavaVerified partners is CapGemini. As I worked for a short while at CapGemini, I can tell you that this is the worst company I’ve met. Having my midlet ‘certified’ by CapGemini is a joke to me. So for now, I’d qualify JavaVerified as the place where you can throw your money away when you have no better use for them.

And on a positive note, Symbian has a similar program called Symbian Signed. What’s great, is that Symbian Signed is offering free certification for freeware applications. This is really a very nice thing, and it’s a great incentive for the small developers to write applications for Symbian (instead of JavaME).

My impression concerning the security model of JavaME / MIDP 2.0 is that they were less concerned with the security and comfort of the users, and more concerned with making sure that everybody (manufacturers, operators, JavaVerified etc) gets its share of profit from the certification business. Some operators (Orange, Cingular) even go as far as to completely disallowing the installation of unsigned midlets on their phones; I can only see this as an expression of their greed in the detriment of their users.

I’ll describe here in short how signing works:
A key is a pair of a private key and a public key. These two key have the property that what is encrypted with one can be decrypted with the other. So if you encrypt something using the private key, it can be decrypted using the public key, and vice-versa. You keep the private key secret, so that only you can use it. When you sign a document, a message digest (MD) of the document is computed. A MD is a secure hash of the document; it has the property that each document has it’s own MD. You can’t find a different document which has the same MD as a given document. Because of this, the MD can be seen as a characteristic of the document. If you make any change to the document, its MD changes. So you compute the MD of the document you want to sign, and afterwards you encrypt the MD using your private key. This encrypted MD represents your signature of the document. The signature assures two things: that you indeed signed the document (non-repudiation), and that the document wasn’t changed from the form that you signed (integrity). Now let’s see how the signature is verified: another person receives the document together with the signature (the encrypted MD), and wants to check if the document was signed by you. He decrypts the MD using your public key, and also computes a new MD of the document. If these two MDs are the same (the computed one, and the one decrypted from the signature using your public key), it means that indeed you signed the document. If they’re not equal, it means that either the document was signed with a different key (i.e., it wasn’t signed by you), or that the document was modified since you signed it.

There is also a different aspect: how is the person who verifies the signature sure that the public key he thinks is yours really is yours? Non-repudiation means that once you signed a document, you can’t deny that you signed it. You may try to say something like: that public key is not mine; so it’s not me who signed the document; it’s not my signature. In order to make such denial impossible, the person verifying the signature wants to be sure that the public key really is yours, and that you can’t deny this fact. This is achieved by having your public key certified by a Certification Authority (CA). A CA is an organization which verifies (at your request) your identity, and emits a certificate declaring that the given public key is yours. This certificate is signed by the CA. So this certificate, signed by a CA, is the mechanism which makes the link between a public key and a real-world identity.

It order to be able to sign, you need a key (a pair of a private key and public key). You may easily generate any number of keys yourself, using a program like OpenSSL. Afterwards, you need to associate the public key with your identity (your company name, for example). This is done by obtaining a certificate from a Certification Authority (CA). The CA verifies your identity (by calling you on the phone, or by having you fax them some official documents declaring your identity), and afterwards gives you a certificate, which says that the given public key belongs to you.

These are some popular phones that people are still using for running JavaME applications:

	Nokia 6600		176×208, MIDP 2.0
	Nokia 6230		128×128, MIDP 2.0
	Nokia 3510i		96×65, MIDP 1.0
	Nokia 3200		128×128, MIDP 1.0
	Nokia 3100		128×128, MIDP 1.0
	SE K700i		176×220, MIDP 2.0

MIDP 2.1 was released on 20 June 2006.
It only brings minor differences with respect to MIDP 2.0.

MIDP 3.0 is expected to be released toward the end of 2006.
The Reference Implementation (of MIDP 3.0) will be released as Open Source under the Motorola Extensible License.

Sun recently announced that it plans to open source JavaME before the end of 2006; this would mean to open source the WTK and perhaps the MIDP 2.x Reference Implementation. Sun has yet to decide what license to use.

I recently looked into emulators capable of running JavaME applications as an applet in browser (JavaSE). Such an emulator is useful for presenting MIDlets in the browser, so that the user is able to try the application before installing it on the phone.
Right now it is usual to put screenshots (pictures) of MIDlets on the web page, but having a running screenshot allowing to try the application is much more powerful.

The emulators I found are: ME4SE and Microemulator.
ME4SE is licensed under GPL. It isn’t developed anymore. It implements MIDP 1.0, and partially MIDP 2.0. Also some functionality (like phone skins) isn’t released under GPL, but only available under a commercial license.
Microemulator is under active development but it seems to be, right now, less mature than ME4SE. Microemulator is licensed under LGPL.

In short, while both projects are interesting, none is very useful now; and it seems that only the Microemulator is progressing. Yet what they potentially offer, the possibility to run MIDlet in the browser, is very useful indeed.

What is interesting to see is whether the annonced release as open source of the MIDP 2.0 and MIDP 3.0 RIs (reference implementations) will allow to easily transform them in MIDP emulators over JavaSE. We only have to wait about 4 moths (until the end of 2006) to see it.