Mathieu Trudel-Lapierre
on 11 August 2017
Secure Boot signing
The whole concept of Secure Boot requires that there exists a trust chain, from the very first thing loaded by the hardware (the firmware code), all the way through to the last things loaded by the operating system as part of the kernel: the modules. In other words, not just the firmware and bootloader require signatures, the kernel and modules too. People don’t generally change firmware or bootloader all that much, but what of rebuilding a kernel or adding extra modules provided by hardware manufacturers?
The Secure Boot story in Ubuntu includes the fact that you might want to build your own kernel (but we do hope you can just use the generic kernel we ship in the archive), and that you may install your own kernel modules. This means signing UEFI binaries and the kernel modules, which can be done with its own set of tools.
But first, more on the trust chain used for Secure Boot.
Certificates in shim
To begin with signing things for UEFI Secure Boot, you need to create a X509 certificate that can be imported in firmware; either directly though the manufacturer firmware, or more easily, by way of shim.
Creating a certificate for use in UEFI Secure Boot is relatively simple. openssl can do it by running a few SSL commands. Now, we needs to create a SSL certificate for module signing…
First, let’s create some config to let openssl know what we want to create (let’s call it ‘openssl.cnf’):
# This definition stops the following lines choking if HOME isn't # defined. HOME = . RANDFILE = $ENV::HOME/.rnd [ req ] distinguished_name = req_distinguished_name x509_extensions = v3 string_mask = utf8only prompt = no [ req_distinguished_name ] countryName = CA stateOrProvinceName = Quebec localityName = Montreal 0.organizationName = cyphermox commonName = Secure Boot Signing emailAddress = example@example.com [ v3 ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical,CA:FALSE extendedKeyUsage = codeSigning,1.3.6.1.4.1.311.10.3.6,1.3.6.1.4.1.2312.16.1.2 nsComment = "OpenSSL Generated Certificate"
Either update the values under “[ req_distinguished_name ]” or get rid of that section altogether (along with the “distinguished_name” field) and remove the “prompt” field. Then openssl would ask you for the values you want to set for the certificate identification.
The identification itself does not matter much, but some of the later values are important: for example, we do want to make sure “1.3.6.1.4.1.2312.16.1.2” is included in extendedKeyUsage, and it is that OID that will tell shim this is meant to be a module signing certificate.
Then, we can start the fun part: creating the private and public keys.
openssl req -config ./openssl.cnf \
-new -x509 -newkey rsa:2048 \
-nodes -days 36500 -outform DER \
-keyout "MOK.priv" \
-out "MOK.der"
This command will create both the private and public part of the certificate to sign things. You need both files to sign; and just the public part (MOK.der) to enroll the key in shim.
Enrolling the key
Now, let’s enroll that key we just created in shim. That makes it so it will be accepted as a valid signing key for any module the kernel wants to load, as well as a valid key should you want to build your own bootloader or kernels (provided that you don’t include that ‘1.3.6.1.4.1.2312.16.1.2’ OID discussed earlier).
To enroll a key, use the mokutil command:
sudo mokutil --import MOK.der
Follow the prompts to enter a password that will be used to make sure you really do want to enroll the key in a minute.
Once this is done, reboot. Just before loading GRUB, shim will show a blue screen (which is actually another piece of the shim project called “MokManager”). use that screen to select “Enroll MOK” and follow the menus to finish the enrolling process. You can also look at some of the properties of the key you’re trying to add, just to make sure it’s indeed the right one using “View key”. MokManager will ask you for the password we typed in earlier when running mokutil; and will save the key, and we’ll reboot again.
Let’s sign things
Before we sign, let’s make sure the key we added really is seen by the kernel. To do this, we can go look at /proc/keys:
$ sudo cat /proc/keys 0020f22a I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 0022a089 I------ 2 perm 1f0b0000 0 0 keyring .builtin_trusted_keys: 1 003462c9 I--Q--- 2 perm 3f030000 0 0 keyring _ses: 1 00709f1c I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 00f488cc I--Q--- 2 perm 3f030000 0 0 keyring _ses: 1 [...] 1dcb85e2 I------ 1 perm 1f030000 0 0 asymmetri Build time autogenerated kernel key: eae8fa5ee6c91603c031c81226b2df4b135df7d2: X509.rsa 135df7d2 [] [...]
Just make sure a key exists there with the attributes (commonName, etc.) you entered earlier
To sign kernel modules, we can use the kmodsign command:
kmodsign sha512 MOK.priv MOK.der module.ko module.ko
should be the file name of a kernel module file you want to sign. The signature will be appended to it by kmodsign, but if you would rather keep the signature separate and concatenate it to the module yourself, you can do that too (see ‘kmosign –help’).
You can validate that the module is signed by checking that it includes the string ‘~Module signature appended~’:
$ hexdump -Cv module.ko | tail -n 5 00002c20 10 14 08 cd eb 67 a8 3d ac 82 e1 1d 46 b5 5c 91 |.....g.=....F.\.| 00002c30 9c cb 47 f7 c9 77 00 00 02 00 00 00 00 00 00 00 |..G..w..........| 00002c40 02 9e 7e 4d 6f 64 75 6c 65 20 73 69 67 6e 61 74 |..~Module signat| 00002c50 75 72 65 20 61 70 70 65 6e 64 65 64 7e 0a |ure appended~.| 00002c5e
You can also use hexdump this way to check that the signing key is the one you created.
What about kernels and bootloaders?
To sign a custom kernel or any other EFI binary you want to have loaded by shim, you’ll need to use a different command: sbsign. Unfortunately, we’ll need the certificate in a different format in this case.
Let’s convert the certificate we created earlier into PEM:
openssl x509 -in MOK.der -inform DER -outform PEM -out MOK.pem
Now, we can use this to sign our EFI binary:
sbsign --key MOK.priv --cert MOK.pem my_binary.efi --output my_binary.efi.signed
As long as the signing key is enrolled in shim and does not contain the OID from earlier (since that limits the use of the key to kernel module signing), the binary should be loaded just fine by shim.
Doing signatures outside shim
If you don’t want to use shim to handle keys (but I do recommend that you do use it), you will need to create different certificates; one of which being the PK (Platform Key) for the system, which you can enroll in firmware directly via KeyTool or some firmware tool provided with your system. I will not elaborate the steps to enroll the keys in firmware as it tends to vary from system to system, but the main idea is to put the system in Secure Boot “Setup Mode”; run KeyTool (which is its own EFI binary you can build yourself and run), and enroll the keys — first by installing the KEK and DB keys, and finishing with the PK. These files need to be available from some FAT partition.
I do have this script to generate the right certificates and files; which I can share (and itself is copied from somewhere, I can’t remember):
#!/bin/bash
echo -n "Enter a Common Name to embed in the keys: "
read NAME
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME PK/" -keyout PK.key \
-out PK.crt -days 3650 -nodes -sha256
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME KEK/" -keyout KEK.key \
-out KEK.crt -days 3650 -nodes -sha256
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME DB/" -keyout DB.key \
-out DB.crt -days 3650 -nodes -sha256
openssl x509 -in PK.crt -out PK.cer -outform DER
openssl x509 -in KEK.crt -out KEK.cer -outform DER
openssl x509 -in DB.crt -out DB.cer -outform DER
GUID=`python -c 'import uuid; print str(uuid.uuid1())'`
echo $GUID > myGUID.txt
cert-to-efi-sig-list -g $GUID PK.crt PK.esl
cert-to-efi-sig-list -g $GUID KEK.crt KEK.esl
cert-to-efi-sig-list -g $GUID DB.crt DB.esl
rm -f noPK.esl
touch noPK.esl
sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \
-k PK.key -c PK.crt PK PK.esl PK.auth
sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \
-k PK.key -c PK.crt PK noPK.esl noPK.auth
chmod 0600 *.key
echo ""
echo ""
echo "For use with KeyTool, copy the *.auth and *.esl files to a FAT USB"
echo "flash drive or to your EFI System Partition (ESP)."
echo "For use with most UEFIs' built-in key managers, copy the *.cer files."
echo ""
The same logic as earlier applies: sign things using sbsign or kmodsign as required (use the .crt files with sbsign, and .cer files with kmodsign); and as long as the keys are properly enrolled in the firmware or in shim, they will be successfully loaded.
What’s coming up for Secure Boot in Ubuntu
Signing things is complex — you need to create SSL certificates, enroll them in firmware or shim… You need to have a fair amount of prior knowledge of how Secure Boot works, and that the commands to use are. It’s rather obvious that this isn’t at the reach of everybody, and somewhat bad experience in the first place. For that reason, we’re working on making the key creation, enrollment and signatures easier when installing DKMS modules.
update-secureboot-policy should soon let you generate and enroll a key; and DKMS will be able to sign things by itself using that key.
This article was originally posted on Mathieu Trudel-Lapierre’s blog
