Protect iOS Database information

Question

I am busy writing a commercial electronic words-dictionary type of app for iPhone and iPad iOS7. The value of the app is really in the database that I worked many years on, and not so much the app itself. The database is very large (195mb on a windows computer before converted to something like SQLLite) and I and would like to know what is the best way to protect the data in it so the app can read it but other people cannot read/get to it. It seems most mobile developers use SQLLite, but the data can easily be read with a normal hex editor on it.

From this forum and others I gathered that SQLCipher is a good tool. My problem is that it SEEMS that SQLCipher encrypts the database, and then decrypts it when it needs to be read in a temporary file and then encrypt it again afterwards. If this is the case, I have two problems.

1. The database is very large and to decrypt it every time and encrypt again is going to make the app very slow.
2. What stops a hacker from reading/copy the decrypted (temp) file when it's available even for a short time?

Do I understand SQLCipher's working correctly, if so, is there any other tools/methods to encrypt/protect a database so that the program can still read it with SQL Queries without making the data so easily available in any way, or any other suggestions you might have?

Thank you

Answer 1

According to this page: http://sqlcipher.net/design they don't decrypt your database as a whole, so the answer to your question #1 is no. They claim about 5-15% overhead to the standard SQLite performance.

As for #2 - SQLCipher will decrypt database in pages, so theoretically - somebody can get access to that page in memory in decrypted way. However this would be true for any encryption method you use. Just think about it - even if you decrypt full database, your application would need to display/access some data from it, somehow at some point. And at this point data must be decrypted. The only question here - how much of the data will be decrypted at given moment.

The other alternative you have is to try to implement ecnryption/decryption yourself using standard SQLite and standard ecnryption library. You can for example encrypt each row (or even fields with sensitive data) individually and decrypt them when needed - but then again, at certain moment this particular row will be in the memory decrypted and visible to hacker.