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

Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

binarly.io

Post reply on HN
Print view View original

101–110 of 142 posts

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#101

Post by JCattheATM »

fsflover wrote: post #86
heavyset_go wrote: post #85

Earlier quoted context omitted.

Unless your BIOS/UEFI supports full disk encryption unlocking of hardware-encrypted Opal drives, you will always have an unencrypted bootstrap process at early boot from the disk. That unencrypted bootstrap process can be modified by anyone with access to the disk, physical or remote. Theoretically, someone can inject a keylogger into the process and exfiltrate your encryption key's password, or a process that waits…

https://news.ycombinator.com/item?id=44246281

What you've described in that comment is just kind of reinventing the wheel. You're solving the same problem a different way, in a way that has slightly more complexity than just using UEFI and secureboot.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#102

Post by JCattheATM »

adrian_b wrote: post #56
gruez wrote: post #12

Earlier quoted context omitted.

BIOS isn't magically secure either. It has no secureboot so it just runs whatever.

Nevertheless, it is trivial to make any BIOS-based computer at least as secure as the most secure UEFI/secureboot-based computers. For that, any SSDs/HDDs included in the computer should be non-bootable and fully-encrypted. Then the BIOS will happily run whatever an intruder will attempt to run, but nonetheless the intruder will not have any access, neither for reading nor for writing, to the data hosted by the compu…

> Nevertheless, it is trivial to make any BIOS-based computer at least as secure as the most secure UEFI/secureboot-based computers.

Mmm....no.

I use my own keys and removed vendors keys from my secureboot setup. Hard disk is encrypted and automatically pulls keys from the TPM to boot into a guest OS, which is running something akin to prey. If the hard drive is removed, it can't be read or examined, and you can't replace the HDD with a different OS to get it to boot.

How would you recreate that setup with just a BIOS?

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#103

Post by fsflover »

JCattheATM wrote: post #101
fsflover wrote: post #86

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=44246281

What you've described in that comment is just kind of reinventing the wheel. You're solving the same problem a different way, in a way that has slightly more complexity than just using UEFI and secureboot.

The main difference is that the user owns the root of trust and doesn't have to blindly trust a (buggy) proprietary software from a commercial company. Also, the community review.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#104

Post by JCattheATM »

fsflover wrote: post #103
JCattheATM wrote: post #101

Earlier quoted context omitted.

What you've described in that comment is just kind of reinventing the wheel. You're solving the same problem a different way, in a way that has slightly more complexity than just using UEFI and secureboot.

The main difference is that the user owns the root of trust and doesn't have to blindly trust a (buggy) proprietary software from a commercial company. Also, the community review.

You could still have that with UEFI though.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#105

Post by fsflover »

JCattheATM wrote: post #104
fsflover wrote: post #103

Earlier quoted context omitted.

The main difference is that the user owns the root of trust and doesn't have to blindly trust a (buggy) proprietary software from a commercial company. Also, the community review.

You could still have that with UEFI though.

But not with Secure Boot AFAIK.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#106

Post by JCattheATM »

fsflover wrote: post #105
JCattheATM wrote: post #104

Earlier quoted context omitted.

You could still have that with UEFI though.

But not with Secure Boot AFAIK.

Well, yeah, you could, that was the point of my comment.

Coreboot supports secure boot, so why isn't that sufficient?

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#107

Post by fsflover »

JCattheATM wrote: post #106
fsflover wrote: post #105

Earlier quoted context omitted.

But not with Secure Boot AFAIK.

Well, yeah, you could, that was the point of my comment. Coreboot supports secure boot, so why isn't that sufficient?

Secure Boot is closed and not auditable.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#108

Post by JCattheATM »

fsflover wrote: post #107
JCattheATM wrote: post #106

Earlier quoted context omitted.

Well, yeah, you could, that was the point of my comment. Coreboot supports secure boot, so why isn't that sufficient?

Secure Boot is closed and not auditable.

Not so, the reference implementation is open source and incorporated into Coreboot, for a long time now.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#109

Post by mjg59 »

AnthonyMouse wrote: post #96
mjg59 wrote: post #62

Earlier quoted context omitted.

How does the system know whether the new bootloader is legitimate or not? All TPMs have private keys from the factory. They're entirely unrelated to the secure boot keys.

> How does the system know whether the new bootloader is legitimate or not? However it wants to. Maybe the existing bootloader (chosen by the owner rather than the vendor) or the OS it loads has its own signature verification system for update packages, like apt-get. Maybe the OS downloads it from a trusted URL via HTTPS and relies on web PKI. Maybe it uses Kerberos authentication to get it from the organization's ow…

The situation you're protecting against is one where someone who compromises the OS can make that compromise persistent by replacing the bootloader. That means you can't place any trust in any component after the bootloader, since an attacker could just fake whatever mechanism you're enforcing.

> The point isn't which device has the keys, it's that it shouldn't contain any from the factory. Nothing good can come of it.

TPMs have private keys, and are not involved in enforcing secure boot. The firmware validating the signatures only has public keys.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#110

Post by RiverCrochet »

mjg59 wrote: post #87
RiverCrochet wrote: post #82

Earlier quoted context omitted.

If an attacker gains root privileges on your system, an attacker can modify the bootloader on your boot device to load a different kernel than the one you have installed, possibly one that the attacker uploaded that may have backdoors, etc. Secure boot requires that the bootloader match a hash derived from a TPM-stored key. Of course, you get the same protection (and update hassle) by storing the bootloader in someth…

> Secure boot requires that the bootloader match a hash derived from a TPM-stored key. This isn't even slightly accurate. Secure boot does not rely on TPM keys on any way.

Huh, I don't know why I thought it did. Looking into the link below briefly I see it uses a PKI scheme with CAs.

https://learn.microsoft.com/en-us/windows-hardware/manufactu...

So I guess if you provide a key for the bootloader, the firmware will sign it when it's in setup mode? I guess that private key is embedded directly in the firmware then? I presume that's made invisible once control is handed to the bootloader somehow ...

Post reply on HN