Unlocking database with Onlykey is a hit and miss

[Jeroen2000]

Expected Behavior

When KeepassXC says "Please touch the button on your YubiKey!" I expect the database to open if I touch a button on the Onlykey and have typed the correct password.

Current Behavior

I sometimes get this error: "Error while reading the database: Unable to calculate master key". I have verified thoroughly that I got my password typed right. There seems to be some timing issue: press too fast and it won't work, press too late and it won't work either.

Steps to Reproduce

1. Plug-in the Onlykey in a USB-port and unlock it
2. Open KeepassXC and enter your password as usual
3. Hit enter and touch a button on the Onlykey when requested

Debug Info

KeePassXC - Version 2.5.3
Revision: f8c962b

Qt 5.13.2
Debugging mode is disabled.

Operating system: Windows 10 (10.0)
CPU architecture: x86_64
Kernel: winnt 10.0.18363

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare (signed and unsigned sharing)
• YubiKey

Cryptographic libraries:
libgcrypt 1.8.5

[droidmonkey]

This could be an onlykey firmware issue. We block the unlock process until the hardware key returns the response. There is no way we would continue unless we heard back from the key.

[Jeroen2000]

Also a possibility I will also notify the Onlykev Dev's. Is there some debug I can enable in order to see what is being received by KeepassXC? I could try to sniff the USB-bus but that probably won't be as easy:)

[droidmonkey]

No you'd have to debug KeePassXC itself. It would be unintelligible to a human anyway

[onlykey]

@Jeroen2000 This may happen if you created a keepass database using slot 1 on OnlyKey (or Yubikey) and then you select slot 2 when trying to open the database created with slot 1 (or vice versa). Can you verify that you see the issue when you know for sure that the right slot is selected?

[Jeroen2000]

@onlykey 100% positive I have the right slot. KeepassXC defaults to slot 1 so I need not select anything. I was adding some entries to my Keepass just now and when I save, I have to hit a button on the Onlykey and I had 2 failures out of 5 saves

[onlykey]

@Jeroen2000 Is there any other details you could provide that would help reproduce? Have you tried on Mac at all and had similar issues? Created an issue here to track in OnlyKey repo - trustcrypto/OnlyKey-Firmware#107

[Jeroen2000]

@onlykey do we need to take this discussion to the link you posted?

I have tested on 2 Windows 10 devices so far (a laptop and a desktop)
This might be relevant during a failed attempt to save the database:

1. When KeepassXC asks to 'touch the button' Onlykey starts flashing yellow.
2. Upon pressing the button, KeepassXC immediately throws the error and Onlykey keeps flashing yellow
3. After a while, onlykey strobes (rapid flashing) red and goes to green again
4. Then the next attempt to save works (so far)

For the database opening errors, I have had to try many times (4 or 5) on one occasion. Unplugging Onlykey, closing and opening KeepassXC. Each time I verified my password attentively.

I happen to have a Macbook so I'll try to find out whether there is similar behaviour or not.

[Jeroen2000]

@onlykey I have now started testing on the Macbook. When trying to open my DB just now, KeepassXC would not recognise Onlykey. I hit refresh multiple times, closed and opened KeepassXC and unplugged and replugged Onlykey. I gave up after 5 tries and rebooted.
On 2 occasions Onlykey did show up in KeepassXC (one time only slot 1 was selectable) but I could not get Onlykey to flash yellow: led remained solid green.

This morning it worked fine though. I was able to update 5 entries with only one failure on the first try. It happens enough to reproduce but I am unable to pinpoint what makes it go into limbo.

[droidmonkey]

I am going to work on hardware key robustness next for 2.6.0 so this will be a good test of my changes.

[onlykey]

@Jeroen2000 For mac if you have Catalina there are extra steps to install KeepassXC and use with OnlyKey/Yubikey mentioned here - https://docs.crp.to/usersguide.html#keepassxc

I have not seen or have been able to reproduce issues like the ones you are finding here. Do you have something else you could test to help verify, a Yubikey or another OnlyKey? Some possible issues would be a bad USB extension (try directly plugging in device) or a damaged Onlykey.

[Jeroen2000]

@droidmonkey you may always contact me for testing. More than happy to help.
@onlykey I am still on High Sierra.
My spare Onlykey should arrive shortly. I should be able to rule out a faulty key then. It really does error quite a lot. It does not look physically damaged (it is about a week old :-)) but hardware could be faulty but I do not have that impression.

[Jeroen2000]

@onlykey
@droidmonkey

Got a new 'type' of error. Normally, when KeepassXC asks you to 'touch a button' on the Onlykey, it should start flashing yellow. As you can see in the video, nothing happens and KeepassXC errors out (almost) immediately. I had to unplug and replug to get out of this state.

See video

[droidmonkey]

Thank you for the video! I still think this is a firmware issue.

[nkichukov]

Seems like there is something wrong with the keepassxc implementation for OnlyKey with challenge response on Linux too.

My setup:
GNU/Gentoo Linux kernel 5.4.13 (amd64)
Keepassxc version app-admin/keepassxc-2.5.3 compiled to only support: autotype and yubikey
ykpers version compiled against: sys-auth/ykpers-1.20.0:0
OnlyKey firmware: v0.2-beta.8c

