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

121–130 of 142 posts

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

#121

Post by JCattheATM »

fsflover wrote: post #120
JCattheATM wrote: post #119

Earlier quoted context omitted.

This seems like a ridiculous argument. There is a fully source open source secure boot implementation, that if you have concerns about it you can fully audit, just as you can fully audit your current setup if you wanted to - but almost certainly have not.

So you are suggesting me to audit an implementation which I do not necessarily run and there's no way to know if I do. What's the point? How will it help? The code running on my hardware is open, so anybody from the community can audit it and I have a possibility to verify that this is what I run at least by reflashing it. And I did reflash it. This approach is getting more reliable with more software becoming reprod…

> So you are suggesting me to audit an implementation which I do not necessarily run and there's no way to know if I do. What's the point? How will it help?

No, I'm pointing out your, what seems to fundamentally be contrarian, alternative method that you are preferring because it is 'open', is no more secure than the coreboot secureboot implementation. Your concern seems to be based on the idea that the coreboot secureboot implemetnation could have sus code in their, but that is equally true for your heads setup. Unless you audit both, or pay to have both audited, either could have problem code.

Your position is an irrational inconsistency.

> The code running on my hardware is open, so anybody from the community can audit it and I have a possibility to verify that this is what I run at least by reflashing it. And I did reflash it. This approach is getting more reliable with more software becoming reproducible.

This is equally true for coreboot.

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

#122

Post by adrian_b »

JCattheATM wrote: post #102
adrian_b wrote: post #56

Earlier quoted context omitted.

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 re…

The setup that I have described has identical behavior, except that I use a removable USB memory (containing a bootable OS kernel and encrypted SSD/HDD keys) instead of a TPM and a firmware implementing SecureBoot, which are included in the computer motherboard.

In my variant, you do not need to trust anyone but yourself, because an attacker will have access only to a system where the component that needs to be secure is not present. In your variant, you must trust the vendors of the TPM and of the firmware, that their products do not have either intentional backdoors or bugs that would allow the extraction of the secret keys.

Having seen first hand how the development of "secure" products is done even at the companies that do not have bad intentions, I do not trust anyone, except myself.

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

#123

Post by fsflover »

JCattheATM wrote: post #121
fsflover wrote: post #120

Earlier quoted context omitted.

So you are suggesting me to audit an implementation which I do not necessarily run and there's no way to know if I do. What's the point? How will it help? The code running on my hardware is open, so anybody from the community can audit it and I have a possibility to verify that this is what I run at least by reflashing it. And I did reflash it. This approach is getting more reliable with more software becoming reprod…

> So you are suggesting me to audit an implementation which I do not necessarily run and there's no way to know if I do. What's the point? How will it help? No, I'm pointing out your, what seems to fundamentally be contrarian, alternative method that you are preferring because it is 'open', is no more secure than the coreboot secureboot implementation. Your concern seems to be based on the idea that the coreboot secu…

Can I compile coreboot with Secure Boot from source and reflash my UEFI/BIOS with it? If yes, then you have a point. I would appreciate the corresponding link to the source and supported devices.

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

#124

Post by JCattheATM »

adrian_b wrote: post #122
JCattheATM wrote: post #102

Earlier quoted context omitted.

> 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 re…

The setup that I have described has identical behavior, except that I use a removable USB memory (containing a bootable OS kernel and encrypted SSD/HDD keys) instead of a TPM and a firmware implementing SecureBoot, which are included in the computer motherboard. In my variant, you do not need to trust anyone but yourself, because an attacker will have access only to a system where the component that needs to be secur…

> The setup that I have described has identical behavior, except that I use a removable USB memory

That's a huge difference though!

With my setup, if someone steals the device, they get a fully useable laptop with no password, locked down and restricted - they can join wifi networks, use the browser, download etc, but can't access the 'real' OS, and the laptop won't boot from anything other than the encrypted HDD it has the keys for.

It sounds like your setup leaves out the guest OS aspect, and is just set to boot into an encrypted OS only if a hardware key is present, which is quite a bit different.

> In my variant, you do not need to trust anyone but yourself,

That's true for my setup as well. Secureboot has an opensource reference implementation that has been in Coreboot for a long time, and it's not necessary to keep or add any vendor keys.

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

#125

Post by JCattheATM »

fsflover wrote: post #123
JCattheATM wrote: post #121

Earlier quoted context omitted.

> So you are suggesting me to audit an implementation which I do not necessarily run and there's no way to know if I do. What's the point? How will it help? No, I'm pointing out your, what seems to fundamentally be contrarian, alternative method that you are preferring because it is 'open', is no more secure than the coreboot secureboot implementation. Your concern seems to be based on the idea that the coreboot secu…

Can I compile coreboot with Secure Boot from source and reflash my UEFI/BIOS with it? If yes, then you have a point. I would appreciate the corresponding link to the source and supported devices.

Yes, you can, as long as you have supported hardware.

