Forgot your password?

RIM Details Their Roadmap for Code Signing – Still Seems Relatively Useless


I have always had a huge issue with code signing for BlackBerry applications. For almost a decade code signing has been a hugely frustrating and annoying barrier to entry for new BlackBerry developers while providing marginal security improvements. Hell it used to cost $200 for code signing keys. As far as I have been able to research all code signing does, at least until the BlackBerry PlayBook, is prove that the code you are installing has not been modified since the developer signed it. In other words it provides trust (aka Integrity) though even RIM can see how laughable of a security model that is all by itself. I am not necessarily against code signing but the benefits have to outweigh the cost. More on that later.

One of RIM’s devs, Mark, was kind enough to detail the current past and present of code signing for all BlackBerry devices on the RIM DevBlog. He even tries to explain why it is of value especially on the BlackBerry PlayBook. The two major additions RIM did with code signing on the BlackBerry PlayBook is use part of the code signing key to protect the data your application can access and another was to add debug tokens to allow you to test unsigned code on an actual BlackBerry PlayBook. It is nice to see that code signing is getting easier and I truly hope it becomes as simple as pie without 14 different steps no matter how easy the wizard. I just want to stress how important it is for RIM to streamline this process until there are no longer flooded in their support forums with developers frustrated with the code signing process. (Just take a look to see what I mean)

Code signing certificates mainly provide the ability to verify that the application you installed is coming from the developer without any modifications. It does not tell you if the developer is somebody you should trust or if they just plan on stealing all your data. Hell all RIM even does is just verify a developers information with their credit card company. This is semi-redundant on the BlackBerry PlayBook since RIM plans on restricting PlayBook app installations to App World only unless you sideload your app. That means RIM already authenticates that the application you are installing comes from that developer. They do this by making developers jump through hoops to register for App World and verify their identity. So why do we need to double verify that fact? Also it is laughably easy to get a code signing key from RIM so it does not stop you from trusting bad developers since they can just as easily sign their code with another key.

The code signing keys also provide little value to developers especially PlayBook developers. It does not protect your application code or make sure that another developer cannot simply unzip your .BAR install file (for WebWorks and Flash apps) compile the app again and sign it with their key. That sort of makes the whole Debug Token security model another painful step that does not add as much value as the painful setup scheme it requires. It gets even worse if you lose your key and can no longer update your app until it is reinstated or want to share your key with other developers you are working with.

This model is even more flawed on BlackBerry smartphones where code signing is not even required for apps to run unless they need access to protected APIs. Also they can be installed from any source which is probably why RIM started with the code signing model. It allows RIM to centrally revoke a developers ability to sign new code. The thing is that developer could have many more code signing keys that they could just as easily sign malicious code with. If anything part of RIM’s improvements to streamline code signing has been to make it easy for ANYBODY to get a code signing key.

All in all it seems like code signing is simply maid to deter lazy crooks instead of providing the level of benefit that would justify the high toll it takes on BlackBerry developers. The question is if RIM can simplify this process to make it less painful or at least justify the cost by adding actual benefits. I understand that RIM wants to protect users from imposters signing code or impersonating another company but the security it offers against that is not that hard to bypass. All it does is make sure the code signer cannot be anonymous but a malicious dev could easily obtain a stolen credit card number and purchase a code signing key especially since nobody would notice the $1 code signing authorization charge.

My dream is that RIM finds a way to create a 3 step wizard that within 10 minutes sets up your development environment, requests and installs your code signing keys, and sets up your App World vendor account. I am truly hoping Mark and his team can make that a reality ASAP… Since right now that process is measured in hours-days instead of minutes. You can see the advancements RIM has made in the last year below but hopefully RIM overhauls the whole system so we don’t need anymore:

  • Made code signing keys easier to obtain by removing the credit card requirement for ordering them
  • Reduced the order time for code signing keys from 7-10 days to approximately 1-2 hours so you can start building right away!
  • Created Configuration Wizards to walk you through configuring and backing up your keys
  • Automated many previously manual steps by integrating Debug Tokens into the SDKs
  • Updated the hardware for our code signing servers
  • Created the Code Signing Support site to walk through the ordering, configuration and signing process

Let me know what you think! I would love to be proven wrong…

8 total comments on this postSubmit your comment!
  1. While I do agree that RIM can do a lot more to make obtaining and using a key easy, I do feel that even the current model adds more value than is claimed in this article. It may not prevent all instances of malware, but doesn’t it keep mass infections from taking place? For example, if you found a particular line of malware signed with a particular key, isn’t it easier to clean it out by using the key as the identifier? Malware detection today has to look inside the code to identify it, but if you have code-signing in place and you know code by a particular (even unknown) developer is bad, couldn’t you just wipe it off the entire BlackBerry system by sending out the offending signing key?

    • Hi Squished,
      Sadly the code signing does not allow RIM to do that. They can revoke the developers ability to create/sign new signed applications but it does not invalidate current applications nor does it stop them from releasing unsigned apps for smartphones. They might be able to do this with App World on the PlayBook but that is something they could do without code signing so once again it adds no value yet adds a cumbersome extra step that deters developers.

      I am not saying that we should throw it out but if this is one of the main things that turns away BlackBerry developers it has to be worth the cost by adding just as much or even more value. Don’t you think?

      • OK, I misunderstood the value of these keys then. Perhaps RIM could establish a two-tier system where developers could opt-in to code-signing which earns them a “BlackBerry Certified” designation. Entry-level developers who want zero pain in getting started can get going without a key, but “BlackBerry Certified” would offer a marketing and trust tool for more serious developers.

        On a side note, I’m just finding out how exposed the WebWorks model is to piracy and reverse-engineering. Isn’t that a huge barrier for serious development on that platform. Why can’t RIM implement some code obfuscation/encryption within the packaging process that gets unpacked within the QNX-based OS before being interpreted. Wouldn’t that offer developers some protection for their code and an advantage compared to Android?

  2. Code signing on IOS is just as complicated. It can take weeks to get from registration to being able to sign your app for distribution. Apple even requires you to FAX documents to them and don’t accept a scan via e-mail. Oh and it costs $99.

    Code signing on Android is a joke. Devs can create their own code signing keys, and enter just about any info they like.

    Code signing for BlackBerry has improved a lot over the past year or so. It’s relatively straightforward now. If any dev has trouble with it, I really don’t want their apps on my device.

    This article confuses the topic with other issues. Code signing is not meant to protect the code from piracy, but from tampering en-route. It means that a hacker can’t impersonate a verified dev. The verification process is by definition a little complicated, because it requires the dev to prove he is who he claims to be.

    • Hi Jon, I didn’t mean to imply that it is any better on other platforms. It is just not one of the number one complaints from developers on those platforms. The issue I am pointing out is that there is very little to no added value for having code signing since anybody with a credit card can sign code. For RIM’s next generation platform, BlackBerry 10 and PlayBook, the only person who has the opportunity to modify of tamper the code en route is RIM who anyways has the ability to sign your code however they wish since the only delivery method is through App World.

  3. Typo in the signing server url, no ‘code’ included.

  4. I agree with you that it is annoying to go through hoops just to get the app. I think the code signing keys should provide more features then to verify identity.

BlackBerry© is a registered Trademark of BlackBerry Limited. BerryReview is in no way affiliated with BlackBerry Limited though sometimes their lawyers send us love letters...

Copyright © 2007-‘2018’ BerryReview LLC