Is it possible to cross-load Nitrokey 3 firmware to Solo2?

The Solokeys Solov2 was originally developed with Nitrokey. Is it possible to cross-load the Nitrokey 3 firmware onto a Solov2 Hacker? I have two of the Solo2s which have been sitting around doing nothing forever. I want to use them with OpenPGP, but Solo hasn’t updated their firmware with the Nitro OpenPGP changes. I’m hoping that I can cross load the Nitro firmware seeing as they are essentially identical under the hood.

1 Like

The short answer is: no, this will not work

The reasons are roughly:

  • there might be smaller differences in internal wiring/pin-assignments on hardware level, which would need to be adapted inside the nk3-firmware
  • only a properly signed firmware can be uploaded to the devices, solo uses another signing key, which we don’t have
  • other seemingly small differences (se050, external memory) in hardware might need additional adaptations on firmware side

As far as the second point goes, both my devices are Solo2 Hackers, which as I understand it, don’t care about firmware signatures since the whole point was to be able to load custom firmware onto them.

I understand about the possibility of small hardware differences. At this point though, SoloKeys look like they are down for the count and these devices are probably going to be otherwise useless to me, so I’m willing to risk it. I’m going to see if I can hack pynitrokey to recognize my two devices, starting with the USB vendor and device IDs.

If that is something I can get to work, is it of interest to the Nitrokey community here?

Hey @VA1DER

ok if you have hacker devices I can roughly give you a path towards a Nitrokey 3 firmware on such a device:

  • adapt MCU-pinmapping according to the solo-hardware within the nitrokey-3-firmware

  • disable non existent hardware inside the firmware (might be se050 (i2c) and ext-mem (spi) - but I am not sure if ext-mem is not actually included)

Then you should be able to build and flash using the tooling found in utils/lpc-builder inside the nk3-fw repository.

If you flash a “bad” firmware you might need to force the device into bootloader mode, for our devices this is done via shorting the rst pad with gnd during bootup - this will essentially allow you to revive your device if you end up in a bad firmware state.

best

Thank-you! That will save a lot of time. I’ll let you know how it turns out.

1 Like

Would not the trussed firmware be enough of an abstraction from the hardware so that the individual apps like for openpgp be portable?

Yes, this is the reason why I expect that only minimal changes might be needed - if the pinout assignments are not adapted, things like the LED might bring the device into a weird state during boot … It might even not be needed to disable i2c/spi as there are fallback mechanisms in place to the device will still init but report an error in nitropy nk3 status

Then this would be the best option as I don‘t think the project is dead but only heavily cut down on costs (and people) due to manufacturing issues and supply shortage.

As a backer I was pleased to have gotten all my devices and at least FIDO2 works fine.

I would wish for Trussed to flourish with multiple vendors.