another one of microsoft's anti competitive behaviors

[leadeater]

4 hours ago, hishnash said:

Why does there need to be any Root CA at all? if when you install and flag a partition as bootable and secure part of that you present the CA chain you want the system to trust and the TMP were to store that along with the drive keys I don't see the need for a single CA authority at all MS or TCG/UEFI group. 

Because how do you know, as well as the system know, that the OS you are installing and the bootloader is actually trusted.

 

How do you know to trust that this site is secure? Should you have to install the CA that signed this site's certificates? You might know to trust this site, or do you? Is this the site you really think it is?

 

And that is the core of the issue, someone has to be the CA or you end up requiring people to accept the installation of key(s) they have no idea about so the whole trust chain falls apart because of "Yes, w/e just install ism".

 

4 hours ago, hishnash said:

I don't think TMP drive encryption is paired to the secure boot chain.

It's not but what you are talking about is drive encryption. Unlocking a partition is drive encryption, reading the data after that is secure boot. UEFI checking the boot loader and OS signature is secure boot.

 

 

 

 

 

[hishnash]

1 hour ago, leadeater said:

Because how do you know, as well as the system know, that the OS you are installing and the bootloader is actually trusted.

as long as all the data created by a give CA chain is only accessible to that signed chain does it matter?

[leadeater]

30 minutes ago, hishnash said:

as long as all the data created by a give CA chain is only accessible to that signed chain does it matter?

To some extend probably yes

 

The first image is basically what you suggest however the Shim still has to be signed by the UEFI CA, after that point you can sign and load your own kernels and modules with that MOK (Machine Owner Key).

 

Quote

Proper, secure use of UEFI Secure Boot requires that each binary loaded at boot is validated against known keys, located in firmware, that denote trusted vendors and sources for the binaries, or trusted specific binaries that can be identified via cryptographic hashing.

 

Most x86 hardware comes from the factory pre-loaded with Microsoft keys. This means we can generally rely on the firmware on these systems to trust binaries that are signed by Microsoft, and the Linux community heavily relies on this assumption for Secure Boot to work. This is the same process used by Red Hat and SUSE, for instance.

 

Many ARM and other architectures also support UEFI Secure Boot, but may not be pre-loading keys in firmware. On these architectures, it may be necessary to re-sign boot images with a certificate that is loaded in firmware by the owner of the hardware.

 

Quote

Given the limitations imposed on the automatically generated MOK and the fact that users with superuser access to the system and access to the system console to enter the password required when enrolling keys already have high-level access to the system; the generated MOK key is kept on the filesystem as regular files owned by root with read-only permissions. This is deemed sufficient to limit access to the MOK for signing by malicious users or scripts, especially given that no MOK exists on the system unless it requires third-party drivers. This limits the possibility of compromise from the misuse of a generated MOK key to signing a malicious kernel module. This is equivalent to compromise of the userland applications which would already be possible with superuser access to the system, and securing this is out of the scope of UEFI Secure Boot.

https://wiki.ubuntu.com/UEFI/SecureBoot

 

The problem is still the KEK and DB Keys, the OS EFI data is not the firmware UEFI, these are different things. UEFI firmware in secure boot will block any OS EFI if it doesn't trust it which means it needs to be signed by it. So unless you are loading your own KEK and DB keys anything after this doesn't matter, you're dead in the water without addressing this phase first. This is simply how UEFI Secure Boot works.

 

UEFI Secure Boot purpose is to block malicious boot loaders and it can't know that you trust it, unless you start loading your own keys.

[hishnash]

3 minutes ago, leadeater said:

UEFI Secure Boot purpose is to block malicious boot loaders and it can't know that you trust it, unless you start loading your own keys.

I suppose there is now device local keys that you can use to self sign images that you trust since there is no device level auth that you setup on first boot. 

[leadeater]

3 minutes ago, hishnash said:

I suppose there is now device local keys that you can use to self sign images that you trust since there is no device level auth that you setup on first boot. 

Have a read of this, mainly around the PK parts, then you'll start to understand why the whole UEFI Secure Boot thing needs a complete overhaul/replacement. Has to be a better way. https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11

 

There is device level auth, that is the PK, and you can actually put the UEFI Firmware in to setup mode and change it etc. Just make sure you read everything that entails by doing that, not fun.

[Just that Mario]

On 7/16/2022 at 12:12 AM, kirashi said:

Learning doesn't help for those who've already spent $1000, $2000, or $3000 on a laptop and cannot return it.

 

While I can understand the logic behind locking down devices, consumers MUST be educated by the manufacturer about this at or before point of sale so they can make an informed decision as to whether a locked down device is right for their use-case.

 

It's really no different than purchasing a motor vehicle - it's just that motor vehicles don't prohibit the installation and use of third party wheels & tires (yet) so one would never think to ask the dealership if there are any protection mechanisms in place to prevent this.

It isn't OE's job nor the seller's to ensure the person purchasing it knows how the product works.

 

On 7/15/2022 at 11:55 PM, emosun said:

This is a major issue for anyone who needs to natively boot a different os on a portable computer with no knowledge of other computer brands or methods in which to do so.

Where does someone like this even live? They somehow NEED to boot multiple OS, but have so little knowledge on the topic? This must be a made up issue.

[emosun]

16 minutes ago, Just that Mario said:

 

Where does someone like this even live? They somehow NEED to boot multiple OS, but have so little knowledge on the topic? This must be a made up issue.

r/woosh

[Just that Mario]

7 minutes ago, emosun said:

r/woosh

Bruh, this forum is full of some wild stuff. Never going to assume something dumb being sarcastic in LTT forums.