Where are Canonical's secure boot certificates?

Asked by James Wilson

Where can I find copies of the certificates used by Canonical's secure boot setup? I want to roll my own PK, KEK, and db lists and need the certificates in PEM or DER form.

There appeared to be links on this page (https://wiki.ubuntu.com/UEFI/SecureBoot/KeyManagement/ImageSigning), but they are dead now.

Specifically, I am looking for the two certificates in the following chain on the bootloader:

% sudo sbverify --list /boot/efi/EFI/BOOT/BOOTX64.EFI
signature 1
image signature issuers:
 - /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority
image signature certificates:
 - subject: /C=GB/ST=Isle of Man/O=Canonical Ltd./OU=Secure Boot/CN=Canonical Ltd. Secure Boot Signing (2017)
   issuer: /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority

Question information

Language:
English Edit question
Status:
Answered
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Bernard Stafford (bernard010) said (last edit ):
#1
Revision history for this message
James Wilson (jmwilson) said :
#2

I've read all of them. None of those pages have the actual certs.

The second page contains a link to a git repository (https://git.launchpad.net/qa-regression-testing/tree/notes_testing/secure-boot), which purports to have the certificates. The repository's code signing key (/notes_testing/secure-boot/keys/canonical-signing-public.der in that repo) is outdated, no longer used to sign the bootloader, and will not work when used.

The real certificate has a CN of "Canonical Ltd. Secure Boot Signing (2017)", and the one in that repository has a CN of "Canonical Ltd. Secure Boot Signing".

Revision history for this message
Bernard Stafford (bernard010) said :
#3
Revision history for this message
James Wilson (jmwilson) said :
#4

That also doesn't have them. The ca-certificates packages and /etc/ssl only contain certs for TLS, not secure boot.

Revision history for this message
Manfred Hampl (m-hampl) said :
#5

Are you looking for the keys that are used for creating the signed kernels that are accepted by secure boot?
I cannot imagine that they are publicly available, because that would invalidate the whole concept of secure booting.

see https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html

...
As announced earlier today, we've generated an Ubuntu signing key for
use with UEFI. The private half of this key will be stored securely on
our Launchpad infrastructure, which will be responsible for signing boot
loader images and distributing them in the Ubuntu archive.
...

Revision history for this message
James Wilson (jmwilson) said :
#6

I'm looking for the certificates, the public half of the signing process. Certificates are public so anyone can verify a signature made by the private key. For example, Microsoft makes their secure boot certificates easily available via links on its secure boot help page https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance

Revision history for this message
Bernard Stafford (bernard010) said (last edit ):
#7

Embedded in the shim loader.
How UEFI Secure Boot works on Ubuntu
On Ubuntu, all pre-built binaries intended to be loaded as part of the boot process, with the exception of the initrd image, are signed by Canonical's UEFI certificate, which itself is implicitly trusted by being embedded in the shim loader, itself signed by Microsoft.
https://wiki.ubuntu.com/UEFI/SecureBoot
Secure Boot is proprietary software owned by Microsoft.
Which an agreement to use for canonical software... etc! Fact...
If question is solved press solved.
Quote: "that would invalidate the whole concept of secure booting."
embedded within the shim loader. not human readable to be secure.
https://ubuntu.com/download/server
Ubuntu Jammy Jellyfish Ubuntu 22.04 LTS is in final release: 2022-04-21

Revision history for this message
James Wilson (jmwilson) said :
#8

Ubuntu does it's own signing on the bootloader; see the output of the sbverify in the original question. I need the certificates that correspond to those signatures.

Revision history for this message
Bernard Stafford (bernard010) said (last edit ):
#9

Ubuntu Jammy Jellyfish Ubuntu 22.04 LTS is in final release: 2022-04-21
lsb_release -a; uname -a; python --version

Revision history for this message
James Wilson (jmwilson) said :
#10

That still doesn't help. Maybe a better answer is a who - who on the Ubuntu team works with bootloader signing and can supply the certificates?

Revision history for this message
Manfred Hampl (m-hampl) said :
#11

There is a https://launchpad.net/~canonical-signing team, but I do not know whether they are involved in the area of your question.

Revision history for this message
Bruce Elrick (virtuous-sloth) said :
#12

I could be wrong, but if I'm reading this:
"Since the shim binary embeds a Canonical certificate as well as its own trust database, further elements of the boot environment can, in addition to being signed by one of the acceptable certificates pre-loaded in firmware, be signed by Canonical's UEFI key."

(https://wiki.ubuntu.com/UEFI/SecureBoot) right then the Canonical cert is embedded inside the shim PE32+ executable:

# ls -l /boot/efi/EFI/ubuntu*/shimx64.efi
-rwx------ 1 root root 955656 Apr 9 2022 /boot/efi/EFI/ubuntu-20.04/shimx64.efi
-rwx------ 1 root root 955656 Apr 9 2022 /boot/efi/EFI/ubuntu-22.04/shimx64.efi
-rwx------ 1 root root 960472 Feb 16 12:34 /boot/efi/EFI/ubuntu/shimx64.efi

But a UEFI expert had better weigh in, as I am not one.

Running

objdump -x /boot/efi/EFI/ubuntu-22.04/shimx64.efi

definitely show a lot of sections related to certificates. Unfortunately I don't know of any specialized tools for extracting and inspecting apart from generally knowing you can use objcopy to extract the contents of a section to a separate file.

Revision history for this message
Dimitri John Ledkov (xnox) said :
#13

Using non default (without any Microsoft certs) boot chain is possible, but is not widely supported or encouraged. Doing this will likely prevent application of dbx revocations, and will leave your system vulnerable to attacks using otherwise publically revoked Canonical binaries. Furthermore it will render your system unable to perform automatic firmware, bios, and attached hardware firmware updates (i.e. usb-c dock). It may also cause a lot of hardware to not work due to option Roms being signed with Microsoft keys only.

A better option is to assert the state of the system, and the certs/binaries used on every boot by asserting TPM bios measurements. This can make your system tamper proof, and provide additional measure of confidentially. On Ubuntu, this is done by default on our Ubuntu Core product with TPM backed FDE with measurements of the full boot chain asserted and verified on every boot. Is this what you are trying to achieve?

Please explain in detail what you are trying to achieve.

For running VMs we do provide edk2 builds with default set of certificates enrolled, and this is also used by default in LXD VM. These do use Microsoft KEK & DB keys with uefi.org dbx which ensure that Secureboot works, with ability to rotate keys, apply revocations, and support firmware hardware upgrades.

Revision history for this message
James Wilson (jmwilson) said :
#14

Yes, I am trying to create a secure boot chain without Microsoft's UEFI CA key for 3rd party UEFI executables. In light of confirmation of the BlackLotus UEFI bootkit, I feel this is a reasonable mitigation.

I am fine keeping Microsoft's KEK for the purpose of accepting dbx updates. I understand this will break option ROMs signed by the Microsoft UEFI CA. I can work around by extracting the option ROM hashes from a TPM boot log and adding them to the db myself. I have done this for nVidia option ROMs and it works; for example, I can boot into Windows with an nVidia card and without the MS UEFI CA cert in the db. Option ROMs are so rarely updated that adding hashes are fine, bootloaders on the other hand ... it would be more robust to trust a 1st-party signing certificate.

For Ubuntu, I just need the public certificate that Canonical uses to sign its bootloader. They rotated the key in 2017 and have not made the certificate public. One system is a NUC that does not have a TPM for measurements, so a hardened secure boot setup is the best option.

Revision history for this message
Dimitri John Ledkov (xnox) said :
#15

 To boot Canonical signed artifacts, without Microsoft keys in dB, you will need Canonical Master CA in the db. You can get it by using sbattach --dettach, openssl pkcs7 -inform der -print_certs -in detached signature, x509 to convert from pem to der. Alternatively you can find our master ca certificate in the source code of shim package shipped in Ubuntu. I will not provide links to any of the above, as you should be able to verify in a trusted manner where you are getting these from.

Above will guarantee you can boot any Ubuntu current, past, future shim/grub/kernel.

For shim, you will want to divert .signed and use .dualsigned one instead. Hopefully your firmware accepts it fine. Otherwise use sbattach --dettach to strip Microsoft signature and only keep Canonical Master CA signature.

If you want to limit to booting only the most current signing certs, without any ability to boot past or long into future Ubuntu binaries, you can use sbattach --dettach to only enrol a particular signing certificate - currently various 2021, 2022 certs depending on the product and kernel you use. But these may be rotated in the future, still chained to Canonical Master CA. If enrolling individual signing certs into db, do ensure you verify it against Canonical Master CA that you have securely obtained.

You must sign/enroll the most recent dbx from uefi.org into dbx. It contains revocations of previous boot binaries that were signed by older Canonical certs, all chained to Master CA. Any future revocations from Canonical will be published to uefi.org as well. Updates there are signed by Microsoft KEK keys.

Can you help with this problem?

Provide an answer of your own, or ask James Wilson for more information if necessary.

To post a message you must log in.