Support hmac-secret FIDO2 extension for calculating hash

[antelle]

KeeWeb connects to YubiKeys using their proprietary HMAC-SHA1 Challenge-Response API, which is less than ideal. FIDO2 standard now includes hmac-secret extension, which provides similar functionality, but implemented in a standard way.

This should give us support for other tokens, for example, Trezor One, without using their API.
Additionally, if hmac-secret is ever supported in browsers (for example, this PR adds support for it, but it's limited to Windows Hello), we'll be able to use it on web as well.

• related issue in KeePassXC: Add support for hmac-secret FIDO2 extension keepassxreboot/keepassxc#3560
• libfido2: https://github.com/Yubico/libfido2
• hmac-secret usage test in Trezor: https://github.com/trezor/trezor-firmware/blob/master/tests/fido_tests/libfido2/hmac-secret.sh

[rugk]

Regarding the current campaign for SoloKey v2 there has been some comment by the creators that supports this implementation, too:

We still think the way to do this is to use the hmac-secret extension that is part of the actual standard (it is in essence HMAC-SHA256 challenge-response). In that sense, the answer is, yes, at launch (and Solo V1 has it too, just like every fully certified FIDO2 dongle).
If the question is whether we will implement Yubico's proprietary app (in essence, HMAC-SHA1 challenge-response), the answer is no, we do not plan to do so. This sentiment is shared by other vendors such as Trezor - if OSS such as KeePassXC and LUKS moves on to an actual standard instead of one company's private sauce, everyone wins.

[gynet]

Very cool. Once it got implemented, is keeweb going to deprecate the existing 'Challenge-Response'?

[antelle]

Depends on its compatibility and ecosystem progress. My gut feeling says it may be not interchangeable with the existing mechanism, as in, it will generate different codes, and most apps will probably support both methods. But nobody knows now...

[leandroferreira]

@antelle is this on keeweb's roadmap? Is there appetite for someone from the community to give it a go at implementing this solution?

[antelle]

First step is to understand how it actually works. Help here would be very welcome and if the understanding is present, we can progress from here.

[leandroferreira]

Do you envision it being implemented as a native module in the molds of node-yubikey-chalresp?

[antelle]

Indeed, using libfido2

[antelle]

I did some investigation, and the script linked in the issue (hmac-secret.sh) works well with a YubiKey with a small correction for a combination of macOS and YubiKey. It generates equal results for the same input, so it's technically usable as a HMAC implementation and it can be relatively easily coded.

Now, some thoughts:

1. 💥 It's not possible to change or manually set the seed (unlike in the Yubico's implementation), which means, you won't be able to program another YubiKey with the same secret. For now, I'm not sure what to do with this and it's a blocker for adoption.
2. (1.) means it's obviously not compatible with the existing implementation. The usage of hmac-secret FIDO2 extension also not implemented in any of forks, so we don't have anything to compare. Well, this is expected.
3. Discussion in the linked issue makes me think that libfido2 doesn't work on Windows, however there seems to be a workaround (use Windows API), if the workaround works, it should be fine, just a bit more code.
4. I'm also not sure if this will work on iOS, but maybe it will. I don't have a possibility to check it though, as far as I know you need to have MFi for testing this. Because of (1.), there won't be an option to unlock the database using just the seed, without your YubiKey, which means Safari integration won't work.

So, now the biggest question is, how to provide support for multiple keys? Without backup, using a YubiKey with kdbx doesn't make a lot of sense.

I see two options here:

1. I can imagine something like there's another key stored in the db that is used for backups. When you save the db, it makes a backup that can be opened with that separate key. But it still doesn't sound right and probably it won't be implemented like this across forks. I don't find it not a good solution and I would discard it.

2. Use additional fields in the file header for secret sharing. This way the calculated HMAC will be used as an additional encryption key to get the secret and you can enroll as many keys as you want. I haven't thought much about it yet, but I can imagine the way it will work. It needs some math to decide if it can be done right, I'll try go through it when I have time. This is probably the best, but it needs some collaboration across forks, so that it's accepted everywhere. It can also provide a way to securely share the secret with iOS without current hacks.

[leandroferreira]

Thank you for looking into this, it certainly sounds promising!
I agree with your premise, and I'm not completely sure what would be the steps for validating solution 2 (honestly, some of it flew over my head). Sorry if I'm not being much help.

[antelle]

I spent some time thinking about it today. It's going to be a long read, sorry, I tried to put as much detail as I could. It's a bit hard to write all of this here, so I extracted this draft to a wiki page: https://github.com/keeweb/keeweb/wiki/%5BWIP%5D-FIDO2-hmac-otp

How to proceed from here? For now I need some feedback and critique, maybe the whole idea of having publicly available identity and challenge is absurd. It makes sense to get an approval from different popular KeePass implementations before we write any code.

I also haven't checked if the scheme is cryptographically safe ❗ 💣, it's just a quick idea so it may be wrong. Actually, I've already found some issues with it, but I'll try to come up with something usable.

[rugk]

In any case, it should be compatible with KeePassXC etc.

[antelle]

@rugk it won't be compatible with the current implementation. I assume KeePassXC, as well as the 2FA KeePass plugin, will come up with a new variant. I hope it will be accepted in the kdbx format (then it would be easier), but I don't know, I can ask Dominik.

[antelle]

I've moved it to Future not because I find it unnecessary, but it's not very much actionable in the current state. Now we need to come up with a solution that would work and agree on this, it won't happen fast.

[gynet]

The secret used for signing data is stored on the authenticator and is never exposed. It's not possible to provide your own secret when making a new credential.

This makes me feel sad about the standard

[antelle]

Well, it is good! The standard is here to protect us and make our world better. If secrets can leak, they will leak. If secrets can’t leak, developers will adapt and eventually make the software accept several authenticators, it will be better for users, right?
A real issue here is the kdbx format. If it was my software with mobile apps, etc... multiple authenticator enrollment would be a matter of couple of meetings. Now... 🤷‍♀️ who knows when other developers want to support it.

[gynet]

Yeah, it's more secure, but to be honest, I like how the current Yubikey challenge-response or GPG works: I can generate or backup my secret or key in two USB drives using my secure laptop, and lock up them in a safe box, and it is more flexible, but sometimes I am cynical, and I can see the business reasons might behind "standard makers" :P

Anyway, it seems like if keeweb applies the FIDO2 standard, users have to purchase at least two physical authenticators in order to prevent lost/theft scenarios, I think FIDO2 standard might be good for online services because usually, they have other alternative ways to finish authentication or reset the key if a user lost his hardware token, but for offline auth or decryption, like Keepass, to have a backup physical authenticator might be the only way to recover a database, otherwise, the user is screwed

[antelle]

Yes, that's the point, that you have a backup authenticator. It makes sense to have it anyway if you use WebAuthn.

But this can be made a soft requirement. If multiple challenge-response codes are supported in KDBX, one of them may be generation based on a backup code, or stored on a server and given via WebAuthn, and so on.