Self-contained keystore encryption key

[OtaK]

• On database creation, CoreCrypto would generate a random key and/or ask the host OS to generate and enclave it
  • WASM/WASI: call web-sys and use a CryptoKey stored in an IndexedDB database
  • iOS: Secure Enclave'd P256 key
  • Android: To research, but some sort of keypair stored in the Android Keychain
• And reuse it when accessing the store
• Optionally, that would allow transparent periodical encryption key rotation

This would require API breakage by not requiring any more encryption key parameters from the outside.

[OtaK]

Concern: That would lower the security of access by making it trivial to open the database via CoreCrypto

[rohan-wire]

Concern: That would lower the security of access by making it trivial to open the database via CoreCrypto

I don't think we have any choice here. The user needs to secure their browser or device with the correct permissions. Our clients need to request only the appropriate permissions.

[OtaK]

After giving it more thought, there's no need to change the API but rather we can provide a new API for an "enclaved" mode where the caller doesn't provide keys and let them being managed by Core-Crypto itself

[OtaK]

Gave it another thought, and I've looked into a viable approach I'm considering in this particular "maximum security" mode

Requirements

• Keystore encryption key is not stored anywhere except in dedicated hardware
  • This would mean that biometrics (on mobile) or a WebAuthn provider (i.e. yubikey/touch ID etc) for web would be a hard requirement.
• This means that except on initialization that encryption key is only present on the enclaved security module (HSM)

Implementation

• Web/Desktop
  • Use WebAuthn/FIDO2 to call into a HSM such as a YubiKey (preferred) or fallback on biometrics like Touch ID/etc
• Android
  • HSM or fallback on android biometrics
• iOS
  • HSM or fallback on Touch ID
• Native (?)
  • https://github.com/mozilla/authenticator-rs