There has been some discussions around SecureBoot recently, which a lot of it prompted by Intel's clearlinux team saying that they do not support Secure Boot. I wanted to clear several misconceptions on the matter.

1) Secure Boot is a microsoft product.

No it's not. It's part of the UEFI (Unified Extensible Firmware Interface) standard that evolved out of Intel's EFI replacement for legacy IBM-PC bios.

UEFI is a defined interface that is presented by a motherboard's firmware to allow conforming operating systems to interact with the platform hardware. Secure Boot is nothing more than a standard for comparing cryptographic signatures on bootable executables and some OS code against a database of keys. https://www.intel.com/content/www/us/en/support/articles/000006942/boards-and-kits/desktop-boards.html . In pretty much all x86 motherboards (by which I mean I can't find any exception,) the key database is entirely controllable by the end user. If you want to add your own key, you can. If you want to delete microsoft's key, you can. The only way that microsoft is involved is that 1) the majority of motherboards ship by default with MS's key, and 2) for a computer to be designated "Certified for Windows 8 or 10 or whatever" it has to ship with Secure Boot enabled by default and have Microsoft's key. It does not prevent user management of the keys.

Many distros have partnered with windows to piggy-back off their keys since they're distributed by default, but this is only relevant for REALLY new users who cannot manage their own key store. It's entirely possible to get the signing keys of your distro or to sign your own stuff without using MS's key at all.

2) Secure boot is meant for enforcing DRM

Secure boot isn't even capable of enforcing DRM by itself. Once the OS is loaded Secure Boot doesn't do anything, it is only capable of restricting execution of boot loaders and OS kernel / modules. Most people confuse the criticism of secure boot with the criticism of hardware TPMs (trusted platform module). A TPM is a hardware device that contains private cryptographic keys with a defined interface for decrypting data without exposing your private key. In theory a company can require a TPM that does not expose an interface for user management of the keys and use it to restrict what devices are authorized to use its software or view media. Essentially a dongle. For that to be effective you'd have to enable both a TPM and a bastardized version of secure-boot that only allows heavily restricted operating systems to boot so that someone could not just load the software, find the unencrypted version of the software / media in RAM, and dump a cracked version that bypasses the DRM. But there are no examples of this type of thing being done on consumer PCs since most don't come with a TPM, and most users are not computer savy enough to understand how to buy / install / use one.

3) secure boot doesn't protect anything or isn't useful.

It is entirely possible that your specific use case and risk tolerance is such that it is not an overall benefit for you to use secure-boot, but there are real benefits to it. If you dual boot your computer with both Windows and Linux, and have encrypted your Linux main drive, you still have unencrypted files that are used to bootstrap your computer enough to unencrypted those files. Even without a filesystem driver in windows that can read a linux partition, there still exists a theoretical attack where someone could compromise your windows OS, modify your initramfs, and put in some code to sniff your decryption password, writing it back onto your windows system to be retrieved the next time you boot into your compromised windows. SecureBoot prevents this attack, and even if your windows system is compromised by someone without a private key matching your secure boot key database, your linux boot files cannot be modified. If you only run one Linux distro, it's much less beneficial since a compromised Linux system that allows modifying boot files would mean access to anything else, but it would still prevent certain theoretical classes of attack.

I'm certain I missed something, and am open to discussion or debate, but I wanted to clear up a lot of confusion and myths that seems to exist.

submitted by /u/Paul_Aiton
[comments]

This site uses Akismet to reduce spam. Learn how your comment data is processed.