9

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.

Thusitha Nuwan
  • 193
  • 1
  • 1
  • 5
  • 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 07 '12 at 08:50
  • You should also considered an encrypted database implementation (check out http://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 02:47

1 Answers1

11

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.

Community
  • 1
Polynomial
  • 133,763
  • 43
  • 302
  • 380
  • 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 08 '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 03: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](http://yro.slashdot.org/story/12/11/02/1737219/us-government-you-dont-own-your-cloud-data-so-we-can-access-it-at-any-time), 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 06:59
  • But I see there are number of pros when storing data in a remote data storage. My initial plan was to store data in my own database and use Rest API for data transmission. But I'm not sure these legal restrictions still apply if I own the data storage and access those data via Rest API deployed in a remote server. – Thusitha Nuwan Dec 13 '12 at 04:56
  • @ThusithaNuwan Anything "business records" stored on a server in the US is open to theft by the government, and they recently ruled that customer data on cloud storage is a business record. – Polynomial Dec 13 '12 at 06:52
  • @Polynomial Regarding forgot password, what if user don't remember his/her old password? how should we handle the data in this scenario, will data get lost forever? – dcool Apr 24 '15 at 12:10