R3 Nitrokey Pro failure to enable update mode

[ghost]

I have been trying to revive an old Nitrokey Pro (R3 marking in PCB) with the latest firmware. Unfortunately, neither Nitrokey App (1.5 RC) nor nitropy are able kick it into update mode. I have access to the PCB and can likely just go the JTAG route.

However this is not entirely clear in terms of who's to blame: the firmware does not seem to indicate a meaningful error code if the firmware update PIN is wrong, and the userland tools also do not provide any meaningful error output (nitropy happily takes any PIN, acts as if any of them worked successfully). Nitrokey App 1.5.x however does provide a "state 9" error code and reports the failed update mode setting.

Please do not close this issue before creating (and referencing) it from any other issues in other repositories that might be applicable. There is absolutely zero information out there about the error code and this will likely help people in a similar situation.

Firmware reported by the way is 0.10.

[ghost]

The error reported by Nitrokey App is 'Device could not be set in update mode. Status code: 9'

[szszszsz]

Hi! This firmware version does not contain bootloader, which was released in v0.11:

• https://github.com/Nitrokey/nitrokey-pro-firmware/releases/tag/v0.11

You need to flash it with debug adapter, if you would like to update it.

Connected: https://github.com/Nitrokey/nitrokey-pro-firmware/issues/95

[ghost]

Hi! This firmware version do not contain bootloader, which was released in v0.11:

* https://github.com/Nitrokey/nitrokey-pro-firmware/releases/tag/v0.11

You need to flash it with debug adapter, if you would like to update it.

Connected: #95

Yes, I have a JTAG attached but the scripts in ./scripts/ are broken and outdated. They also rely on ELF files. Long story short, I have successfully unprotected the STM32 and then seemingly flashed the compiled (from sources) FW. No dice. Device is dead (not recognized anymore as USB, so the image is obviously not functional). The documentation should not recommend the cheap STLink clones either, purely for reliability issues.

I will give it another go and if it doesn't revive it isn't worth the billable hours it takes to fix. I'm disappointed Nitrokey does not put more care into this side of things (forcing dependence or suggesting a closed source tool by STM, since it is the only tool whose instructions here are somewhat up to date). This is a security product some people pay for.

I'm not even complaining about the security implications: it's all fine and dandy that you can compile the firmware yourself, but the moment you introduce closed source tools in the mix your threat model goes poof. The fact that some of the keys were never capable of being field updated is also quite telling for something that is essentially a USB bridge to a OpenPGP smartcard.

So, taking back the issue to an actual situation that should be fixed by the developers: can the instructions be verified and updated? The devloop(-release) is also not functional for a clean clone of the repository, BTW.

[szszszsz]

1. I've never had any reliability issues with the clones, and they worked on par with the official hardware. Of course YMMV. What have occurred is probably a hard halt on the MCU after dropping the flash lock, which needs power cycle for the further use.
2. We have never supported hardware flashing in the field, and never intended to. You can write to support asking for the firmware update for devices not having it.
3. Actually, some see firmware update as a liability in the threat model, and instead of implementing it make recalls for the actual update in the factory. We have introduced bootloader exactly to make sure devices could be updated by users asap in case of any security issues, but this has not happened thankfully. Do not forget that except for the OpenPGP smartcard there is also additional functionality as well, like PWS or OTP.
4. devloop was working for me last time I've tried. It was also intended for the development more, than for the actual end user. I can't help you if you would not specify any details.

PS I can't see, how angry tone is going to help here.

---

Edit: you can't flash raw ELF to device. Use hex or bin.

[ghost]

Edit: you can't flash raw ELF to device. Use hex or bin.

https://github.com/Nitrokey/nitrokey-pro-firmware/blob/master/scripts/flash-versaloon.sh

I will just quote verbatim:

sudo $OPENOCD_BIN/openocd gdb_memory_map disable                \
...
                                -c "flash write_image erase ../build/gcc/nitrokey-pro-firmware.elf" \
                                -c "verify_image ../build/gcc/nitrokey-pro-firmware.elf"             \
...

Actually, some see firmware update as a liability in the threat model, and instead of implementing it make recalls for the actual update in the factory. We have introduced bootloader exactly to make sure devices could be updated by users asap in case of any security issues, but this has not happened thankfully. Do not forget that except for the OpenPGP smartcard there is also additional functionality as well, like PWS or OTP.

How is it a liability to provide mechanism to fix potential issues in the hardware? How is it any safer to do the update in your factory? Nitrokey is a small vendor. I find it somewhat difficult to picture a SCIF inside the company where handpicked engineers with extraneous background checks go in to update hundreds if not thousands of devices... I suppose the entire process of delivery for the tokens back and forth is under close inspection. If organizations with borderline draconian security protocols get compromised, I really doubt you can offer any better security than any other organization with an audit process in place.

This also does not correlate with the design decisions made for pynitrokey (ex. network-driven update retrieval). We do our updates inside a Qubes environment, vetting the source and compiling afterwards (which does not negate upstream vulnerabilities), with no network access.

There is no angry tone, perhaps a little sarcasm, which should not necessarily cause offense. Back to the point, and without going into a tangent off topic, Nitrokey has been promising things in marketing and launching incomplete or non-functional products for a while now (see the Nitrokey 3 debacle, you just released an alpha with OpenPGP support, but the truth is, most N3 devices were sold as vaporware that only now is seeming materializing -they were glorified FIDO2 keys, and still are, at least until the full functionality materializes-).

4. devloop was working for me last time I've tried. It was also intended for the development more, than for the actual end user. I can't help you if you would not specify any details.

I'll get you a separate issue reported for that.

I've never had any reliability issues with the clones, and they worked on par with the official hardware. Of course YMMV. What have occurred is probably a hard halt on the MCU after dropping the flash lock, which needs power cycle for the further use.

This seems anecdotal, but the build quality of the clones is notoriously bad. Even a cheap Olimex JTAG is orders of magnitude better. They also do not have a CNC mill-drilled IC inside ;P

[ghost]

Regarding my original report: "Edit: you can't flash raw ELF to device. Use hex or bin."

Could you guys provide an up to date verified flash procedure that accepts the all/firmware.hex files as-is?

Edit: the request is specific to using a non closed source tool (STM32's CubeProgrammer works fine, obviously). I can confirm that the device is recoverable that way, and readout protection can be activated again (regardless of how useful it might be against glitching attacks anyway).