Where is the data used in secure boot process stored?

I am spent a lot of time researching and reading about this topic but I am now very confused.

I have read that computer manufacturers include some Microsoft keys. For example, Microsoft Corporation UEFI CA, seems to be a key that somehow lets a system boot to Linux distros that are signed by Microsoft. I'd like to understand where these are stored. For example, is it on your hard drive? Where is other data in the secure boot process read from? What are the steps that secure boot goes through?

Sorry if I am using some terminology incorrectly. I am doing my best.

Solution 1:

Your motherboard has a small amount of built-in storage, where it primarily keeps the "BIOS settings" (like the boot order) – in the past this was known as "CMOS memory", now it's more commonly called "NVRAM" and is of somewhat higher capacity.

Physically, it's just some sort of "flash" memory or maybe EEPROM (I don't know which) that the firmware can read/write, but the OS can't – not directly, at least.

In UEFI type firmware, the data that's stored in the NVRAM is structured in terms of "EFI variables" and the firmware does allow the OS to access them – but still, only through the functions provided by firmware, not directly at block level. (It's a lot like how the OS allows your regular apps to use the HDD/SSD but only through file management functions – it does permission checks, etc.)

The list of operating systems in UEFI is stored as "EFI variables" in the motherboard's NVRAM – when the OS is installed, it calls the firmware function to create a variable named Boot0002 or similar, with specified data.

Secure Boot settings are mostly the same. There is a variable named db that lists the certificates allowed to sign operating systems (the MS UEFI CA certificate is stored in db), and the only thing special about it is that the firmware requires the new value itself to be digitally signed.

At boot time, the initial OS files are validated against certificates listed in 'db'; updates to 'db' must be signed with the certificate found in 'KEK', and updates to that are verified against 'PK'. (The firmware settings screen can bypass those checks and let you import any certificate – but the OS can't.)

If you are running Linux, take a look at /sys/firmware/efi and you'll find the list of EFI variables currently stored in the NVRAM, including the ones used by Secure Boot. You also have tools like efi-readvar to dump a formatted list of the Secure Boot certificates, or efibootmgr -v to list the boot options – they both get their data from EFI through the Linux-provided /sys interface. (There are similar tools for PowerShell in Windows.)

Note regarding the TPM – while some manufacturers might put some SB-related parameters in the TPM's own NVRAM, that is not required; it's just one possible way the manufacturer can comply with the tamper resistance requirement, but most Secure Boot implementations do not use the TPM in this way at all. (Indeed many don't even have a TPM.)

Secure Boot only involves the TPM in that the current satate is appended into its event log and hashed into the "PCR" registers – which are all kept in volatile RAM and their purpose is measuring each individual boot, not persistent storage.