Best practice to encrypt data in an Android application

Question

I'm writing an application which recovers statistical data about a user. I'm still pondering about what would be the best way to encrypt the data. I haven't got any experience with mobile applications. But I was thinking of hardcoding an RSA public key and encrypting it in that way before sending it over the net.

Another guy working on the project suggested AES and hardcoding the pass phrase, but that seems to be a bad approach to me as a hardcoded password might be found through decompilation of the program. (I doubt someone would do it but just in case).

Are there any other approaches which would be better suited (setting up a ssl connection is not an option unfortunately) ?

I'm also still thinking about how I could provide integrity, I was thinking of hashing the file and then zip the whole package of message + hash into one file before encrypting it. If you have a better solution please feel free to share.

Answer 1

I'd just use SSL with a hardcoded public key of the server. Nobody on the way can manipulate or read what you sent. No need to invent your own protocol.

But of course the user himself can manipulate and read the data this way, but solving that is a DRM problem and not a security problem.

I believe BouncyCastle can be used for that Android. I prefer TLS 1.2 with a DHE AES128 based ciphersuite, but depending on what your server supports, you might need to downgrade to a lesser suite.

Answer 2

Implementing your own ad-hoc-ish crypto solution is not a good idea. You'll probably get something wrong. (For instance, AES with a hardcoded passphrase is terrible. Anyone can get the passphrase by just downloading the app and extracting the passphrase. I don't know why you doubt anyone would do it.)

I recommend that you use standard, well-vetted solutions. If you have a communication channel you need to secure, use SSL/TLS. If you want to protect stored data, use GPG/PGP/OpenPGP. There are libraries and code available for both of these that should make them easy to integrate into your software.

Answer 3

I'd probably opt for the solution the OP mentioned, and make use of RSA and only have the public key in the application. You generally want to avoid the application being able to do both encryption and decryption (particularly with a hard coded key) because the key will eventually get out. If user input is possible, then symmetric crypto is possible as well.

Reverse engineering tools to look for well known encryption and hash functions via the sboxes in use exist, and from there it's usually pretty straightforward to extract the keys if you store them in the binary.

Just keep in mind that rsa is quite slow, which is one of the reasons most uses of it involve using it to encrypt a symmetric key which is used to do the actual cryptography.

Answer 4

I'm still pondering about what would be the best way to encrypt the data.

If you want to store the data on the device itself you can ask for a user password and derive a symmetric key using a key derivation function. Bcrypt and PBKDF2 are well known examples.

Answer 5

The best way to encrypt data is not on the client-side. By HTTP POST'ing the data via a properly-configured TLS 1.2 tunnel, one can be sure of network confidentiality. By implementing strong secure development practices (e.g. OWASP ASVS L4) along with periodic, but stringent testing (e.g. advanced application penetration-testing using Burp Suite Professional, wXf/Buby, and fuzzdb) -- one can help prevent server-side compromise, although certainly this is not limited to just development, but also secure deployment, secure operations, etc. ISO 27k programs are normally suggested for these kinds of environments.

It is not usually wise to store any data on the client-side that would represent a compromise of personal or application-critical specific information -- encrypted or not. For example, storing (or even keeping in memory for too long) active credentials to a banking application -- especially along with usernames, passwords, real names, account numbers, etc... is an absolute no-no.