Nitrokey 3 Firmware Security Improvements Wishlist

[qwrd]

Hello, I made a small list of wishes that could potentially benefit the security of the Nitrokey 3 firmware.
I may add things to the list as time goes on, but here is my current wishlist.

Make the NK3 LED blink differently when entering bootloader mode
When performing a firmware upgrade on a Nitrokey 3 NFC, the user is required to put the device into a bootloader mode by initiating the update from software, and then touching the device to confirm. While the device is waiting for touch confirmation, its LED will blink in a regular pattern.

Now, I performed the firmware upgrade just once, because I currently have only one NK3ANFC device available, and I wasn't paying that much attention. But, I think I saw the LED blink in the exact same way as when the device is waiting for touch confirmation to perform some cryptographic operation. So, my proposition is to make the device LED blink in a different and more distinctive way to make it more obvious that it is waiting for touch confirmation to enter the bootloader mode and not to perform some cryptographic operation. Currently the LED seems to blink like on-off-on-off-on-off. Perhaps make it so that it blinks like 3 times in quick succession followed by a 1-second pause, and the pattern repeats. Do this only for when the device is waiting to enter bootloader more. Keep the blinking of doing crypto-operations unchanged. This change would make it more obvious that the device is requesting a firmware upgrade when it's not supposed to, and that there is something fishy going on.

Protection against weakened firmware upgrade attacks
I've been reading the Nitrokey forums, and I came across an interesting thread with some valid points.
https://support.nitrokey.com/t/nitrokey-3-nk3-and-firmware-upgrade-security-considerations/6297

Government intervention should be considered a security threat. What, if a court orders the Nitrokey team to hand over the firmware signing keys? What, if a government intelligence agency under the pretext of national security demands the Nitrokey team to produce a firmware with weakened security? What, if a rogue employee steals and hands over the firmware signing keys to the government? Then 3-rd parties will be able to sign their own firmware and perform a firmware upgrade attack on NK3 devices.

My proposition is to add a configuration option/flag to NK3 on-board settings (admin app) to restrict firmware updates in some way. This flag would default to level 0 (disabled) upon device production, and would not apply any restrictions, meaning that firmware could be upgraded freely like it is currently possible to do. Firmware would still have to be signed though. Then, the end-users can customize this option and set it to a more restricted level that suits their own threat model. For example, the option could be set to level 1 (PIN required), which would require the user to provide a correct PIN (in addition to touch authentication) before the firmware update becomes enabled. Once set, this restriction can only be unset by a device factory-reset, which also erases all stored data. Finally, there could be a level 2 (firmware locked), which would permanently disable any firmware updates. Once this flag is set, no more firmware upgrades are possible. Ever. Even if the device is factory-reset, the restriction stays in place. This cannot be unset, and a new Nitrokey3 has to be purchased.

Put the NK3 Admin app behind a PIN
I had this idea that the NK3 admin app itself could be put behind a PIN to prevent non-owners or malicious programs from messing with the settings. The PIN would have like 5 tries, but once exhausted, the device automatically performs factory-reset.

That's it for now. Keep up the awesome stuff you guys are doing!

[robin-nitrokey]

Thank you for the suggestions!

I’ve created separate tickets for two of the specific feature requests:

• Use different LED pattern for some actions #552
• Introduce a PIN for admin-app #554

Also, a useful feature that is related to the admin PIN is device authentication, i. e. making sure that your device has not been tampered with after you’ve used it last:

• Implement a mechanism for device authentication #553

Please upvote these issues if you are interested in the features.

LED patterns is something that we could implement rather soon. Adding a PIN for admin-app is a bigger issue and more of a mid-term topic. Restricting the bootloader is complicated because we have multiple MCUs with different bootloader implementations. The first step would anyway be to use an admin PIN to protect the reboot. I don’t know if we can realistically implement and support more restrictive features, so I did not create a ticket for that. We can reconsider that after (and if) we’ve implemented an admin app PIN.

I’ll close this issue in favor of the more specific issues. Please let me know if I missed something.