UEFI Secure boot with custom keys

novist · 2014-12-14 16:07:11

I nearly won this fight already but when its all done something is broken.

Custom keys generated
installed in efi firmware
kernel signed
boot entries added

And signature verification fails. I need some help.

My approach is based on self-signed bootable efi kernel how-to from Greg.

So this is what i have done:
1. Boot into efi setup and clear secure boot keys. This is mandatory step!
2. This script creates PK, KEK and db keys and installs them. Installation will fail if old keys are present in firmware.

#!/bin/bash

rm KEK.*
rm PK.*
rm noPK.*
rm db.*

# create a PK key
openssl req -new -x509 -newkey rsa:4096 -subj "/CN=PK/" -keyout PK.key -out PK.crt -days 3650 -nodes -sha256
cert-to-efi-sig-list -g `uuidgen` PK.crt PK.esl
sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth
> noPK.esl
sign-efi-sig-list -k PK.key -c PK.crt PK noPK.esl noPK.auth

# create a KEK key
openssl req -new -x509 -newkey rsa:4096 -subj "/CN=KEK/" -keyout KEK.key -out KEK.crt -days 3650 -nodes -sha256
cert-to-efi-sig-list -g `uuidgen` KEK.crt KEK.esl
sign-efi-sig-list -k KEK.key -c KEK.crt KEK KEK.esl KEK.auth

# create a db key
openssl req -new -x509 -newkey rsa:4096 -subj "/CN=db/" -keyout db.key -out db.crt -days 3650 -nodes -sha256
cert-to-efi-sig-list -g `uuidgen` db.crt db.esl
sign-efi-sig-list -k db.key -c db.crt db db.esl db.auth


sudo efi-updatevar -f KEK.auth KEK
sudo efi-updatevar -f db.auth db
sudo efi-updatevar -f PK.auth PK

3. Signed kernel:

sudo sbsign --key PK.key --cert PK.crt --output /boot/vmlinuz-3.15.0.signed /boot/vmlinuz-3.15.0
rm /boot/vmlinuz-3.15.0
mv /boot/vmlinuz-3.15.0.signed /boot/vmlinuz-3.15.0

4. Added boot entries to efi:

#!/bin/bash
version=3.15.0
sudo efibootmgr -d /dev/sda -c -L "Kernel" -l "\vmlinuz-$version" -u "initrd=initrd.img-$version root=/dev/mapper/os-root ro quiet splash nomodeset"
sudo efibootmgr -d /dev/sda -c -L "Kernel (Recovery)" -l "\vmlinuz-$version" -u "initrd=initrd.img-$version root=/dev/mapper/os-root ro recovery nomodeset"

5. Verified signature:

sbverify --cert PK.crt /boot/vmlinuz-3.15.0 
Signature verification OK

Now i can reboot machine and boot directly into kernel if secure boot is disabled. No bootloader needed. But if i turn secure boot on kernel image is rejected because signature verification fails. WHYYYY??? :\

Does anyone know how i could maybe verify kernel image against installed keys? They seem to be available at /sys/firmware/efi/(efi)?vars. Not sure what else could i try..

P.S. CPU: AMD FX-8350, Motherboard: Asus Sabertooth FX990 R2.0. If it matters..

TheSaint · 2014-12-14 19:25:01

Did you read this ?

novist · 2014-12-14 19:58:10

No that slipped past me. Although it looks like pretty much what i have done except for inserting keys which i did from within OS. I am pretty sure inserting keys worked because if keys were present in firmware i could not insert new ones so i had to reboot and clear them. I could see no keys in firmware then and after booting into OS, generating new keys and inserting them (and sigbig kernel with new key ofc) i could see keys being again present in firmware. So that worked.

TheSaint · 2014-12-15 05:45:23

I can't get you clear. Does it work now?

novist · 2014-12-15 12:49:43

No. What i was trying to say that only difference between what i did and what that page instructs was procedure of adding keys to firmware. Though my procedure adds keys too because i can see firmware saying keys loaded while before adding keys it was saying that keys are not loaded. not sure if i messed up with keys or what.

olive · 2014-12-15 13:44:12

This replies is a little off topic, but I fail to understand the real purpose of all of this. If you sign an Archlinux kernel and enable secure boot, you will still be able to kexec an unsigned kernel with it (or load evil modules). So you end up in a system that have the same security as a system without secure boot: an evil malware could choose to start whatever kernel it wants by kexec-ing it from the signed Archlinux kernel. Simple tricks such as recompiling the kernel without kexec won't really change anything since a custom evil module can still be loaded. Simply disabling secure boot is much easier than all of this for the same security.

Moreover I really have to think hard to find a situation where this secure boot really increase security.

Last edited by olive (2014-12-15 13:51:41)

Head_on_a_Stick · 2014-12-15 14:35:28

FWIW I have tried the method linked by @TheSaint and successfully generated a signed kernel image with my own keys and loaded those keys to my motherboard's firmware and it still wouldn't boot the signed image.

I gave up and attributed this to my crappy firmware (it does not retain NVRAM entries consistently).

TheSaint · 2014-12-15 15:50:07

@novist
There's a little quirk on point 4 (Added boot entries to efi), usually is rw mode. But I suppose you're not getting there yet.
One more point is that you should care about your initcpio like

$ zgrep CONFIG_INITRAMFS_SOURCE /proc/config.gz

That's also mention in that blog you posted above. And probably also the modules should be signed too.
One more question, why did you increase rsa to 4096 ?
The blog and my link use only 2048 words encryption.

Arch Linux

#1 2014-12-14 16:07:11

UEFI Secure boot with custom keys

#2 2014-12-14 19:25:01

Re: UEFI Secure boot with custom keys

#3 2014-12-14 19:58:10

Re: UEFI Secure boot with custom keys

#4 2014-12-15 05:45:23

Re: UEFI Secure boot with custom keys

#5 2014-12-15 12:49:43

Re: UEFI Secure boot with custom keys

#6 2014-12-15 13:44:12

Re: UEFI Secure boot with custom keys

#7 2014-12-15 14:35:28

Re: UEFI Secure boot with custom keys

#8 2014-12-15 15:50:07

Re: UEFI Secure boot with custom keys

Board footer