Add support for hmac-secret FIDO2 extension

[prusnak]

FIDO2 standard (the superset of the older U2F standard) includes hmac-secret extension introducing behaviour similar to older Yubikey HMAC-SHA1 Challenge-Response merged in #127 but much more universal as FIDO2 is an open standard.

We could try to expand the current Challenge-Response implementation in KeePassXC to cover this too (using libfido2) which will make KeePassXC compatible with any FIDO2 dongle.

This will satisfy #3450 and any other vendor-specific requests in the future.

[flocke]

I would love that, I have a Solo that supports HMAC-SHA1 and I would love to be able to use it to unlock KeePassXC. If you need a tester at some point just ping me here, I would be more than happy to help.

[janis91]

Do you think about adding this in terms of a second factor or "passwordless"?

[prusnak]

With Trezor both use cases are possible, because the device contains touchscreen where you can enter your PIN (which is the second factor, the other one is having the device).

But I think starting with 2factor might be a good start.

[qertoip]

It would be really cool to have this.

Currently Trezor cannot be used with KeePassXC, which is unfortunate, as it is the most secure 2FA hardware key on the market, simply because it was originally designed for storing huge amounts of Bitcoin. In practice this comes down to super reliable backups and secure PIN with exponential escape and keypad scrambling.

[droidmonkey]

Just like OnlyKey, Trezor is more than welcome to use the new Yubikey API that allow us to specify a vendor hardware id. @prusnak please let me know if you need more information on this.

[prusnak]

@droidmonkey Yes, please give me more info on this - point me to the new Yubikey API. Is this using libfido2?

[droidmonkey]

No it's hmac-sha1. Take a look at Yubikey.cpp init function

[prusnak]

@droidmonkey I know about this, of course, but this is not relevant to this issue. The old hmac-sha1 method by Yubikey is obsoleted by FIDO2 hmac-secret extension and that's what new tokens will use. This issue is about implementing this via libfido2. Trezor will not use the obsolete and proprietary Yubikey API.

[droidmonkey]

Ah I see, I was confused by the conversation above a little. We do not have plans (yet) to implement libfido2.

[banym]

I am interessed in FIDO U2F / FIDO2 support for the Nitrokey FIDO2 and would add $150 as a bounty if it would be implemented.

I would love to use it as a second factor if possible. It would be nice be able to add multiple keys to one database for backup reasons.

[banym]

What do I need to do to make the bounty added to the topic of this like on the other issues with bounty?

[riedel]

Here is a implementation for LUKS using libfido: https://github.com/mjec/fido2-hmac-secret/blob/fd19bf40a94f177818bce5d2c50cc5eb57136478/src/authenticator.c#L315 that could be build upon

[riedel]

I actually managed to do a very dirty quick POC : d63e737 . It seems only diligence work if someone wants to grab that bounty ;)

To get it to work you first need to create a resident hmac token with the hostname 'keepassxc.org'
See https://developers.yubico.com/libfido2/Manuals/fido2-cred.html

I doubt that I fully understood how the whole thing is supposed to work though ;)

[riedel]

Just one more comment: I guess it makes sense to support multiple drivers by passing not only the slot, but also the driver to the challenge function and add an intermediate proxy class.

Currently only one device with multiple slots is supported by design (getSerial, getVendor), that IMHO could be fixed in any case.

Currently credential management is only supported by Yubikey, so on my Solo Key I also cannot search any slots but only define the assertion to hopefully match.

I haven't quite got if you need the resident key. I am happy now with the challenge that I got something mysteriously working.

As this is a security product, I would ask someone with much better C++ / QT skills take on the task though :)

[riedel]

Actually on my solo key now the credman extension is working (FIDO_2_1_PRE) . So listing the rk (slots) would be possible. However this might require a PIN, which would probably break the UX a bit.

[My1]

With Trezor both use cases are possible, because the device contains touchscreen where you can enter your PIN (which is the second factor, the other one is having the device).

But I think starting with 2factor might be a good start.

even normally when you enter the PIN on the computer instead of the fido device you have 2 factors, although it's not perfect security-wise

To get it to work you first need to create a resident hmac token with the hostname 'keepassxc.org'
See https://developers.yubico.com/libfido2/Manuals/fido2-cred.html

resident credentials only? if yes then sad.

couldnt keepass just keep the credentialID in the db file but not encrypted so it can be used to poll a "normal" credential?

