UI for key security level

[JamesSmartCell]

Background: Alphawallet security is being upgraded to the best achievable security whilst keeping convenience.

I have simplified the key usage for the sake of narrative, but it doesn't affect the UX.

Keys created by the Android security system are locked away from the user/OS. We use this system to protect the user's private crypto signing keys.

The keys can be created with usage constraints; for simplicity this is either that you need to authenticate (system fingerprint, PIN, swipe or facelock) before use, or you do not.

If you specify that the user needs to authenticate, then if any negative security event happens those keys are rendered unusable. Negative security events are mostly:

• user adds a fingerprint.
• user removes screen lock.
• user removes the only fingerprint on the device.

Note that changing PIN is not a negative security event, but removing a fingerprint when there's only one fingerprint would count as a negative event.

Keys created without this constraint won't be affected by the security event.

Imagine the scenario where a user has created an account on alphawallet. Then they receive some ether on it, but still haven't backed up the account despite the app nagging them to.

They lend the phone to a friend who complains about the phone keeps locking up, so they remove security for the friend.

This event triggers all the protected keys to be destroyed.

Now, the user is really upset and will blame Alphawallet for losing their key, rather than their own actions. It's a grey area really.

After discussion we settled on the following solution:

At the time of key import/creation, the key requiring authentication is created as normal, but also another key is created which doesn't have the authentication requirement. Note that this second key is less secure.

In the same scenario, the user again receives eth, doesn't back up the key, removes their authentication lock, voids the secure key but there's a backup key which will still work. The app will automatically recover this key (should there be a warning? This is a UX design issue).

Once the user actually backs up their key, the key that doesn't have authentication can be erased as if the user does the same thing again they can restore the key from the backup.

What we need is a UX design for this process. Some points I thought of:

• how should the user be told that their key security can be improved by backing up?
• should the insecure key be erased after we confirm they backed up, or should we wait a bit, ask the user to re-import their key to prove they backed it up then erase it?
• how to represent that the key is now more secure?

[JamesSmartCell]

Cross reference this with #769

[SmartLayer]

Tomek has:

When the key is used? A. when you want to open AlphaWallet app or B. only when importing a wallet C. when there is a need to confirm a transaction (and any other sensitive moment confirmation)

The key is used 𝑐 The key is also used in 𝑑: when backing up a wallet.

Of the key can be a faced or fingerprint then it also requires pin code as an alternative. This is how it works with my bank: I set a fingerprint + pin code. When I disable fingerprint for my phone then when logging in it asks me to enter pin code. So the fingerprint/faceid is a primary option, after three attempts or if you have this disabled it asks my pin code.

Currently, iOS and Android regards fingerprint/faceid/PIN/Pattern-protection the same. They are all provided by the OS. There is no app-level password, PIN, pattern etc (except the password for KeyStore in the backup process, which is specific to that piece of backup, not affecting the app behaviour). We can't change that decision (that we don't have any app-specific PIN/FACE/PATTERN/FINGERPRINT) at this stage of the sprint.

Is backing up the key a different action then backing up seedphrase or this can be a part the same flow?

In either cases, if you backed up, the key can now be encrypted safely, since if the key gets destroyed due to the user disabling operating system level fingerprint/faceid/PIN/Pattern-protection the user can recover from the backup (be it seed phrase or keyStore).

Where the key is actually backed up? And how does it work?

If the wallet is a wallet created from seed, the seed phrases are backed up. If the wallet is a legacy wallet (existed before this new version of αWallet is released), then it is a keystore wallet, and the keystore is backed up.