Use Android secure storage (for 23+, or earlier if possible) for FxA state

[liuche]

Why/User Benefit/User Problem

As an Android 23+ user, Android provides secure storage for keys, and I want my sync key to be stored safely in this manner.

Dependencies

• encrypted Firefox Account Storage (AC)

What/Requirements

Use AndroidKeyStore to manage Sync keys.

See Lockwise documentation and implementation

Acceptance Criteria (how do I know when I’m done?)

• Sync keys are stored securely in Android 23+ in Android secure storage.

┆Issue is synchronized with this Jira Task

[liuche]

Wait it actually looks like AndroidKeyStore is 18+! @jhugman do you know if there's anything specific to the 23+ version of the API that Lockwise is using in the LW library (that we wouldn't
https://developer.android.com/training/articles/keystore

[liuche]

@ekager will talk to @linuxwolf about what is possible with AndroidKeyStore, and give an update and then we'll size it.

[linuxwolf]

will discuss with @ekager.

My understanding is AndroidKeyStore was added in API 18, but only supporting RSA keys; API 23 added support for symmetric keys (e..g, AES).

[ekager]

FYI I think this is a prerequisite for #5544 to land because once we set an encryption key for logins we would have to worry about moving users forward if we change the key which could get messy.

[liuche]

It sounds like there are 2 keys here: sync key and login encryption key. Is the login key dependent in some way on how we store the sync key?

Why can't we a) store the sync key normally until we figure what our sync key storage story is, and then b) encrypt it, and decrypt it when we pass that into AS?

[grigoryk]

This is indeed a per-requisite for securely storing logins data.

FxA state contains everything you'd need to fetch logins from a sync server. So, encrypting logins storage at rest is moot if you store FxA state in plaintext.

[grigoryk]

Secure storage support for FxA state is tracked in mozilla-mobile/android-components#3982

[liuche]

@ekager I just talked to grisha and going to summarize here - this does not need to block #5544 as long as we actually get this in place before we ship (but ideally, much sooner than that!).

Our plan here is, generate a key and store it in #5544, and then encrypt it once we get this issue fixed.

[ekager]

Opened #6066 to track the similar issue for securely storing the logins db key.

AC issue here to track lowering the min API for dataprotect
mozilla-mobile/android-components#4758

[liuche]

@ekager when you summarize the approach and discussion you had w/ @linuxwolf can you also give an update in https://bugzilla.mozilla.org/show_bug.cgi?id=1587993 ?

[liuche]

Sizing as E2 because this should primarily be done in AC.

[ekager]

This was merged in mozilla-mobile/android-components#5053
and we can close this ticket now

[grigoryk]

Support for this merged, but we still need to flip the flag in Fenix.

[liuche]

@grigoryk i'm going to close this bc it looks like your change landed.