Security Approach

(Our original thoughts on the android security approach can be found here)

The approach has been broken down to cover a variety of different scenarios

Scenario 1:

The following diagram illustrates how we plan to deal with securing the data held on the android device in a fully connected scenario (where the android device has an active connection to the rapidFTR server)

Explanation:

• the android device will use a SQL Cipher DB (which in turn has an underlying sqllite databse) - SQL Cipher allows us to encrypt a database with a key.
• When logging in, as well as sending the login data, the android device will also post the IMEI of the mobile device
• the server will have an additional database table which maps an IMEI to a db_key (a generated UUID which will be the encryption key for the database on the device)
• the server will authenticate the use as before, and if successful, it will then retrieve the "db_key" for the IMEI provided, and send it back
• the android device can then use this key to access the DB

notes

• in order to prevent a user from accessing all data on the device, we will need to record the username against records saved so that we know who a record belongs to.
• the UUID is not generated based on any user data, it is a randomly generated UUID.

Scenario 2:

This scenario assumes that the user has no connectivity when attempting to log in (and so cannot retrieve the db_key from the server). HOWEVER, this scenario assumes that the user has at some point previously logged in successfully via the device

###Explanation:

To support this scenario we need to go back and modify the logic when fully connected. The first time a user logs in successfully

• the android device will now have a second, regular SQLite database, in addition to the SQLCipher DB.
• this second database will have just 1 table, which maps a username to the db_key, however the db_key has been encrypted with the users password. (Note that just the field has been encrypted, not the entire DB)
• we need to keep in mind what happens when a user changes their password and modify this table (decrypt with old password and re-encrypt with the new)
• When the user attempts to log in, we get the encrypted key from this DB and use the password to decrypt
• this alone will not tell us if the password is correct, so once we have the decrypted key, we then need to use it to attempt to access the main database, if successful, we know the user entered the correct password