How to securely store sensitive data on mobile application?

Question

I want to develop a mobile bank app (Windows Phone, Android, iOS) that interact with a bank channel.

First time when user opens application the key exchange process begins and at end of this process a long-term SymmetricKey generates and must store in mobile device. All of request that sends to server encrypt with this key. If someone can steal the SymmetricKey he/she can hijack the user session. In simple way I can store SymmetricKey in plain text format. another solution is that define a MasterKey in Code (Hardcode) and encrypt the SymmetricKey with the MasterKey. but in this solution there is exists exactly one MasterKey for several instances of app that installs on different devices. If someone can decompile the mobile app code and retrieve MasterKeyhe/she can retrieve SymmetricKey Again, what is the best solution for store sensitive data in mobile application?

I read about some method that belongs to mobile os that guarantee that data is securely stored but all the of them needs to user set Profile Account (eg : Protect() and Unprotect() in Windows Phone that needs Hotmail account to be set).

Can I generate different master keys per different device?

Answer 1

Just use TLS, it's what it was meant for: securely send data between two parties across an untrusted channel.

Should you want additional protection, there are two ways to solve this problem that spring to my mind:

• Use a password to encrypt the symmetric key
• Use a token such as an OTT through SMS or generated using a smartcard and external cardreader with a challenge/response

The first option will password protect the symmetric key, the side effect is that the only secure way of implementing this is that the password is only saved temporarily in memory. This will require the user to input his password to decrypt the symmetric key every single time your program requires to use it.

The second option is what I've seen implemented plenty of times and does not require a key to be stored on the device. They use the bankaccounts card and an external card reader. You generate a challenge server side and send this over TLS (don't forget certificate pinning!) to your user. The user inputs the challenge in the card reader which generates a response. Client then sends the response to the server which can be verified by the server.

Remember that it's all about risk assessment, the likelihood someone is able/wanting to go as far to get your mobile app needs to be assessed. As a first recommendation ensure that you build in checks to verify if the device is rooted/jailbroken or not. If you find that the phone is jailbroken simply do not allow usage of your app and make sure to put it in the terms and conditions that the risk of loss of money is the client's responsibility when using jailbroken/rooted devices (allthough you still also need to account for reputational damage).

Make sure you have plenty of sanity checks server side as well to see where money is going. If suddenly a user is sending way above average amounts of money to accounts in Eastern European countries, it might be a good idea to temporarily block the transaction and actively call the customer to see if he intented to send that money.

Answer 2

For android phones, there is a credential storage that allows you to store keys. It runs as a system daemon and uses AES to encrypt the keys. The keys are tied to the UID of the app that created it so other rogue apps are unable to access these keys.

For iOS, there is a similar keychain which serves a similar purpose. It is also encrypted and sandboxed so applications can only retrieve their own keychain items.

Do not store the symmetric key in plain text. Although application storage in android is only accessible to the app itself, there is a probability that user may move the app to the SD card which is then fair game for all apps with the permissions to access the SD card.

I do not think a master key is necessary since the credential storage and keychain both provide encryption already.

However, it might be good to use the symmetric key as a shared secret to negotiate a new session key for every session probably through Diffie–Hellman. This allows you to have perfect forward secrecy.

Lastly, you would be dealing with skilled adversaries trying to compromise the app since there is a financial incentive. I would suggest you seek professional advice. Not to discredit the community here but the risks are quite high.

Answer 3

I suggest you should distribute the key in more than one place. For example

Symmetric Key:

• divide the keys in two parts
• save first part on device and second part in server
• when user successfully able to login by using OTP/SMS then provide second part of key and encrypt/decrypt whatever sensitive information you want.

Asymmetric Keys

• You can use Asymmetric keys too, where two keys involved (Public-private key pair)
• One for encryption and other for decryption
• Send Public key and second part private key to server
• Then process is same as Symmetric key.