Actually on my solo key now the credman extension is working (FIDO_2_1_PRE) . So listing the rk (slots) would be possible. However this might require a PIN, which would probably break the UX a bit.

you can iirc poll RKs for a specific RP without having the credential management. like I have had a few devices which dont have credential management but when getting asked to log in they just listed all RKs nicely. (it did require PIN though as browsers as far as I am aware always force PIN for RK stuff)

[riedel]

resident credentials only? if yes then sad.

couldnt keepass just keep the credentialID in the db file but not encrypted so it can be used to poll a "normal" credential?

don't rks make sense in the case of HMAC? Why is is this sad? You do not need a credentialID if its not resident don't you? I can try if it generates a HMAC also from the builtin key. It might however be a security risk, because some other "service" might just do the same and then your secret is exposed. IMHO this breaks security a bit.

you can iirc poll RKs for a specific RP without having the credential management. like I have had a >few devices which dont have credential management but when getting asked to log in they just >listed all RKs nicely. (it did require PIN though as browsers as far as I am aware always force PIN for >RK stuff)

Yes you can simply do try and error with assertions, so that is polling. So you suggest to simply have also 2 "slots" and poll them like for yubikey. Or poll the maximum (in my case) of 50 ?

[My1]

don't rks make sense in the case of HMAC? Why is is this sad? You do not need a credentialID if its not resident don't you? I can try if it generates a HMAC also from the builtin key. It might however be a security risk, because some other "service" might just do the same and then your secret is exposed. IMHO this breaks security a bit.

isnt hmac same as with normal credential based on the keys it generates instead of the master secret? would be pretty bonkers if not.

also big problem is that

1. 90% of all FIDO2 devices I know of have no credential management so grilling RKs is kinda impossible without resetting the whole device which is just crazy
2. the credential management extension is still not fully released (the Fido2.1 pointer on options isnt called FIDO2_1_PRE without reason.

also considering the fact that there is a "salt" as the CTAP2 spec calls it needed, which obviously would be random on database creation, it would be the same as with file based secrets that there certainly is a small chance you can just hit the same, but probably negligible

Yes you can simply do try and error with assertions, so that is polling. So you suggest to simply have also 2 "slots" and poll them like for yubikey. Or poll the maximum (in my case) of 50 ?

no random try and error involved, the user just enters PIN and gets a list and selects the one needed.

[riedel]

isnt hmac same as with normal credential based on the keys it generates instead of the master secret? would be pretty bonkers if not.

This is (ab-)using the HMAC as symmetric key so things are a bit more difficult I guess. "Normal" credential work in an asymmetric way so there is no risk in replaying.

I don't have much time to experiment at the moment. I tested the interface with the commandline libfido2 tools, so if you can also easily try the workflow there without programming.

Yes you can simply do try and error with assertions, so that is polling. So you suggest to simply have also 2 "slots" and poll them like for yubikey. Or poll the maximum (in my case) of 50 ?

no random try and error involved, the user just enters PIN and gets a list and selects the one needed.

Can you explain the screenshot and may make a reference to the FIDO2 CTAP spec? A command line version would also help!

[My1]

sure. in chrome and Windows 10 implementations (which are the most widespread webauthn implementations I have seen so far) when multiple RKs exist for any RP (relying party, generally meaning domain of a website in webauthn contexts) after entering the pin is spawns a selection of the Resident Keys for that RP.

linking to CTAP2.0 for obvious reasons here:
https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#authenticatorGetAssertion

step 9 and 10 say:

If more than one credential was located in step 1 and allowList is present and not empty, select any applicable credential and proceed to step 12. Otherwise, order the credentials by the time when they were created in reverse order. The first credential is the most recent credential that was created.

If authenticator does not have a display:

Remember the authenticatorGetAssertion parameters.

Create a credential counter(credentialCounter) and set it 1. This counter signifies how many credentials are sent to the platform by the authenticator.

Start a timer. This is used during authenticatorGetNextAssertion command. This step is optional if transport is done over NFC.

Update the response to include the first credential’s publicKeyCredentialUserEntity information and numberOfCredentials. User identifiable information (name, DisplayName, icon) inside publicKeyCredentialUserEntity MUST not be returned if user verification is not done by the authenticator.

basically you can use this and authenticatorGetNextAssertion to pull all the assertions for all RKs concerining that RP and go, in web contexts you have to select one to actually use and send, a local software could theoretically try them all but obviously that is not efficient.

obviously no matter whether an RK is used or not, if you keep the credentialID around, you dont have to do any ambiguity steps

[prusnak]

@My1 You seem to be very knowledgeable in FIDO subject. Are you also a programmer? Maybe you can pick up what @riedel has done and develop it further. I'd gladly provide assistance with the testing if needed.

[My1]

I am a big fan of fido stuff and I am more using it in context of webauthn and just gained experience by also testing quite a few fido devices both U2F and Fido2, I have played around with U2F for about 4 years already.

probably cant help with programming though as I have borderline no experience in desktop programming, I mostly do webstuff in PHP, CSS and HTML, although I could give a look over the code and hack though a bit

the part about how this stuff works just now was not something I knew prior to the last response, I just gave the spec a quick read at the places where I would think they would have to be, lol.

[My1]

the biggest piece of fun though will be multi-OS support as W10 >= 1903 does Fido stuff from the OS side, but all others do not do this so keepass needs to run all the fido requests by itself on all other OSes and needs to either
a) pipe through windows
b) run as admin (not desirable usually)
on later w10

