-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nitrokey hangs when switching between libnitrokey and GnuPG #137
Comments
Thanks for filing this issue, Robin. I've experience that myself, but never produced a minimal example.
I honestly doubt that. Back in the day when |
Hi! Edit: Perhaps there is an error somewhere in handling this lock, since further calls are failing as well.
|
cc @NKelias |
I tried executing the commands with at least 60 seconds delay, but the problem occurred nevertheless. By the way, the page Programming the Nitrokey only provides information for the Pro, Start and HSM. Are there any resources on debugging the Storage firmware? Would you just have to add an SD card to the Pro setup, or do you need a different development board? |
See #137 (comment) for details Issue #137 Signed-off-by: Szczepan Zalega <[email protected]>
Signed-off-by: Szczepan Zalega <[email protected]>
I have confirmed the issue on Storage v0.53, with code from branch 137-stick_hangs. This might be related to (or the same as) Nitrokey/nitrokey-storage-firmware#66. Edit: tested with delays: {1, 90} |
@robinkrahl For debugging Nitrokey Storage you would need a development board, which we do not sell. It's hardware layout is available in the proper hardware repository. |
It Edit: add run log: |
Crosslinked to Nitrokey/nitrokey-pro-firmware#54 |
The larger topic of parallel accesses is non-trivial. If you @robinkrahl would like to dig deeper and need a development board, please let me know. |
@jans23 Thanks! If I’m going to play with the firmware, I’ll start simple and have a look at the Pro. I was just curious because the homepage didn’t say anything about the Storage. |
Are there any news on this issue? It seems like every subsequent gnupg call fails after generating an OTP, no matter how long the delay, which is really annoying in daily usage. |
@robinkrahl Sorry, but nothing new yet. |
It seems to me that the issue is on the GPG side of things, since it assumes a persistent session. This does not apply here, however, because the state has been altered in the background through the libnitrokey call. As a workaround, the following works for me:
This makes GPG drop its assumed current session state and start a new one. I'd have to dig deeper into the protocol on how to prevent the error state you're seeing. |
For some very rudimentary printout-debugging, you could also use this bit: [1]
This allows you to write text output from the firmware to a file on the SD card. Though in general as mentioned above, a DevBoard and a debugger are the recommended way of doing it. |
It's been a year since the last update. Where are we with this issue? It seems rather unfavorable for your product to have such a blatant incompatibility with one of the arguably most widely spread privacy-related software in circulation. |
@d-e-s-o Indeed, it takes too long with it. Thanks for bumping this up. |
Is this issue understood? Has it been identified as indeed falling under this bug's umbrella or is that a separate problem? |
My suspicion is that we may have to add support for Nitrokey devices to the application switching code in scdaemon. If I am understanding correctly, switching of that sort is covered by the ISO standard for smart cards. The Geldkarte certainly managed to do that. |
@d-e-s-o @szszszsz Could this be a path forward? I have not delved much deeper than a short internet browsing, and maybe GPGME is too limited with the level of service that is expected from libnitrokey. |
I doubt it. GPGME just interfaces with GnuPG from what I understand ("Currently it uses GnuPG's OpenPGP backend as the default, but the API isn't restricted to this engine."). Given that the issue at hand is an incompatibility (for lack of a better term) between libnitrokey's way of accessing a smart card and GnuPG's, I don't see anything gained. |
We mentioned the libnitrokey/scdaemon incompatibility leading to a hanging Nitrokey [0] in the readme, but did not explain how to deal with this issue. With this patch, we mention that killing scdaemon after running nitrocli mitigates the problem. Fixes d-e-s-o#164. [0] Nitrokey/libnitrokey#137
We mentioned the libnitrokey/scdaemon incompatibility leading to a hang in Nitrokey [0] in the README, but did not explain how to deal with this issue. With this patch, we mention that killing scdaemon after running nitrocli mitigates the problem. Fixes #164 [0] Nitrokey/libnitrokey#137
We mentioned the libnitrokey/scdaemon incompatibility leading to a hang in Nitrokey [0] in the README, but did not explain how to deal with this issue. With this patch, we mention that killing scdaemon after running nitrocli mitigates the problem. Fixes #164 [0] Nitrokey/libnitrokey#137
We mentioned the libnitrokey/scdaemon incompatibility leading to a hang in Nitrokey [0] in the README, but did not explain how to deal with this issue. With this patch, we mention that killing scdaemon after running nitrocli mitigates the problem. Fixes #164 [0] Nitrokey/libnitrokey#137
Environment: Archlinux x64 with Linux Kernel 5.10.71-1-lts, GnuPG 2.2.29, Nitrokey-App 1.4.2 and Nitrokey Pro 2 Firmware 0.11. I just got started with the Nitrokey and ran into this issue when working with password manager via Nitrokey-app and GPG decryption. Running "gpgconf --kill gpg-agent" before and after running nitrokey-app while trying not to trigger anything with GPG seems to avoid a lock-up of the system. I think the provided error message "Device is locked/had timeout. Re-connect device..." makes users think that something unexpected happened although this is a systematic issue. The issue will immediately become active just after reconnecting if the user continues to use the app with GPG in parallel. Instead, the user should be properly instructed that the user cannot use GPG and any nitrokey-app at the same time and has to apply a good workaround that is required by their particular system. The re-connection is probably the most generic workaround, but it is rather inadequate. I think everyone who uses the Nitrokey as intended will run into this issue and given the age of the issue the information flow is quite unsatisfactory. |
… is true: the dongle is in a clean state here without bad PIN entered. This doesn't imply that we are using the default PINS. This seems to have been based on wrong assumption that if no prior PIN attempt we are in factory state with default PINS (USER 123456, ADMIN 12345678). Calling code should be, and is responsible of interpreting artifacts telling that the USB Security dongle is not in factory reset mode with default PINS. --- History: Prior of linuxboot/heads@99673d3, Heads was doing the same wrong assumption. Heads was consuming 1/3 of the PIN to check if it was the default one without, resulting with the user only having 2/3 PIN input attempts before being locked out. Because of Nitrokey/nitrokey-pro-firmware#54 (unfixed, linking to unfixed Nitrokey/libnitrokey#137), if Heads attempts to use scdaemon/libnitrokey, the dongle hangs. Let if be libnitrokey/gpg expecting exclusive dongle access, this cause hangs. Therefore linuxboot/heads@99673d3 bases its assumptions on Heads previously created gpg keyring without relaying on neither scdaemon/libnitrokey. It uses public key creation vs current timsetamp to determine if the user should be reminded that is using default PINs, they should be changed. TODO: - Fix Nitrokey/nitrokey-pro-firmware#54 - Fix Nitrokey/libnitrokey#137 Otherwise, if on any situation, libnitrokey/scdaemon operations are intertwined, this causes Nitrokey/heads#48, which i'll reopen. Any Heads developer will come to the same problems: - Develop on host. Push signed commits with said dongle, which use scdaemon on host to interact with USB Security dongle to do signing ops. - Call make BOARD=qemu-coreboot-fbwhiptail-tpm2-hotp USB_TOKEN=NitrokeyPro/NitrokeyStorage/Nitrokey3NFC/LibremKey to test Heads. - Land under kvm/qemu, observe reported locked problems, blame QubesOS, blame Heads, blame gnupg. - Truth is that its libnitrokey/firmware bug. ---- hotp-verification should only report on : firmware version(currently wrong), serial number and success/fail state and not do any assumption reporting false information, confusing the end user. Signed-off-by: Thierry Laurion <[email protected]>
… is true: the dongle is in a clean state here without bad PIN entered. This doesn't imply that we are using the default PINS. This seems to have been based on wrong assumption that if no prior PIN attempt we are in factory state with default PINS (USER 123456, ADMIN 12345678). Calling code should be, and is responsible of interpreting artifacts telling that the USB Security dongle is not in factory reset mode with default PINS. --- History: Prior of linuxboot/heads@99673d3, Heads was doing the same wrong assumption. Heads was consuming 1/3 of the PIN to check if it was the default one without, resulting with the user only having 2/3 PIN input attempts before being locked out. Because of Nitrokey/nitrokey-pro-firmware#54 (unfixed, linking to unfixed Nitrokey/libnitrokey#137), if Heads attempts to use scdaemon/libnitrokey, the dongle hangs. Let if be libnitrokey/gpg expecting exclusive dongle access, this cause hangs. Therefore linuxboot/heads@99673d3 bases its assumptions on Heads previously created gpg keyring without relaying on neither scdaemon/libnitrokey. It uses public key creation vs current timsetamp to determine if the user should be reminded that is using default PINs, they should be changed. TODO: - Fix Nitrokey/nitrokey-pro-firmware#54 - Fix Nitrokey/libnitrokey#137 Otherwise, if on any situation, libnitrokey/scdaemon operations are intertwined, this causes Nitrokey/heads#48, which i'll reopen. Any Heads developer will come to the same problems: - Develop on host. Push signed commits with said dongle, which use scdaemon on host to interact with USB Security dongle to do signing ops. - Call make BOARD=qemu-coreboot-fbwhiptail-tpm2-hotp USB_TOKEN=NitrokeyPro/NitrokeyStorage/Nitrokey3NFC/LibremKey to test Heads. - Land under kvm/qemu, observe reported locked problems, blame QubesOS, blame Heads, blame gnupg. - Truth is that its libnitrokey/firmware bug. ---- hotp-verification should only report on : firmware version(currently wrong), serial number and success/fail state and not do any assumption reporting false information, confusing the end user. Signed-off-by: Thierry Laurion <[email protected]>
… is true: the dongle is in a clean state here without bad PIN entered. This doesn't imply that we are using the default PINS. This seems to have been based on wrong assumption that if no prior PIN attempt we are in factory state with default PINS (USER 123456, ADMIN 12345678). Calling code should be, and is responsible of interpreting artifacts telling that the USB Security dongle is not in factory reset mode with default PINS. --- History: Prior of linuxboot/heads@99673d3, Heads was doing the same wrong assumption. Heads was consuming 1/3 of the PIN to check if it was the default one without, resulting with the user only having 2/3 PIN input attempts before being locked out. Because of Nitrokey/nitrokey-pro-firmware#54 (unfixed, linking to unfixed Nitrokey/libnitrokey#137), if Heads attempts to use scdaemon/libnitrokey, the dongle hangs. Let if be libnitrokey/gpg expecting exclusive dongle access, this cause hangs. Therefore linuxboot/heads@99673d3 bases its assumptions on Heads previously created gpg keyring without relaying on neither scdaemon/libnitrokey. It uses public key creation vs current timsetamp to determine if the user should be reminded that is using default PINs, they should be changed. TODO: - Fix Nitrokey/nitrokey-pro-firmware#54 - Fix Nitrokey/libnitrokey#137 Otherwise, if on any situation, libnitrokey/scdaemon operations are intertwined, this causes Nitrokey/heads#48, which i'll reopen. Any Heads developer will come to the same problems: - Develop on host. Push signed commits with said dongle, which use scdaemon on host to interact with USB Security dongle to do signing ops. - Call make BOARD=qemu-coreboot-fbwhiptail-tpm2-hotp USB_TOKEN=NitrokeyPro/NitrokeyStorage/Nitrokey3NFC/LibremKey to test Heads. - Land under kvm/qemu, observe reported locked problems, blame QubesOS, blame Heads, blame gnupg. - Truth is that its libnitrokey/firmware bug. ---- hotp-verification should only report on : firmware version(currently wrong), serial number and success/fail state and not do any assumption reporting false information, confusing the end user. Signed-off-by: Thierry Laurion <[email protected]>
AFAIS Nitrokey/heads#48 is about the Nitrokey 3, but libnitrokey is only used with Nitrokey Pro or Storage. Can you add more details please? |
I will do another rounds of tests on real hardware with heads outputting more debug around the gpg/hotp-verification related calls. The ping was based on the behavior observed in those issues, and directly on notes under seal-hotp script workarounds pointing to those unresolved issues either firmware/library/gpg based. If either of those tools expect exclusive access, the behavior will stay. This would mean for Heads to have to kill the culprit expecting exclusive access, which to say the least is a problem. |
The particular problem in this issue was caused by the fact that the Nitrokey Pro and Storage internally used the OpenPGP smartcard to implement the (H)OTP feature. As GnuPG caches some information about the state of the smartcard, this could lead to problems. This is no longer the case for the Nitrokey 3, so this kind of problem should no longer occur. There still is the problem that GnuPG requires exclusive access to the CCID smartcard. But this should not cause any conflicts with libnitrokey as it does not use CCID. In case any other library or tool wants to access the CCID smartcard via pcsc, scdaemon probably needs to be stopped or restarted before that. |
@robin-nitrokey also, we do not talk specifically of the nk3 here, maybe the issue tilte is misleading. Heads abstracts as much as possible if the USB dongle is a Librem Key/Nitrokey Pro, Nitrokey Strorage or NK3. If differences, Heads expects the firmware/hotp-verification provided tools to do the right thing here. After all, Heads is a downstream user of those tools and in any case, if those issues exist, it's a problem. The user should not be expected to have to remove/reinsert the dongle between signing and HOTP interactions with the dongle. In my use case, signing commits and then launching qemu to test such code most always resulted in the dongle not properly behaving on HOTP check, and digging down and fixing timings under Heads driver loading didn't fixed those other issues. There is something wrong happening here, not sure which tool to blame, or the firmware needing to remove some locks after said operation, or issuing a reset or whatever more clean solution. Worst case scenario, Heads will need to ask the user to remove the USB dongle after an operation, which I hope won't be the solution here. This won't resolve development cycle operations. As you may know, development cycles for Heads under QubesOS requires passing the usb dongle from sys-usb to testing qube for qemu to take ownership of that device and do there hotp and signing operations. This always go wrong after signing commits under the "host", that host being testing qube launching qemu after a singing operation. Exclusive access of the dongle by the host? Under qemu launching built rom with signed code after a signing op, the device is always detected properly (usb ID detected, but talking to the device always results in kernel error - 32). And here starts a dance of removing the dongle, passing it again to the qube, and timing issues makes the device mostly always unavailable, requiring qube restart, sys-usb restart and sometimes rebooting the development machine altogether with pretty low success rate. Those opened issues made me realize that neither qubesos, sys-usb, qubes-usb-proxy, qemu nor scdaemon were maybe to to blame here. If hotp/gpg expects an exclusive access or the firmware is locked into doing one or the other type of operation, we still have a problem. Would it be for Heads qemu launching code to kill scdeamon and whole gpg toolstack on the host prior of launching qemu? Preliminary tests shows this doesn't fix the problem. So the question is: where is stemming the problem. Those issues still being opened (unfixed) seems to show some shared root causes. If needed, I can open another issue. Will test other hypothesis and add debug traces in both oem-factory-reset and around all gpg/HOTP related codepaths under Heads meanwhile. The issue also shows on non-development cycles. The dongle is not always in a state permitting to interact with on real hardware, reducing reproduction complexity. So I'll add debug code and report what is happening from debug traces collected on real hardware so we can't blame qubesos nor qemu here. |
@robin-nitrokey Thanks for clarifying. @JonathonHall-Purism tagging you here since Librem Keys are definitely still affected by this and should probably be tested more to see if still relevant after linuxboot/heads#1638 being merged being enough or not. |
When switching between libnitrokey and GnuPG, both my Nitrokey Pro and my Nitrokey Storage hang with the red LED staying on. Any GnuPG calls will hang or return an error message. Further libnitrokey calls fail too.
To reproduce the error, encrypt any file
test.txt
for the key stored on the Nitrokey. Connect the Nitrokey. Execute these commands:The second
gpg
command fails.test
is compiled from this C code:Error messages when calling GnuPG or libnitrokey again:
The problem can be fixed by removing and reconnecting the Nitrokey device. Are you aware of this issue? Am I doing something wrong when calling libnitrokey? Can this problem be avoided?
The text was updated successfully, but these errors were encountered: