Question

Since starting to learn about mobile computing I frequently missed discussions about security. However, it seems to me that this is a major topic for mobile computing. There are certain aspects to developing a secure mobile application:

1. How to create save communication between device and server?
2. How to identify a device and how to authenticate a user on a mobile device?
3. How to handle the possibility of device theft and ensuing misuse of data stored on the device and access granted to the device?

There are probably more, but those are the key questions, I think. So far I have come up with this solution:

1. SSL.
2. Use OAuth to grant access to the device, then store the access token AES-encrypted. Check the user’s identity before allowing him access to the app by requesting the decryption key (most likely a PIN as those are more easy to enter on a mobile device).
3. If storage of data is unavoidable, use AES encryption. Either use the key mentioned in 2. or alternatively store the decryption key on the server and have the app request it from there every time. In case of theft revoke the OAuth key. (This will also prevent the thief to retrieve the decryption key from the server.)

Do you see any flaws in this approach or see any points where the strategy could be improved? I tried to find a balance between usability and security, as it seems they are opposing concepts.

Note: This is meant as a general concept, not specifically designed for one operating system.

Answer 1

This is open-ended and very general, so SO might not be the best place. Do you really think you can summarize this in 3 bullet points? You cannot even try to promise security without specifying concrete guidelines, parameters and practices.

1. ‘Use SSL’ means nothing by itself. There are a hundred ways to misuse SSL: trust every certificate, use weak ciphers, use vulnerable protocol versions (SSLv2, etc.), don’t check revocation, etc., etc.
2. Using AES doesn’t guarantee much either: you might be open to attacks if you use ECB mode, or re-use the same IV in CBC mode, or your IV is not truly random (real example: TLS tried to cut corners with this one), etc., etc.
3. If you store you encryption key on a server, that’s just another attack vector: do you really trust the server (how do you make sure it’s your own one?) to store/manage your key?

So, yes, lots of potential flaws, and the answer is simple: it’s not that simple.