You have examples for that claim?
Sure. All USB3 devices have embedded proprietary firmware. That’s the sort of firmware that was intended for the RYF exemption, but that doesn’t mean it isn’t there.
2 Likes
Does this mean if I unplug the spare mouse I was using from my Librem 14 that it becomes truly trustworthy?
1 Like
I didn’t say anything about “trustworthy” – that’s for the tin foil hat types to debate.
I was simply saying that pretty much everything that is USB3 has proprietary firmware … it’s just embedded. Even your USB-C-PD cables have embedded chips and firmware (read up on Channel Configuration and/or Port Controller chips). Similarly, internal to your laptop, the USB controller has embedded proprietary firmware. Any USB thumb drive has embedded proprietary firmware. All of that falls under the RYF’s exception —> and was the clear intention for that exception [as opposed to the firmware on the Librem 5’s wifi module or the Librem 5’s cellular modem].
1 Like
True enough, with the following additional points:
- some firmware is open source (and in an ideal world more would become so)
- it may not matter that the firmware has access to the data - what matters is what the firmware can do with that access (hence, for example, a blackbox keyboard has access to your password but there are limits as to whether it can successfully exfiltrate the password - but a somewhat sophisticated attacker could probably exploit this)
- it may not matter in the case that the data is encrypted (hence, for example, a blackbox SSD obviously has access to the encrypted data on your root partition but does not have access to the corresponding plaintext - and again a sophisticated attacker in some circumstances could exploit this) - and likewise the firmware in your WiFi card and in your cellular modem (where applicable) both have access to the data but the data is, or should be, encrypted, thereby removing access to the plaintext content
So imagine the nightmare scenario where you have a hostile keyboard and a hostile SSD and the keyboard is able to grab your LUKS password and then exfiltrate it to your SSD i.e. the two pieces of hostile firmware are cooperating. 
I think in this case “Perfect is the enemy of good”. Open source is not perfect security but it is good security. It raises the bar for the attacker.
2 Likes
There are some exceptions, like the Librem Key, or the various Nitrokeys. Another one of the top of my mind is the NeuG USB True Random Number Generator, and there are various similar TRNG examples like it.
1 Like
Yes the Nitrokeys+Librem Keys have open firmware. But technically those are not “thumb drives” (flash data storage USB devices), they are encrypted password stores.
2 Likes
Interesting. I still assume that there is some firmware on that device that is proprietary. What I’m saying is that while the encryption and key management is FOSS, the firmware for the flash memory controller is probably proprietary (the wear leveling and garbage collection is at a chip level and the firmware for that chip is AFAIK always proprietary).
1 Like
Okay, I will contact Nitrokey Support and let you know once I have a response.
Thanks! I’m curious. I looked briefly at the source code, but would need to spend more time on that. I’ve googled to try to figure out what chip they use for the flash memory controller and have come up empty.
1 Like
Here are GitHub repositories pertaining to the Nitrokey Storage:
What is likely relevant to your query is the bill of materials (BOM):
1 Like
Huh. So the people building the thing that the Pureboot uses to achieve security… designed their thing with Microsoft Excel XLSX files?
That feels similar to when I tried to download Android on the NXP website. Contrary to the nature of Purism, the nature of NXP who manufactures the Librem 5 CPU as I understand it… is very privacy-invasive. Their user agreement in order to run code on the NXP CPU that originates from them was extremely awful.
Granted, that code isn’t really meant for a Librem 5 but rather for some other kind of “evaluation version” of the i.MX 8M Quad chip or something else like that that I don’t understand, but still… Is Purism bound to all the terms of the NXP agreement? Including banning of reverse engineering how code runs on the CPU?
Although one of the only parts of the agreement when I signed up as Chris Kringle or Leeroy Jenkins or whatever my supposed name was (I forget what I told them)… was that the agreement can be terminated.
So, yeah, NXP, if you’re reading this, consider our agreement terminated. Whatever I clicked on late at night without reading wasn’t a legally binding contract to me, because I thought it was in bad faith that you requirement me to click through it in order to download some random source code. You can tell I’m not a lawyer so your agreement with me is terminated, for both our benefit. Thanks.
1 Like
The Nitrokey Storage is not directly related to PureBoot. However, the Librem Key, which is used with PureBoot, is based on the Nitrokey Pro 2:
Nitrokey Partners with Purism to Build the Librem Key | Nitrokey
Unfortunately the Nitrokey Pro 2’s development has been discontinued, with the Librem Key still five versions behind upstream since its release:
Not sure, you will need to contact Purism for further details about their legal arrangements.
2 Likes
Well, interesting to see that you had made an issue about this problem that we have long been stuck with: how to upgrade those early/older Librem Keys to more recent firmware updates that were for the Nitrokey Pro 2. I noticed this was 8 months ago…but there was no follow-up whatsoever.
I guess it’s a tricky problem: just flashing the Nitrokey firmware update will not make it a Librem Key, hence it will not be recognized as such by PureBoot. So it means Purism SPC has to make their own firmware update from the Nitrokey code, so that the LK still is an LK with the newer version.
Anyway, not much happening here. I don’t feel at ease with still using my older NKs, and the question is always the same: if there is a firmware update, it means a bug or a flaw was discovered (but thankfully, was kept secret!) Or is it the case? An update could also be only an improvement or new feature.
So: should we or should we not update? And should we be worried if this proves impossible? The situation is not clear and I feel Purism should clarify.
Is it even possible to flash a new firmware in those LK/Nitrokey Pro 2 - I’m not even sure about this? I know it is possible with their newer NK3 product line, but what about the former family line?
1 Like
No.
Storing a list of parts in a spreadsheet, regardless of format (xls, ods, hand written) of that spreadsheet, is not designing.
1 Like
@jonathon.hall has commented on the issue at February 6th, 2024:
Yes you can, but v0.10 and below can only be done with hardware reflashing:
There are multiple issues involved:
- The Nitrokey Pro 2, which the Librem Key is based on, has discontinued development on v0.15.
- The Librem Key is behind several version releases from upstream, on v.0.10.
- The Librem Key firmware repository is not updated to v0.15, as highlighted earlier.
- Documentation for hardware flashing the Librem Key firmware does not exist.
Even if the last three issues are resolved, it is clear that the Nitrokey Pro 2 is obsolete, so there are only two options for Purism at that point:
- Maintain and update the Librem Key firmware repository, which is unlikely given the current situation.
- Rebase on the Nitrokey Pro 3 (AKA Librem Key Mini), or another hardware design, which was claimed to not be in development when I asked about this years ago.
5 Likes
Thank you for the detailed information.
Checking on my several LKs showed that all have firmware 0.10, as you rightly pointed out.
Checking on my two NitroKey Pro 2, both are 0.15 (they were purchased much later)
It appears to be the latest and final firmware release, since dev has stopped and the product is being discontinued anyway.
I wonder how many LKs Purism still have in stock - and should they all be considered obsolete?
Those LibremKeys will never be updated, even if Purism rebases on firmware 0.15 and comes up with a firmware update. The reason for this is that firmware 0.10 and below CANNOT be updated with nitropy cli: it lacks a bootloader needed for flashing the new firmware once the device gets enabled in firmware flashing mode. Unfortunately, this bootloader (and the possibility to update the firmware via cli) appeared as a new feature of version 0.11 - one version above LKs!
But is this really so bad? There has been a lot of talk and divergent opinions on the subject of there security dongles and firmware upgradability. For some threat model, this is viewed as an unacceptable liability and a considerable increase of the attack surface: there should be no way to tamper with the device by simply reflashing a forged or modified firmware.
On the contrary, some claim that firmware updates are necessary for correcting bugs or flaws; and also as a way to introduce new features on the same product (which is what Nitrokey has done from firmware versions 0.11 and above)
I don’t know…
Which is best? I guess it depends on the threat model, in the end.
1 Like
It may interest you to know - regarding the future of these projects - that Nitrokeys (and I quess by extension, Librem Key) have been funded by EU. See Nitrokey | Next Generation Internet and Nitrokey 3 | Next Generation Internet
Unfortunately that funding for future improvements is now threatened, see thread: EU funding to open source projects in jeopardy - YOU can help
1 Like
Yes, at least I would given all of the citations I provided.
It is possible for Purism to offer hardware flashing services for the Librem Key, among other Librem products, via RMA, but that idea has not been raised yet.
Always update. In practice, adversarial threats refine their techniques and tools over time.