Hangs when smart card is used in parallel locally and via CCID #54
Labels
Comments
tlaurion
added a commit
to tlaurion/nitrokey-hotp-verification
that referenced
this issue
Apr 17, 2024
… 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]>
tlaurion
added a commit
to tlaurion/nitrokey-hotp-verification
that referenced
this issue
Apr 17, 2024
… 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]>
tlaurion
added a commit
to tlaurion/nitrokey-hotp-verification
that referenced
this issue
Apr 17, 2024
… 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]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Device hangs, while using smart card features locally (e.g. PIN validation), and just after that
gpg2 --decrypt.Reproduces on Pro v0.7 (OPC2), v0.10 (OPC3).
Details: Nitrokey/libnitrokey#137
The text was updated successfully, but these errors were encountered: