Jonathan Nobels, Research In Motion
Security: Who Needs It?
There is a mantra at Research In Motion (RIM) that goes as follows:
“Never ignore the top three concerns of your corporate customers. In order, these are security, security and finally... security.”
The design of the BlackBerry platform, indeed the architecture of the Java Virtual Machine upon which the BlackBerry Platform is built, owes much of its existence to this mantra.
Security is a broad term affecting many aspects of any wireless solution. To an enterprise customer, security could mean limiting access to confidential information and systems. To a network operator, security often means guaranteeing the integrity of their networks. To an end user, security typically means that personal information cannot be compromised, applications do what they are expected to do, and the user is only billed for things they have explicitly agreed to pay for.
In designing the BlackBerry platform, RIM recognized that in many instances, these visions of security conflicted. Many applications, by their very nature, require unfettered access to personal data or network Resources. At the same time, access to these Resources creates significant security concerns with the various stakeholders. Power users may not want to be hassled for permission every time an application wishes to open a network connection, and enterprise developers may not wish to submit their applications to scrutiny by a third party.
To address their security concerns, some network operators are choosing to lock down their networks to only specific “network-certified” applications. MIDP 1.0 addresses security by severely limiting the APIs available to the developer, but at the same time severely limiting usefulness of the platform. Many other operating systems have chosen to use the PC model, forgoing most security controls and putting the responsibility for handling security on the user. This latter approach can create a support problem for wireless network operators.
RIM's Controlled API Java architecture was created as a compromise between these extremes. Recognizing that developers require flexibility, and that IT managers and users will demand to be masters of their own destiny, RIM implemented the notion of “controlled APIs” with BlackBerry 3.6.
BlackBerry Code Signing 101
The BlackBerry API set is subdivided into five distinct classifications.
The first of these classifications is the set of “Open” APIs. These APIs include all standard Java APIs from MIDP and CLDC, as well as many BlackBerry-specific APIs. The open API set is, as the name implies, open for all developers. Applications developed that use only open APIs require no signatures of any sort.
The remaining classifications are all “Controlled” APIs. These APIs fall into four categories pertaining to their specific use:
- RIM Runtime APIs
- BlackBerry APIs
- RIM Cryptography
- Certicom Cryptography
There is a security risk associated with every class and method in these APIs. For example, the BlackBerry API allows a developer to access the user's Personal Information Manager (PIM) data, which may be a security risk to the end user. The RIM Runtime API allows the developer to send SMS messages, a potential security risk to the network operator and the end user.
To help control these risks, any application that uses a Controlled API will not run on a BlackBerry handheld unless the application is properly signed.
How Do Developers Sign Applications?
Prior to granting access to any of the Controlled APIs, RIM requires the developer to go through a simple registration process during which the developer's identity is verified. The developer needs to download and fill out a registration form from www.na.blackberry.com/eng/developers/downloads/api.jsp then fax it to RIM. Once the registration form and associated processing fee has been received, RIM will send the developer a set of keys via email. These keys can be used in conjunction with the Signature Tool utility in the BlackBerry JDE to sign any application.
The signing process itself is very straightforward. After compilation, the developer manually starts the Signature Tool , which displays a list of necessary signatures. With a single button press, the Signature Tool submits a hash of the application to RIM's signing authority. The signing authority automatically returns the required signature, which is automatically appended to the application. The application can then be loaded onto a handheld.
Detailed instructions related to installing keys and running the signature tool can be found in the BlackBerry Java Developer Guide, Volume 2 - Advanced Topics.
A Few Things to Remember...
In order to run applications that use controlled APIs on a handheld, you must first get it signed by RIM. At no point in the signing process does RIM receive a copy of your application, only a hash of the file(s). The application itself is not reviewed by RIM and the signing is completely automated. Should an application later turn out to have malicious intent, RIM will be able to determine the author of the application by matching the hash of the application against records of the hash kept by RIM signing authorities.
As a developer, your key is your identity. Do not give your keys to others or let others use your keys to sign their applications.
When you register for your keys, you will get three emails from RIM, one from each of the various signing authorities (with the exception of Certicom Crypto). Follow the instructions in the BlackBerry Developer Guide carefully. Also, when you request your keys, you provide RIM with a PIN number. This PIN is used in conjunction with the keys when first contacting the signing authority to ensure that you, and only you, can use the keys that you have been assigned.
To receive a key for the Certicom Cryptography APIs, RIM requires confirmation from Certicom Corp that you have a license for Certicom's Security Builder Toolkit v3.0.
Keep in mind that you do not need to register with RIM to use the JDE or to simulate applications. Applications do not need to be signed to run on the BlackBerry simulator.
Why a $100 fee?
A $100 fee is charged to sign applications. This fee is only charged once to receive a set of keys. There is no fee for each subsequent use of thek eys.
There are two reasons for the fee. First, a legitimate credit card account and a successful transaction help us verify the identity of the registrants. Second, it helps us offset some of the costs of running the program. The expectation is that this small fee is not a burden to legitimate developers, but creates a moderate disincentive for any developer with malicious intent.
So Where is the Benefit for Developers?
RIM has made every attempt to ensure the code signing process presents as minimal a barrier as possible to legitimate developers. While the initial request for keys requires some paperwork and a small administration fee, from that point on the developer has full access to any of the APIs they have registered to use.
In building this system, we hope we have achieved a balance that gives developers the freedom they require in terms of development and deployment while imposing legitimate and useful checks and balances to ensure that all other stakeholders are comfortable with the BlackBerry platform.