[prusnak]

Keep in mind that the HMAC-secret extension is not supported in the Windows 10 version of the Win32 WebAuthN API, only in recent versions of Windows 11.

This sounds more like an oversight than intended behavior. Do you have more information about this? Will Microsoft ever backport the functionality to Windows 10 API?

[My1]

Keep in mind that the HMAC-secret extension is not supported in the Windows 10 version of the Win32 WebAuthN API, only in recent versions of Windows 11.

althugh the timing of the change makes it seem more like it's already included in the base version of w11, 21h2, at worst being enabled by a minor update.

with recent version of w11 I assume you mean 22h2, as w11 only has had 2 versions yet. any chance you (or anyone for that matter) tried w10-22h2?

[StarGate01]

I will reproduce the relevant exchange with fido-dev@microsoft.com :

Dear FIDO / WebAuthN Team at Microsoft,

I am working on integrating the new Windows WebAuthN API into [project].

I already managed to create FIDO2 resident key with the hmac-secret
extension enabled using the API, however the response from GetAssertion
does not contain the expected hmac-secret extension data. In fact,
Windows does not set the hmac-secret extension identifier in the request
to the authenticator, even though I specifiy in the API call to do so.

Does this extension require a specific version of Windows? Is this
expected behavior, is the hmac-secret extension ignored?

Are you targeting Windows Hello or external security keys? hmac-secret is not yet supported in Windows Hello. It is supported for external security keys in latest version of Windows 11.

I am targeting external PC/SC or USB hardware authenticators, via the WebAuthN API - since third-party FIDO2/CTAP implementations require administrative permissions.

I will test the latest version of Windows 11, up until now I did my testing on Windows 10.
...
I was able to confirm hmac-secret working properly on Windows 11, thank you. Is this feature something Microsoft plans to backport to Windows 10?

Sorry, I can't comment on backport/future plans.

One more thing about hmac-secret. We have one API (WebAuthNGetApiVersionNumber) which can help in figure out which features are available on which OS. So, as documented in the header, if the WebAuthNGetApiVersionNumber returns WEBAUTHN_API_VERSION_4 or above, then platform supports hmac-secret for external security keys.

[My1]

I see, you know what version of w10 you used at the time? also maybe one could check insider if the Webauthn API Version was upped there already. (I have no idea how to check)

[StarGate01]

I used Windows 10 22H2 (19045.2604) and Windows 11 22H2 (22621.525) respectively.

[xchapron-ledger]

Ledger recently published a new application for their main hardware device, making them compatible with FIDO2 protocol and supporting HMAC extension.
So one more reason for Keepass to start supporting FIDO2 instead of custom mechanism !

[xchapron-ledger]

@My1 I saw some discussion above regarding HMAC extension and the questionned need of using RK for credentials supporting HMAC.
I can confirm that there is no need to create a RK credential to use HMAC extension. As I seen in this thread, the idea is to store something in the credential which will allow the authenticator to derive the HMAC private key.
And as also mentionned above, using RK credentials when not strictly needed (userless authentication) is not the best idea due to the limitation they brings.

[My1]

I can confirm that there is no need to create a RK credential to use HMAC extension. As I seen in this thread, the idea is to store something in the credential which will allow the authenticator to derive the HMAC private key.

neat

Ledger recently published a new application for their main hardware device, making them compatible with FIDO2 protocol and supporting HMAC extension.

