The boot process, in computer hardware, forms the foundation for the security of the rest of the system. Security, in this context, means a “defense in depth” approach, where each layer not only provides an additional barrier to attack, but also builds on the strength of the previous one. Attackers do know that if they can compromise the boot process, they can hide malicious software that will not be detected by the rest of the system. Unfortunately, most of the existing approaches to protect the boot process also conveniently (conveniently for the vendor, of course) remove your control over your own system. How? By using software signing keys that only let you run the boot software that the vendor approves on your hardware. Your only practical choices, under these systems, are either to run OSes that get approval from the vendor, or to disable boot security altogether. In Purism, we believe that you deserve security without sacrificing control or convenience: today we are happy to announce PureBoot, our collection of software and security measures designed for you to protect the boot process, while still holding all the keys.
Good initiative.
Wow. “PureBoot” is the most devious social engineering attack I’ve ever seen. Convincing people to replace their firmware with untrusted code (the “PureBoot” malware/rootkit) is brilliant.
Brendan,
That’s a little harsh. There’s nothing intrinsically devious about a company putting owners in control over their hardware with open source firmware. I’d argue that manufacturers who lock us into closed proprietary firmwares are more devious because independent security researchers cannot easily audit or fix the code. These are proprietary black boxes, and we’re not allowed to know what they do. In some cases major vulnerabilities have gone unchecked for years.
Keep in mind “trusted code” is highly misleading in the context of secure boot because the code being executed doesn’t actually have to be trustworthy at all, it just has to be signed. For example, if I install linux using secure boot under signed by microsoft’s key, then does that protect me from untrustworthy code from the NSA, which is also signed by microsoft’s key? No it does not. Secure boot can only verify signatures, it cannot verify trustworthiness. Purism seeks to address that by using open firmware and hardware to the maximum extent possible. I think is is a laudable goal.
> There’s nothing intrinsically devious about a company putting owners in control over their hardware with open source firmware. I’d argue that manufacturers who lock us into closed proprietary firmwares are more devious because independent security researchers cannot easily audit or fix the code.
There’s something very devious about pretending that owners are capable of checking that the binary they’re installing actually matches the source code, pretending that owners are capable of finding any (deliberate or accidental) security holes in the source code, and pretending that the tiny number of owners who are capable of both of these things actually have the time to do either.
There’s something very devious about pretending that an “unverifiable binary blob” from one place (e.g. the original manufacturer who has something to lose if their “unverifiable binary blob” is faulty – their reputation and future profit) is less secure than a different “unverifiable binary blob” from a different place (e.g. a group of volunteers that have nothing to lose if their “unverifiable binary blob” is faulty).
There’s something very devious about pretending that an “unverifiable binary blob” from one group of developers (who have access to all the specs/documentation for the chipset, etc) is less secure than a different “unverifiable binary blob” from a different group of developers who often have to resort to reverse engineering and hackery because they didn’t have access to all the specs/documentation for the chipset, etc)
There’s also something very devious about ignoring “man in the middle” – the increased risk of unknown attackers tampering with firmware before installing it on computer’s they sell or give to other people (which goes from “almost zero risk” for proprietary code backed by digital signatures to “very high risk” for open source code provided to anyone).
> Keep in mind “trusted code” is highly misleading in the context of secure boot because the code being executed doesn’t actually have to be trustworthy at all, it just has to be signed.
SecureBoot means that you can trust that it wasn’t modified after it was signed. It should have also been used for authentication (so that if it says it was signed by Dave then you can trust that it was created by Dave and not signed by someone else) but without a secure way to advertise keys this can’t work (e.g. if it says it was signed by Microsoft you have no idea who created it) and PureBoot does nothing to solve this problem.
Beyond that, trust depends on reputation. E.g. if you know something wasn’t modified after Dave signed it and know that it was created by Dave and not someone else; then you can decide if you do/don’t trust Dave.
That is the essential piece that PureBoot developers have overlooked – at the end of the day, all trust depends on reputation, but why should anyone trust PureBoot developers (instead of trusting any other stranger who has nothing to lose)?
Brendan,
That’s more naive than devious. However I’d also point out that if the Librem Key works as described, it offers even better security than secureboot for non-technical users.
Open source code is not unverifiable as you state. While there are shortcomings to the “to many eyes, all bugs are shallow” open source philosophy, I’d still take an open source BIOS over a proprietary one any day of the week. I only wish all my computers supported it. It’s the proprietary firmwares that are unverifiable even to professionals. Sure you could reverse engineer, which is painful, but the argument you make that these are equally unverifiable is insincere. Even if you don’t want to personally verify it you can still make sure you flash a version that has been verified by others.
Did you not read the article? Because if you did you would see that they specifically address man in the middle/interdiction attacks where your hardware has potentially passed through an adversary. Nothing can be totally foolproof, but I gotta say that their approach is objectively superior to secure boot. By using separate hardware to verify the laptop’s integrity and shipping it through a different channel, that helps to protect from an interdiction attack where secure boot would fail.
I’ve got to ask why are you this biased against this manufacturer though? At the end of the day you could have misplaced trust in any of the manufactures: dell, apple, etc. But at least with open source you can reinforce trust by having multiple parties attest to the integrity of the firmware. As long as you flash the same version that’s been attested to (in practice this means verifying the MD5/SHA hashes), then single party trust because less of an issue.
My experience with open source is that typically there’s severe quality control problems originating from a combination of “no leadership, everyone does what they feel like” and “works for me, worse is better”. When you add “reverse engineered hackery from people that don’t have a good working relationship with the hardware designers” into the mix and then throw the end result in at the lowest possible (and most critical) level, it’s a recipe for disaster.
Did you read the article? Their “interdiction prevention” is to send the laptop to a malicious attacker, then send the key via. a different path to the same malicious attacker; then fail to do anything that’s actually useful when the malicious attacker downloads the source code and tampers with it (yay, open source!), installs it on the laptop, then re-sells the laptop to your grandmother (or any person that has no idea what firmware is).
Mostly; I don’t like “our unproven product is more proven than products millions of people use that were created by our competitors who have decades of experience” marketing hype; and I think the company is snake oil salesmen trying to cash in on people’s fears (while doing what they can to increase people’s fears, and while doing nothing that will actually make their systems more secure than anything else).
Brendan,
I hear you, open source is not a panacea. Nevertheless, it’s often better than proprietary black boxes where many of the same problems exist anyways and security is based on blind trust. Additionally there have been several times I’ve needed fixes to commercial products (expensive ones at that) only to be slighted by the vendor who aren’t interested in after sales support. This is a big reason that people like me want open source.
They don’t send the laptop to an attacker, haha. 🙂
There’s actually a technical reason it’s important to send the keys separately. Consider the scenario where an attacker intercepts your new laptop and flashes a hacked firmware. Secureboot cannot protect from this because secure boot is implemented in firmware. 1) The attacker can re-flash the chip using a hardware flasher to bypass all firmware protections 2) In the case the NSA or other agencies, their code is likely signed anyways such that they don’t even need to hack in.
By using the remote attestation features of the TPM chip, a separate hardware key can verify the boot process has not been tampered with even if the secureboot firmware was modified. This is better than what secure boot can offer by itself.
Funny, I felt the same way about secure boot because I’m not a fan of microsoft’s keys effectively getting embedded into all UEFI PCs. While some linux distros are getting signed by microsoft’s key, I see it as a major conflict of interest. You may trust microsoft and you may not trust purism, and I won’t judge you for that. It’s no big deal if pureboot is not for you. In terms of diversity, I’ll grant you that I’d like to see more vendors get on board.
You seem to hate this company’s products and developers, that much comes through loud and clear, but I cannot tell from your posts precisely where that comes from since what you’re accusing them of could apply to just about every company. Are you opposed to their use of open source firmware? Is it just this company in particular? Is it all small companies you have a problem with? If a big vendor like dell implemented something similar would you have a problem with it? Do you or your employer benefit from discrediting this company? I don’t know if you can explain it in a way that will make sense to me, but as of right now I get the impression that your posts attacking them are motivated by some source of bias.
It’s “devious” for an OEM to update the firmware on their OWN laptops that is opensource and gives more control to the owner no less? I am not sure if you are trolling or just uninformed?