Provide option to lock saved credentials with PIN/biometrics

[bedhub]

As a user of the Tutanota mobile or desktop app i want to be able to protect my stored credentials with the PIN/fingerprint of my device. If i choose "Store credentials" from the login screen the app should display options of how to secure my stored credentials. The option should be used for all further stored credentials. The selection can later be changed in the settings.

Every time i need to access the stored credentials the app should ask for the chosen option.

Acceptance criteria:

• Provide options to secure the saved credentials after creating a persistent session using "Store credentials"
• Ask for biometrics/pin when accessing credentials
• Usage of biometric unlock option should not be required.
• Setting to change selection
• Migrate existing credentials and ask for options when opening new app version.

Implementation hints
We currently use the local storage of the web view to store the credentials. It is the same mechanism that is used for the web browser. We want to change the storage location to the secure storage of the device which is already used to store the device keys that are used to decrypt calendar event reminder notifications.

With this issue we will not automatically lock the application. We will protect how the saved credentials are stored on the device by encrypting them with a device key. The device key should be stored in the secure storage of the device. We will not have direct access to that key but instead we need to ask the system to decrypt the credentials.

When setting up the this for the first time the user should have the following options:

1. Use biometrics
2. Use system password/pin (or biometrics)
3. Use device lock (no user interaction when accessing credentials)

Every time user needs to access the credentials we will ask for authentication.This is the case when:

1. Access login screen
2. Save additional credential
3. Delete credentials

Together with @charlag @rosso-ptg @bedhub we discussed if it is acceptable to ask for authentication again upon delete or logout because it might be ask too often. We decided that it is acceptable for now.

We will do biometrics/pin protection for mobile apps only. For desktop clients we will store the key to decrypt credentials in the keychain of the system. Which usually will be unlocked when user logs in.

We decided that we will use intermediate key in encryption chain which can do multiple operations. This will allow us to do multiple operations on multiple credentials. Keeping it in memory for a short time has almost no effect on security but improves user experience a lot.

---

When selecting authentication method user should see a dialog with following text:

The credentials are stored encrypted on your device. How would you like to unlock them in the future:

• Automatically
• System password or biometrics
• Only biometrics

The dialog should have three vertical options. It should have a skip button to default to automatic authentication. Option in settings should also open the same dialog.

--

• Android: Provide option to lock saved credentials with PIN/biometrics #3588
• iOS: Provide option to lock saved credentials with PIN/biometrics #3653
• [Desktop] Secure saved credentials. #3733

[charlag]

Our initial implementation so far fell out of date with the issue and we identified some blind spots so to rewrite the issue I'm gathering more information. We need to decide on multiple points:

1. When is user enrolled into biometric authentication
2. When is user presented with authentication challenge (after selection credentials, upon opening the app etc)
3. When is user asked to authenticate again (logout button, screen turned off, app put in background, timer)
4. Whether we want to allow fallback to device credentials
5. What is the behavior on desktop (do we need additional app protection besides the keychain, like a pin code, and whether it falls into the scope of this issue)

We should write down scenarios with what we want to protect and from whom.

---

Additional info:

• Android: https://developer.android.com/training/sign-in/biometric-auth?hl=en
  • Biometric-only auth does not support expiration timer
• iOS: https://developer.apple.com/design/human-interface-guidelines/ios/user-interaction/authentication/

  • In general, avoid offering a setting for opting in to biometric authentication within your app. If biometric authentication is enabled at the system level, just assume the user wants to use it. If you implement an app-specific setting, the user may get into a state where biometric authentication appears to be enabled in your app when it's really disabled systemwide.

---

Login & biometric authentication

Goals:

• Protect stored credentials with system security mechanism (trusted hardware/keychain)
• Prevent unauthorized access to the app when another person has temporary access to the device

Non-goals:

• Define offline storage security mechanisms
• Improve security for credentials in browser

Context

System mechanisms

Most operating systems provide two security mechanism related to our goals: Keychain and Biometrics.

Keychain allows apps to store credentials using high-security mechanism (like special hardware) and system promises to
handle such items with additional care (e.g. lock them when the device is locked).

Biometrics allow app to authenticate the user more easily. This allows apps to ask for authentication more often as
authentication is quick.

iOS and Android both allow tying credentials stored in Keychain to the Biometrics. Both allow using them separately.

Since Android 4.4, the contents of the user’s data partition are encrypted by default. iOS encrypts disk for a long time
as well.

Android Keystore keeps key completely outside of OS ref1

Android by default already performs full disk encryption with PIN/pattern/password. You add biometric
authentication in your app to ask the system to further guard your secret keys using authentication binding.
Even if a device should become compromised and an attacker makes a request, the Android Keystore would still refuse
to decrypt the data — unless the attacker can somehow get the user to authenticate with their biometric credentials.
Biometric authentication adds an additional layer of security — even on a compromised device — because the hardware
managed by Keystore cannot be accessed unless the user is present.

ref1

iOS devices also include specialized hardware: ref2. It is possible to create biometric-protected entries as well:
ref3

It is important to note that all biometric-protected entries are removed on both iOS and Android when biometric data
is changed.

Tutanota

When the user selects to "store password" on the login screen we create a "persistent session". Session data contains
three things: accessKey (remotely), encryptedPassword (locally) and authToken (in both). authToken is used as
authentication for making requests to the server while accessKey and encryptedPassword are used for cryptography.
accessKey encrypts password and password in turn is used to derive the rest of the keys. This property can be used to
actively protect the key: if the device is lost but key is not key compromised, then the session can be closed remotely.
When the session is closed it cannot be downloaded anymore and cannot be used to decrypt the password.

When choosing implementation we would like to first protect authToken. It might be good to also hide other details of
stored credentials e.g. mail address.

Extraction methods

Depending on the device's and app's state and security different extraction methods might be possible. For an overview
see https://privacyinternational.org/long-read/3256/technical-look-phone-extraction.

[bedhub]

Pin/biometrics is available for mobile apps, for desktop client credentials are stored in keychain.
We will add another lock method to the desktop client here #3853