Signed Midlets
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.