Hi guys, I really like their idea about that, and they make me feel I’m not the only one on the earth with such strange worries…
But there is a problem, I think they rely on the USB key to do the software part of temper evident, which is not good enough. We want this service because we do not trust the physical delivery path, so if there’s really a bad guy in the middle, he can just temper both the device and the key, even they are shipping to different address on different date. So when we use the key to test the device, how to test the key? The old chicken and egg problem…
I just came up with a thought, inspired from Apple company(I know you guys hate them). I think we could do something similar to their “activate” system for their IOS devices, but better:
The disk is fully encrypted, and save part of the the key on the Purism server.
Every time the computer boots, it will need to connect to the Purism server first to identify itself, Purism test the client signature to determine if the boot loader is authentic and untempered, then the server send the missing part of the key to the device.
Such operation is logged each time, and no way to erase the log. The log can be checked by a webpage.
By doing the above, we only have to trust Purism(and a trusty device you may already have, to see the log), instead of a separate piece of hardware. Of course this should be optional because not every want to store their info online, or connect to the internet on every boot.
The boot loader would be heavier because it will need the driver and software for network, encryption, etc.
This is just my own thought, maybe stupid, I’d like to hear you guys’ ideas!
I think any system employed relies on a modicum of trust. Ultimately, unless you built all the components and soldered them to the board, etc. you will NEVER be fully sure.
I would also be of the opinion that what you’ve proposed goes against the freedom aspect of Purism’s foundation. Needing to rely on a Purism server for the lifespan of the product, and an internet provider, just doesn’t seem to fit into those requirements.
On the other hand, modifying a mainboard in such a way that it is evident or triggers anything is not easy, and requires state level assets I’d think.
There is a certain tipping point where your attempts at security will never outweigh the individual who is better funded and more knowledgeable. Instead of a chicken and egg, it is a rabbit hole that continues to get more and more expensive the further down you go.
For 99.99% of Purism’s customers, the security features they’ve already implemented and offer are completely unnecessary. The privacy elements are what matter.
Instead of saving any portion of disk encryption key on Purism’s server; I’d be curious, conceptually, about having the heads/boot verification validated by not just a hash from the Librem key, but also a hash generated by Purism’s private key before shipping. You could then verify with Purism’s public key that nothing has been modified as well as whether or not the Librem key agrees.
If the Librem key doesn’t agree with the Purism key that could imply interdiction and resetting of the Librem key with the key of the attacker and using the attackers key to then sign the laptop afterward. I’m pretty sure this could just as easily be caught by sending information about the key in encrypted email before sending the key, but the comment did spark this idea…
Yes that’s really clever, I used to thought that too, just forgot to mention in my first post… It would work similar to “secure boot” from Microsoft.
Yes I know many people hate those companies that control our devices, but at some point they do make your device safer.
This depends entirely on what you’re being saved from. Having a fully locked down boot chain with the signing keys controlled by the manufacturer will only protect you against things which can’t influence said manufacturer.
That includes:
Suited goons turning up on the doorstep with papers commanding you to obey a law which you’re forbidden from discussing, can’t challenge in any kind of legitimate court and which has no kind of oversight (various parts of the “free” world).
Sleazy goons waving large amounts of money at those who work there for either a copy of this private key or to get a ready-made backdoored version of this bootloader signed (industrial espionage, organised crime).
Goons with no neck turning up either at the company or one of the employee’s residences making an offer that they can’t refuse (the “non-free” world, also organised crime).
Note that I’m assuming that the hardware manufacturer has their cryptographic secrets stored on a properly air-gapped system and that goons with scripts can’t just sneak in over the Internet and make off with the signing keys.
It all depends on who you’re worried about. If not a single one of these types of goon are in a place to influence the manufacturer and never will be at any point in the future, then sure - lock in the hardware.
But on the other hand, if whoever your enemies might be is in a position of power over the device manufacturer, then your system now belongs to them. And there’s nothing you can do to reset it, because in this kind of situation it is not you who are the actual owner of “your” device, it’s whoever has the bootloader signing key. They control what software is allowed to run on such a system.
The final problem here is that the hardware manufacturer needs to create their own custom silicon with this root of trust burned in. If it’s just some software setting, anyone can re-flash the BIOS and either get rid of or subvert it. Since Purism is not in the business of creating their own CPUs (semiconductor plants are not cheap, nor is the requisite experience to create a functioning processor which can handle modern workloads), that’s not about to happen any time soon.
EDIT: and since you mentioned MS’s secure boot, it should be noted that they are very VERY far from being trustworthy in this situation. To list one example, Skype used to operate in very peer-to-peer manner using its central servers only as a directory lookup. A great way to make the system more reliable and reduce server costs.
The moment MS got their hands on it, the entire system changed so that all of its calls were now routed through the central servers rather than being direct connections between participants. Coincidentally, one of the things revealed by a certain famous whistleblower was that Skype calls were now remarkably easy to spy on and that MS was something like a “tier one partner” or some other similarly sickening set of weasel words. You really don’t want to use them as an example here.
I think the intention is that the key itself is somewhat tamper proof and the delivery also requires secure communication between Purism and the customer.
So the really bad guy needs also to tamper either with the communication in transit or with one or both ends of the communication. If the really bad guy is tampering with the Purism end of the communication then in the worst case, you effectively can’t trust Purism and the anti-interdiction will fail. If the really bad guy is tampering with your end of the communication then you are probably toast already (for example, how do you even know that you are buying the device from Purism?). It is assumed without proof that the really bad guy can’t tamper with the communication in transit.
You could collect the key in person?
Creating that ongoing dependency is probably not ideal. Who knows what unsightly legislation might be created in the future?
In addition, you are assuming that internet connectivity is available - which may conflict with the use of the kill switches but is in any case problematic.
We are pretty explicit that we don’t claim to prevent tampering with our anti-interdiction service, we only attempt to make it difficult to tamper with the laptop without detection. After all, someone could just cut through all the tamper-evident tape.
To the specific point about the Librem Key and software-based protections, we set up a custom PIN w/ the customer for the Librem Key, TPM, etc. so for someone to tamper with both during shipment they’d have to know the PIN and they would have to intercept both packages (sometimes sent to different addresses), then remove the tamper-evident tape without it showing it, both on the Librem Key shipment and in two different layers on the laptop shipment. And they would need to have both the laptop and the Librem Key together to attempt to change the linkage between the two.
As far as trusting Purism, you do have to trust us that we set up the initial laptop and Librem Key as you request, as we generate a random GPG key and other secrets for you at the factory. But once you receive the Librem Key and laptop, you can verify that it hasn’t been tampered with and then replace all of those secrets with your own–your dependence on us for trust can stop at that point.
Can’t they take the information from the first device(the key?), and then change the information to the second device(maybe the laptop) after he got the package?
No, they can’t extract the existing HOTP secret nor the GPG private keys from the Librem Key. To change the existing HOTP secret on the Librem Key independently from the laptop, they’d need to know the current PIN we set at the factory, or they’d need to reset the Librem Key entirely, which would be detectable because it would no longer respond to the pre-set PIN, and the GPG keys wouldn’t match the public key we ship along w/ the laptop on a “Librem Vault” USB thumb drive. The signatures on the laptop itself in /boot and the public key that’s loaded into PureBoot’s keyring would also no longer match and the attacker would have to reset those on the laptop.
For the laptop they’d have to break through all of the physical seals on the laptop, indetectably, and modify our firmware so that it could load the TPM with their preferred HOTP secret instead of a randomly-generated one the firmware creates itself. Since they don’t know the TPM PIN that we set at the factory, this would mean completely resetting the TPM (which erases all data and secrets in it) and assigning a new PIN–another area where a customer could detect the intrusion.
And of course, while it’s much more labor intensive and not necessary for most people’s threat models, for extreme threats we also offer the option for customers to provide us with their own private GPG subkeys instead of generating them ourselves, which would provide another safeguard and another way to detect tampering.
i personally don’t believe i’ll need such anti-interdiction services but i do understand why you guys invest so much time and energy in something like this and i think that more not less companies should mimic your behaviour so that in the future we have a chance to find better ways of improving this process.
you have written in your blog-post that many people that have no concern for shipping-interdiction also choose to invest currency in this process at check-out. could this behaviour incite suspicion at the customs or even a secret actor that might be monitoring the server side of the online shopping orders ?
depending on how much it would cost to do this for a few L5s i might have to cannibalize one L5 from my order to apply anti-interdiction measures to the rest.
would i be able to use just one L-key for more than one L5s or would each of them require their own dedicated hw-key ?
I think having more people from all walks of life and threat models select this option helps reduce suspicion in the same way that having everyone use Tor is better for the ecosystem than if only criminals used it.
We probably won’t have PureBoot ported to the Librem 5 when we start shipping Evergreen so anti-interdiction orders will be adapted based on that fact and focus more on the physical tamper detection and probably not include a Librem Key. But to answer your question in general, for PureBoot you need one Librem Key per machine you are validating. The shared HOTP secret is randomy generated in the PureBoot firmware and added to the Librem Key. There is currently no mechanism in place to set a shared HOTP secret, and even if you could, HOTP requires an always-incrementing counter, which would go out of sync if you used one Librem Key with multiple machines.
