We’re working on an app that requires local data to be encrypted. Till now, the solution has been using the username/password combo to be the ultimate source of the encryption key (I’ll spare you the process of going from u/p to key, but safely assume its sufficiently boring and secure). The u/p combo is kept in memory, so if somebody stole the device, assuming the password was sufficiently complex, its beyond unlikely that they’d ever crack it.
Now we need to implement some form of SSO. That means we don’t get the password. Only some form of key to use when talking to the server, which changes periodically, and is generally not used for the hacky thing we want to use it for.
We *should* be able to keep the Encryption key in the KeyChain, and tie it to the lock screen, but as far as I can tell, that’s not possible (if so, PLEASE correct me). That would let us enable the lock screen and do what we want to do.
Since this app needs to be secure, enabling the lock screen is pretty much a given anyway.
However, its all more work than it needs to be. We *could* force the user to encrypt their whole disk, but that’s a crazy long process, and we couldn’t programmatically verify the disk was encrypted (again, I think we couldn’t. Please correct if I’m wrong). Without being able to verify, this wouldn’t fly. Plus, nobody would be OK with the process.
If I could have one wish for my birthday (its not my birthday), it would be a way to enable local data encryption for a single app. All of it. When you go to run the app, it dumps into the same sequence as when you go to add a cert to the KeyChain (or something similar). You are forced to enable the lock screen (assuming you haven’t, of course). The Android runtime then encrypts/decrypts your data seamlessly.
That would be sweet.