IssueTracker

Same issue with some Samsung Galaxy Note 3(android 4.4.2) and nexus 5 (4.4.2). If the user changes screen lock (from PIN to password or simply changes his PIN) the keyStore is deleted.


I tried a test application at https://github.com/nelenkov/android-keystore (a "backport" for older android version using unsupported API and java reflection) and it works fine on android 2.3 ---> android 4.3 but not on KitKat devices

This issue makes impractical de use of the AndroidKeyStore, because it is not possible to control if the user changes the pattern.

With this bug, there is no secure way (such as provided by iOS) for an application to store its secrets.
Please, urgently provide a fix.

Samsung S5, LG Nexus 5 are also affected.

All the Android devices are affected by this bug.

Not sure this is in to-do list of Android team, meanwhile if anybody have any solutions to workaround this issue please share.

Tested on Android L dev preview and this issue is not present

[Comment deleted]

[Comment deleted]

When you say 'this issue is not present' in android L version does it mean:
1) that data is not deleted when you locking mechanism or lock screen pattern is changed?
2) that you will be required to set a pin when you store data in android key store? (this functionality was also broken in kitkat)

Is not entirely clear to me what is the function of screen lock pin in AndroidKeyStore. My understanding is that is only used to lock/unlock access to key store data, and not used for encryption. I assume that this is not used to encrypt the data store in key store, and master key for encryption/decryption are provided by a software/hardware backup available from 4.3 onwards.

It seems that the screen lock in AndroidKeyStore IS required to encrypt. See the comment in https://developer.android.com/reference/android/security/KeyPairGeneratorSpec.Builder.html#setEncryptionRequired()

Anyone found a workaround about that, it is really a big issue for me, because I use this to decrypt sensitive data stored in the app, and because, KeyPair is re-generated, data cannot be decrypted anymore ...

Tested on L preview (Nexus 5). I see the same behavior as reported. As soon as I switch from Pattern to PIN, the keystore seems to get reset.

This is a very bad news so ... IT shoult be something in the KeyStore API that password/pattern/pin should be or not associated with the KeyStore to reset it or not on change. Less secure I guess, but at least it is working.

Hi,

we have tried with the latest Android L emulator released last Friday and the
AndroidKeyStore seems to work when a new certificate/private key is generated by
an application and stored inside the AndroidKeyStore with a screen lock enabled
( Pattern, PIN and Password).

For instance, if the user changes from PIN to Password, the keypair generated by
the application is not deleted.

At the same time, being the option in the Security Settings disabled, as shown
in the attached image, the user can't change the screen lock to None or Swipe.

In this way, a keypair can be deleted only by the application that has generated
it, by uninstalling the application or by removing all the user credentials by
choosing "Clear Credentials" from the Security Settings.

 mobilesecuritylab, #15 sounds like a new bug, please file a new issue. feel free to reference it here for discoverability.

Working with Android version 5.0 ,
Use case 1: No screen lock is set (its either None or Swipe)
Now app use AndroidKeystore stores keypair , now if user sets screen lock to pin or pattern we loose the keys again.

Use case 2 : User has screen lock set, behavior is as mentioned by #15

Is having screen lock type set a prerequisite to use this provider ?  or is it a bug .
And also if user can clear credentials , then again this is not usable by the app to store its private keys.

Created a new bug https://code.google.com/p/android/issues/detail?id=83218  as suggested by #16

Hi, adding my testing info here too in case its useful.

I have tested on a Nexus 4 running 5.0.1 and a Samsung Galaxy 3 running 4.3.

General Platform Behaviour

The 5.0.1 device WILL wipe the keystore when going from

None -> Pin
None -> Password

and will NOT when going from

None -> Pattern
Password -> Pin

The 4.3 device WILL wipe for ALL the above.

Annoyingly the above behaviour is not deterministic is its behaviour in how it works out when a keystore 'wipe' is due and what this means. This manifests in two ways

1) Sometimes when a wipe is expected i.e. the 5.0.1 device going from None -> Pin the keystore is still valid. I saw this twice in maybe ~15 tests.
2) When the KeyStore is wipes this can result in one of two things happening with the below code

final KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
final KeyStore.PrivateKeyEntry entry = (KeyStore.PrivateKeyEntry) keyStore.getEntry(alias, null);
KeyPair mPair = new KeyPair(entry.getCertificate().getPublicKey(), entry.getPrivateKey());
Cipher cipher.init(Cipher.UNWRAP_MODE, pair.getPrivate());
cipher.unwrap(blob, "AES", Cipher.SECRET_KEY);

Most of the time the last line will throw a InvalidKeyException (~95%)

Caused by: java.security.InvalidKeyException: javax.crypto.BadPaddingException: error:0407106B:rsa routines:RSA_padding_check_PKCS1_type_2:block type is not 02
at com.android.org.conscrypt.OpenSSLCipherRSA.engineUnwrap(OpenSSLCipherRSA.java:340)
at javax.crypto.Cipher.unwrap(Cipher.java:1545)

Occasionally it will throw an IllegalArgumentException instead (~5%)

Caused by: java.lang.IllegalArgumentException: key.length == 0
at javax.crypto.spec.SecretKeySpec.<init>(SecretKeySpec.java:62)
at com.android.org.conscrypt.OpenSSLCipherRSA.engineUnwrap(OpenSSLCipherRSA.java:333)
at javax.crypto.Cipher.unwrap(Cipher.java:1545)

It seems that sometimes it will remove the key(pair) and some it will just get the incorrect key value (I guess due to the user supplied encryption key changing). The alias for the pair seems to persist through all of this so its a bit annoying to detect - my method is to try and use the keypair and if it dosent work lead the user through a process of setting up the data encrypted with this key pair again, not ideal but I dont see another solution at this point.

imho the platform should just detect when the device security settings have changed and migrate the encrypted key pairs. These should never be wiped unless the user requests it. Maybe easier said than done!

Have written a post on this problem http://systemdotrun.blogspot.co.uk/2015/02/android-security-forgetful-keystore.html

This issue can be replicated using existing Google apps in both KitKat and Lollipop (as of 5.0.1):

