Mobile Application Security : BlackBerry Security - Local Data Storage

The BlackBerry’s file system is a virtualized view of flash memory and external media cards. Data is saved on the file system using the MIDP2 record store or IOConnector classes, or RIM’s proprietary PersistentObject interface. The file system is relatively flat, but there are security rules as to which areas of the system signed and unsigned applications can read from and write to. For the security nut, almost everything can be encrypted using the BlackBerry locking password.

Files and Permissions

The BlackBerry OS’s file system is laid out somewhat like a traditional Unix file system, with the exception that there is no root directory. “File:” URLs are used for referring to individual files, and URLs must contain the physical storage location. For example, file:///store/home/user/pictures/pretty_picture.png references an image file within the user’s home directory on the device’s internal storage, also known as “store.” Other storage locations include SDCard and CFCard.

The BlackBerry implements simple file-access restrictions, and not all files are readable or writable by all applications. For example, unsigned applications can write files under the file:///store/home/user directory but not under the operating system location file:///store/samples. To explore the file system, download and install BBFileScout from http://bb.emacf1.com/bbfilescout.html. BBFileScout is a donation-supported application for browsing the file system and performing basic management tasks, including copying, deleting, and moving files. Because BBFileScout is signed, it provides a lot of information about what signed applications are able to do on the file system.

Programmatic File System Access

