aws-amplify / aws-amplify/amplify-android

Encryption / KeyStore Failure Fallbacks [Community Feedback Requested]

Open
#2,971 10 comments 0 reactions 0 assignees View on GitHub
auth feature-request
Dominant language
Java
Stars
287
Forks
132
Avg merge
2d 2h
Merged PRs (30d)
45

Description

### Describe the feature request

Amplify Android has received reports of crashes during EncryptedSharedPreferences initialization.
* https://github.com/aws-amplify/amplify-android/issues/2939
* https://github.com/aws-amplify/amplify-android/issues/2845
* https://github.com/aws-amplify/amplify-android/issues/2723
* https://github.com/aws-amplify/amplify-android/issues/2681
* https://github.com/aws-amplify/amplify-android/issues/2548
* https://github.com/aws-amplify/amplify-android/issues/2891

Recently, we attempted a fix:
* https://github.com/aws-amplify/amplify-android/pull/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.
* https://github.com/aws-amplify/amplify-android/pull/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.

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the linked crash reports and pull requests #2686 and #2969 to understand the existing KeyStore and in-memory fallback behavior. The issue names no files, tests, or entry points; this work is done only after the insecure-storage API, default behavior, and fallback policy are agreed and the affected implementation and tests are identified.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, java
Domain
authentication, mobile, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.