In parts one and two of this series on security, we discussed IT Policy and Application Control. Today, we’ll discuss the final piece of the puzzle with code signing. More accurately, let’s return to the dialog prompt that grabbed your interest in the first place:
“This application does not contain a signature. It might not be from a trusted source. Do you want to proceed?”
This message has nothing to do with IT Policy and nothing to do with Application Cotnrol – it’s shown to the user because your application has not been code signed. There are two types of code signing, carrier code signing and RIM code signing. For MIDlets, carrier code signing keys are applied to JAR files and will remove all MIDP security prompts (including the prompt above), but does not bypass IT Policy or Application Control permission prompts. Carrier code signing will grant your application the MIDP 2.0 permission set:
RIM code signing keys can be applied to any COD file, be it a MIDlet or a BlackBerry® Java application. There are three categories of APIs that require code signing, RIM Runtime API (RRT), RIM BlackBerry Apps API (RBB), and RIM Crypto API (RCR). An example of each would be the APIs to retrieve a phone number, the APIs to insert menu items into native applications, and the cryptography libraries. Functionally, you don’t really need to be aware of the differences between the three, since when you perform code signing on an application, the Signature Tool will automatically determine which signing keys are required for your application. To request code signing keys, you’ll need to complete the registration form found here. Again, it’s important to note that applying code signing to your application will not bypass a company’s IT Policy or Application Controls, but it will allow you to use protected APIs and it will also remove all MIDP security prompts, including the message relating to not being from a “trusted source.”
We’re nearing the end of our three part series on security, so let’s quickly review what we’ve covered.
IT Policy is a device-wide level of security for an enterprise that defines user behaviour on the BlackBerry smartphone. For the purposes of a consumer application developer, your application will really only be affected in the case where an end-user’s BlackBerry smartphone is connected to a BlackBerry Enterprise Server and their company has a strict IT Policy that defines policies like the one that prevents third party applications from being installed on the smartphone.
Application Control is a very fine-grained level of security that defines application behaviour on the BlackBerry smartphone. Your goal as a consumer application developer is to provide the best possible user experience while still adhering to the rules set out in the BlackBerry security model, achieving this goal by leveraging the APIs available to you.
RIM code signing allows your application to access protected APIs on the smartphone, but does not bypass the BlackBerry security model.
Hopefully this series of posts have helped you gain a firm grip on security. You should now have all the information you need to provide your users an optimal user experience. It’s time to take your solution to market, sell it with confidence, and don’t ever let a security prompt ever come between you and what you’re trying to achieve.