Hello,
On Nitropads ns50/ns70, which way should I proceed in order to safely update the firmware on both the Dasharo/HEADS firmware (to 2.5.0 from 2.4.1) and the NK3 to latest 1.7.2?
I understand there are some incompatibilities between both devices’ firmware versions that could lead to an unbootable laptop…
Hello,
Anybody there? Support?
Firmware updates are very important! And especially more so that I now discovered that anybody can just enter any Admin pin as they wish and compromise my whole system - I would never even know about it…
And could you please also update the documentation, with clear explanations and procedure for such cases when both the Nitrokey AND the Nitropad are failing.
Once you update only one, it won’t work anymore, so you can’t eliminate a mismatch on boot (something that happens after each regular kernel update, so you will know the steps), but you can still boot the Nitropad by overriding the warning a few times (at least if you did not seal the disc encryption in the TPM, but enter its passphrase manually; I’m not sure about the other case).
Disclaimer: the following is theoretical, best you follow instructions if unsure. In any case, I guess the smoothest way to perform the update is if you have a second system which you can use to update the NK3. Then you can prepare the heads update, boot the nitropad with the NK3 and its old firmware verification, keep heads menu running, switch the NK3 to the second system to update its firmware, flash heads, poweroff. Next, restart the nitropad, regenerate its credentials with the updated NK3 and carry on. If you don’t have a second system, I would opt to update the Nitropad first, do a one-time override to boot it without Nk3, update the NK3, shutdown and then regenerate on next boot, but I don’t see why both ways should not work due to the override. It’s nothing else than switching one NK for another, which you can do anytime via the heads menu.
Two points to keep in mind: 1. Until you regenerate heads credentials, you can check the firmware is ok via the secondary TOTP entry. This will change later (with new heads fw), so don’t forget to verify it and update your authenticator after the update. 2. The HOTP can theoretically be manipulated by a third-party due to this bug. This means the initramfs/kernel may have been compromised, but only if said party got physical access of your NK3 for that. If you are unsure about this point, it depends on your personal assessment of likeliness. There is a couple of things you can do to cross-check. However, it’s pretty clear these can only be measures to reconfirm trust in your system installation, so I skip on that. If you consider yourself having been at risk for such an attack (without any doubt a criminal act in Germany), you should consider the system compromised and act accordingly. (final sidenote: clearly, one malicious package you install could do the same damage and the only difference would be that you may have affirmed the heads bootchain yourself, instead of a third-party.)
Thank you for these very helpful and detailed instructions.
I succeeded in updating both the NK3 and the Nitropad to the latest (and hopefully less vulnerable) firmwares. In the end, to make it work, I had do a re-ownership - but that doesn’t matter because I had nothing else in the NK3 that I wouldn’t want to loose. And since I also wanted to activate the hardware security chip, that was a good time to do it as well.
Seems to work well. At least the HOTP bug is gone, I checked on that.
I now noticed a new warning message appearing right after the Heads splash screen that says: WARN: check public portion of the tpmkey manually
what does that mean? Should I do something about it?
Very good. You can re-flash the same heads firmware without a re-ownership, but re-ownership was definetely an important step here in any case.
Your question was also asked by another user and it’s a new warning indeed. If you go to the heads gpg menu, there is an option to display the public key. This relates to the gpg signature key on the NK3 you see when you execute gpg --card-edit from the booted machine to crosscheck it. Imagine a case where someone swapped your NK3, doing a re-ownership and replacing it with a compromised one. You may not notice until you have to enter a PIN. However, the gpg key will have changed during re-ownership and this way you can detect it, if such a situation might have happened. This is no new feature, but I believe the new warning relates to it.
I leave your question below, perhaps NK support finds time to clarify it.