Permissions are determined per-application and
assigned based on the application’s signature or a policy specified by
the user. Most APIs are not considered sensitive and can be accessed by
unsigned applications. The sensitive API set includes APIs for accessing
personal information manager (PIM) data, phone features, operating
system configuration, and the network. Applications that use these APIs
may have to be signed, depending on whether the sensitive API is an MIDP
or CLDC API, or a RIM proprietary API. Sensitive APIs that are
proprietary to RIM and not part of MIDP2 are known as RIM Controlled APIs.
Remember when testing on
simulator that unless security is explicitly enabled, none of the
security behavior discussed in this section will be enforced. Make sure to turn on simulator security when exploring how the OS and permission systems behave.
RIM Controlled APIs
RIM Controlled APIs are
divided into different API sets, each with a unique signing authority.
The three most common signing authorities are abbreviated as follows:
RCR (RIM Cryptographic Runtime) Includes the majority of RIM’s cryptographic APIs. Public key cryptography APIs require a different signing key from Certicom.
RRT (RIM Runtime API) Provides access to sensitive platform functionality, such as the Application Permission Manager.
RBB (RIM BlackBerry Apps API) Provides control of built-in BlackBerry applications (for example, the BlackBerry browser).
Applications that use more
than one controlled API set are signed with multiple signatures. For
example, an application that uses the BlackBerry browser and the
Application Permission Manager will have both RRT and RBB signatures.
The signing infrastructure is extensible, and third-party developers can
add their own signing authorities to control access to their APIs by
using the BlackBerry Signing Authority Tool. Regardless of the signing
key required, the security behavior is the same.The term RIM Controlled API
is used for any API that requires a signature from a signing authority.
When developers purchase signing keys from RIM, they receive
authorization for signing from the RCR, RRT, and RBB authorities.
In addition to
signatures required for accessing RIM Controlled APIs, two BlackBerry OS
features also require signatures: applications that automatically
launch on BlackBerry startup and BlackBerry system modules. If these
features were allowed, unsafe code could run as startup and either
monitor the user’s actions or commit an effective spoofing attack to
steal important information.
Before an application is
allowed to run, it must pass a Java verification stage to ensure that
the application uses well-formed Java instructions and does not use
dangerous Java features such as Java native invocation or reflection.
Disallowing these features ensures that the application does not load
dangerous code or bypass class access restrictions to call or create
prohibited methods. There are three stages to this validation:
Compile Time Verification
All code instructions and class references are verified using standard
Java verification. This step ensures that well-formed Java instructions
are used throughout.
Link Time Verification When
the COD is loaded onto the BlackBerry, it is linked with the platform
APIs. If the COD file links against any RIM Controlled APIs and does not
have an appropriate signature, then the linker refuses to link the
binary. The application will still be loaded onto the device, but will
fail immediately upon startup (see Figure 1).
Run Time Verification Checks
are performed whenever the application invokes a RIM Controlled API.
These checks prevent malicious code, or legitimate code that has been
exploited, from accessing RIM Controlled APIs or bypassing the
application permissions system.
The combination of verified
Java code, code integrity, and per-API access control is powerful for
security. These mechanisms enable sandboxed applications and enable
users to control how those applications use data on the device.
Before getting
too excited about the BlackBerry’s signature-based security
architecture, remember that code-signing certificates are cheap and do
not require an extensive authentication process. Requiring signatures
increases accountability and enables code integrity, but a signature
does not guarantee the signed code is well written or nonmalicious. The
only foolproof mechanism to avoid malware is to avoid installing
third-party applications altogether.
Signatures are required for at least one class contained within each of the following RIM packages:
| net.rim.blackberry.api.blackberrymessenger | net.rim.device.api.bluetooth |
| net.rim.blackberry.api.browser | net.rim.device.api.io |
| net.rim.blackberry.api.browser.field | net.rim.device.api.io.http |
| net.rim.blackberry.api.browser.plugin | net.rim.device.api.ldap |
| net.rim.blackberry.api.homescreen | net.rim.device.api.smartcard |
| net.rim.blackberry.api.invoke | net.rim.device.api.system |
| net.rim.blackberry.api.mail | net.rim.device.cldc.io.ssl |
| net.rim.blackberry.api.mail.event | net.rim.device.api.notification |
| net.rim.blackberry.api.menuitem | net.rim.device.api.servicebook |
| net.rim.blackberry.api.messagelist | net.rim.device.api.synchronization |
| net.rim.blackberry.api.options | net.rim.device.api.applicationcontrol |
| net.rim.blackberry.api.options | net.rim.device.api.lowmemory |
| net.rim.blackberry.api.pdap | net.rim.device.api.memorycleaner |
| net.rim.blackberry.api.phone | net.rim.device.api.file |
| net.rim.blackberry.api.phone.phonelogs | net.rim.blackberry.api.maps |
| net.rim.blackberry.api.spellcheck.SpellCheck (Class) | net.rim.device.api.gps |
Signing BlackBerry Applications
BlackBerry signatures
use public key cryptography and a RIM-managed online signing service. To
sign code, developers must have a public/private keypair and have
registered that keypair with RIM. The following step-by-step guide
describes how to get RIM signing keys and what happens along the way:
Fill
out the form and provide payment information. As part of this
registration process, a PIN will be required. This PIN is essentially a
password for the user account and will be used by the signing authority
to associate cryptographic keys with the account.
After
the form is submitted, a few days will pass while RIM processes your
order. Assuming that everything is acceptable, the signing
infrastructure will send three e-mails—one for each of the RCR, RRT, and
RBB signing authorities.
Attached
are CSI files. These are text files that include the developer ID, the
nickname of the signing authority (for example, RCR), and the URL for
the signing web service. If the JDE is installed, CSI files are
automatically associated with RIM’s Signature Tool. Double-clicking on
the CSI file will launch the Signature Tool and start the
key-registration process. These CSI files don’t really have any key
material in them and are used to tell the Signature Tool about the
signing authorities that exist.
Once
the Signature Tool opens the CSI file, it checks to see if the
developer already has a public/private keypair. If not, the developer
will be asked whether they want to generate one. This is pretty fun,
because RIM makes you move the mouse and pound the keyboard to collect
entropy. At the end of the generation process, a password is required.
This is used to encrypt the keypair and protect it on disk.
Once the public/private keypair is generated, the signature tool asks for your RIM signing authority PIN.
The
PIN and the public key are used to create a message that is then sent
via HTTP POST to RIM’s signing authority servers. This message contains
the public key, the developer’s signing authority ID, and cryptographic
data to ensure the message’s integrity. The curious can watch these
messages in Wireshark. The server records the relationship between the
user ID and the public key. This way, RIM does not need to generate the
private key directly. The same public/private keypair can be registered
with all three signing authorities.
Steps 5–8 must be repeated for each CSI file until all signing authorities are registered.
Getting
signing keys is the first step in creating RIM signed applications. To
actually sign code, use the RIM Signature Tool, which is bundled with
the JDE and Eclipse plug-in. To run the tool from Eclipse, build the
application and then select Request Signatures from the BlackBerry menu.
This will launch the Signature Tool with the currently selected project
already loaded, as shown next. If you’re not using the Eclipse plug-in,
the Signature Tool can be launched as SignatureTool.jar from the JDE’s
bin directory. The COD file will have to be loaded manually. To do so,
click the Add button and browse to the COD file.
An individual application
may not necessitate code signatures from every signing authority. For
example, if the application does not use cryptography, then a RIM
Cryptographic Runtime (RCR) signature is not required. The Signature
Tool inspects the application and determines which keys are required. To
request signatures from the required signing authorities, click the
Request button and enter the private key’s password. Behind the scenes,
the private key is used to create a digital signature of the
application, which is then sent via HTTP POST to the appropriate signing
authorities. If they accept the signature, they will sign the response
and return a signature of the signature. The Signature Tool adds this to
the COD file.
By being online, RIM is able to
monitor the signing process and control the number of times an
individual signing key may be used. RIM can also respond to compromise
and refuse signatures if a key is known to be compromised. Every time a
signature is requested, an e-mail will be sent to the signature key’s
owner summarizing what was signed and who signed it. This e-mail also
contains the number of signatures remaining. Standard developer keys may
be used a little over two billion times.
Programmatically Managing Permissions Using the Application Permissions Manager
If
an administrator or user has denied an application permission to access
certain functionality, the application can read or request permissions
using the
net.rim.device.api.applicationcontrol.ApplicationPermissionsManager
class. This class is a RIM Controlled API and is therefore restricted to
signed applications.
The following example demonstrates requesting access to use Bluetooth and the Phone APIs:
ApplicationPermissions ap = ApplicationPermissionsManager.getInstance()
.getApplicationPermissions();
ap.addPermission(ApplicationPermissions.PERMISSION_BLUETOOTH);
ap.addPermission(ApplicationPermissions.PERMISSION_PHONE);
ApplicationPermissionsManager.getInstance().invokePermissionsRequest(ap);
For a more in-depth example, review the ApplicationPermissionsDemo project included with the JDE.
