Nitrokey Pro firmware upgrade from 0.9 -> 0.14 impossible from nitropy?

[tlaurion]

Edit:

Conclusion: Nitrokey Pro v2 can be upgraded from nitropy (software based firmware upgrades) if dongle is at least having firmware 0.11+

For <0.11: user will need to go the currently documented routes under firmware upgrade guide with external programmer.

SWD programmer can be a RPI :) https://nosmd.com/raspberrypi-swdprogrammer/#rpiprogrammer-target

---

Hello there.

A user reported a Nitrokey Pro delivery delayed of 6 weeks. He decided to not trust received dongle and reflash it with newer firmware through dfu external programmer, which at the time was 0.14 RC4, which had GPIO mapping inversed, which led to issue https://github.com/osresearch/heads/issues/1170 being opened.The user bought programmer and went the manual way since it was unclear that a software method was available.

• I was not aware, either, of a software tool that permitted to do the flashing without external programmer, which is documented deep down under https://github.com/Nitrokey/nitrokey-pro-firmware/blob/master/DEVELOPMENT.md#firmware-update

I was able to upgrade with that tool from Nitrokey's firmware:

• 0.10
• 0.11

But for some reason, attempting to upgrade 0.9 was not possible. I got firware version from heads through hotp_verification info

0.10 and 0.11 firmware version behaves the following way:

• nitropy pro enable-update triggers an internal reboot of the dongle, and the ID is different on next boot and rightfully in update mode.
• nitropy pro update nitrokey-pro-firmware-v0.14-to_update.bin is successful.

0n 0.9 connected dongle:

• Qubes dom0 blocks sys-usb to dom0 keyboard request (irrelevant) on usb dongle connection.
• nitropy pro enable-update reports success putting dongle in update mode, but the dongle doesn't reboot in update mode. The stays attached to affected qubes where tools are installed.
• nitropy pro update nitrokey-pro-firmware-v0.14-to_update.bin cannot find dongle in update mode and suggests to run precedent command, which has no effect.
• Manually triggering sudo udevadm trigger doesn't detect a change in device, while running nitropy pro enable-update confirms device was not in update mode, and reports success into putting it in update mode.

Questions needing answers:

• Are 0.9 firmware based dongle non-updateable with nitropy?
• Purism's Librem Key are not having proper udev rules defined and are not upgradeable through nitropy. Is that expected? @kylerankin @jans23 @MrChromebox? Maybe I haven't digged down enough, but I haven't found a nitropy equivalent on Purism's side.
• Wouldn't we want users to be more aware of the possibility of upgrading their dongles since it is now possible with software, and document limitations?
• I understand branding/rebranding/commercial necessities of having different hardware IDs between Purism/Nitrokey, but maybe some collaboration should happen under nitropy software/documentation/udev rules to not have another fork and confuse users into upgrading their firmware? Maybe udev rules should include Purism's Librem Key IDs?

---

Some unrelated issues here:

• Searching Nitrokey website for Nitrokey Pro led flashing patterns doesn't give info as before. Section removed from FAQ?

[szszszsz]

Hi!

1. The firmware update feature is available only since v0.11, meaning the Nitrokey Pro v0.10 devices and older cannot be updated by solely software means as well. Additionally one can see that the size of the binary increases between these two by about 20 kB, which is taken by the bootloader code.
   • https://github.com/Nitrokey/nitrokey-pro-firmware/releases/tag/v0.11
2. About this specific issue 1170, the firmware reported in the very first screenshot was v0.13, however v0.14RC4 should contain the updated firmware string already (as specified in the repository), hence I suspect the user was really using v0.14RC1 at the time (if not v0.13) and not having the correct LED behavior yet. Perhaps some misunderstanding?
3. We are finishing the work on the firmware update tool, specifically MS Windows support, and plan to publish it.
4. As far as I remember Librem Keys have own Udev rules, with own distribution path. Naturally they might not contain update mode IDs yet, since the tool was not considered to be ready.
5. I have passed further the docs check request. Edit: the closest I could find right now is here:
   • https://docs.nitrokey.com/nitropad/ubuntu/index.html#secure-starting-procedure

Edit:

6. Just for completeness, in case the same hardware is used by Librem Key, and if they happen to have v0.11+ firmware, these could be easily updated right now to the one used by Nitrokey Pro if needed, until the proper branded Librem Key firmware is released.

[tlaurion]

Thanks! You're right, only 0.11+ were upgraded, 0.10 device is a Librem Key. Edited OP.

Right as well for user report, was 0.13.

I would correct flashing references to clarify this as well. 0.11 software upgradeable would help redirection support. Also note that RPI can be used as flasher and should also be referenced (why have multiple flashers if RPI can be used and is handy for multiple purposes for a lot of users.)

[tlaurion]

Note on current instructions.

Debian-11 based appvm under Qubes OS.

• Having nitrokey-app installed on debian-11 template fulfills dependencies for libnitrokey
• sudo apt install python3-pip can be installed with volatilility under a qube (will not persist reboot)
• pip3 install --user pynitrokey installs pynitrokey in user (private volume) and persists reboot.
• problem is that udev rules are incomplete, which causes the following steps to loop
  • Pass dongle to qube
  • nitropy pro enable-update, disconnects device from qube (not same ID).
  • Pass dongle to qube
  • nitropy pro update nitrokey-pro-firmware-v0.14-to_update.bin not successful, complaining "Cannot connect to the device: Bus 001 Device 003: ID 20a0:42b4"
  • Have to download and apply udev referred rules on command line with curl https://raw.githubusercontent.com/Nitrokey/libnitrokey/master/data/41-nitrokey.rules | sudo tee /usr/lib/udev/rules.d/41-nitrokey.rules
  • Unfortunately, calling sudo udevadm control --reload-rules; sudo udevadm trigger as said on console from nitropy pro update was not successful, and would require the udev rules download, reload and trigger calls to be followed by a prompt asking the user to physically unplug and replug dongle and redo the steps above from "Pass dongle to qube" to "nitropy pro update nitrokey-pro-firmware-v0.14-to_update.bin".
• Sucess

@szszszsz that was my successful experience upgrading 0.11 dongles to 0.14, hope this finds a way into the documentation somehow.

Notes:

• if udevs rules were packages correctly, those errors would not arise, since udev rules would already be there and would detect the IDs correctly and would have the nitropy pro update call succeed. Therefore, those would not need to be documented.
• Since we are in qube here, udev deployment outside of being deployed per proper packages in parent template will also not persist between reboots. Hence why packaging nitropy with udev rules would be a really good idea for all use cases.

[tlaurion]

@szszszsz

Hello there,

Physical flashing documentation specifies roughly https://github.com/Nitrokey/nitrokey-pro-firmware#flashing

"This approach requires soldering wires to the contact pads or to use an adapter with pogo pins and some kind of mounting (recommended)."

Any picture or more specifics to share?

[szszszsz]

@tlaurion Hi! I do not think we ended up with the proper mounting for the development, but will pass the question further and get back if there would be anything of use. We do have pogo pins on a header for the production purposes, though its not public. You can see it in action here:

• https://youtu.be/kqUK9cAjH44?t=32

About the actual soldering via contact pads for the SWD connection, the details are just below:

• https://github.com/Nitrokey/nitrokey-pro-firmware#swd

[szszszsz]

@tlaurion Attaching image of the pogo pin adapter below (centered on the actual pins connecting to the PCB):