Skip to content
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

Hangs when smart card is used in parallel locally and via CCID #54

Open
szszszsz opened this issue Jan 7, 2019 · 1 comment
Open

Hangs when smart card is used in parallel locally and via CCID #54

szszszsz opened this issue Jan 7, 2019 · 1 comment

Comments

@szszszsz
Copy link
Member

szszszsz commented Jan 7, 2019

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

@szszszsz szszszsz added the bug label Jan 7, 2019
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]>
@tlaurion
Copy link

tlaurion commented Apr 17, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants