Is it possible to utilize the android keystore daemon on ICS without a device PIN?

Question

I've been using Nikolay Elenkov's blog (http://nelenkov.blogspot.com/2012/05/storing-application-secrets-in-androids.html) to store encrypted password information in our android application. The requirements are such that we a) don't want to store the key/salt in our code directly, because this can be decompiled/removed, b) need to support back to android API level 14, and c) need to store password (encrypted) information on the device (i.e. can't currently use an OpenAuth token or similar system, as it would require server changes that can't be made right now).

So, on JB 4.2+ devices, I can utilize the newer secure credential storage, which doesn't cause any problems. For JB 4.1 and ICS devices, though, I need to use the aforementioned method of interacting with the keystore daemon through nelenkov's techniques.

The problem here is that when the secure credential storage is initialized, it requires that the user set up a device password/pin, as it uses this to base the encryption key used for the master storage off of. This is kind of a bad deal, because it is a big hindrance for the user.

Alternatively, I've looked at using a separate key store, based off of SpongyCastle. The problem with this direction, though, is that I would need to initialize it with some password (likely stored in my source code). This would mean that, if the device were stolen/rooted, it would be relatively easy to procure the contents of the "secure" key store, as the password could be retrieved from the app's decompiled source.

Is there a better solution to this problem that I'm not seeing, or is it just not possible with API versions < 18?

Answer 1

There are really only two ways to do this: either the user enters some kind of password and you derive your keys from it, or you generate a key and store it on the device. Using the device unlock password is a lot more user-friendly than having the user remember a dedicated password for your app only. BTW, on 4.2+ you still need a lockscreen password so nothing is changed compared to 4.0. As usual, if the device is rooted, the attacker can get the user's Google authentication tokens, and bruteforce the lockscreen password so you'd have much bigger problems. So think about your threat model first and decide how far you are willing to go. If the data is truly sensitive, use a dedicated password with sufficient complexity that needs to be entered every time the app is opened. You can also write a device administrator and require that the device is encrypted, that the lockscreen PIN/password is sufficiently long/complex, etc.

The alternative is to use tokens, either your own or from a third party identity provider (Google, FB, etc.).