What would be a valid approach to store private keys?

Question

I'm implementing a mobile app which uses AES encryption algorithm to encrypt some critical values being sent to a remote server (basically, the user password), and then decrypted on the server side using the same private key. This works perfectly now, but I'm a bit concerned about how to store/get the private key.

Currently, I've splitted the private key (which is hardcoded) into 3 string objects, and when needed, I concatenate them. I'm afraid this is not a valid solution, though, as any malicious user could simply decode the binary and with a bit of patience get the three parts.

The questions are:

• What would be a good approach which at least would make it difficult to the attacker to know the private key?

• Would help using a private key based on an event (for example, the current date) instead of storing it?

Answer 1

Instead of building your own AES solution, look at TLS/SSL to encrypt the password being sent to the server. If you build your own solution as you propose, anyone who cracks your app will be able to read all your users' passwords (and if it secures actual money, people will try to crack it.) TLS securely exchanges keys with the server as a part of the protocol, resulting in a communication channel that is very resistant to eavesdropping.

If you have some actual reason to encrypt data locally with AES (not involving communication to the server), then if you're building your app for iOS you should be using Apple's keychain API. I'm not sure what the Android equivalent is, but I believe there is one. This uses OS level support to hide your secret data. It's still vulnerable to hacking, but as you can make it random per user, at least a break on one mobile device won't compromise the security of all your users.

If you don't have OS support for storing a key, then you're ultimately stuck with an obscuration solution. Personally, I'd XOR several values to build the key instead of concatenating fragments of a string, but if someone's going to debug the app and discover it, they're going to discover it regardless. That means you shouldn't use this to protect any secret regarding the customer's money, accounts, finance, health, credit, retirement, or other records that should be properly secured. In other words, this might be fine for a game that doesn't involve the customers' wallet (or your wallet, for that matter.)