BlackBerry Java applications use the javax.microedition.io.file.FileConnection API to directly access the file system. For security reasons, some file locations are inaccessible by this API, including application private data, system directories and configuration files, and RMS application databases (http://www.blackberry.com/developers/docs/4.7.0api/javax/microedition/io/file/FileConnection.html). Unsigned applications can browse the file system, but the user will be prompted each time the application accesses the file system.

To test the ability to read and write individual files, use the following sample code:

try {
    String fileURL = "file:///store/home/user/pictures/my_pic.png";
    FileConnection fileConn =
(FileConnection)Connector.open(fileURLs[i]);
    // If no exception is thrown, then the URI is valid,
    // but the file may or may not exist.
    if (!fileConn.exists()) {
        System.out.println("File does not exist");
        fileConn.create(); // create the file if it doesn't exist
        System.out.println("Was able to create file");
    } else {

        System.out.println("File exists");
        if (fileConn.canRead()) {
            System.out.println("File is readable");
        }
        if (fileConn.canWrite()) {
            System.out.println("File is writable");
        }
    }
    fileConn.close();
} catch (IOException ioe) {
    System.out.println(ioe.getMessage());
}

					  

Structured Storage

The BlackBerry OS provides three forms of structured storage: MIDP2 RecordStores (a.k.a. RMS databases) and RIM’s proprietary PersistentStore and RuntimeStore.

RMS databases have the advantage of being MIDP2 platform compatible and usable by unsigned applications. The downside is that they can only store 64KB of data per store and require the application to manually marshal objects to and from byte arrays. Pretty archaic, but still useful. To program RMS, use the javax.microedition. rms.RecordStore class. Each RecordStore is named with a unique identifier that must be local to the MIDlet suite, but does not have to be unique to all applications on the device. On other MIDP2 platforms, you can share RMS databases between applications by publishing a RecordStore with a well-known name. The BlackBerry only allows sharing between the same MIDlet suite.

To share data between applications, store more data, and not have to worry about byte array serialization, use RIM’s PersistentStore or RuntimeStore classes. These are RIM Controlled APIs. The PersistentStore is stored in flash memory, but the RuntimeStore lives in RAM and will be erased when the device resets. To use the PersistentStore, classes must implement the net.rim.device.api.util.Persistable interface, which describes any special serialization actions required.

Objects are uniquely identified using a data identifier that is stored as a JME type long. By default, objects are readable to anyone who knows the object’s data identifier. To keep objects private, wrap them in a ControlledAccess access object and associate a CodeSigningKey with the wrapped object. Only applications signed with the public key represented by the CodeSigningKey will be allowed to access the persisted object.

Encrypted and Device Secured Storage

The popularity of the BlackBerry in government and enterprises makes on-device encryption a necessity, and the BlackBerry’s secure storage options are extremely advanced.

Content Protection

To encrypt sensitive messaging and contact data stored on the BlackBerry, use the BlackBerry’s content-protection feature. Content protection encrypts data when it is written to flash memory using a key generated from the unlock password. Because there would be no way to generate the key without a password, the user is required to specify an unlock password. All communication data is encrypted by default, including e-mail, calendar information, browser history, memos, tasks, and SMS messages. Users can optionally encrypt the address book, which has the interesting side effect of causing caller ID to not show the name of incoming callers when the device is locked.

Three keys are used by content protection to protect data (refer to http://na.blackberry.com/eng/deliverables/3940/file_encryption_STO.pdf). There’s an ephemeral AES key for unlocking keys, a 256-bit AES key for persistently stored data, and an Elliptical Curve Cryptography (ECC) public/private keypair used for encrypting data when the device is locked. The length of the ECC key can be changed in security options and can be up to 571 bits long. The ephemeral AES key is generated from the device lock password and is therefore only as strong as the password itself. The ECC public key is kept in memory while the device is locked and encrypts all incoming data. The public key has to be used because the AES storage key is wiped from memory as soon as the device is locked. By only keeping a public key in memory, the BlackBerry protects against attackers who are able to read the device’s memory directly. When the user unlocks the device with their password, the ephemeral key is used to decrypt the AES storage key and the ECC private key. The ECC private key is then used to decrypt all of the data that arrived while the device was locked; before being written to persistent storage this cleartext is encrypted with the AES storage key. It is a lot of jumping around, so simply remember this: Data is encrypted with a key that comes from the unlock password, so have a good password!

Keys must be held in accessible memory for some period of time if they are going to be used to perform all of these encryption operations. The BlackBerry can be configured to scrub sensitive data from memory when the device is locked, holstered, or idle. To enable the “Memory Cleaner,” open Options | Security Options | Memory Cleaning and change the Status setting to Enabled. The time window and events that determine when the Memory Cleaner daemon runs can be adjusted, although the defaults are probably adequate. Also notice the list of registered cleaners. The Memory Cleaner system is extensible, and applications can register for memory-cleaning events using the net.rim.device.api.memorycleaner.MemoryCleanerDaemon RIM Controlled API. Once registered, the application will be alerted whenever the daemon runs and should then clear its memory of any sensitive information. When handling encryption keys and other sensitive data, make sure to take advantage of this functionality.

Removable Media Protections

Many BlackBerry devices include memory card slots for storage expansion. The smaller these cards physically get, the easier they are to lose, and the more protected they need to be. BlackBerry can encrypt documents and media files stored on removable media using the same content protection mechanism as is used on the primary device. Not all file types written to the memory card are encrypted, and neither are files written to the card by another source (for example, a computer).

There are three modes for protecting external media:

• Device The BlackBerry uses a cryptographic random number generator to generate the external memory encryption key. If the card goes missing, but the device stays in the owner’s possession, then anyone who finds the memory card will be unable to read it because the key is still on the device.

• Security Password The user’s device password is used to generate an encryption key for the device. This is the weakest form of protection because users choose poor passwords and attackers who get the Secure Digital (SD) card can perform offline grinding attacks against the encryption key. The grinding attack does not work against the main BlackBerry device password because the device will wipe itself after the specified number of invalid attempts.

• Security Password + Device A combination of the device password and a randomly generated per-device key is used to encrypt the memory card. The combination of the two key-generation methods prevents the attacks possible against each one alone.

Cryptographic APIs

The BlackBerry cryptographic suite is comprehensive and includes classes for working with low-level primitives (such as AES and SHA-1) and high-level constructs [for example CMS messages and Secure Sockets Layer (SSL)]. All cryptographic APIs are RIM controlled, and most of the public/private key APIs require a Certicom signature. Unlike many other portions of the RIM’s software development kit (SDK), the Crypto API is extremely well documented. For more information about the Crypto API, review the documentation at http://www.blackberry.com/developers/docs/4.7.0api/net/rim/device/api/crypto/package-summary.html. For a sample application that performs 3DES encryption and decryption, review the cryptodemo included with the JDK.