I am creating a mobile app for Android. This is my first mobile app by the way.

I have decided to store data used in my app in a SQLite database in the target Android device.

The data I am storing is about user's financial data so I have decided to encrypt data before storing into the database. But I don't want to drain all the mobile phone resources to do the encryption and decryption.

BouncyCastle will do the trick. But I am worried if someone de-compiles the code, get the security key and decrypt data. Is there any alternative for this. Any of your ideas are welcome.

  • 1
    If you want password protected encryption you should take a look at PBKDF2 (use a sample implementation). It will turn an entered password into a key usable for encryption, and the key needn't be stored in the app. – Henning Klevjer Dec 7 '12 at 8:50
  • You should also considered an encrypted database implementation (check out sqlcipher.net). There a few out there that are well tested. The less crypto code you have to implement yourself the better. – Ben Holland Feb 13 '13 at 2:47

Don't embed a hard-coded key into your application; that provides little more than a trivial obfuscation for anyone that reverse-engineers your application.

To generate a key for encryption, use a key-derivation algorithm such as PBKDF2, which essentially performs hundreds of rounds of a hash function on a password, combining the results together to produce a secure key. To help understand why you need a key-derivation algorithm, take a look at this other answer.

The benefits of PBKDF2 are:

  • Configurable number of rounds, to tailor computation speed to your device whilst maintaining a reasonable security margin against brute-force.
  • Provable security, i.e. it is at least as strong as the underlying hash function.
  • Can produce any size key.
  • Easy to implement (there's already a Java implementation for you)

Essentially you let the user put his/her password in, then compute the key using PBKDF2, then use that key to decrypt/encrypt the data.

Now, as far as the actual encryption goes, I highly suggest sticking to something easy if you've not dealt with crypto before. Block ciphers have to be used in a mode of operation, and require an initialisation vector (IV) in order to be secure. There's a lot of implementation details that have to go exactly right in order for it to actually be secure, so in this case I suggest reading various other questions around here to understand them further.

  • The main weakness in this approach is in the password. It is quite inconvenient to enter difficult and complicated password on a mobile device, so most of the users will probably use short and easy passwords. As a result it may be possible to effectively crack the encryption key, even though PBKDF2 is used to derive it. Moreover in one application I've tested the encryption key was derived from the PIN, which is totally bad idea. – pgolen Dec 8 '12 at 20:20
  • Thanks very much both for posting for my question. I have implemented what "Polynomial" was saying. But I think I need to suggest some few things. It sounds bit immature because I am not an expert in this area. First I am using the password to generate the key but at the same time I am using randomize salt to make it even harder to crack the encryption. But say I have done this and if the user would change his/her password what will happen. This will make things complex, will it(previous encrypted data become inaccessible?) Need your thoughts on this. Thanks very much. – Thusitha Nuwan Dec 10 '12 at 11:18
  • 1
    If a user changes their password, require them to re-enter their old password. This allows you to decrypt their data, then re-encrypt it with a new password, and doubles up as a protection against an attacker changing the password on an unlocked device. You should also generate a new random salt whenever they change their password. – Polynomial Dec 10 '12 at 11:46
  • Good!!. Thanks for the idea. I will implement that too. I have also changed my initial plan to move the data storage away from the phone to the cloud. Is there any harm doing this. I see number of advanatages. But I'm looking forward for your thoughts on this. The security module I have created so far is not very stable, but I will push that to my GIT repo shortly.I will keep you guys up-to-date. If you can kindly review my code in the GIT, that would be much appreciated. Thanks very much. Nuwan – Thusitha Nuwan Dec 11 '12 at 3:21
  • YES, there absolutely is tangible harm in shifting the data to the cloud. As ruled recently, you have no rights to your data in the cloud, so the US govm't can seize, destroy, modify or distribute that data in any way they like. Encryption will prevent them from reading it in most cases, but you most certainly lose all of the integrity and reliability of your data. – Polynomial Dec 11 '12 at 6:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.