Comment by 9jnjiavh | Hacker News Reader

Comment by 9jnjiavh | Hacker News Reader

3,2,1.... SecureBoot? I sure hope not. As with terrorism, the problem is not removing the owner from the equation any more than is removing privacy everywhere (or encryption without backdoors, or computers without rootkits... lots of parallels there), because "terrorism".

If we can wade through the power-grabs and social-engineering disguised as erudite commentary and philosophizing (similar to that surrounding national security), increasing transparency and user control remains the answer. Any software can have flaws, but software you can't fix because it's locked into hardware is worse. Worse yet is hardware that turns a computer into an single-purpose (flaws-and-all) appliance.

Any bootloader relies on a chain of trust. If the on-disk (OS) portion of that fails (incidentally, the biggest attack surface) and is vulnerable (likely - proprietary software can be fuzzed like any other), then the hardware-linked protection is at best annoying to the actual hardware owner.

In that sense, SecureBoot is actually an inversion of good security principles, which dictate simplicity and accountability/openness. The better place for signed loader verification is in the on-disk bootloader stub. If the OS were perfect, this would be enough too, but at least it is patchable (and the OS is re-installable) when it isn't.

A computer that can't be re-installed when you brick it is expensive garbage that was at best constraining while it even worked.

FOSDEM 2013 had a worthy social and technical overview of UEFI and SecureBoot I enjoyed:

https://www.youtube.com/watch?v=NsoXFvGiAas

Many Secure Boot implementations let you load your own keys. The "removing the owner from the equation" thing is not an issue with Secure Boot, but with particular manufacturers.

> The better place for signed loader verification is in the on-disk bootloader stub.

That is already part of the Secure Boot. But who verifies the bootloader stub? The point is that you can't trust anything on the disk.

> Any bootloader relies on a chain of trust. If the on-disk (OS) portion of that fails (incidentally, the biggest attack surface) and is vulnerable (likely - proprietary software can be fuzzed like any other), then the hardware-linked protection is at best annoying to the actual hardware owner.

Firmware verifies the (on-disk) bootloader, bootloader verifies the kernel, kernel verifies the drivers, and so on. The chain of trust is there.

> The point is that you can't trust anything on the disk.

But the disk is where my choice of software lives. I trust my choice of software, by definition. I don't want to be removed from that equation any more than I want someone else sleeping with my wife.

If I don't trust my (current) on-disk bootloader, the appropriate thing to do is clean it and put something I do trust in its place. If I wake up hearing a noise, I check my house for intruders - I don't lock myself out and throw away the keys.

The reality is that any chain of trust has to start somewhere. It should start in the place I have the most control: on physically-removable, writable media.

> It should start in the place I have the most control: on physically-removable, writable media.

Same goes for malware on most PC operating systems does it not? How can you know the disk has not been silently compromised?

I don't, but if I am in doubt, I can replace the disk. The alternative is worse - I have to replace the whole system. It is fascinating to watch such subtle abuses of language ploddingly erode our free(ish) societies from the inside out, when secure is obviously "newspeak" for centralized. Even technologically-literate people are clearly willing to buy the logic that "well, you might get an STD by having sex... therefore, let this small group of condom manufactures move in and have sex with your wife, in your place, for your protection."

We can't outsource confidence. It doesn't help improve my self-esteem to watch someone else live my life, and it doesn't work to fight "the terrorists" to let someone else make me safe (for some definition of "safe", that I can seemingly no longer contribute to) - but that all seems to be beside the point. :(

> Many Secure Boot implementations let you load your own keys.

And there is no promise that this will not change.

That's a great reason to get rid of security features!

Might as well ditch TLS since soon you'll only be able to get certs for government approved content.

Please allow for the possibility that the word "secure" is no more than an attempt by a company (Microsoft) to leverage your fears and co-opt your natural pursuit of safety in order to help make a consumer-restricting technology appear to be a feature. Would you have as much faith in the technology under a different name? Perhaps: MicrosoftBoot (implying it could only boot a Microsoft OS, or the specific version of Windows your PC came with)?

(In a sense, dropping TLS is the correct response... In the sense, of not using the limited set of services. The corresponding response here is to not buy PCs with SecureBoot present in any imposing way, which may mean boycotting "modern" computers that are no longer general, user-controlled, devices if, in the future, they all are locked to Microsoft out of the box.)

Reply on news.ycombinator.com