Best way to secure Android app sensitive Data?

Question

Yes this is a pretty general question but I'm trying to get a feel for the best way to handle an app that touches base w/ a webserver that distributes sensitive data to the app. Any links, general information advice etc.. would be appreciated.

Since the app would store persistant data retreived from the database for a certain amount of time.. everything becomes somewhat touchy.

Answer 1

Storing sensitive data on the device

That depends very much on your audience. Normally, the Android OS prohibits apps from accessing each other's files (i.e. databases, preference files, regular files stored in the app's private directory) through proven Linux file permissions. However, on rooted devices an application can obtain root access and read everything. A few things to think about:

1. If you know your users won't have root (e.g. if you are not distributing the app through Android Market, but only in your company, or something like that), you can simply rely on Android's filesystem-based security.
2. If a user does get root access, he will be very careful what application he gives that priviledge to
3. If an app does get root access, it can wreak a lot of havoc. The information in your app could be the least of the user's worries.
4. Rooting leads to zero warranty. Including in apps. You can't be held responsible for leaking information on a rooted phone.

To conclude, if your information is not super-duper sensitive (e.g. credit card information), I'd suggest just sticking with the default security provided by Android (i.e. save everything in plain text, knowing other apps can't access it).

Otherwise, encryption is the way to go. It's not 100% secure (a hacker could de-compile your app and figure out how to decrypt the data), but it's a major pain to crack and will stop most hackers. Especially if you obfuscate your code with something like ProGuard.

---

Transferring sensitive data from the server to the device

You have a few options here. First of all, always use HTTPS. After enabling HTTPS, here are two extra security measures I would propose:

1. Use an API key system. Include this API key in all your requests and check it on the server side before sending any response back. Remember that since you're using HTTPS, an attacker would not be able to just use a network sniffer to find out your API key. However, this is pretty easy to figure out if someone decompiles your app, which is why you can obfuscate it even further (besides using ProGuard). For example, you can keep the API key broken up into pieces all around your code (for example as static members in two or three classes). Then, when you send a request, you just concatenate all those pieces. You can even apply some other sort of transformation (e.g. bit shifting) to make it even harder to figure out from the decompiled code.
2. You can generate a key every time you send a request. That key would be generated by using a bit of logic that only you know, so that you can implement it client- and server-side as well. For example, a request could include the following parameters:
   time=1321802432&key=[generated-key]
   where generated-key is generated from the time parameter. For example: md5(time + salt). When the server receives this request, it can do two things:
   1. Check that key is indeed equal to md5(time + salt) (note that only the client and the server know the salt and it can be obfuscated similarly to the API key above), and
   2. Check that time is not too far back in the past (e.g. if it's more than 1-2 minutes in the past, consider the request invalid).

The second method is more useful if you are also doing plain HTTP requests, where everyone can see the parameters being sent. Also, it's much harder to figure out from decompiled code. Especially if you spread the key calculation logic across multiple classes.

However, note that nothing makes it impossible to crack your app. You can obfuscate as much as you want, if a hacker is really determined to get to your data, he will be able to so by decompiling your application and spending many sleepless nights passing through your code and figuring out how the requests are formed. The only real way of securing your data is by asking your user for a password, besides doing all the work I wrote about above. You can't get a password that only exists in someone's (the user) head from decompiled code :).

Answer 2

(Came here thanks to a Google search)

I've been researching this a lot lately and this page has come up a lot thanks to Google and Bing searches. The widely-accepted procedure for storing data on the device securely has been to use a strong encryption algorithm like AES. The harder question is "AES requires a secure key. What do you do with the key?"

Google recently announced a cloud-based storage solution for apps, so you could consider storing the key there if the situation allows. Otherwise, its seems that getting the key outside the device, like on a server, is better. If you can make the user punch in a PIN, that would actually work the best. You can do password derivation in order to store the password, and you can redo the derivation to verify the password

Without the "user punching in a PIN" part, I haven't found a lot of good answers to that question. However, DO NOT HARD-CODE THE KEY IF YOU MUST STORE ONE WITH THE APP. At the minimum, generate a key using a secure password generator and/or a derivation function like PBKDF2 (Password-based derivation function 2).

If I read the posts correctly, Google did say that one approach is to generate a key once the app starts the first time, store the key via the MODE_PRIVATE flag to a lot of file I/O operations, and use that as the key. You can also derive other keys based on that master key, and the NIST actually suggests something along that lines.

Whether or not to trust the master-key method, I'll leave to you. This key would get exposed on a rooted device. I'll also admit that I'm still researching the issue