How to Secure Boot EFI images signed with an installed custom key?

Question

I've been trying to configure UEFI Secure Boot to use my own keys for a dual boot (Windows 10 + Linux) system.

This system is a Dell XPS 8700 (circa 2015) with an American Megatrends firmware/BIOS, plus a few standard hardware upgrades.

I've been following guides such as:

https://linuskarlsson.se/blog/secure-boot-when-dual-booting-arch-linux-and-windows/

...and:

https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot_under_OpenRC

...and, of course:

http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html

The first two apply to my situation better, because I wish to keep the Microsoft signatures installed, but Rod Smith's site is a wealth of information.

In short, my problem is that after installing my keys, images that I sign fail to boot. The result is a red, curses-style box with the text:

Secure Boot Violation

Invalid signature detected. Check Secure Boot Policy in Setup

I've made several attempts at this, using the various commands and arguments from the mentioned sites. As well as the different tools to install the keys, such as KeyTool, efi-updatevar, and my BIOS's key management interface. The result is always same, failure to boot an image signed with my keys.

Here's an example of the Secure Boot variables after (what I believe is) a successful installation:

# efi-readvar
Variable PK, length 831
PK: List 0, type X509
    Signature 0, size 803, owner 7c782a70-901d-454c-a708-4cfb0f432718
        Subject:
            CN=My Secure PK
        Issuer:
            CN=My Secure PK
Variable KEK, length 2393
KEK: List 0, type X509
    Signature 0, size 1532, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Subject:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011
        Issuer:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
KEK: List 1, type X509
    Signature 0, size 805, owner 7c782a70-901d-454c-a708-4cfb0f432718
        Subject:
            CN=My Secure KEK
        Issuer:
            CN=My Secure KEK
Variable db, length 3974
db: List 0, type X509
    Signature 0, size 1515, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Subject:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011
        Issuer:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010
db: List 1, type X509
    Signature 0, size 1572, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Subject:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
        Issuer:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
db: List 2, type X509
    Signature 0, size 803, owner 7c782a70-901d-454c-a708-4cfb0f432718
        Subject:
            CN=My Secure db
        Issuer:
            CN=My Secure db
Variable dbx, length 652
dbx: List 0, type SHA256
    Signature 0, size 48, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Hash:80b4d96931bf0d02fd91a61e19d14f1da452e66db2408ca8604d411f92659f0a
    [...]
    Signature 12, size 48, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Hash:90fbe70e69d633408d3e170c6832dbb2d209e0272527dfb63d49d29572a6f44c
Variable MokList has no entries

I have verified that this configuration persists, and that this successfully boots Windows with Secure Boot enabled.

I've also done some other testing and verification... For instance, if I don't install Microsoft's keys, I can't boot Windows with Secure Boot enabled. Interestingly enough, Windows Boot Manager will be absent from the boot menu, yet my "invalid" choices (KeyTool, Grub) are still present. If I disable Secure Boot, Windows Boot Manager is again available.

So based on this behavior, the current configuration (efi-readvars output above) which Secure Boots Windows successfully, and other things that I've noticed but cannot recall, I think that my Secure Boot variables should be set properly.

All of my trial and error was the motivation for my previous question about removing attached signatures, because I didn't want to keep stacking signatures on images every time I created new keys or (re)signed an image. ...I have tried this several different ways.

Signing the image(s) looks like this:

# sbverify --list /boot/efi/EFI/Grub/grubx64.efi 
No signature table present

...then:

# sbsign --key db.key --cert db.crt              \
         --output /boot/efi/EFI/Grub/grubx64.efi \
         /boot/efi/EFI/Grub/grubx64.efi  
Signing Unsigned original image

...and:

# sbverify --list /boot/efi/EFI/Grub/grubx64.efi  
signature 1
image signature issuers:
 - /CN=My Secure db
image signature certificates:
 - subject: /CN=My Secure db
   issuer:  /CN=My Secure db

...and finally:

# sbverify --cert db.crt /boot/efi/EFI/Grub/grubx64.efi 
Signature verification OK

And yet, no love from Secure Boot.

Answer 1

Possible cause: Older versions of sbsign did not correctly recalculate the PE/COFF header checksum, which causes some firmwares to reject the resulting file. (This was only fixed in v0.9.3.)

Note that Secure Boot uses exactly the same "Authenticode" format for signing .efi files as Windows does for signing .exe files, so you're not required to use sbsign specifically – you can can use alternative tools such as osslsigncode or even the Windows signtool.exe.

osslsigncode sign -cert db.crt -key db.key \
                   -in /boot/efi/EFI/Grub/grubx64.efi \
                   -out /boot/efi/EFI/Grub/grubx64_signed.efi ;

As shown above, be careful to NOT sign in place with osslsigncode. Doing so will fail, and the image will be destroyed:

# osslsigncode -certs db.crt -key db.key -h sha256 \
      -in /boot/efi/EFI/Grub/grubx64.efi \
      -out /boot/efi/EFI/Grub/grubx64.efi
Bus error

# ls -l /boot/efi/EFI/Grub/grubx64.efi
-rw-r--r-- 1 root root 0 Jun 13 14:55 /boot/efi/EFI/Grub/grubx64.efi

Images signed with osslsigncode will still validate with sbverify:

# sbverify --list /boot/efi/EFI/Grub/grubx64_signed.efi 
signature 1
image signature issuers:
 - /CN=My Secure db
image signature certificates:
 - subject: /CN=My Secure db
   issuer:  /CN=My Secure db

# sbverify --cert db.crt /boot/efi/EFI/Grub/grubx64_signed.efi 
Signature verification OK

The original osslsigncode project was abandoned after version 1.7.1, it has been revived and version 2.0 was released in 2018.