* Vitaly Zaitsev via devel: > On 26/07/2022 20:05, Chris Murphy wrote: >> Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM. Two different issues result: > > Microsoft has published a new security bulletin on the current state > of Secure Boot: > https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process > > The most important note: > >> Secured-core PCs require Secure Boot to be enabled and configured to distrust the Microsoft 3rd Party UEFI CA signature, by default, to provide customers with the most secure configuration of their PCs possible. > > TL;DR. The new certified by Microsoft devices will be able to load > only Microsoft Windows in the UEFI Secure Boot enabled mode. > > "Microsoft <3 Linux", "Microsoft is a friend", "Microsoft has > changed", - they said. But they also say this: | The default state of Secure Boot has a wide circle of trust which can | result in customers trusting boot components they may not need. Since | the Microsoft 3rd Party UEFI CA certificate signs the bootloaders for | all Linux distributions, trusting the Microsoft 3rd Party UEFI CA | signature in the UEFI database increase[]s the attack surface of | systems. A customer who intended to only trust and boot a single Linux | distribution will trust all distributions–much more than their desired | configuration. And this is an accurate description of the situation. Unfortunately, Fedora promoted this broken model with pervasive cross-distribution/cross-OS trust as well. People are generally quick to criticize those who control a PKI, but very few organizations are willing to step up to hold the key material for the key of last resort because of the risk inherent to that. Consequently, pretty much all distributions hide behind the Microsoft key, instead of running their own PKI and working with OEMs to get it accepted by the firmware. I wonder if this Secure Boot interoperability failure is the result of using PKI in a situation where it is really not applicable. Based on a shim/first-stage boot loader, Microsoft cannot really tell what it will boot eventually, and no meaningful security review is possible. It doesn't help that Microsoft does not embed the name of the party who submitted an UEFI driver for signing in the signature itself. (If Microsoft is able to authenticate driver authors properly, this would allow the firmware to provide an informative prompt for unknown boot loaders.) Maybe the answer to that this issue is to have a minimal (cross-distribution) boot loader that displays the SHA-256 hash of second-stage boot loaders (requiring physical presence before booting), and offer to to enrol their hashes for future automated boots (similar to SSH's leap-of-faith authentication). The second stage boot loader can have a long-term distribution-specific key embedded in it and is also supposed to be minimal, so that distribution upgrades do not require re-enrollment of the per-distribution boot loader. I doubt it will be acceptable to Linux distributions, though. People taught Linux to extract public keys from signed UEFI binaries in an attempt to avoid runnig their own PKI. And if Microsoft drastically cuts back signing services (because the new model doesn't need Microsoft signatures anymore), they would no longer be able to offload which Linux kernel module authors to trust to Microsoft. Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