sadly only for new models only tho (I hope they bring it for the S too as that was the primary reason I got them, years worth of promises)

And as also mentionned above, using RK credentials when not strictly needed (userless authentication) is not the best idea due to the limitation they brings.

cant agree more.

[anton-isidore]

Hi, from the above I understand that there is some issue with implementation for Windows. As a Linux user I would kill for an option to have this at least on Linux (and Mac?).

💰 I am offering +$300 to the bounty 💰, redeemable upon release of the build that allows me to use my Trezor as a hardware key-stick using FIDO2 on Linux. Bounty will be payed in Bitcoin over Lightning (or in any shitcoin that is supported by https://fixedfloat.com/ or some other reputable swap service).

(My email to claim the bounty: anton.isidore@protonmail.com)

* Bounty of course applies for general implementation that works everywhere as well.

[My1]

@anton-isidore I hope you have a trezor T, as the T1 currently only supports U2F, and using the same functions the trezor Passowrd manager uses would be way too specific.

Edit: although, I dunno of the Trezor T has hmac-secret on its fido2.

[prusnak]

Trezor T has hmac-secret on its fido2.

Yes, Trezor Model T supports FIDO2 hmac-secret extension

[ashleysommer]

Is anyone else interested in taking on the bounty above? I'm taking a shot at it. I don't have a Trezor, but I have a Yubikey 4C and an older Yubikey "Security Key NFC", both support FIDO2, and both have the hmac-secret extension.

With the latest version of libfido2 supporting Window's WebAuthN (Windows Hello) API, and the latest version of Windows supporting the hmac-secret extension, it seems like the roadblocks are behind us.

I have mocked up a working proof of concept in python using the fido2 python module from yubikey, and now I am working on building that functionality into KeepassXC.

My limitations being that I only have the two Yubikey devices to test with, I don't have a Trezor, and I only work on Linux, I can't test on Windows or MacOS.

In terms of implementation, there are a couple of points of concern. Firstly, KeepassXC uses the Botan library for all of it cryptographic functionality. Libfido2 uses OpenSSL for crypto. By integrating libfido2 into KeepassXC, this will pull an OpenSSL dependency into KeepassXC. That may or may not be received well. Secondly, in order to do this integration correctly, Fido2 will need to be added in a way that complements the existing Yubikey support, and doesn't replace it. That would necessitate a large refactoring of that part of the codebase, that seems out of scope for the bounty. Perhaps it can happen in two parts. First add the Fido2 integration, and secondly refactor the code.

[anton-isidore]

@ashleysommer Hi, I trully appreciate that you are picking up the bounty. I am happy to see the movement.

Regarding the concerns in the implementation, it must be done in a way that will be merged and integrated into standard release, so it will be supported and maintained for all future versions.

(I am however not technical enough in this topic to provide any specific opinion on the technicalities, that you have mentioned.)

[robinschwab]

My limitations being that I only have the two Yubikey devices to test with, I don't have a Trezor, and I only work on Linux, I can't test on Windows or MacOS.

Unfortunately a Yubikey is not optimal for testing since we already have a solution for Yubikeys. What we need is a solution for all those who cannot rely on Yubikey. A better test device would be a Neowave Badgeo since this is dual interface wireless and wired.

[ashleysommer]

Unfortunately a Yubikey is not optimal for testing since we already have a solution for Yubikeys.

There are many different types of Yubikeys and same have features that others don't.

For example, my cheaper Yubikey "Fido Security Key NFC" does not include the "Challenge-Response", feature, that is something only the higher-end Yubikeys support. That means it does not work with the current KeePassXC implementation. However since it supports FIDO2, it will work with the new feature. That is the one I am currently testing with.

I'm also talking with the company Hypersecu about their product Hyperfido PRO FIDO2 Titanium. It is a very low cost device (only AUD$25) that does support FIDO2 and does appear to support the hmac-secret extension. I am planning to test with that model too.

[robinschwab]

Just bear in mind there are other interfaces than USB. NFC is needed on smartphones and supported by many laptops. Mechanical card readers are common on most business laptops.

[My1]

it's not about the security Key series being older, the "blue yubis" as I call them as they traditionally have been blue always were FIDO-only (first U2F, and later FIDO2 as well) keys and also priced lower than the "do-everything" Yubikeys (save for the Yubi-Bio which imo should be classed as a Yubico Security Key, but well ever since USB3.1 came out, naming consistancy be damned lol)

I also have a small army of different FIDO Devices which I can gladly help.

@robinschwab somewhere between almost and all FIDO Devices are USB, I literally know TWO smartcard formfactor FIDO Devices currently.
equally smartcard formfactor FIDO Devices use the same protocol as NFC devices and windows treats them the same way.
also as win hello does the abstraction on windows, you should have them working

[ashleysommer]

@My1

it's not about the security Key series being older, the "blue yubis" as I call them as they traditionally have been blue always were FIDO-only

Yes, that was bad phrasing on my part. I am aware they still sell the "security key" series. It just happens that my particular one is around 4 years old. My new Yubikey is a 4C, only a year old, so I call them "my old Yubikey" and "my new Yubikey", but I know in reality they are different product segments, and the age of them does not dictate the feature set.

@robinschwab

Just bear in mind there are other interfaces than USB. NFC is needed on smartphones and supported by many laptops.

KeepassXC does not run on Android or IOS. I don't know if any of the Linux phones have NFC. I don't think NFC is a great requirement for this feature.

[robinschwab]

somewhere between almost and all FIDO Devices are USB

Not true. In Switzerland the public transport ID is a FIDO2 card. So 80% of all adults have a fido2 smartcard but I guess only about 1% have a fido2 USB stick. This may be different in other countries. There is probably a chicken and the egg problem: As long as fido2 cannot be used widely many issuers of smartcards will not implement it but if the cards are not readily available some developers will say it's not worth the effort.

It's better to think about requirements prior to writing code instead of adapting existing code years later.

KeepassXC does not run on Android or IOS

Off topic, but is the X in KeepassXC not standing for cross-platform? At least this argument is not the fault of smartcards.

[gbdlin]

My limitations being that I only have the two Yubikey devices to test with, I don't have a Trezor, and I only work on Linux, I can't test on Windows or MacOS.

Unfortunately a Yubikey is not optimal for testing since we already have a solution for Yubikeys. What we need is a solution for all those who cannot rely on Yubikey. A better test device would be a Neowave Badgeo since this is dual interface wireless and wired.

Why does it matter for testing that there is a solution for another feature/protocol it supports? It's not like one affects how the other works, they are distinct.

There are Yubikeys with NFC support as well, if your concern is the protocol.

[tsusanka]

My limitations being that I only have the two Yubikey devices to test with, I don't have a Trezor, and I only work on Linux, I can't test on Windows or MacOS.

Hey @ashleysommer, how about we send you a Trezor Model T free of charge so you can get this going? I'll ping you on email to talk details 👌.

[My1]

ideally any decent fido2 enabled device should work for testing, like I currently only know one that has actual FIDO2 but no hmac (being the Mooltipass).
but having a trezor or otherwise backup-enabled FIDO2 device is even better as you can potentially do all the key math and replicate stuff, not sure if it's possible to MITM the FIDO2 proto tho

[prusnak]

ideally any decent fido2 enabled device should work for testing,

Having Trezor Model T is great for testing, because not only it implements full FIDO2 spec including hmac-secret and resident credentials, but also you can also see what's happening by looking at its display (where you are shown the confirmation screens).

[My1]

yeah this is a reason I also thought about getting one but if I am just gonna use it as a FIDO device it's WAY too expensive. (and sadly ledger after doing something after years of promises, left out the nano S, and the T1 also has no FIDO2 sadly)

[ashleysommer]

@banym Support for Nitrokey FIDO2 will be part of this new feature, do you wish to add your bounty (you proposed back in January 2020) to that of @anton-isidore?

[ashleysommer]

Anyone interested, I have created a discussion thread about the specifics of the "hmac-secret" implementation, here: #9506

[t4nature]

@My1

it's not about the security Key series being older, the "blue yubis" as I call them as they traditionally have been blue always were FIDO-only

Yes, that was bad phrasing on my part. I am aware they still sell the "security key" series. It just happens that my particular one is around 4 years old. My new Yubikey is a 4C, only a year old, so I call them "my old Yubikey" and "my new Yubikey", but I know in reality they are different product segments, and the age of them does not dictate the feature set.

@robinschwab

Just bear in mind there are other interfaces than USB. NFC is needed on smartphones and supported by many laptops.

KeepassXC does not run on Android or IOS. I don't know if any of the Linux phones have NFC. I don't think NFC is a great requirement for this feature.

I think the Trezor Emulator might be helpful for you