SQLCipher: How to protect the Key?


#1

I understand SQLCipher has good encryption. However, if your Android App passes the SQLCipher key on SQLiteDatabase.openOrCreateDatabase call, then the attacker can see the Java code and get the key. Then he would use SQLCipher by himself using the same key (even the key is internally hashed and is not the real key, it is the only input needed here).

Is there a way to better hide the key? Say, if I could set the key from native code, then it would be harder to find the key by static analysis.
So I would call openOrCreateDatabase, get the db handler and pass it to C code through JNI. From C, I would generate a new key and then call sqlite3_key(db_handl, new_key, len);
Is this possible? How to get the db_handler from Java?

Thanks!


#2

Hello @nocker,

We don’t recommend hardcoding the key into an application, as it’s just not suitable for any secure implementation. No matter what you do, if the key is hardcoded and the attacker has the installation package, they will be able to find it and use it to access the data, no matter how well you obfuscate it.

SQLCipher is really intended to be used where key material is not included in the application package (i.e. not for use as DRM). In this model the key material comes from somewhere else (e.g. from the user in the form of a pin or password, or from some other means like a key service, secure keystore, etc.)

For more information, please see this related article on Database Key Material and Selection.


#3

Hello @nocker check this demo for secure your key

http://www.informit.com/articles/article.aspx?p=2268753&seqNum=4

we take reference of this link for security purpose.
we getting the key from the .so file, by the support of ndk.
in this link it provide file detail for generating the .so file.
first, we need to create jni folder, then create 3 files with named respectively “Android.mk”,“Application.mk”,“sqlndk.c”.
you have to create new “.so” file using nkd-build command from terminal.


#4

Hello @sarfaraj_makvana

Please note that the article you reference shows one of several possible ways to disassemble a native library that contains the source of the password. Anytime you store the password anywhere the potential of a security breach increases. The amount of security necessary for any given application should of course be considered when discussing key management options.