Linux and Secure Boot certificate expiration

[Warning: I'm not interested in sarcasm or uninformed rants against secure boot, there are plenty already]

I'm hoping to get insights from people who understand secure boot well here. My understanding on Android (for the minority of Android manufacturers that do it correctly) is that there is a "manufacturer key" burnt somewhere on the ROM that cannot ever be changed, and once a first system is installed properly:

1. It is impossible to overwrite the system partitions unless the bootloader is unlocked from the already-installed OS (I assume that something makes sure that only the signed OS can unlock the bootloader?).

2. Once the bootloader is unlocked, it is impossible to overwrite only parts of the system: it's all or nothing, such that one cannot inject stuff into an existing system (evil maid style).

Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use.

How is it on UEFI? It sounds like the "manufacturer keys" are always from Microsoft, but is there not a way to use custom keys?

> Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use.

AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted. Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.

Of course it is possible to use custom keys. At least it was possible on all EFI computers I owned. There are no "manufacturer keys". There's usually an option in BIOS to restore default configuration which resets to MS keys, but you can delete all MS keys.

Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys and if you delete MS keys, you might brick your laptop, because GPU won't start anymore. That said, I'm using Lenovo Thinkpad T14s Gen4 Intel right now with all keys deleted and my custom key added and it works just fine. May be it's AMD issue.

> AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted.

You're right! That's what I mentioned the few manufacturers who do it correctly. GrapheneOS only supports Pixels for other reasons than that. CalyxOS supports other devices (one constraint being to be able to relock the bootloader). /e/OS doesn't seem care so much about the secure boot.

> Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.

That raises a question: what is the point of relocking the bootloader? If overwriting the keys means that the whole system will be formatted, then I don't see why it should ever be prevented at all? If an evil maid wants me to lose my data, they can leave with the laptop, right?

> Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys

Oh right! Yeah if you want to use custom keys, you need to be able to build and sign your OS, and proprietary firmwares are then a problem. Now I wonder why this is not a problem on Android... Is it because the firmware blobs come from the image that you sign yourself?

Would the solution be that the GPU should load the firmware from the OS?

> It sounds like the "manufacturer keys" are always from Microsoft,

The primary key is called "Platform Key" (PK) on UEFI, there can be only one, and it is generated by the mainboard manufacturer, not Microsoft. The PK is then used to sign Key Exchange Keys (KEK) which you will generally have 2…4 of, the Microsoft self-use one, the Microsoft third party one, a board vendor one, and a system/board specific one.

And next to those you can load your custom keys?

You need to replace the PK with one of your own, because that is used to sign all the other keys, and generally there can only be one PK. You can then re-sign the existing keys with your own PK (e.g. if you want to dual boot Windows) — or just ditch the existing ones¹, and/or you can generate your own keys of the other types (KEK & DB).

Ed.: ¹ there are cases where ditching the existing keys breaks the system, because the board vendor was stupid and signed the VGA UEFI driver with one of those keys instead of tying it directly into the BIOS/UEFI image. AFAIK this only affects a specific series of Lenovo laptops, but Google the details before breaking your system.

Ed.#2: actually I think the PK signature is only checked while installing keys into the KEK/DB list, so you don't need to re-sign the existing Microsoft keys, they just stay in the list by default. (Unless they got cleared somehow.) It's been a little while since I did this.

You don't need to be able to build them. Just sign them or sign the keys that sign the third party blobs/binaries.

Then your motherboard firmware will be able to load your GPU and other third party blobs to UEFI memory. Similarly OSes like Linux and Windows enforce the same chain of trust (they don't have to but otherwise it is not really secure, just like a website can lie to you about encrypted storage) so you need your drivers/OS loaded firmware to be signed as well.

What Android does and what UEFI does are not really related. It is like comparing how SSH does authentication vs how HTTP with TLS does. Former is a SSH-specific open-ended implementation detail, latter is standardized by IETF.

Similarly UEFI standardizes how a motherboard manufacturer can write a compatible firmware and Secure Boot (capital letters) is a sub specification of UEFI. It is not the only secure boot implementation scheme.

With Android device manufacturers have complete control over the early boot firmware and the OS. As long as they boot the OS to run apps, how they do it is up to them. Only things like Google's SafetyNet will put certain requirements on them. No standard like UEFI exists in Android phone world or anywhere else except PCs / Servers.