main.c: remove output when RET_NO_PIN_ATTEMPTS (no PIN retry counter) is true #32
Conversation
… 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]>
|
Here: This commit is included under linuxboot/heads#1640 |
tlaurion
changed the title
|
Well, with this in (or not, will have to retest linuxboot/heads#1640 without this commit), it seems that default Admin PIN is never used anymore (was it?) even on a freshly factory reset USB Security dongle with the defaults (so User PIN 123456 and Admin 12345678)
|
|
Nah. This PR doesn't fix it, it just hides the fact that internal structures of hotp-verification are completely broken. I reverted my fix and tested https://github.com/tlaurion/heads/compare/nitrokey_board_unification_clean-enable_htop_validated_autoboot...tlaurion:heads:nitrokey_board_unification_clean-enable_htop_validated_autoboot-without_hotp_verification_change?expand=1 Master is too bogus to attempt with a quick fix like that.
Logic is at https://github.com/linuxboot/heads/blob/82179e4e9894c5cb503f85522ff57088bdd444dc/initrd/bin/seal-hotpkey#L94-L104. Do factory reset. Do @sosthene-nitrokey @szszszsz Please test hotp-verification.
I can only guess a lot of other things are wrong here. |
…ification@8a1f125" This reverts commit 3a3916b. This was Nitrokey/nitrokey-hotp-verification#32 and requires hotp-verification deeper cleanup which won't happen here.
…ification@8a1f125" This reverts commit 3a3916b. This was Nitrokey/nitrokey-hotp-verification#32 and requires hotp-verification deeper cleanup which won't happen here. Signed-off-by: Thierry Laurion <[email protected]>
…ification@8a1f125" This reverts commit 3a3916b. This was Nitrokey/nitrokey-hotp-verification#32 and requires hotp-verification deeper cleanup which won't happen here. Signed-off-by: Thierry Laurion <[email protected]>
The dongle is in a clean state here without bad PIN entered (when RET_NO_PIN_ATTEMPTS is true).
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.
Fixes #30
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:
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:
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.