I hadn’t seen discussion about https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html on this forum.
Would be interestingto gather PureOS devs (and users) opinions on Lennart’s article - especially because there’s lots of overlap with regards to security and privacy goals for both.
(only commenting on #2)
The fundamental point for #2 (SecureBoot) is that it is only as secure as Microsoft is. Many Linux users are escaping Microsoft, so the idea of making your security subject to trusting Microsoft is not appealing. The problem may be that Microsoft is compromised (by a hacker or by executive order / legislation within the US government) or that Microsoft is malicious. I’m not saying that they are, only that you have to trust that they are not, because you sure as hell don’t have any way of verifying it.
(I don’t speak for Purism but) Purism goes even further. They don’t want you to have to trust Purism either. That’s why there isn’t a chain of trust rooted at any company. Not Microsoft. Not Purism. No company. The chain of trust starts (and ends) with the customer.
The other consideration in point #2 is that there is an inherent conflict highlighted by the statement “if you want to modify the boot loader of a system you must have access to the private key used to sign the code”.
On the one hand, it is a good thing that some random can’t replace your boot loader with malicious code. On the other hand, it is inalienable that you as the owner of the device have the unfettered right to change (replace) your boot loader - potentially long after the manufacturer has abandoned your device and/or ceased to exist. That’s what open source is all about.
How this conflict is resolved in practice depends on your priorities. You may put greater priority on certainty and rigidity. Or you may put greater priority on control and flexibility.
Many Linux users are tinkerers and in their eyes there are far too many e.g. phones that have completely locked bootloaders. You run the code, the whole code, nothing but the code … as provided by the manufacturer.
(A locked bootloader coupled with an abandoned device can potentially reduce your security. You are faced with the choice of knowingly having unpatched security holes or binning your device.)
At the end of the day, Purism’s approach is not inferior to that implied by point #2. It’s just different.
Depending on your priorities, you may find that Purism’s approach is superior to that implied by point #2.
I see that Mr. Pid Eins embraces the idea that security should be rooted in vendors, not customers.
He takes UEFI as a given, and (though not saying this explicitey) assumes this situation cannot be changed so it must be embraced.
I do not like it one bit, that’s why I’m here. I ditched UEFI in favor of PureBoot, and suddenly a major drawback on which the whole post hinges - the unauthenticated initrd - is fixed!.
One thing I have to give him, though. Purism product are not “a generic linux distribution running on generic hardware”.
But my solution to admittedly incomplete security of generic linux distribution on generic hardware is not to give my keys to the vendor, not to lose flexibility to vendor pre-made initrd images which would become obsolete in no time, but to ditch the generics altogether and have solid, up-to-date security immune to vendor key leaks/breaks/bugs. I’m better of that way. Peace of mind is invaluable.
The fundamental point for #2 (SecureBoot) is that it is only as secure as Microsoft is.
That’s false: Purism utilizes SecureBoot without relying on MS for anything. See https://docs.puri.sm/PureBoot.html for implementation details.
embraces the idea that security should be rooted in vendors, not customers
He’s simply describing the reality: unless you’re manually building and updating GNU/Linux kernels for Librem, you’re relying for security on the vendor called “Purism” - there’s simply no way around it without major time and resource investement unpractical for regular users.
the unauthenticated initrd - is fixed
That’s just one of the things I hope to clarify - looking at https://docs.puri.sm/PureBoot.html I don’t see details about what’s being verified during the boot process and what isn’t.
Does Heads uses Purism public key to verify the kernel? How is this key updated? What’s measured into TPM?
The particularly interesting use-case are users without Librem Key (which I presume are plenty) - how the SecureBoot looks in this case?
Having said that, I also like the clear separation between laptop-specific keys and the user-specific keys which allow for trivial and secure migration of user’s home between different machines by copying single file. Would be awesome to have that as part of PureOS too.
No, he does not simply describe reality, he goes further: accepts it as inevitable and only way of doing things.
This is the only point that I disagree with. All other things are perfectly valid, but sadly they assume the vendor holds the keys.
Practically all of the industry does it this way: vendor holds the keys. There are few exceptions, few and far between. Lennart dismisses them as non existent, unworthy of even a mention.
I use one such exception in the industry, and I hope they will grow, spread and the security model in which user holds the keys will dominate.
Where does it say that?
Purism may well provide “secure boot” but that is not the same thing as “[UEFI] Secure Boot”, which is specifically what the article linked in the OP is referencing.
Up until recently, as I understand it, PureOS didn’t even support UEFI, which in practice is a pre-requisite for using “Secure Boot”.
In practice, yes.
However if you freeze your system at a point in time and you make the bold assumption that at that point in time your system is secure (so that your security is no longer dependent on Purism) then both Secure Boot and PureBoot aim to solve the same problem: Has my system subsequently been tampered with?
In other words, has my system that was previously secure been tampered with - so that it might now no longer be secure?
If it wasn’t secure to begin with then it doesn’t so much matter whether tampering has occurred. Indeed, knowledge that no tampering has occurred might lead you into a false sense of security if the system wasn’t secure to begin with.
Of course we all know that in practice the system “as frozen” was unlikely to have been secure i.e. there probably were security bugs, we just didn’t know about them. Perfect security is, at the moment, an ideal. Ironically, governments would hate perfect security.
PureOS didn’t even support UEFI, which in practice is a pre-requisite for using “Secure Boot”
Feel free to call it TrustedBoot if it makes it easier. Conceptually there’s exactly zero difference between laptop with UEFI firmware with vendor key baked in which is used to authenticate kernel via TPM measurement and another laptop with Heads firmware with vendor key baked which is used to authenticate kernel via TPM measurement. Unless there’s some intricate detail which I’ve missed - would be glad to learn otherwise.
If you re-build Heads with your own key and UEFI does not provide ability to replace vendor key - than there will be difference but it raises the question of how vendor-signed kernels from Purism will be authenticated if Heads has only your key?
Practically all of the industry does it this way: vendor holds the keys.
That’s exactly the case with Purism too until you’ve re-build Heads with your own key - which is hardly something we could expect from an average user. And even if you did - I hadn’t wrapped my head around making this compatible with kernel updates which are still provided by Purism and signed with their vendor key. Do you have any point to enlightening reading per chance?