Secure Boot custom keys

[NathanZachary]

Hello,

I'm working on getting Secure Boot working with custom keys, but am running into a strange problem and would really appreciate any troubleshooting advice. It's on an Ubuntu system, but I haven't gotten anywhere with their documentation so this is the last bastion of hope.

I have created the PK, KEK, and db keys

I have enroled the keys in the UEFI via `sbkeysync` - no errors reported

I have signed the binaries - no errors reported

I have validated the signed binaries - no errors reported

Yet when I enable Secure Boot (in Custom mode with my keys), the host won't boot. The part that I can't figure out is how everything passes validation, but then results in a boot failure. For instance:

[pietinger]

If your UEFI shall start grub at first ... THEN grub must be signed.

If you sign your kernel, you will need a stub kernel and you must tell UEFI to boot this stub kernel directly (=without grub).

What is the output of "efibootmgr" ?


Maybe you want read: https://wiki.gentoo.org/wiki/EFI_stub

and my approach to do SecureBoot:

https://forums.gentoo.org/viewtopic-p-8492354.html#8492354

[NathanZachary]

Thank you for your reply. Ideally, I would like to keep GRUB instead of using a stub kernel directly with EFI. Interestingly, though, when I enable Secure Boot with only my custom keys (PK, KEK, and db), I don't have any options at all for booting. I'm starting to wonder if something needs to be done regarding the RAID controller itself?
_________________
“Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---

[pietinger]

[szatox]

[NathanZachary]

Looking at these details that you requested, I still can't see anything that is misconfigured:

[pietinger]

If you want to boot your system with SecureBoot there are three main possibilities under Linux:

1. You use the SHIM, which already has a Microsoft signature. To my knowledge Ubuntu uses this way. The SHIM itself then loads the GRUB. Here I can't help you, because this was never an option for me (because then still "foreign" keys are used).

2. You work with MOK (machine owner keys). Here I can't help you, because this was never an option for me (because then still "foreign" keys are used).

3. You do EVERYTHING manually yourself. For this you need your own keys. You have to give these to your UEFI. Since there are motherboards that cause problems when using "efi-updatevar" (or "sbkeysync"), I recommend to take over the keys yourselv in the BIOS (beware you must reboot your machine twice).

As @szatox already wrote correctly, signing a bootloader is not very useful. That is why the UKI (unified kernel image) was "invented".

I don't know Ubuntu and can't help you there. I strongly suspect that re-signing the SHIM will not work (since it already has a Microsoft signature). Maybe this helps you:

https://wiki.ubuntu.com/UEFI/SecureBoot
https://wiki.ubuntu.com/UEFI/SecureBoot/Testing



My installation looks like this:

- Before the switch to SecureBoot -

1. I use "gentoo-sources" and configured my kernel myself.
2. I configured everything I need statically <*> in the kernel and then turned off the module support. With this I have a monolithic kernel. (But this is not a requirement for SecureBoot).
3a. I configured this kernel as a STUB kernel (so it will boot directly).
3b. This also requires configuring the kernel command line parameters INTO the kernel.
4a. One of my boxes does not have an initramfs.
4b. The other box has the initramfs EMBEDDED into the kernel.
I used: https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Initramfs_Overview#Embedded_with_a_file-list
If you have already a CPIO and want embed it, then you can use:
https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Initramfs_Overview#Special_Case:_Building_an_embedded_initramfs_with_a_CPIO_archive
5. UEFI boots directly this (UKI) kernel. For this I created a UEFI entry with "efibootmgr"

[NathanZachary]

Thank you very much for taking the time to look at it with me. I think that the problem somehow revolves around the shim, which I don't even want to use in the first place. Like you, I haven't done this with Ubuntu before, and have never had any problems with using my own Secure Boot keys in Gentoo. I'm going to see if I can find a way to bypass using the signed shim, and just go directly to GRUB. How I understand it is that Ubuntu looks to /boot/efi/EFI/ubuntu/ for all of the related options. It chooses shimx64.efi for Secure Boot, and grubx64.efi when Secure Boot isn't needed. I'm thinking that I may be able to bypass shim, and update the entry to point directly to grubx64.efi. Maybe it would even work with signing shimx64.efi, grubx64.efi, and the kernel. I haven't attempted signing grubx64.efi, but that might be my next step.

Thanks again for taking the time to reply.

Cheers,
Nathan Zachary
_________________
“Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---

[pietinger]

[GDH-gentoo]

[CaptainBlood]

[sMueggli]

What is the goal of this exercise?

Secure Boot is based on a chain of trust. The root of trust is the PK in the firmware. The PK is usually a public key of the mainboard vendor. Then there are several KEKs, which all are signed by the the private key of the PK. Usually the public keys of Microsoft are part of the preinstalled/signed KEKs.

The db and dbx are not keys, but databases of signatures. In db are the authorised signatures and dbx contains the forbidden signatures.

Roughly the Ubuntu boot process is as follows:

The firmware is checking the EFI binary \EFI\ubuntu\shimx64.efi. The binary shimx64.efi was audited by Microsoft and then signed with the private key of the Microsoft certificate. During the boot process, the firmware is checking that the signature of shimx64.efi is not part of dbx, exists in db and the used KEK is signed by the PK.

If this was successful, shimx64.efi is loading grubx64.efi and checking the signature of grubx64.efi. The grubx64.efi EFI binary is signed with a distribution-specific certificate and the public key is part of the shimx64.efi binary. If also Grub is passing the check, it takes over the control. Also Grub is checking the binaries to load (https://www.gnu.org/software/grub/manual/grub/html_node/UEFI-secure-boot-and-shim.html) which are also signed by the distribution-specific certificate.

To be able to load kernel modules that are not signed by the distribution-specific certificate there is a "MOK" (machine owner key). Enrolling this key in the firmware allows you to load kernel modules (e.g. WLAN) signed with the private key of the MOK part.

If you want a "Do-It-Yourself-Secure-Boot" you need to

• setup a working PKI (storing the private keys on the same machine is not a "working" PKI)
  
• setup a signing and auditing process for every piece of software you want to sign
  
• need to learn how to incorporate your certificate into the software (shim_lock and kernel lockdown)
  

A boot process that deserves the name "Secure Boot" involves a lot of work and knowledge. If the chain of trusts ends at Grub (you can disable the validation process in shim) or attackers can easily sign their binaries with your keys you end up with what I call a "Signed Boot" instead of a Secure Boot.

[GDH-gentoo]

[nvaert1986]

You can keep using grub without using a EFI stub kernel by generating a strandalone grub version and signing that compiled EFI binary and the kernel. I use this myself with sbctl. You do need to create an sbat file. This is a CSV file with information required as a standard.

To generate the standalone grub image use the following command: