Add support for hmac-secret FIDO2 extension

[J-Jamet]

Allow the use of SoloKey keys.
Implement a challenge-response using the hmac-secret FIDO2 algorithm. https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-client-to-authenticator-protocol-v2.0-rd-20180702.html#sctn-hmac-secret-extension

Links :
keeweb/keeweb#1681
https://github.com/keeweb/keeweb/wiki/%5BWIP%5D-FIDO2-hmac-otp
https://github.com/MartinKolarik/KeePassFIDO2
#304
keepassxreboot/keepassxc#3560
https://github.com/Yubico/libfido2
https://developers.yubico.com/libfido2/Manuals/fido2-cred.html
https://github.com/mjec/khefin
https://solokeys.com/
https://github.com/solokeys/solo1-cli#challenge-response
https://github.com/saravanan30erd/solokey-full-disk-encryption#table-of-contents

[rugk]

Well… yeah, good idea. Given the cited key (SoloKey) now has the v2 campaign running, here are some more details on how that would have to be implemented:

In contrast to #8, which uses HMAC-SHA1, which is a proprietary extension from Yubikey, the thing better to be done is use hmac-secret, which any FIDO2 (WebAuthn) token supports.
According to some comment by the creators of the token here is how that should be implemented:

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.

"Upstream" KeePassXC issue for that is: keepassxreboot/keepassxc#3560
KeeWeb: keeweb/keeweb#1681

[rugk]

Also I'd propose to rename this issue to a more accurate title like "Add support for hmac-secret FIDO2 extension".

[samsapti]

@rugk I would like to add, that the use of hmac-secret for FIDO2 would defeat the main purpose of implementing support for hardware keys (at least for me). IMO, the main purpose of this would be to have compatibility with other KeePass programs, such as KeePassXC for desktop, which uses HMAC-SHA1 for YubiKeys (and OnlyKeys too). This missing functionality is in fact the only reason for why I haven't switched to KeePassDX. I currently use Keepass2Android, which uses the ykDroid driver app (available on F-Droid) to achieve support for HMAC-SHA1, but I would like to switch to KeePassDX in the near future due to better looking UI.

Implementing both could also work. I think that HMAC-SHA1 implementation is important in order to ensure cross-compatibility with other KeePass implemtations (such as KeePassXC). I don't know of any desktop KeePass programs supporting hmac-secret, but if you know any I'll be more than happy to check them out.

[rugk]

IMO, the main purpose of this would be to have compatibility with other KeePass programs, such as KeePassXC for desktop, which uses HMAC-SHA1 for YubiKeys (and OnlyKeys too).

That's a problem of KeePassXC, actually and tracked in keepassxreboot/keepassxc#3560 as said. As argued, it makes no sense to only support YubiKeys, when you can support a standard and thus all keys.

The feature request you are probably looking for is thus #8, which is about YubiKey.

[samsapti]

@rugk as I understand it, hmac-secret makes use of the normal FIDO2 flow used for authentication in e.g. browsers (correct me if I'm wrong). In that case, please note that degoogled phones don't have native support for FIDO/FIDO2, as it's a part of Google Play Services, so KeePassDX should have it's own implementation instead of relying on Android's (or rather, Google's) implementation.

AFAIK, FIDO is only supported in Chrome, so KeePassDX would need its own implementation anyway. Also, I think that omitting the use of Google Play Services is important for a FOSS project like this.

[J-Jamet]

Here is an alternative FIDO2 SDK in GPL3 that does not require the play service, it may be a good starting point to study the feasibility.
https://github.com/cotechde/hwsecurity

[J-Jamet]

@rugk I would like to add, that the use of hmac-secret for FIDO2 would defeat the main purpose of implementing support for hardware keys (at least for me). IMO, the main purpose of this would be to have compatibility with other KeePass programs, such as KeePassXC for desktop, which uses HMAC-SHA1 for YubiKeys (and OnlyKeys too). This missing functionality is in fact the only reason for why I haven't switched to KeePassDX. I currently use Keepass2Android, which uses the ykDroid driver app (available on F-Droid) to achieve support for HMAC-SHA1, but I would like to switch to KeePassDX in the near future due to better looking UI.

The goal would be to promote the implementation of open protocols make as many protocols and physical keys as possible compatible with KeePass apps. Historically, Yubikey was the first to be implemented (and not in a homogeneous way), I promote backward compatibility but we might as well favor open solutions for new implementations.
There is nothing to stop other KeePass applications from evolving by making contributions and pull requests to make FIDO2 supported.

[rugk]

Note that on Android by default all apps/browsers seem to depend on Google Play Services (yet again 🙄) for FIDO2/WebAuthn to work/use that implementation. A feature request for implementation at microG (microg/GmsCore#849) is still open.

Okay though WebAuthns is likely a different scope… though I don't know about the internals/what the Play Services support/provide, so just throwing this in here FYI. (Maybe yet again one could cooperate here just like with the exposure notification thing that you could use a library provided by microG to implement this, if you want to have support for de-googled devices without microG.)