What is the recommended way to handle the encryption key for the database on Android?

SQLCipher
1

Hi all,

I want to use SQLCipher to encrypt my local database on Android.
By reading docs and docs on the web I can’t find a clear recommendation on the handling of an encryption key.
Using SQLCipher without a proper pattern for the encryption key is worth nothing as far as I understand, so I am trying to find the best practice.

Options:

  • Write the key in the code -> Not secured, can be found by reverse engineering.
  • Save the key in the shared preferences -> Not secured, can be found if Root access.
  • Save the key in the Android KeyStore -> so so… Android 4.2 has a vulnerability on this, but we can accept this.
    Also you can use it without passing a user generated password (example: https://android.googlesource.com/platform/development/+/master/samples/ApiDemos/src/com/example/android/apis/security/KeyStoreUsage.java)
    Can anyone explain?
  • Derive the key from a user input (PIN number for ex).
    Do you guys have a good example of a way to generate the key from this (salting function??)
    If I want to access the database from a background service while the tablet is at rest, since the user is not there to input the PIN, I can’t do anything with the DB, right?

Do you have any other suggestion?

Thanks!

2

Hi @Fabien_Demangeat

Key management is a difficult topic, and the implementation for an application often varies based on the security requirements of a given application. You are correct that storing the password within the application binary or shared preferences is an insecure approach. You can certainly consider mixing user provided, or device provided data into the password. SQLCipher utilizes PBKDF2 to transform the provided password into the key material used for encryption. You are correct that your application would need to provide the password in order to access any data. If the security constraints of your application allows for it, you may consider caching the password in memory to allow for those extended use cases.

3

Hi,

Forgot to say thank you, so thank you for your reply :slight_smile:

Fabien

4

Hi @Fabien_Demangeat

We are glad to help, take care!