Discussing multi-factor decryption and optional-factor decryption

[ashleysommer]

This discussion has evolved out of comments on the FIDO2 topic: #9506, particularly this comment by @BryanJacobs #9506 (reply in thread)
Also probably closely related to the KDBX features topic: #6229

For years there have been requests from users like "I want to use a password or a keyfile to unlock the database" or "I want to use my password plus one of either my yubikey or my keyfile" or "I want to use my password and this yubikey, or my password and that solokey" or many others along those lines. Normally the answer is simply "KeepassXC doesn't support that, the KDBX format doesn't work that way, you cannot do that".

In the topic of implementing FIDO2 key support, one very important aspect came up. Most other applications that use the FIDO2 protocol (like Webauthn, etc) allow you to register more than one FIDO2 device to use. The premise is it is easy to imagine losing a security key, or not having access to it when you need to unlock your database, so having a second device registered means you have a backup. We get around this issue with Yubikey support through the ability to clone the HMAC code from one yubkey to another, so it can provide the same challenge response. The FIDO2 hardware keys do not allow this, their memory is read-only and their HMAC code cannot be cloned. So the only way to have more than one FIDO2 hardware key to be used to unlock the database is to have optional factors supported. It was also expressed by some that it is not even worth implementing support for FIDO2 keys if it is not possible to enroll more than one key.

When discussing this in the FIDO2 topic, I had originally intended to implement this multiple-FIDO2-keys feature in a way that is contained within the FIDO2 implementation, with this ability to use one-of-many keys specific to the FIDO2 feature only. This is to minimise the impact this feature has on other functions of the database, and other decryption factors.

However, it was pointed out that this should be done in a more general way, implementing a new AdditionalFactors structure in the KDBX extended header that will allow support for all decryption factors (Password, Keyfile, Yubikey, and FIDO2), as well as enrol more than one of each, and have some optional sets (eg, 1 of these two Keyfiles, and 1 of these two FIDO2 keys). This would address the need to have this feature for optional FIDO2 keys, as well as open up the opportunity to address the older feature requests that I mentioned at the start. For more details, see the comprehensive write up by @BryanJacobs.

As discussed in the other thread this more generic method would not necessarily constitute more work than implementing it specific to FIDO2 keys as part of the FIDO2 feature implementation, but it does mean this change would be out of scope of that feature set, and will require much more discussion and direction. That is what this new discussion topic is opened for.

[droidmonkey]

When the DB is unlocked, if the header contains 1-of-N, DO NOT ROTATE THE MASTER SECRET PART as you can't re-encrypt the other authenticators' versions of it.

This is what is going to kill this effort. You will corrupt the use of the additional factors the moment you save it in any other program or a previous version of KeePassXC.

You are best to NOT do this and instead advocate for formal support of general multi-keying in KDBX 5.

[ashleysommer]

When the DB is unlocked, if the header contains 1-of-N, DO NOT ROTATE THE MASTER SECRET PART as you can't re-encrypt the other authenticators' versions of it.

That's right, we cannot rotate the master secret part that is shared and separately encrypted by secrets from each authenticator, but we can rotate the salt (FIDO2's name for the challenge string) that is saved in the db and reencrypt the master key part for the currently used authenticator only.

Hmm, that brings up another question. What happens if the DB needs to save, but the authenticator used to decrypt it has been removed from the device? Does KeepassXC need to deal with that in the current Yubikey implementation? I haven't checked what happens.

[droidmonkey]

We wait until the yubikey with the same serial that unlocked the database is available in order to save. This is mainly because the master seed (the thing that gets rotated on save) serves as the challenge.

I would actually not use the master seed as a challenge in this 2FA implementation. Each factor should have its own seed that can be independently rotated. The master seed is used in the combination of key material, but not used when unlocking the "crypto box".

[ashleysommer]

Each factor should have its own seed that can be independently rotated.

Yeah, that's what I was referring to above, in FIDO2 terms that is called the "HMAC Salt". That will be per-key and can be rotated each save. That means we would still need the key present at save time, just like with the Yubikey code.

[BryanJacobs]

If you use the HMAC response as two separate 128-bit salts (instead of one 256-bit), you don't have to present the key again at save time.

When unlocking the database send the key the current value, and also the value-you-will-use-for-saving. Then you can rotate the salt one time without needing the user to present the authenticator again.

I think it's okay that if the user edits the database and saves it five times in succession the salt is only rotated once, right?

[droidmonkey]

Yes, one rotation per 'session' makes a lot of sense.