HMAC Challenge Response Leads to Unresponsive OnlyKey #98
Comments
|
I can reproduce this type of unresponsiveness on my system as well: OS: Manjaro Linux (with Kernel v5.5.7) @schlomie: I guess, you're also on a Linux based system? Checked it on MacOS, it works as expected and OK does type passwords after having unlocked database with KeePassXC. |
|
@tafli Yes. On Void, 5.4.24 |
|
Same here, GNU/Gentoo Linux with kernel 5.4.13. Apps are same versions as @tafli reported. |
|
Further investigation on this issue revealed that whenever the OK is detected by keepassxc for challenge response, it is actually removed from the kernel (unbind). This is why it works no more as a keyboard, it simply does not exist and the OK does not present itself afterwards (after being listed or used as challenge response factor) as HID device to the kernel. Here is what the udevadm monitor shows: OK added to computer: keepassxc started up and OK found for challenge response: So a simple workaround to continue using your OK without having to remove it from the computer thus having to type your unlock code again is to simply 'bind' to the usb subsystem manually, ie:
Because the OK was never power-cycled, it keeps your profile open and everything continues to just work. After the device got detected or used for challenge response it needs to tell the kernel that it is again a hid(hidraw) device so it can be bound and used again to type. Perhaps this can become in-firmware fix or udev-rule type of thing. |
|
one correction, you'd workaround with binding the whole USB device(as initially suggested) if you have previously unbound it, which is not the case when OK is detected by keepassxc. The detection only removes/unbinds the HID device. Thus the correct 'bind' should go to usbhid instead, something like this udev rule:
However this most likely prevents the 'press any key to approve the challenge response' functionality... which essentially breaks the whole challenge response concept. In addition, I see strange misbehaviour where the device sporadically disappears from the list of devices for challenge response... |
|
Seems very related to: |
|
@nkichukov Excellent job here tracking down the issue. I think with this info I will have what I need to find a solution, time to dust off the USB protocol analyzer. |
|
@nkichukov I did some testing today with Yubikey to see if it has the same issue, looks like it does. I set a static password in slot 1 (keyboard), then HMAC SHA1 in slot 2. Keyboard works fine until I attach the device to KeepassXC, after attaching it no longer works as a keyboard. Going to do some more testing to see what options are available, in firmware we might be able to do a time based reconnect USB 10 seconds after receiving last HMAC related event to reconnect key to the host. I am thinking the best fix would probably be if this is just an issue that could be fixed in KeepassXC so I will look into that too. |
|
Hi Tim, As to the short-term workaround, at least applicable on linux, the additional udev rule I posted before I have modified a bit more to include a delay, so instead of doing it at the firmware level, I do it at the OS level:
What this does is, every time I get to the unlock keepassxc database screen, the onlykey does not work for 5 seconds to type my password, then it works as keyboard again, then I can select the challenge response slot and follow the process. Not ideal, but temporary resolves the problem. Why the challenge response slot enumeration function disables the keyboard? Why is this needed? Can this be avoided? The listing of available slots should not disable the keyboard feature, the actual response generation(when opening the database) should as it prompts for a key to be pressed, without generating any output. So instead of adding 10 seconds delay in firmware to reattach, we should perhaps see if we can completely avoid this scenario(in keepassxc, yubikey-personalization as keepassxc relies on it and OK-firmware)? |
|
@schlomie @tafli KeepassXC has pushed a fix that addresses hmacsha1 issues, including the issue where you can't use OnlyKey as a keyboard after using with KeepassXC on Linux. Are you guys able to test it out and see if you have any issues? I have tried it out and this seems to fix the issue, @nkichukov tested as well. |
|
I built it from that commit, still the same issue with the OnlyKey - AND it no longer detects the Yubikey. Debug Info:
|
|
@schlomie Hmm I am not seeing that, I know @nkichukov mentioned in the keepassXC issue that it was now working for him as well. KeePassXC - Version 2.6.0-snapshot Qt 5.12.5 Operating system: Kali GNU/Linux Rolling Enabled extensions:
Cryptographic libraries: I do see that by default Hardware Key just says select hardware key, you have to click the arrow to see the Yubikey
When both Yubikey and OnlyKey are inserted I see that the OnlyKey slot assigned to my KBDX is autoselected
At this point I can open a text editor and select one the static passwords in my OnlyKey and it now types. I tested this on Debian. |
|
Interesting. Yeah, I have both my Yubikey and Onlykey plugged in, and the only option available is the OnlyKey. With the OnlyKey disconnected, a
But anyway, I'm still seeing the same behavior, where the OnlyKey "locks up" (so to speak,) where it no longer types out passwords. All other functions continue to work (including the HMAC-SHA1 challenge response on keepassxc) |
|
This has been resolved for me, however I am at commit a430c304e2291f25794ae22772036742743dd689 and you are at the next one. I do not have yubikey to test, but onlykey works as expected. After I recompiled with the patches included, I did see some strange behaviour, but next day after system reboot everything was working as expected(perhaps old preserved libraries were loaded). I do like the new functionality, where keepassxc 'remembers' if your database file makes use of hardware key and only lists/refreshes the tokens and then pre-selects those for the databases that actually make use of it. Typing from Onlykey works after keepassxc token refresh without any additional udev rules required now. I do not like their(keepassxc) new theme, but functionality-wise: all just works. |
|
@schlomie I don't see the "WARNING" message in your screenshot, that should appear if you are running Keepassxc built from the commit 048386c3f9a655fb19d9eff6b52b7fd85b64a972 |
|
Bah! I dismissed the warning before snapping the pic.
Here's the debug, indicating it is built from that commit.
|
|
So I've built KeepassXC a few times now, since this PR was merged, and once again last night with the 2.6.0-beta1 tag. The changes made to #4584 before it was merged made it work without issue with OnlyKey. Interestingly though, it no longer works with my Yubikey 4 or 5. Yubikey OnlyKey I thought it might be an issue with my build environment, so I checked out the 2.5.4 tag and built it using the same libs and toolchain - result was the same as the pre-built 2.5.4 binaries. Yubikeys would work fine, OnlyKey would not. Anyone else want to try building the 2.6.0-beta1 tag and test with both the OK and YKs? The 2.6.0 milestone only has a few outstanding issues remaining, so they are likely only a few days or so away from a release. I think I'll wait until after before I open a bug report over there.
Also - now built on Artix (arch) instead of Void - just to rule out any irregularities. |
|
With 2.6.0 out the door, I guess I can comment on this further. Looks like I wasn't the only one who encountered the issue of Yubikey not being detected: But it was a pretty simple fix and has been tagged for 2.6.1: Anyway - nevermind all that. OnlyKey works well with 2.6.0 and I no longer feel this issue needs to be open any longer. |
Per our discussion here, this issue describes the behavior I am seeing on the OnlyKey when using the HMAC Challenge Response to open a kdbx file with KeePassXC.
Firmware: v0.2-beta.8c
App: v5.2.0
KeePassXC: 2.5.3
Per your instructions, I added my 20 byte HMAC secret (generated with the ykper tool) to ECC Slot 30 on the Advance Tab of the app, padding the right with zeros to fully supply the required 32 bytes.
The OnlyKey was disabled (became unresponsive to password touches1) in exactly two ways, although I think both are triggered by the same mechanism.
Steps to reproduce 1.
Steps to reproduce 2.
I will upload some screenshots/video demonstrating this when I have a bit more time.
1 This HMAC soft lock (as we might call it) only affects using the OnlyKey to type out passwords. onlykey-agent still works, after OK has become unresponsive. Although interestingly, in this state, an extra
<Enter>press is necessary with onlykey-agent. Under normal operating conditions, the moment the 3-digit challenge is met (or pressed when 3-digit challenge is disabled) the secure shell session is opened. After the HMAC soft lock as described above, the moment the 3-digit challenge is met, the terminal will wait until<Enter>is pressed on the keyboard.2 I've noticed KeePassXC favors the Yubikey. If the YK is inserted prior to all of this, the OK isn't even considered.
Additionally (and possibly related,) this is kind of still an issue (I need to update that issue with new findings post beta8.) Any time the OnlyKey is used for any operation outside of typing passwords, the OnlyKey App no longer detects the OK. The OK still functions correctly, types out passwords (sans HMAC soft lock,) works with onlykey-cli and onlykey-agent and functions correctly as a U2F token. To get the App to recognize the OK again, it must be disconnected, re-inserted and re-unlocked.
The text was updated successfully, but these errors were encountered: