Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Authenticated Boot and Disk Encryption on Linux (2021)

0pointer.net

Post reply on HN
Print view View original

61–70 of 75 posts

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#61

Post by ruthmarx »

fsflover wrote: post #60
ruthmarx wrote: post #59

Earlier quoted context omitted.

I realize now you are talking about using the nail polish to detect if a screw has been removed as opposed to checking if the screws had been taken out and put back in a different order. In that case, I would say 1) Nowadays with high res photos and various types of printers, I do think a pattern could be printed back onto a screw head, 2) there is no way you would be checking this every time the laptop was out of yo…

> I do think a pattern could be printed back onto a screw head I've never seen anything like that and don't believe it's practical. 3D-printed patterns will not look the same. > there is no way you would be checking this every time This entirely depends on your threat model and how much you suspect a tampering at specific conditions. In principle, you could even (automatically?) take a picture of all screws regularly…

> I've never seen anything like that and don't believe it's practical. 3D-printed patterns will not look the same.

I'm not talking about 3d printers specifically, just high precision printers. It's absolutely practical.

> This entirely depends on your threat model and how much you suspect a tampering at specific conditions.

I was talking about you personally, who I assume is a pretty average developer that doesn't have state actors after them.

> What is simpler depends on the threat model and a person.

No, it doesn't. This screws method you describe is inferior for all threat models and persons. It's basically security theater.

> For me, Secureboot is not a better method anyway.

You might not prefer it, but it is objectively a superior method.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#62

Post by fsflover »

ruthmarx wrote: post #61
fsflover wrote: post #60

Earlier quoted context omitted.

> I do think a pattern could be printed back onto a screw head I've never seen anything like that and don't believe it's practical. 3D-printed patterns will not look the same. > there is no way you would be checking this every time This entirely depends on your threat model and how much you suspect a tampering at specific conditions. In principle, you could even (automatically?) take a picture of all screws regularly…

> I've never seen anything like that and don't believe it's practical. 3D-printed patterns will not look the same. I'm not talking about 3d printers specifically, just high precision printers. It's absolutely practical. > This entirely depends on your threat model and how much you suspect a tampering at specific conditions. I was talking about you personally, who I assume is a pretty average developer that doesn't ha…

> just high precision printers

2D printers just won't cut it: https://i.pinimg.com/originals/90/7a/2e/907a2ece23d412d28b66...

https://3.bp.blogspot.com/_BkvigWu1n1A/S8YrMyV_kTI/AAAAAAAAB...

(and so on)

> I was talking about you personally, who I assume is a pretty average developer that doesn't have state actors after them.

This is why I wrote below about eventual discovery of a possible tampering and low priority of checking it in principle.

> This screws method you describe is inferior for all threat models and persons. It's basically security theater.

This is a strong claim without any evidence. You didn't show how to overcome it.

> You might not prefer it, but it is objectively a superior method.

It isn't: https://forum.qubes-os.org/t/discussion-on-purism/2627/187, and https://forum.qubes-os.org/t/discussion-on-purism/2627/158, and https://news.ycombinator.com/item?id=41072929, and https://news.ycombinator.com/item?id=41071708, and https://news.ycombinator.com/item?id=35843566

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#63

Post by ruthmarx »

fsflover wrote: post #62
ruthmarx wrote: post #61

Earlier quoted context omitted.

> I've never seen anything like that and don't believe it's practical. 3D-printed patterns will not look the same. I'm not talking about 3d printers specifically, just high precision printers. It's absolutely practical. > This entirely depends on your threat model and how much you suspect a tampering at specific conditions. I was talking about you personally, who I assume is a pretty average developer that doesn't ha…

> just high precision printers 2D printers just won't cut it: https://i.pinimg.com/originals/90/7a/2e/907a2ece23d412d28b66... https://3.bp.blogspot.com/_BkvigWu1n1A/S8YrMyV_kTI/AAAAAAAAB... (and so on) > I was talking about you personally, who I assume is a pretty average developer that doesn't have state actors after them. This is why I wrote below about eventual discovery of a possible tampering and low priority of…

> 2D printers just won't cut it:

Not your off the shelf consumer stuff, no, but there are printers that could do it, for sure.

What's more, I really have no idea what the point you are trying to make by linking those images is showing. Printing designs on nails doesn't require the level of resolution your screws idea would, so it isn't really relevant.

A quick search shows an especially high resolution 3d printer released last year in May, that can print at a 20-nanometer resolution, the D4200S[1]. That's basically cutting edge, and way, way overkill to print at the resolution required to fool you after tampering with your device.

> This is why I wrote below about eventual discovery of a possible tampering and low priority of checking it in principle.

It's a given that how often someone would check something like that (not that it would be used in practice) depends on their threat model, but you used yourself in the example originally. The point was you wouldn't be doing this, and in the context of the original comments and conversation it didn't make sense as a suggestion.

> This is a strong claim without any evidence. You didn't show how to overcome it.

The problem here is your assumption that the screws are not easy to reproduce, except they are. It's a false assumption. I showed capable printers exist, in addition exist the level of precision the worlds best counterfeiters can work at and are capable of, and yes, state actors have access to such people.

> It isn't:

It absolutely is.

All your arguments, or the links you gave that imply the arguments you didn't make, are limited to using preexisting keys which is not a requirement, or existing flawed implementations, which are not a requirement. Secureboot is a standard, and you are free to use your own keys, and own implementation - if you can't write or manufacturer your own, there are still open solutions you can trust like those from pureism, and software like coreboot.

It would really be better if you make an actual argument and reference urls rather than just spamming a bunch of links FYI. I shouldn't have to open 10 tabs to understand your reasoning.

[1] https://3dprinting.com/news/nano3dprint-launches-highest-res...

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#64

Post by rollcat »

bubblesnort wrote: post #57
kreetx wrote: post #56

Earlier quoted context omitted.

I don't quite get the arguments against the topic at all: if you don't want the added security, you can continue as you do now; and if you do want it, then you can compile and sign the entire software chain yourself; or get the precompiled one. Don't seem like there are any downsides here, or are there?

The downside is that one company holds the keys to the castle for this particular security scheme. Also, saying freedom requires technical knowledge and fiddling is a non sequitur. Technical knowledge and fiddling is possible with freedoms 1 and 3. Without technical knowledge and fiddling you still benefit from freedoms 0 and 2. Thus, software freedom applies to everyone irrespective of skill level.

> The downside is that one company holds the keys to the castle for this particular security scheme.

And how exactly does that take away any of your freedom? You can still disable any or all parts of the verification chain at will, or enroll your own keys. No privilege has been taken away from you.

If you truly cared, you'd advocate for a way to make managing a self-signed trust chain less cumbersome, but you're instead advocating for the user to choose whether to compromise their security entirely. It's a lose-lose situation for a free software platform, ideally the user does not have to choose any compromises.

The tech world is full of mono/oligopolies. You're running an x86 CPU from one of two vendors, using a browser engine either made by Google or paid for by Google, etc. Not depending on any "one company" is as simple as not using a computer at all. Is that a compromise that you'd be ready to suggest?

> Thus, software freedom applies to everyone irrespective of skill level.

Only if your definition of freedom is as narrow as the fundamentalistic "four software freedoms". To someone else, their definition of computing freedom may go more like "I want to play my favourite computer game, but I only have one hour left this evening". At that point, "irrespective of skill level" is an utter lie: most games are significantly more difficult to run on free OS's.

Unless you mean Steam, but isn't that a platform owned by a single company?...

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#65

Post by fsflover »

ruthmarx wrote: post #63
fsflover wrote: post #62

Earlier quoted context omitted.

> just high precision printers 2D printers just won't cut it: https://i.pinimg.com/originals/90/7a/2e/907a2ece23d412d28b66... https://3.bp.blogspot.com/_BkvigWu1n1A/S8YrMyV_kTI/AAAAAAAAB... (and so on) > I was talking about you personally, who I assume is a pretty average developer that doesn't have state actors after them. This is why I wrote below about eventual discovery of a possible tampering and low priority of…

> 2D printers just won't cut it: Not your off the shelf consumer stuff, no, but there are printers that could do it, for sure. What's more, I really have no idea what the point you are trying to make by linking those images is showing. Printing designs on nails doesn't require the level of resolution your screws idea would, so it isn't really relevant. A quick search shows an especially high resolution 3d printer rel…

> 3d printer released last year in May, that can print at a 20-nanometer resolution, the D4200S[1]

This is impressive indeed. I agree that if you expect that your adversary spends this much resources on you, nail polish wont' be sufficient.

> Secureboot is a standard, and you are free to use your own keys, and own implementation

Show me a FLOSS implementation of this standard and you will have a point. At the moment, I would have to trust a megacorporation obeying NSA, so I don't see it as a good defense against real adversaries. Your threat model may vary.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#66

Post by ruthmarx »

fsflover wrote: post #65
ruthmarx wrote: post #63

Earlier quoted context omitted.

> 2D printers just won't cut it: Not your off the shelf consumer stuff, no, but there are printers that could do it, for sure. What's more, I really have no idea what the point you are trying to make by linking those images is showing. Printing designs on nails doesn't require the level of resolution your screws idea would, so it isn't really relevant. A quick search shows an especially high resolution 3d printer rel…

> 3d printer released last year in May, that can print at a 20-nanometer resolution, the D4200S[1] This is impressive indeed. I agree that if you expect that your adversary spends this much resources on you, nail polish wont' be sufficient. > Secureboot is a standard , and you are free to use your own keys, and own implementation Show me a FLOSS implementation of this standard and you will have a point. At the moment…

> Show me a FLOSS implementation of this standard and you will have a point

I've had a point from my first comment and it hasn't changed in validity. It's just taking time to convince you, but I think I'm making progress :)

I referenced several open implementations in my last reply, an a cursory search reveals more [1] [2]. Besides, this still doesn't help you trust the hardware, even if that hardware is entirely open like some sort of RISC chip. Can you verify every step in the supply chain? At every stage of assembly? No? Or, assuming a trusted device, can you be 100% confident something wasn't added, a simple keylogger? Most keyboards can be removed from laptops without leaving a trace, so can screen casings, speakers, batteries, etc. Plenty of places to hide something tiny.

> At the moment, I would have to trust a megacorporation obeying NSA,

That's less likely than the software you use having been compromised, for example by introducing an obfuscated bug, or MitMing as you perform a software update (many software update mechanisms have notoriously weak security, search some defcon talks on the subject).

> Your threat model may vary.

No, what I'm saying applies to all threat models, and I challenge you to name one to disprove that.

Secure boot is an open standard and can be implemented in a trustworthy and secure way, you just need to put in the work to do so. It's entirely possible to do so.

Of course if you are putting in all that work, if you are that at risk, you would need to switch your software stack entirely as well and use something like seL4 as a starting point.

[1] https://github.com/prplfoundation/prpl-secure-boot

[2] https://www.coreboot.org/

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#67

Post by bubblesnort »

rollcat wrote: post #64
bubblesnort wrote: post #57

Earlier quoted context omitted.

The downside is that one company holds the keys to the castle for this particular security scheme. Also, saying freedom requires technical knowledge and fiddling is a non sequitur. Technical knowledge and fiddling is possible with freedoms 1 and 3. Without technical knowledge and fiddling you still benefit from freedoms 0 and 2. Thus, software freedom applies to everyone irrespective of skill level.

> The downside is that one company holds the keys to the castle for this particular security scheme. And how exactly does that take away any of your freedom? You can still disable any or all parts of the verification chain at will, or enroll your own keys. No privilege has been taken away from you. If you truly cared, you'd advocate for a way to make managing a self-signed trust chain less cumbersome, but you're inst…

You're missing the point entirely and brought a plate of red herring to the table.

I could roll keys for my own computer, but freedom 3 falls flat on its face when everyone elses private key is kept secret by one company. People unknowingly trust one company for their "security", while in fact the "security" in this entire scheme boils down to securing stock gain. You can hardly blame the consumers for buying computers that come pre-compromised with vendor-specific keys as the change was touted as "more secure". Secure, again, in the sense that it secures even more money in already deep pockets. Those who can't change their OS or can't easily tick a box on a security checklist will stay on the prerolled platform.

Not being dependant on any one party is an effect of having freedom. Not a prerequisite.

And you conflate software freedom with personal freedom. The four freedoms you call narrow and fundamentalistic, apply to software. You argue no privilege is taken away from me, which is correct, but that also applies to the four software freedoms. I choose not to buy games that don't work on the OS I run. That's personal freedom. The software I write is free on its own to end up on anything from a roll of toilet paper to critical mission control systems. I don't care because it's free as in freedom on its own.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#68

Post by rollcat »

bubblesnort wrote: post #67
rollcat wrote: post #64

Earlier quoted context omitted.

> The downside is that one company holds the keys to the castle for this particular security scheme. And how exactly does that take away any of your freedom? You can still disable any or all parts of the verification chain at will, or enroll your own keys. No privilege has been taken away from you. If you truly cared, you'd advocate for a way to make managing a self-signed trust chain less cumbersome, but you're inst…

You're missing the point entirely and brought a plate of red herring to the table. I could roll keys for my own computer, but freedom 3 falls flat on its face when everyone elses private key is kept secret by one company. People unknowingly trust one company for their "security", while in fact the "security" in this entire scheme boils down to securing stock gain. You can hardly blame the consumers for buying compute…

> I choose not to buy games that don't work on the OS I run.

That's your personal choice. All I ask is that you don't advocate for narrowing down the personal choice for others.

> I don't care [...]

Yeah, that's the real problem here. When your needs are met, you don't care.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#69

Post by bubblesnort »

rollcat wrote: post #68
bubblesnort wrote: post #67

Earlier quoted context omitted.

