Content Security on BlackBerry Devices

In general, all mobile workflow files and extra data entered by the user, or retrieved from the server, are stored on the BlackBerry device’s PersistentStore.

This is the same storage area used by e-mail, calendar entries, and applications. See your BlackBerry documentation for information about persistent store APIs.

The BlackBerry mobile workflow container uses the RIM PersistentContent APIs when reading and writing of data from PersistentStore is required. This ensures that the content being written is stored at the device’s current encryption level. See your BlackBerry documentation for information about content protection strength settings.

When content protection is turned on, content on the BlackBerry device is protected using the 256-bit Advanced Encryption Standard (AES) encryption algorithm.

Use 256-bit AES encryption to encrypt stored data when the BlackBerry device is locked
Use an Elliptic Curve Cryptography (ECC) public key to encrypt data that the BlackBerry device receives when it is locked

These settings apply to the encryption of data that the BlackBerry device receives while locked:

Content protection strength setting	ECC encryption key length (in bits)
Strong	160
Stronger	283
Strongest	571

The BlackBerry mobile workflow container also registers a PersistentContentListener, which allows it to be notified when the device’s encryption level changes. This also enables previously stored content to be re-encoded to the new encryption level setting. The device’s encryption level setting can be changed by a BlackBerry Enterprise Server Administrator remotely, or by the user, from the device.

Mobile Workflow Files

Mobile workflow files include all the files contained in the <workflow_package_name>.zip that is deployed to the device, including all HTML, JavaScript, CSS, and any other files that may be included as part of the Workflow zip package. When the platform’s browser control requests these Web files, they are read from the device’s PersistentStore and passed to the browser control in memory, which means there are no temp files.

Attachments

If attachments, such as *.docx, *.pdf, and so on, are part of the <workflow_package_name>.zip deployed to the device, they are stored on the device’s PersistentStore:

When the JavaScript requests to display these attachments, they are read from the PersistentStore, and temporarily written unencrypted to the device’s flash memory for the external viewers to display them.
Once the mobile workflow application closes, these temporary attachment files are immediately removed.

Attachments that are downloaded using an online request that use an object query are stored unencrypted in the device’s flash memory for the file viewers to display them. Once the mobile workflow application closes, these temporary attachment files are immediately removed.

Cached Online Requests

The results of online requests that are specified to be cached are stored on the device’s PersistentStore. Cached results are removed when the mobile workflow package is unassigned from the device, or uninstalled from the server.

Notifications From the Server

Notifications from the server are stored in the same PersistentStore area, including the payload that makes up the notification. When the notification is acted upon, the JavaScript makes a request for the notification contents. This is read from the PersistentStore and passed to the browser in memory.

User Input Sent to the Server

When the device has no network connectivity, and the user submits a mobile workflow for the server to process, the data destined for the server is queued up on the device. This queue is part of the device’s PersistentStore.