Dual System Secure Boot (Gentoo+Windows), shim vs non shim

[nxe9]

Hi, I am considering secure boot on a dual system (gentoo + win11). I have read few articles and I want to make sure I understand the difference between shim and non shim secure boot in terms of security specifically with reference to one example.

Let’s assume we have a malware on our system which interfered with our boot binary. Let's assume that our private keys are well secured and the malicious actor has no access to them. In the case of non shim, for the system to boot the malware would have to modify the uefi db data. In turn, to do this, you would need a private key PK/KEK (which is not available) or resetting the PK (setup mode) and uploading your own, which would require running UEFI, i.e. physical access to the computer. In this case, the malware would not harm us regarding the boot process.

In the case of shim, the MOK list is modified. Since the MOK list is not stored in UEFI memory, malware could modify not only our boot binary, but also the MOK list without having physical access to the computer, which would make it possible to start the system with replaced boot components. As a result, the safety associated with shim is lower than non shim.

So what are the benefits of shim? From what I understand, there is no need to backup old, delete old and generate new keys and create a compound (old+new) because the shim is signed with a Microsoft certificate. However, we do this at the expense of security, because we transfer some public keys to the operating system level.

Is everything I wrote correct?

[GDH-gentoo]

[nxe9]

OK, but there is still, in my opinion, a key difference. The MOK list can be reset and overwritten from the system level without knowing the private key. According to https://wiki.gentoo.org/wiki/Shim

[GDH-gentoo]

It is mentioned in only one sentence in that Wiki article, but the MokManager does a password verification for that step. There is a procedure for setting up the password for importing a new MOK that I don't see described in the article.
_________________

[sMueggli]

Secure Boot is based on a chain of trust. The root of this trust is the PK (platform key). The PK is usually set by the OEM or mainboard vendor. Where this chain of trust ends depends on the distribution. Normally the chain of trust ends with the signed kernel modules (but might end with shim).

The next step is the KEK (key exchange keys). The KEKs are signed with the PK.
At least one of the KEK is a Microsoft public key which is used to verify the signature of the Microsoft UEFI binaries and also to verify the signature of shim. Usually shim loads then Grub and is normally checking whether Grub is signed with a distribution specific key.

PK and KEK are public keys or certificates (not sure, but I guess they are certificates, not just public keys). They do not contain any private or secret stuff. Then there are at least two lists: db and dbx. The list of known certificates and the list of forbidden certificates (comparable with a CRL in a PKI).

You can replace every bit of this chain of trust, without knowing the private key. But usually this is only possible with physical access to the system. If the MOK list is part of the chain of trust, then the list must be signed with one of the "trustworthy" keys.

In an ideal world, the private keys are not stored (and were not created) on the system that is protected by Secure Boot.

[nxe9]

@GDH-gentoo: In my opinion, this does not change anything, because in fact, to add the signed modules to the MOK list I need to have a private key, but I can clear such MOK list from the system level (just as I can clear the PK and the entire trust chain from the UEFI level). Unless I'm still not understanding something.

@sMueggli: I more or less understand it the way you wrote it. What I meant was that in the case of a shim digitally signed by Microsoft I have two chains of trust. The first one from PK to shim, and the second one after shim. In my opinion, such a chain of trust is easier to break and can be broken from the operating system level. In the case of one continuous chain from PK to kernel modules I am not able to do this.