Ok, so I am not an expert, and I am not the OP. But my understanding is that Secure Boot is checking with a relatively small list of trustworthy signing certificates to make sure that the OS and hardware are what they claim to be on boot. One of those certificates belongs to a Microsoft application called Shim, which can be updated regularly as new stuff comes out. And technically you can whitelist other certificates, too, but I have no idea how you might do that.
The problem is, there’s no real way to get around the reality that you’re trusting Microsoft to not be compromised, to not go evil, to not misuse their ubiquity and position of trust as a way to depress competition, etc. It’s a single point of failure that’s presents a massive and very attractive target to attackers, since it could be used to intentionally do what CrowdStrike did accidentally last week.
And it’s not necessarily proven that it can do what it claims to do, either. In fact, it might be a quixotic and ultimately impossible task to try and prevent boot attacks from UEFI.
To use secure boot correctly, you need disable or delete the keys that come preinstalled and add your own keys. Then you have to sign the kernel and any drivers yourself. It is possible to automate the signing the kernel and kernel modules though. Just make sure the private key is kept secure. If someone else gets a hold of it, they can create code that your computer will trust.
The kernel modules usually are signed with a different key. That key is created at build time and its private key is discarded after the build (and after the modules have been signed) and the kernel uses the public key to validate the modules IIRC. That is how Archlinux enables can somewhat support Secure Boot without the user needing to sign every kernel module or firmware file (it is also the reason why all the kernel packages aren’t reproducible).
And technically you can whitelist other certificates, too, but I have no idea how you might do that.
When you enter the UEFI somewhere there will be a Secure Boot section, there there is usually a way to either disable Secure Boot or to change it into “Setup Mode”. This “Setup Mode” allows enrolling new keys, I don’t know of any programs on Windows that can do it, but sbctl can do it and the systemd-boot bootloader both can enroll your own custom keys.
Ok, so I am not an expert, and I am not the OP. But my understanding is that Secure Boot is checking with a relatively small list of trustworthy signing certificates to make sure that the OS and hardware are what they claim to be on boot. One of those certificates belongs to a Microsoft application called Shim, which can be updated regularly as new stuff comes out. And technically you can whitelist other certificates, too, but I have no idea how you might do that.
The problem is, there’s no real way to get around the reality that you’re trusting Microsoft to not be compromised, to not go evil, to not misuse their ubiquity and position of trust as a way to depress competition, etc. It’s a single point of failure that’s presents a massive and very attractive target to attackers, since it could be used to intentionally do what CrowdStrike did accidentally last week.
And it’s not necessarily proven that it can do what it claims to do, either. In fact, it might be a quixotic and ultimately impossible task to try and prevent boot attacks from UEFI.
But OP might have other reasons in mind, I dunno.
To use secure boot correctly, you need disable or delete the keys that come preinstalled and add your own keys. Then you have to sign the kernel and any drivers yourself. It is possible to automate the signing the kernel and kernel modules though. Just make sure the private key is kept secure. If someone else gets a hold of it, they can create code that your computer will trust.
The kernel modules usually are signed with a different key. That key is created at build time and its private key is discarded after the build (and after the modules have been signed) and the kernel uses the public key to validate the modules IIRC. That is how Archlinux enables can somewhat support Secure Boot without the user needing to sign every kernel module or firmware file (it is also the reason why all the kernel packages aren’t reproducible).
In any case, not for the average person.
Your want to store a copy of the private key on the encrypted machine so it can automatically sign kernel updates.
When you enter the UEFI somewhere there will be a Secure Boot section, there there is usually a way to either disable Secure Boot or to change it into “Setup Mode”. This “Setup Mode” allows enrolling new keys, I don’t know of any programs on Windows that can do it, but
sbctlcan do it and thesystemd-bootbootloader both can enroll your own custom keys.Definitely not for the “normie” then.