Resco Connect: meetup in Las Vegas, September 17
Resco Mobile CRM security
The Resco Mobile CRM app was designed with a particular focus on security.
Local storage
The local storage encryption is enabled by default and cannot be disabled by the user. The administrator can use the Woodford tool to disable the encryption via Configuration (Use Database Encryption parameter), but this is not recommended.
User password
The main security token for the application is the application password. The application uses this password to encrypt the application database, as described later in more detail.
In case of legacy authentication methods which require the app to submit the user’s password to server (standard user, external user), the server password is used as an application password for user’s convenience. With the OAuth2 authentication, the user must provide a dedicated application password. Regarding password storage, the app can be configured to either:
- Require the user to enter the password each time the application is launched (or resumed from background), or
- Store the password in the device secure storage so that the user does not need to type it in repeatedly.
Explanation:
The device's PIN protects the secure storage so that it cannot be decrypted until the device is unlocked. The device secure storage implementation is platform specific.
- iOS secure storage (keychain) security: https://www.sit.fraunhofer.de/fileadmin/dokumente/studien_und_technical_reports/sc-lost-iphone-keychain-faq.pdf
The device's PIN prevents access to the device. Most platforms allow for the PIN to be disabled, in which case the application should not rely on storing the password in the device secure storage.
Data encryption details
Data encryption is based on an application key. The application key is randomly generated and protected by the user password. The key is used to encrypt all local CRM data. The details of this procedure are explained below.
The application generates the random application key when it creates its local database. Afterwards, it is stored in an encrypted form on the device file system and the application decrypts it when needed. The application key AES256 is used together with the user password (PBKDF2), a random IV and salt for encryption/decryption.
The following explains how the application key is used to secure application data. Remember, there are two data stores: the database and the blob store (attachments).
For encrypting the SQLite database, the application key is passed to the SQLite database driver. The driver uses the application key and IV to encrypt/decrypt individual database pages using AES128 in CFB mode. Each page (1024 bytes) is encrypted separately. The IV is the page header (contains variable/unpredictable data). Each file in the blob store (attachment store) contains a header with random IV (16 bytes) and encrypted data. The blob data is encrypted with AES256 in CBC mode using the application key, file header IV. PKCS7 is used for data alignment.