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.)

[BryanJacobs]

I've raised a pull request again hwsecurity to add support for hmac-secret. No response yet from the maintainers, but the GPLv3 license of that library would permit bundling a fork of it into the hardware key driver code.

I would recommend against implementing a solution that directly uses the FIDO2 hmac-secret challenge response as part of the keying material for the password database. If you do that, users will have one hardware token whose loss would mean being unable to open their database. To me that's not an acceptable state of affairs...

Instead, the database should store an encryption of the primary keying material part with n-many different hmac-secret challenge responses. That way one of n-many different FIDO2 devices could be used to unlock the database.

[J-Jamet]

I agree with that, the problem would be where to store the n-many. The Keeweb WIP explains the concept well but will putting this info in the database header pose a security problem?
Some KeePass plugins used the method of creating a separate file for the increments but I don't really like this method because the goal of KeePass is to have only one file to manage.

I will remove the option "FIDO2 secret" in the selection of the hardware key of KeePassDX because the functionality still needs to be discussed further and standardized.

[ale5000-git]

The latest release of microG have FIDO/FIDO2/WebAuthn support, while currently is only for browsers at least we already are some steps ahead.
An app can include only play-services-fido to work on devices with microG, or it can include both play-services-fido AND play-services-fido-core to work with and without microG (this will keep it completely FOSS also on devices with Google Play Services).

[ashleysommer]

Good news on this topic.
The implementation of FIDO2 "hmac-secret" in KeePassXC is going forward. (I am the volunteer making the implementation based on libfido2). See the aforementioned KeepassXC issue thread, and this discussion topic for further details.

As a user of KeePassDX on Android, it would be great to see this also implemented here in a compatible manner, so that a keepass database created in KeePassXC secured with a hmac-secret device could be opened in KeepassDX with the same key.

The challenges as discussed above is the primarily which FIDO2 library to pick. The official android FIDO2 api does support "hmac-secret" but is tied to Google Play Services, which I believe we want to avoid.

The mentioned alternative library https://github.com/cotechde/hwsecurity is out of date, unmaintained, and does not support "hmac-secret".

The latest release of microG has its own FIDO2 implementation, as mentioned above, and while its only intended for browsers it may be able to work directly with this app. Does KeePassDX use microG elsewhere already?

There is a fully independent complete FIDO2 implementation created by the NitroKey team, but I believe it is proprietary, it requires a payment or subscription: https://www.nitrokey.com/products/android-fido2-sdk

[J-Jamet]

KeePassDX doesn't use microG, but there's nothing to stop extracting the source code and turning it into a driver app.

[ashleysommer]

I just noticed the existing KeePassDX Security Key Hardware Driver https://gitlab.com/kunzisoft/android-hardware-key-driver already mentions planned support for "hmac-secret" extension (For the solo key, but I don't see why it wouldn't work on other keys).

[samsapti]

@ashleysommer the one from Nitrokey is the same as the Hardware Security SDK. It's dual-licensed as GPLv3 and a proprietary license.

[ashleysommer]

@samsapti Thanks for pointing that out. Looks like that library doesn't yet support "hmac-secret" extension, but there is an open pull request (hwsecurity-sdk/hwsecurity#5) to add support.

[BryanJacobs]

I opened that pull request, and since nobody has responded in the months since, I think it's safe to say that hwsecurity is indeed unmaintained.

[ashleysommer]

Ah right, yep I didn't to see the connection until now, with your comment from earlier in this thread.

[lazytownfan]

I just wanted to bring up that recently KeePassXC added support for the Nitrokey 3, but using challenge-response. (This will only take place after current version v2.7.5 is superseded by the next release version.)

• Does this in any way help support for SoloKeys?
• Also, does this mean the Nitrokey 3 will be able to work with the latest version of KeePassDX, just like the YubiKey and OnlyKey?

[ashleysommer]

@lazytownfan

recently KeePassXC keepassxreboot/keepassxc#9631 support for the Nitrokey 3

Does this in any way help support for SoloKeys?

No, this is unrelated to the FIDO2 efforts that will enable support for SoloKeys and other FIDO2 keys.

does this mean the Nitrokey 3 will be able to work with the latest version of KeePassDX, just like the YubiKey

Yes. That feature is merged, and be part of the v2.8.0 release of KeePassXC, I don't know when the release date for that will be.

[J-Jamet]

At the moment, I don't have a Nitrokey, so I can't test with it. The driver may need to be modified.

[rugk]

@J-Jamet AFAIk vendors are usually quite helpful on supporting software devs with a hardware sample, so you may just contact @Nitrokey to get a key.

[jans23]

@J-Jamet For development purposes we can provide you a free Nitrokey 3. Please DM me or send us an email to arrange that.

[BryanJacobs]

I am in the process of writing a suitable FIDO2 Platform implementation that could be used for this feature: https://github.com/BryanJacobs/FIDOk/ .

It's not ready yet: although technically things work with USB or NFC authenticators on Android, and it supports HMAC-Secret just fine, the documentation, error handling, and test coverage aren't up to snuff.

But soon it will be able to serve as an alternative to both the hwsecurity code and to Google's own half-baked FIDO implementation.

[BryanJacobs]

I've raised https://gitlab.com/kunzisoft/android-hardware-key-driver/-/merge_requests/12 to make supporting hmac-secret here possible.