You're missing the point entirely and brought a plate of red herring to the table. I could roll keys for my own computer, but freedom 3 falls flat on its face when everyone elses private key is kept secret by one company. People unknowingly trust one company for their "security", while in fact the "security" in this entire scheme boils down to securing stock gain. You can hardly blame the consumers for buying compute…

> I choose not to buy games that don't work on the OS I run. That's your personal choice. All I ask is that you don't advocate for narrowing down the personal choice for others. > I don't care [...] Yeah, that's the real problem here. When your needs are met, you don't care.

You have it backwards. One company holding the keys hurts personal choice for everyone.

And again you conflate software freedom with personal freedom. The needs of any particular piece of software are outlined in its license. My personal choice is to prefer hardware that works fine without non-free software, because I need a different level of trust than you.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#70

Post by rollcat »

bubblesnort wrote: post #69
rollcat wrote: post #68

Earlier quoted context omitted.

> I choose not to buy games that don't work on the OS I run. That's your personal choice. All I ask is that you don't advocate for narrowing down the personal choice for others. > I don't care [...] Yeah, that's the real problem here. When your needs are met, you don't care.

You have it backwards. One company holding the keys hurts personal choice for everyone. And again you conflate software freedom with personal freedom. The needs of any particular piece of software are outlined in its license. My personal choice is to prefer hardware that works fine without non-free software, because I need a different level of trust than you.

> One company holding the keys hurts personal choice for everyone.

I understand why you like to hate on Microsoft (they have a long track record of playing dirty), but the actual keys that are preloaded into hardware that ships with UEFI are ultimately the choice and responsibility of individual OEMs (Lenovo, HP, Dell, etc etc), and some of them are directly accountable for major screw-ups in this area - while others ship systems preloaded with a free OS, and go the extra mile to verify that you have the means to install your own. Microsoft could give zero fucks about cooperating, but rather than making this an impossible problem to resolve between every individual OEM and every individual distro/OS, they chose to sign a shim, so that everyone can play with everyone. I do not dismiss this as a possible threat vector, but please consider the wider picture.

What I don't understand is why you're hyperfixating on hating Microsoft (which, 13 years in, still haven't made an aggressive move in this area), while Intel[0] puts an entire dedicated core, with its own -completely opaque and unauditable- OS, network interface, and a long track record of security holes, into every CPU they've shipped in the last 15+ years, with no user choice/control over that whatsoever.

[0]: https://en.wikipedia.org/wiki/Intel_Management_Engine

> [...] because I need a different level of trust than you.

Do you trust your CPU vendor - Intel? AMD? Apple? Qualcomm? Broadcom? Any other piece of silicon (hint: PCIe) that has unrestricted R/W access to your entire RAM? (Or did you even check if your system has an IOMMU, let alone who made it, how it's configured?)

I'm not dismissing the issue you're hyperfixated on, but the points you're raising are irrelevant in light of much more direct threats. You can't trust the software if you can't trust the hardware.

"Reflections on trusting trust" by Ken Thompson[1] is a 40yro classic, we are a looong way from that even if you dismiss hardware entirely and only consider trivial software-only supply chain attacks[2], and yet all you can see is the source code.

[1]: http://genius.cat-v.org/ken-thompson/texts/trusting-trust/

[2]: https://research.swtch.com/nih

My own need for trustability includes the need to continue trusting my laptop after I've left it unattended for one minute. SecureBoot&co is currently the most practical way to even detect boot chain tampering. Evil Maid[3] has been described 15 years ago - this is centuries in the black hat world, and free software developers (yes - you and me) are the most valuable targets, because of our work's potential far-reaching impact on the community.

[3]: https://en.wikipedia.org/wiki/Evil_maid_attack

If you develop software, and dismiss this class of problems, you become a liability to your users and/or employer - they can no longer trust you.

> And again you conflate software freedom with personal freedom.

I do not conflate them, I recognise software freedom as an aspect of personal freedom - but ultimately it is your own personal choice, which freedoms do you value the most. The vast majority of people using FOSS are anything but interested in compiling their own bootloaders/kernels, because we don't do boot-chain development work and instead we want this part of the OS to be stupid, simple, reliable, and secure, so that we can be free to focus on our actual work.

The "stupid, simple, reliable, and secure" part is the very thing that's missing from the entire Linux ecosystem and why I'm usually a vocal opponent of everything-Poettering, choosing to run OpenBSD where I can - their FDE[4] is orders of magnitude simpler/easier to audit than the bloody mess that is UEFI-shim+GRUB+Linux+initrd+cryptsetup. Again, if you actually cared, you would be advocating for software that is easier to audit. Source code that you can't read/comprehend is no better than a binary blob.

[4]: https://www.openbsd.org/faq/faq14.html#softraidFDE; the entire disk decryption code fits directly into the bootloader, thus even the kernel is encrypted.

Post reply on HN