Monday, July 6, 2009

BlackBerry Code Signing Tips

So you’ve written the perfect BlackBerry application. It runs great in the device simulator and now you want to run it on a real device. You install it, but it won’t run — because you’re using controlled APIs. That’s right, a lot of the interesting APIs on the BlackBerry — for example, the persistent store — are protected by a security layer. To get past that layer you have to sign your application using certificates provided by RIM. Here’s a quick guide to the realities of BlackBerry code signing.

Applying for Code Signing Privileges

RIM is very security conscious, which is why developers must apply for code signing privileges. You do this by filling out this form. Note that there’s a US$100 charge for each application. You may need to apply more than once — see the gotchas below for the reason.

Once you’ve submitted the application, RIM will do some investigation to ensure themselves that you’re a legitimate developer. If you’re approved, you’ll receive the code signing certificates within 4 or 5 business days.

ISV Alliance partners can have the application fees waived, mail your ISV technical contact for the details. The turnaround time for ISV partners is quicker since RIM has already established a relationship with your company.

Code Signing Gotchas

Here are some interesting facts about code signing that won’t necessarily be obvious until you go through the process:

  • There are three sets of controlled APIs, each of which requires its own certificate. RIM will therefore deliver you a certificate set. You must install all three certificates in the set in order to get full coverage of the controlled APIs.
  • Each certificate set is per developer — or, more precisely, per machine. Either you’ll need certificates for each developer and each build machine or you’ll use one machine (the build machine) as a central signing machine that all developers use.
  • Code signing requires an active Internet connection back to RIM’s certificate servers. No connection, no signing. If RIM’s servers are offline, you’ll also be stuck.
  • Whenever code is signed with a certificate, the person who applied for the certificate set gets email from RIM’s servers with the status of the signature request and how many signings remain on the certificate. If you use the same email account and you’ve got a lot of developers doing code signing, the email account will get flooded with emails.
No Automated Code Signing!

Here’s the one that really annoys me the most, though:

  • Code signing cannot be automated. The code signing tool pops up a dialog that prompts you for a secret key in order to access the necessary certificates. There’s no way to pass the key in from the command line. So if you automate your builds using Ant or makefiles, you’ll need to use some kind of tool that looks for the dialog and simulates the user entering the key via the keyboard.
I don’t know why they’re so hard-headed about this. When I’ve complained, the answer’s been that they do this for security, and that there’s no need to sign the code until you’re ready to deploy, at which point a developer can sit there and manually enter the signing key to prepare the final version. They think this is good enough because the application can run in the device simulator without being signed.

But those of us who use automated build processes with nightly builds and regression testing don’t want a separate manual signing step — the point is to automate everything and to test the actual version of the software that will be deployed. After all, the size of the .cod files changes because of the signing, and that can affect other things like the .jad files used for over-the-air (OTA) deployment (which, unfortunately, don’t get updated automatically by the signing tool, so you have to create your own tool/process to re-build the .jad files after the code signing is done).

If more people can complain to RIM about this, perhaps they’ll change their minds about this “security feature”.

Article Source: Synclastic.Com

No comments:

Post a Comment