Below are some screenshots and test cases:
1.) After several (successful and unsuccessful) challenge response database updates:
https://i.imgur.com/Cdj2cJc.png - multiple instance of the same appear in the Master Key section. The impression is, those increase every time the challenge response was attempted/initialized during the timespan of the running keepassxc.
2.) When trying to update the database via the Master Key section ( https://i.imgur.com/sLopKSR.png ) and touching the key on the OnlyKey to accept (twice), the failure is: 'Writing the database failed: Unable to calculate master key' ( https://i.imgur.com/RJE4wcV.png ). Doing a save on the database via the menu: Database / Save database works fine and saves successfully every time.
3.) If you lock the database and try to unlock, the list of OnlyKey devices and slots shows fine:
https://i.imgur.com/diwhc7n.png

So this does not seem to be OS specific. Perhaps it is a combination of both: firmware and keepassxc so changes on both may be required.

I have provided some more feedback on the firmware issue when manipulating OnlyKey via keepassxc here:
trustcrypto/OnlyKey-Firmware#98 (comment)
which is mainly to deal with lack of input capabilities after challenge response usage and also keepassxc randomly not able to detect the OnlyKey for challenge response.

HTH,
-Nik

[droidmonkey]

The code on KeePassXC side between onlykey and yubikey is exactly the same. The duplicate slots in the master key dialog was fixed (I thought so)?? It has nothing to do with this problem.

[nkichukov]

Hi @droidmonkey
As it looks, the bug for
1.) is not fixed yet, but I can easily apply a patch if you have one
2.) is exactly the same issue as originally reported: 'Writing the database failed: Unable to calculate master key'. In addition it always saves fine through Database / 'Save database' menu, so there is some difference in the code between adding and saving a database from the Master Key section and Database / 'Save database' menu (3.) ).

As for the random failure to detect OnlyKey for challenge response, this could be something that is either with keepassxc detection causing the firmware to fail or just a bug in the firmware alone. I do not know and I do not have an easy way to figure out. Let me know if I can do anything else to help.

The fact is, this is happening on all 3 OSes: GNU/Linux, Mac OS and Windoze running latest stable keepassxc and latest OnlyKey firmware.

[droidmonkey]

I am currently working on this problem. I hope to have a fix by tonight

[Jeroen2000]

@droidmonkey I can also test since when you have it ready.

I can also confirm the issue is present on MacOS (I am running High Sierra) and I have tested with a 2nd key just to rule out whether my key was a lemon. It feels actually worse than on Windows as on MacOs there is the additional issue of getting the key recognised in the first place. On Windows it is "just" the unlocking that goes wrong when the led is already flashing yellow.

[droidmonkey]

I've gotten it to the point where onlykey is extremely reliable and can work concurrently with another connected yubikey!

[onlykey]

@droidmonkey That's great news! Let me know if you want me to test out any changes I will be happy to do that.

[droidmonkey]

Sure will, I'll notify here when I post the PR for my changes. They are quite substantive.

[droidmonkey]

@onlykey Please see the PR I just posted with the major refactor to hardware key support

[nkichukov]

Nice work on this! Thank you.
I could not apply the patches on top of 2.5.3, so I had to switch to latest code...

This works much better now, so it is usable I would say. On a quick glance, I noticed some issues:

1.) If you have more than one database files opened, one configured with challenge-response but the others not, once you work with the one for challenge response, if you go back to a file that does not make use of challenge response, it still enumerates the slots... should it 'remember' and only issue a 'refresh' on database files that were used with challenge response?

2.) at least with OnlyKey, refreshing the slots makes the HID Keyboard disappear, so I still need the workaround with udev to reattach it. Here, there is no change of behaviour with the previous version.

3.) There is no prompt anywhere in the UI to 'remind' the user that a button has to be pressed for challenge-response to work (not a big deal).

Cheers,
-N

[droidmonkey]

1. This is intentional behavior, the default choice is to not use a hardware key with a database. This behavior is no different then the prior implementation that always polled the keys everytime you switched tabs.

2. I have no idea what you are referring to here

3. There absolutely is a prompt, it's a big blue bar

[Jeroen2000]

I can test too for several weeks to see how it behaves:-) @nkichukov what did you do exactly to get this running? I am on MacOS.

[nkichukov]

@droidmonkey
1.) I like the new behaviour, it works fine for me today and as designed.
2.) See: trustcrypto/OnlyKey-Firmware#98 (comment) for some background info
3.) This is correct, I can see it today, so it is perfect!

@Jeroen2000

wget -O hardware-detection-fixes.patch https://github.com/keepassxreboot/keepassxc/commit/a430c304e2291f25794ae22772036742743dd689.patch
git clone https://github.com/keepassxreboot -b develop --depth=1 testme
cd testme
patch -p0 < ../hardware-detection-fixes.patch

and then follow the steps to compile and install it from the source in 'testme'.

[droidmonkey]

Ahhh the press to type... That works for yubikey with my changes, I explicitly tested that case. There is really no reason why it wouldn't work for only key. The only time the key is "held" by kpxc is when it is being polled on refresh and when a challenge is occurring.

[nkichukov]

confirmed, it also works fine with OnlyKey now.
Great job @droidmonkey , I am looking forward to the official release that will contain those patches.

[onlykey]

@droidmonkey I ran this through some tests today, so far so good, great job! I will keep testing and let you know if I run into any issues.