Here is there list of supported hardware: https://doc.coreboot.org/mainboard/index.html

Also, heads seems to use coreboot also.

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

#126

Post by fsflover »

JCattheATM wrote: post #125
fsflover wrote: post #123

Earlier quoted context omitted.

Can I compile coreboot with Secure Boot from source and reflash my UEFI/BIOS with it? If yes, then you have a point. I would appreciate the corresponding link to the source and supported devices.

Yes, you can, as long as you have supported hardware. Here is there list of supported hardware: https://doc.coreboot.org/mainboard/index.html Also, heads seems to use coreboot also.

Thanks, I already know where the coreboot source is (and I'm already using it with Heads). Concerning Secure Boot, I only found this (emphasis mine):

> soc/amd/common/block/psp: Add platform secure boot support

>

> Add Platform Secure Boot (PSB) enablement via the PSP if it is not already enabled. Upon receiving psb command, PSP will program PSB fuses as long as BIOS signing key token is valid. Refer to the AMD PSB user guide doc# 56654, Revision# 1.00. Unfortunately this document is only available with NDA customers

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

#127

Post by JCattheATM »

fsflover wrote: post #126
JCattheATM wrote: post #125

Earlier quoted context omitted.

Yes, you can, as long as you have supported hardware. Here is there list of supported hardware: https://doc.coreboot.org/mainboard/index.html Also, heads seems to use coreboot also.

Thanks, I already know where the coreboot source is (and I'm already using it with Heads). Concerning Secure Boot, I only found this (emphasis mine): > soc/amd/common/block/psp: Add platform secure boot support > > Add Platform Secure Boot (PSB) enablement via the PSP if it is not already enabled. Upon receiving psb command, PSP will program PSB fuses as long as BIOS signing key token is valid. Refer to the AMD PSB u…

I guess I misunderstood your request. This[1] and this[2] should be what you are looking for.

[1] https://doc.coreboot.org/security/vboot/index.html

[2] https://github.com/tianocore/edk2

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

#129

Post by adrian_b »

JCattheATM wrote: post #124
adrian_b wrote: post #122

Earlier quoted context omitted.

The setup that I have described has identical behavior, except that I use a removable USB memory (containing a bootable OS kernel and encrypted SSD/HDD keys) instead of a TPM and a firmware implementing SecureBoot, which are included in the computer motherboard. In my variant, you do not need to trust anyone but yourself, because an attacker will have access only to a system where the component that needs to be secur…

> The setup that I have described has identical behavior, except that I use a removable USB memory That's a huge difference though! With my setup, if someone steals the device, they get a fully useable laptop with no password, locked down and restricted - they can join wifi networks, use the browser, download etc, but can't access the 'real' OS, and the laptop won't boot from anything other than the encrypted HDD it…

The open source feature of Secureboot is true only if you have replaced the laptop firmware with Coreboot, which is compatible only with few, mostly old, laptops.

Even in that case, a laptop with Coreboot will still use closed-source components that cannot be trusted, at least for the auxiliary CPUs of Intel and AMD (ME/PSP) and for the CPU of the TPM, i.e. for the parts that are the most important for security.

If someone steals the device, I cannot see any difference between our 2 setups. In both cases, the thiefs can use the laptop, but without accessing the internal SSD/HDD, unless they format it, which will remove any of the original information stored on it.

Even if you configured a laptop with UEFI/SecureBoot to not display the boot device selection menu without a password and to not boot from the internal SSD without a password, that can stop only someone with momentary access to the device, the same as in my setup, where an intruder would see the error message that no bootable disk has been found. Thiefs will erase the non-volatile UEFI settings, so they will be able to boot your laptop from an external device, regardless of your configuration, but the original internal SSD/HDD will remain inaccessible in any of the 2 setups.

However in the case that relies on the internal firmware and TPM to protect the keys, there are more sophisticated hardware attacks against the motherboard, e.g. using fault injections, logic analyzers, desoldering the relevant chips and replacing them, etc., which may succeed in some cases. Such hardware attacks are impossible when the component that must be attacked is not present, because it is a removable key (which is temporarily inserted only during booting).

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

#130

Post by fsflover »

JCattheATM wrote: post #127
fsflover wrote: post #126

Earlier quoted context omitted.

Thanks, I already know where the coreboot source is (and I'm already using it with Heads). Concerning Secure Boot, I only found this (emphasis mine): > soc/amd/common/block/psp: Add platform secure boot support > > Add Platform Secure Boot (PSB) enablement via the PSP if it is not already enabled. Upon receiving psb command, PSP will program PSB fuses as long as BIOS signing key token is valid. Refer to the AMD PSB u…

I guess I misunderstood your request. This[1] and this[2] should be what you are looking for. [1] https://doc.coreboot.org/security/vboot/index.html [2] https://github.com/tianocore/edk2

I found no installable code for Secure Boot itself in your links.
Post reply on HN