Use either the BasicAndroidKeyStore sample (http://developer.android.com/samples/BasicAndroidKeyStore/index.html)
or the ApiDemos (https://android.googlesource.com/platform/development/+/master/samples/ApiDemos or
https://play.google.com/store/apps/details?id=com.hmh.api&hl=en)

BasicAndroidKeyStore:
1. Tap "Create" to create a hardware backed RSA keypair.
2. Tap "Sign" to create a signature based on the internal string.
3. Tap "Verify" to verify the signature.
4. Change the user Security Mode (see below)
5. Tap "Verify" to verify the signature (see below).

API Demos:
1. Tap "Security"
2. Tap "KeyStore"
3. Fill "Entry alias" with a key name (e.g. "testkey")
4. Tap "Generate" to create the key
5. Select the generated key entry at the top of the screen
6. Fill "Plaintext" with some test text
7. Tap "SIGN" to create "Ciphertext"
8. Tap "VERIFY" to verify "Ciphertext" (text turns green on success, red on failure)
9. Change the user Security Mode (see below)
10. Tap "VERIFY" to verify "Ciphertext" (see below)

In KitKat (4.4.x), any change to the security mode, including something as trivial as switching from "Swipe" to "Swipe," invalidates the keystore, so the last step of both tests above fail.

In Lollipop (5.0.1), some combinations work, but not all:

All Users:
None -> Anything: Keys lost
Swipe -> Anything: Keys lost

Owner:
Pattern/PIN/Password -> Pattern/PIN/Password (None/Swipe disabled): Keys retained

Non-Owner User:
Pattern -> Pattern: Keys retained
Pattern -> PIN/Password: Keys lost
PIN/Password -> PIN/Password: Keys lost

Any news, feedback, alternatives from Google would be welcome here. Because for now, we can't provide any Security promise that data would be secured and remains valid no matter what the user is doing with his phone.
For now it's secured without any guaranty that he will be able to get it back if Key is deleted...

Hi, as others, i have observed the clean of keystore by switching the security.

But i encountered more strange behavior on kitkat OS.

When switching from a password to a Swipe policy, mthe keys are lost, but worse at reboot, the keystore is still locked under the older password. ( it can be unlocked through this screen: startActivity(new Intent("com.android.credentials.UNLOCK"));

This has been observed on a Galaxy S5 mini and an HTC one M8. Although behaviour somewhat changes.

If i reintroduce a password policy on the M8, keystore is unlocked.
If i reintroduce a password policy on the S5, keystore is still locked with the old password, until i use the "com.android.credentials.UNLOCK" screen.

I precise that i do not requires encryption for my keys.

With the new M preview we have the below

"Keys which do not require encryption at rest will no longer be deleted when secure lock screen is disabled or reset (for example, by the user or a Device Administrator). Keys which require encryption at rest will be deleted during these events."

From https://developer.android.com/preview/behavior-changes.html#behavior-keystore

This is great and I will test myself next week when I get my hands on a n5.

#24 I'm not sure the situation has changed much?

"[...]Keys which require encryption at rest will be deleted during these events."

The Keystore loses a lot of utility if the keys it owns aren't encrypted at rest

#25

I havent flashed M yet but it looks like the sentence I quoted would apply to 5.* anyhow.

Even if keys in the keystore are not encrypted at rest they would still be protected by OS level security so it would still have use. Better than storing keys in app filespace anyhow.

We are using SQLCipher to encrypt the sqlite database in our Android app and we are using the Android keystore to store the private key we encrypt the database password with.  We have run into an issues where the keystore becomes unusable with either an "java.lang.IllegalStateException: could not generate key in keystore” or an “java.security.InvalidKeyException: javax.crypto.BadPaddingException: error:0407106B:rsa routines:RSA_padding_check_PKCS1_type_2:block type is not 02” when we attempt to use it.  We are wondering if anyone has a recommended work around for either of these issues that would allow us to continue using the keystore?

Was wary of answering this as obviously this is a bugtracker and not a SO like Q&A site. However I do think its relevant to this bug (which seems to now be a feature) as the presence of this behaviour makes it very inconvenient to actually use the keystore. From my research #20 everything works fine for main device users on 5+ when encryption is required from the keystore. However #21 mentions the behaviour changes for devices with multiple users - I will test this. If targeting < 5 there is no option but handle the fact you may lose access to the DB at any time, and therefore access control would either need to not use the keystore or you would need to have some backup / restore process in place for when this case occurs. Options on the latter would be many.

Here http://stackoverflow.com/questions/35987510/illegalargumentexception-unparseable-date-during-androidkeystore-key-generatio I described also very strange behaviour which produces IllegalArgumentException during key generation. Anybody knows how to deal with it correctly?

This issue, besides critical, is also two and a half years old. Google, either fix it or explicitly state it's actually a feature.

cool)

Nice to see a regression here and some good old backwards progress (in M). Outlined http://doridori.github.io/android-security-the-forgetful-keystore/

Related bug listing https://code.google.com/p/android/issues/detail?id=210402&thanks=210402&ts=1463676837

I think this issue was mostly fixed in Marshmallow, in large part by the deprecation of the setEncryptionRequired() method. The behavior of keys when apps use setEncryptionRequired(true) has been stabilized; you should no longer see key loss when you change from one sort of lock screen to another... but keys *will* be deleted if the user removes their lockscreen and those keys were created with setEncryptionRequired(true). That is what the documentation for that method says must happen, and we can't break that security guarantee.

However, I strongly encourage developers NOT to use setEncryptionRequired(). It never provided much security, and with our move to using keymaster in the TEE to secure keystore keys it's not completely irrelevant. The fact the deletion behavior of keys with that option has been so inconsistent across various Android releases also makes it almost impossible to use the option safely. It was deprecated for both of those reasons, and will be removed completely as soon as is practicable.

Thanks a lot for your comment, #35!

One question: Should we read the
"It never provided much security, and with our move to using keymaster in the TEE to secure keystore keys it's not completely irrelevant."
as
"It never provided much security, and with our move to using keymaster in the TEE to secure keystore keys it's *now* completely irrelevant."
?

Can someone clarify what 'moving keymaster in the TEE to secure keystore keys' means and wether it impacts security ?

Hello, same question here: what does "moving keymaster in the TEE to secure keystore keys" means?

Thank you for your feedback. We assure you that we are doing our best to address all issues reported. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with the bug report here https://goo.gl/TbMiIO and reference this bug for context.