-
Notifications
You must be signed in to change notification settings - Fork 431
Hardware Supported Keychain for Lollipop+ #103
Comments
We'll look into the keychain from Lollipop. Do you have any docs of where the storage of keys changed to hardware backed keys? The last time i checked the android keystore stored keys protected by the unlock password. |
👍 for the feature. |
Yeah most of the Keystore stuff is pretty late API, we could have it fallback to shared preferences. A lot of the keystore stuff, as I understand it, is broken even on APIs that support it. From my experimentation it's very difficult to rely on a particular handset having the proper encoding or keytype support. There is going to have to be a lot of testing and graceful fallback to ensure operation. |
Android 4.3 is vulnerable https://securityintelligence.com/android-keystore-stack-buffer-overflow-to-keep-things-simple-buffers-are-always-larger-than-needed/ Is it actually safe to use the default SharedPrefsBackedKeyChain to store the KeyChain? If someone roots the device, wouldn't he be able to access the keys and be able to read the encrypted values? Cheers! |
I can see a beginning of answer in this thread: |
Using the system keystore probably is not a good idea. The fragmentation is one issue, but there's also the design goal of "Extraction Prevention" - key material is not available to the application process. So if you're not using the "standard" android/java API's for encryption, you can't access the key. This means alternative implementations like Conceal or the crypto used by Realm, are pretty much out of luck - http://developer.android.com/training/articles/keystore.html#SecurityFeatures |
Thanks, so is there any way to use Conceal with a safe way to store the encryption key? |
Based on previous discussion, I assume that the purpose of Conceal is to provide easy encryption mechanism, but the burden to store keys is purely on user shoulders ? The case I want to protect users against: phone is stolen - data should not be retrieved (assuming that phone was already rooted). Let's imagine, that keys are in One can say that password-derived encryption key is a good idea, but then you have to cache password hash somewhere in order to avoid necessity of user login on each application launch. So, the solution I see (for Android) is to have user data encrypted by password-derived key which is cached on the file system and thus vulnerable (actually, it does not really matter if it's password-derived or not) I'm not a security specialist, so want to hear thoughts from you guys :) |
Hi @Vandalko, I am trying to cover the same scenario than you but moved onto other stories for now. |
What do you all think about this idea? Using the AndroidKeyStore, create an RSA key pair (see https://developer.android.com/training/articles/keystore.html#GeneratingANewPrivateKey). This will work on SDK 18+, and gives you a public and private key, stored in the secure hardware (assuming the device has the secure hardware). We can't get the private key bytes back out, and we can't use RSA keys with AES, but we can get the public key as a byte array, as not being able to share that would be... problematic given the whole concept of asymmetric encryption. As long as the public key isn't shared anywhere, the byte[] of the public key can then be used as input into PBKDF2 (https://android-developers.googleblog.com/2013/02/using-cryptography-to-store-credentials.html) to generate an appropriate AES key as needed. For example, you might sign a device id with the private key and base64 encode the signature as the password, and then use the public key as the salt. And then you can use Android's built-in require authentication for key use features (https://developer.android.com/training/articles/keystore.html#UserAuthentication). |
Hello, that sounds interesting. It's true that how Facebook manages log-in (user is not challenged if already logged in) makes difficult to protect data for current logged in user in case of a stolen phone. If you have other app that behaves differently then you could use the user-challenge (pin, password, something) to generate a key which protects the real data key. There's a project I'm on but wasn't first on my priorities for now. It involves leveraging the Android KeyStore when possible. The idea is similar but as everything else in computing involves another step of indirection. KeyStore doesn't allow the user to retrieve data from it. But it can generate RSA pairs and you can use it (it doesn't allow symmetric encryption in old versions at least). But you can use that to encrypt the data key in internal storage. Let use names: DEK = data encryption key, this is what Conceal would use for the data you want Therefore:
When app needs the key (at least first time, later it can cache it in memory), it can ask the KeyStore to decrypt the EDEK from disk with its KEK. The issue with this is that supposedly the Android KeyStore might be wiped if user changes the phone screen lock. That means app should need a backup mechanism to restore the DEK. If you're ok with asking user to login again, then the same mechanism of having a EDEK can be applied with a server provided KEK, or with a key derived from the user password (using PBKDF). But yes, if you are ok with having a backup method of challenging the user in case the KeyStore is wiped out, this scheme would be totally usable. |
Can we get a KeyChain class that implements the hardware keystore instead of shared preferences?
The text was updated successfully, but these errors were encountered: