MIDP Application Signing
June 21, 2006 · Print This Article
Part 2 of 2
For details on the background of this project, and details about the overall Java Verified process, see part 1 of this article. This post will exclusively deal with signing MIDP applications, irrespective of whether you’ll also be going through the Java Verified process.
Why sign your MIDP application?
- Some devices might restrict certain functionality to those applications with valid signatures.
- Some security policies reject the installation of any unsigned application.
- Other devices will warn users about an application being “untrusted” if it’s not signed.
- Security pop-ups on phones can get really annoying, and these can be lessened with signed applications.
- Ensures that no one but you can distribute his or her applications or updates to your application under your name.
In short, you want your application signed.
MIDP 2 Security
Before going further, if you’re unfamiliar with the security architecture in MIDP 2.0, you might to check out this article written by Jonathon Knudsen. If you’re unfamiliar with security certificates and how they work, this article on X.509 PKI is worth the read.
Certificate Authorities
The two primary Certificate Authorities (CA’s) for code signing are Thawte and Verisign. Thawte certificates will cost you $200 per year (discount on renewals), whereas Verisign will cost you $500 per year (discount on renewals). So which do you choose? Both of them!
Unfortunately, not all phones have a Thawte root certificate, and not all have a Verisign root certificate. If you try to install a Thawte-signed application on a phone without a Thawte root certificate, the installation will be aborted. So you need to determine which phones have which certificates installed, and target your builds accordingly.
Or, if you’re only developing for a few phones, just sign with the certificate needed for those phones. If you can only afford to get one certificate, you’re better off to shell out the extra money for the Verisign certificate, because it is currently installed on more phones than Thawte.
Complicating this scenario somewhat are carriers who can impose further restrictions, or add or remove certificates from phones they sell. An example of such a case is Sony-Ericsson phones sold by Cingular Wireless. Most Sony-Ericsson builds should be signed with Verisign certificates (there are several that must be signed with Thawte, as
well), but Cingular has removed this certificate on some phones sold through them, meaning that your Verisign-signed application might not be installable on some Cingular / Sony-Ericsson devices. In this case, it’s advantageous to have a build that is not signed at all (or, if possible, one that is Java Verified). It’s annoying for the user, but it might be the only way to deploy your application to some handsets.
Mechanics of Signing Your Application
The easiest way to sign your application is by using Sun’s Wireless Toolkit (WTK). Detailed instructions can be found in the WTK User Manual. If you’d prefer to use command line utilities, check out the steps available here. This blog also includes plenty of comments from developers attempting to sign applications, and is a glance into the quagmire of signing.
Signing MIDP Applications with the WTK
- Open KToolbar, and choose Project | Sign.
- Select the “New Key Pair” button to generate a new key pair.
- Enter your key alias, your name, and company information, and click the “Create” button.
- Press “Generate CSR” This is the certificate signing request.
- Click “Browse” to choose a location for the CSR file, and press “Create” to write the CSR file.
- Head to Verisign (or Thawte) and begin the enrollment process for a code signing ID. You’ll copy the CSR file contents and paste them directly into the Verisign enrollment form. Pay them their fee, and then they’ll verify your identity, and e-mail you back a certificate.
- Back in KToolbar, choose Project | Sign.
- Import the certificate by pressing “Import Certificate.”
- To sign your MIDlet suite, you will first package it.
- Then choose Project | Sign.
- From the Alias List, select the key you just imported, and click “Sign MIDlet Suite.”
- Do a happy dance, and pray for the day when this becomes easier.
If you’re using J2ME Polish as your build tool, follow the first 8 steps above, and then add two jar elements to your build.xml file according to the Polish instructions found here.
Conclusion
If you have the time and money, need or want the sales channels, and have a relatively stable application or a small number of builds, the best way to sign your application is by going through the Java Verified process. Otherwise, pick up a Thawte and/or Verisign certificate, and do it on your own.
If you have any tips, advice, additions, or corrections, please post them in the comments section.
Tags: J2ME, Java ME, J2ME Polish, mobile software, mobile development, MIDP, code signing, Java, Java Verified
This is what I’ve been waiting on. I take it I’m the “one” mentioned in your last post??? I’m going to try to tackle this in a few days. Thanks for the info Joe.
Great post that summarize quite well all development steps of signature….Keep us informed about your issues/achievement here, as there is not so many discussion about this.
that great post but i have some question.
1. what about if my application not include About, Help, and Exit functions ?
2. on the babel test provider there is some ticket from java verified that must i send to babel with my application. my question is what kind of ticket is that ?
Julian, per the Unified Testing Criteria (see FN11, page 38), your application must include About, Help, and Exit functions to be JavaVerified. If you have special circumstances that make it impractical to include these, you should discuss them with Babel. They’ll test by the book otherwise.
The ticket is described on this page http://www.javaverified.com/jvProcess.jsp. When you create an account and successfully submit an app to JavaVerified, you’ll be able to download the ticket to send to Babel.
Good luck.
Shaun
thanks for your explanation.
but i have a few question again.
i wonder how long you doing the proccess. i mean step by step estimate time needed. from the first step you upload your application until you get the certification your application.
and what about if my application get the certification example for device Nokia N71 is there will be certified as well as the Nokia N73, N75, N92, E50, N77, E65. because on Table Of supported Devices have some explanation if the lead device in this case N71 then the other device in this case N73, N75, N92, E50, N77, E65 will automatically pass the test.
thanks.
I’ve had two apps JavaVerified, and from initial submission to verified took 4-6 days for each, including a few retests. Obviously don’t submit your app until you’ve self-tested according to the Unified Testing Criteria. Your test provider should give you 1-2 day turnaround on each test.
Yes, if you certify on the lead device, you are considered certified on all the devices in that category.
Good luck!
Shaun
thank you for your reply.
i have other question.
i have upload my application.then i have upload my flow application and choose babel tester.what i want to ask is what next step it will be ? because first time i have on this step as well as but tester never contact me. is there any mistake ?
thank.
Don’t wait for Babel to contact you — it’s your responsibility to contact them. The process overview page (http://www.javaverified.com/jvProcess.jsp) says this:
“Once a tester has been selected, developers notify the tester that they have submitted their application to the JVP and wish to have the tester retrieve it and test it.”
thanks and sorry i’am not read that carefully so i didn’t notice that.
when i notify the tester is there i need enclose my application and ticket ? and still i’am not understand what kind of ticket is it. what the mean with ticket is application id in java verified ? and what email that i notify the tester is that javaverified@babelmedia.com or sales@babelmedia.com.
sorry for so much question.
oh i have question again. may i send email to you for the next answer at joefission@gmail.com or just on this comment ?
thanks for your help.
ok i have contact the babel.
i want ask you again what tester that you choose and price for first time testing. and when that’s fail how much price to testing again. and is that true that after pass the test we can’t add some function again. and what about if i add some function and test again ?
thanks.
I didn’t use Babel, so I can’t say which e-mail to use. If they don’t have the steps outlined on their site, I’d go with javaverified@babelmedia.com because it’s the more specific address. You won’t need to send them your app — just your id. They’ll use your id to pull your app from the JavaVerified portal.
I paid $175 for the initial test for EACH build. So one build in three languages counts as three builds. Retests were at $125. Once you pass testing, they sign your app with the GeoTrust certificate — that’s how you prove that your app is verified. Because it’s signed, any change to the jar makes the signature invalid. So if you want to make any changes to a verified app, you must submit it again for testing after doing so.
hai Mr. Joe Fission i have a question again.
hopely you not boring.
i just read on wiki.nokia.com that said if javaverified is also trusted third party like verisign and twathe.
is that means API restriction is not fully allow ? i mean like network connection is that will still ask one time every time making connection and read write file using JSR75 is that will still ask every time read / write just like untrusted third party ?
thanks.
It’ll differ a bit depending on the handset, but the JavaVerified certificate (GeoTrust) will allow your app to run as a trusted third party, so users should NOT get repeated prompts.
[...] my earlier post about application signing. If at all possible, sign your application with a Verisign code-signing certificate. JavaVerified [...]
hello mr.joe Fission..
i’ve got problem with java wireless security
i built it with wireless toolkit 2.5.2 for CDLC but when i executed it, in the WTK console show error message below :
java.lang.NullPointerException
at java.lang.StringBuffer.(+2)
at URLBuilder.(+13)
at PasswordMIDlet.login(+154)
at PasswordMIDlet.access$000(+4)
at PasswordMIDlet$1.commandAction(+26)
at javax.microedition.lcdui.Display$DisplayAccessor.commandAction(+282)
at javax.microedition.lcdui.Display$DisplayManagerImpl.commandAction(+10)
at com.sun.midp.lcdui.DefaultEventHandler.commandEvent(+68)
at com.sun.midp.lcdui.AutomatedEventHandler.commandEvent(+47)
at com.sun.midp.lcdui.DefaultEventHandler$QueuedEventHandler.handleVmEvent(+186)
at com.sun.midp.lcdui.DefaultEventHandler$QueuedEventHandler.run(+57)
therefore i hope you can help me for resolve it, pelase……..
best regard
Irwan
Hey, Can we have the midlet signed by more than one CA certificate . I mean by both Verisign and Thwate???
Do you have the intersection of handsets which supports both the CA and which supports one and not the other.
Thanks ..
Shrikant
Sure, you can. More than one signature is just fine.
I don’t have an intersection list. It’s a tangled web. I’d just do your research on the devices you are certain you want to support.
“If you have the time and money, need or want the sales channels, and have a relatively stable application or a small number of builds, the best way to sign your application is by going through the Java Verified process.”
Does Java Verified cost money? I have submitted my game there and have yet to here back. I thought that this was an open/community process and therefore free? Please clarify?
JavaVerified most definitely costs money — but the initiative doesn’t charge it, the testing house does.
Dig a little deeper into the process: http://www.javaverified.com/jvProcess.jsp; in step 3, you select a testing provider: http://www.javaverified.com/test_providers.jsp.
How many times can I sign my code (with Thawte or Versign CA)?
I need to test my applications and have 10 to 20 builds a day, if I want to avoid security popups at the cellphone, can I sign my code everytime without paying anything ?
Thank you!
As many times as you like, Rondy. The cert is time-limited, not use-limited. Once, a hundred times, a thousand times, it makes no difference.
If I do small change to my code do I have to pay another 500$ to get MIDlet signed?
@Force, if you’re talking about JavaVerified, then yes, every time you make a code change, your builds must be re-verified and you pay for that. If you’re talking about signing with your own cert, then you can use an unlimited number of times for no extra cost.
Сдается мне, на вашем сайте развелось слишком много так называемых говн*комментатров, которым лишь бы ляпнуть чего-нибудь:)
Can anyone tell me that how can I sign J2ME Polish Jar file