Encryption / KeyStore Failure Fallbacks [Community Feedback Requested]

[tylerjroach]

Describe the feature request

Amplify Android has received reports of crashes during EncryptedSharedPreferences initialization.

• AndroidKeystoreAesGcm.encryptInternal #2939
• The master key android-keystore://amplify_master_key exists but is unusable #2845
• javax.crypto.AEADBadTagException and android.security.KeyStoreException #2723
• Crash when AndroidKeyStoreKeyGeneratorSpi.engineGenerateKey #2681
• AndroidKeystoreAesGcm.encryptInternal error #2548
• Failed to delete entry: CognitoIdentityProviderCache.aesKeyStoreAlias #2891

Recently, we attempted a fix:

• fix(all): Add fallback logic for corrupt keys to EncryptedKeyValueRepository #2686

As shown in some of these crash reports, the default Android master key was reported as unusable. When we detect this, we now attempt to create a new master key for Amplify. While this fix may work in some scenarios, it has not resolved all of the issues.

Unfortunately many of these crashes appear to be due to bugs within the Android KeyStore implementation. Some of these appear to be manufacturer specific bugs.

For these devices, it does not appear possible to use KeyStore based encryption. In order to prevent such crashes, we will now fallback to an In-Memory Key/Value repository.

• fix(auth): Fallback to in-memory key value storage if encryption fails #2969

This behavior is consistent with Amplify v1 and the AWS Android SDK. This approach will allow Amplify to function normally within an app session, however, data will not persist across device restarts (ex: Auth will need to sign in each time a new app instance is opened). This may be sufficient for this small edge case of devices that does not seem to have functioning KeyStore based encryption.

Ultimately, in order for these limited number of devices to operate normally, we would need to soften our encryption stance and allow these devices to store data (ex: Cognito auth tokens and refresh token) in plain text. This may be acceptable to some develpers, as Android's application sandbox already provides its own security mechanisms: https://source.android.com/docs/security/app-sandbox.

This ticket is to request community feedback for an option to fallback to plain text key/value storage in the event that the KeyStore is unusable. This could look something like Amplify.configure(context, allowInsecureDeviceCaching = true) and the value would be false by default.

[github-actions]

This issue was opened by a maintainer of this repository; updates will be posted here. If you are also experiencing this issue, please comment here with any relevant information so that we're aware and can prioritize accordingly.

[4brunu]

Hi @tylerjroach, this is an issue we are facing as well.
Unfortunately this seems to be a problem that will not be fixed.
May I suggest that instead of having the EncryptedSharedPreferences or Plain Text options, that you consider a third option by using a plain SharedPreferences where you would store the keys in plain text, but you would store the values encrypted?
By doing this, you would encrypt the values each time you want to write then to the SharedPreferences, and unencrypt them each time you want to read them.
This should be a middle term that offer more security than the plain text option can offer, for those who need it.
Thanks

[tylerjroach]

May I suggest that instead of having the EncryptedSharedPreferences or Plain Text options, that you consider a third option by using a plain SharedPreferences where you would store the keys in plain text, but you would store the values encrypted?

@4brunu I don't believe what you are suggesting would work in these cases. While the stacktrace is within EncryptedSharedPreferences, the actual crash seems to be a complete failure to access the Android KeyStore (with or without EncryptedSharedPreferences). If we can't access they Android KeyStore, we can't properly encrypt values on these devices.

This is how Amplify v1 worked. It did not use EncryptedSharedPreferences, but it did use the Android KeyStore to encrypt the values. I believe that Amplify v1 was still problematic on these devices, and it was quietly falling back to its in memory preferences.

If you have any evidence to the contrary, please let us know and we can investigate further.

[4brunu]

@tylerjroach You are right, the issue is in the Android KeyStore.
What I'm suggesting is using a plain SharedPreferences with encrypted values, but the encrypt/decrypt process would be done without using the Android KeyStore.

[tylerjroach]

Without the Android KeyStore, there is no way to secure the encryption/decryption key, especially as an open source library. The Android KeyStore is a vault (most of the time, hardware backed) that is able to act as a secure storage location to hold encryption keys. Without it, the key would have to be stored within the application sandbox, defeating the purpose of encryption as anyone could decrypt.