I recently upgraded my X230 (running Ubuntu 20.04) Heads firmware version to 1.4.
When I do a system update, Heads does warn me that there is a boot hash mismatch and asks me to update the checksums, but the nitrokey, which used to blink in red in such case, is now blinking in green.
Is this a normal behavior, or is there something I should check or do to have the Nitrokey behave as it was prior to the upgrade ?
Indeed I would expect it would blink red on the mismatch (as it worked for you before).
- What Nitrokey model and firmware version do you use?
- I understand that it was working before the update. Can you tell what method / guide did you use?
Thanks for your reply.
- I use a Nitrokey Pro 1, which came along with my Nitropad (back then, I ordered it with Qubes preinstalled, but I then switched to Ubuntu); as I understand, firmware update is not possible with this model of Nitrokey, so the key has got the same firmware it had when I received it.
As for the Nitropad Heads firmware, it is currently v1.4
- To update my Heads firmware (wich was v1.1) to v1.4, I used the instructions provided here and here
At some point, I also had to do a factory reset following this guide, but I’m not sure to remember when exactly and why I had to do it.
But reading this guide again, I notice that step 1.is about to backup my security key, and I didn’t do it. Has it anything to do with my issue ?
I notice that step 1.is about to backup my security key, and I didn’t do it. Has it anything to do with my issue ?
I do not think so.
Thank you for the updates. I asked in the team to schedule a retest of your problem on our side.
Certainly green LED blinking should not happen on the boot hash mismatch. In case you would have any additional information please feel free to share.
Please also write here in case no one would get back to you in a week (or to email@example.com, linking to this page).
Ok, thanks a lot, I will look forward to hear from you.
received my NitroPad x230 just a few weeks ago - it’s a great machine!!
It came with Qubes OS 4.1 and the newest Heads.
I’ve noticed a similar issue:
After a Qubes system update the Nitrokey will be blinking green, but then on the next screen warn me of a boot hash mismatch and ask me to update my checksums.
According to the Qubes system update doc this is the expected behavior?
It shows a screenshot that shows TOTP / HOTP: Success - and then the warning comes in the step after that. Now, reading the above posts does confuse me a little:
Is there something wrong, should the Nitrokey be blinking red?
IIRC the light has also blinked red before, but it seems during the last few upgrades it’s like Winst0nSm1th says - the light keeps blinking green.
I’ve only done a “refresh TOTP/HOTP”.
Now I assume that the Qubes system update doc is correct, and that only some system upgrades (those involving BIOS or firmware?) will cause the light to blink red, while other upgrades involving the /boot partition might keep the light green but then warn over a checksum mismatch on the next screen?
There are two stages:
The TOTP / HOTP is used to verify that heads firmware itself was not tampered with.It is mandatory to verify this on update of Qubes to maintain a trust chain.
When you then boot the updated OS, heads will verify signatures and notify you that the Linux kernel/initramfs changed or new files have been added. Only when you are certain that you updated the OS yourself, you could use the GPG key on your token to sign the changed boot image. While doing this, you should verify the signature counter of the token.
- The retest was rescheduled to this week.
- In the meantime I’ve heard, that the direct cause might be in receiving a different answer than expected from the accompanying Nitrokey USB device, while it gets the right one from the Nitropad.
Potential solution for that is running a regular factory reset of the Nitropad. You may want to wait for the results on the our end first to make sure this is the right solution.
Ok, thanks for the update; personnally I will wait for the result of your retest.
I sorry for the confusion here. @danten and @nku you a correct with your assumptions. So this is expected behavior. The Nitrokey will Blink red if something goes wrong with the hotp check (details see here GitHub - Nitrokey/nitrokey-hotp-verification: A command line C app to validate HOTP codes on Nitrokey Pro v0.9+ device) .
It will blink green if every thing is fine. There is also always some red blinking this shows the activity of the openpgp card, checking the signature of the hash file.
The check if the hashes in this file are the same then the actual files in the /boot menu is done later (heads/gui-init at master · Nitrokey/heads · GitHub line: 65 )
Hope this clear thinks up we will make it more explicit in the Doc’s
is the LED hardware just blue/green or is it RGB? because maybe it might make sense at least in a setup with a nitrokey as boot verifier that the color of other operations is not red or green but maybe for example Blue to not cause literally this confusion
These are two separate LEDs, red and green.
okay interesting, might have been a cool idea if one could split “boot is okay” from “i exist and I am okay” or whatever
It’s split by the blinks count. Additionally, the boot indicator has higher priority, and the failed boot blinks red LED almost infinitely, regardless of other functions (whether it’s PWS or smart card or something else).
What was the outcome to this ticket?