Imaging with FOG and Secure Boot (PoC)

[george1421]

In this tutorial we will walk through the process of setting up FOG to utilize the Secure Boot option in the UEFI firmware.

This thread is very much still under construction and not as refined as I would like it. In this state its more of a brain dump than a finished product.

Understand this process is complex, detailed, and is not officially supported by the FOG Project Devs. In the end does it work, so far yes.

Secure booting into any non-microsoft OS is a bit complex. There are basically two ways to go about it.

1. Go through the process to get Microsoft to officially sign your operating system kernel.
2. Create your own signing keys and then sign your own kernel with your keys.

If the FOG project would go with having Microsoft officially sign the FOG kernel that would be the best solution since you would not need to change anything on the target computer other than enabling Secure Booting. The down side to this is that the FOG Project would have to create some kind of subscription service (my opinion) and charge for the secure booting feature. Not only does it cost to have Microsoft sign the FOS linux kernel they will need to hire someone to manage the entire secure boot kernel and boot loader process. To be able to completely image with FOG with secure boot on, we need to have signed bzImage, bzImage32, ipxe.efi, snponly.efi, refind.efi. As you see its not really a simple matter of just having FOS Linux signed. The other thing with having an outside party sign our files is that it will slow down the FOG versioning and upgrade process. The real answer is to somehow have the FOG server to add a digital signature to the files needed for booting. The problem with this approach is that target computer’s firmware needs to hold the same certificate used to sign the files needed for booting to signal that the software that is starting up is valid and known.

I checked a another FOSS imaging solutions (Clonezilla) to see how they managed secure booting linux for imaging. They took an interesting approach and used debian/ubuntu generic kernels that were signed by microsoft. Since Clonezilla is not booting over the network in this case they eliminated the need for needing a network boot loader signed. Everything that is needed for imaging with Clonezilla is on the boot usb drive.

I have to say when I started this project I did not have any idea how secure boot worked and what was needed to make thinks click in order. I still only know enough to be dangerous. Everything I now know came from these articles.
https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki's_EFI_Install_Guide/Configuring_Secure_Boot
https://forums.fogproject.org/post/145434

I’m not going to explain how secure booting works because I really can’t add anything more that the articles above could provide. In the following posts I will go through the step by step process I used to get secure booting working in my test lab. The actual process, while it has many steps, none of the steps are more difficult to execute.

The overall workflow of this tutorial will be to add the capabilities to a ubuntu or debian FOG server (I was able to duplicate the process on a centos/rhel 7 server, but alas, red hat is now dead to me) and create the secure boot PKI infrastructure, create an enrollment boot loader, sign the FOG boot files, and lastly update the certificates on the target hardware with the new FOG secure boot PKI certificates.

[george1421]

Here is the last Easter egg I’ll leave behind here for those that read the entire thread.

Knowing what we know now, we could take advantage of this information with this situation.

Lets say you make a custom point of sale device that has an embedded computer. To save on production costs you want to use off the shelf commodity IA64 based single board computer in a custom case with a touch screen display and 3d barcode reader. The actual capabilities doesn’t matter. But lets say you want to lock this generic IA64 hardware down so that it can only run your custom version of Linux. How do you think we could go about this?

Remember above we created our own custom keys/certificates and tagged them onto the existing microsoft certificates. What do you think would happen if we just uploaded our keys alone and then turned secure boot on? Could someone run MS Windows on this embedded single board computer? No they couldn’t because the uefi firmware will only load operating systems that matched the certificates loaded into the uefi firmware. So all we would need to do is sign our custom linux kernel with our self created certificates. Then the firmware will only boot our linux kernel. No other operating systems would be accepted.

[george1421]

For those that made it this far here is an easter egg.

Here are the one time setup actions.

sudo apt-get update
sudo apt-get upgrade -y 
reboot

# sudo to root user to run the following commands. 
sudo su -

apt-get install -y openssl efitools gnu-efi git build-essential help2man libssl-dev
perl -e'use CPAN; install "File::Slurp"'

mkdir -p /opt/fog/secureboot/efikeys

# Note: If you are running this for the first time, I would execute each command line by 
# line to ensure you are not missing any dependencies. To execute the script manually 
# start copy and pasting line by line starting with the 'NAME=FOGProjectSB' line until the closing
# hastags. 

vi /opt/fog/secureboot/buildkeys.sh
{insert into that file}

####### Insert all text below to stop #######

#!/bin/bash
# Copyright (c) 2015 by Roderick W. Smith
# Updated 26-Nov-2021 by George1421 for the FOG Project
# Licensed under the terms of the GPL v3

NAME=FOGProjectSB

openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME PK/" -keyout efikeys/PK.key \
        -out efikeys/PK.crt -days 3650 -nodes -sha256
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME KEK/" -keyout efikeys/KEK.key \
        -out efikeys/KEK.crt -days 3650 -nodes -sha256
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME DB/" -keyout efikeys/DB.key \
        -out efikeys/DB.crt -days 3650 -nodes -sha256
openssl x509 -in efikeys/PK.crt -out efikeys/PK.cer -outform DER
openssl x509 -in efikeys/KEK.crt -out efikeys/KEK.cer -outform DER
openssl x509 -in efikeys/DB.crt -out efikeys/DB.cer -outform DER

GUID=`python3 -c 'import uuid; print(str(uuid.uuid1()))'`
echo $GUID > efikeys/myGUID.txt

cert-to-efi-sig-list -g $GUID efikeys/PK.crt efikeys/PK.esl
cert-to-efi-sig-list -g $GUID efikeys/KEK.crt efikeys/KEK.esl
cert-to-efi-sig-list -g $GUID efikeys/DB.crt efikeys/DB.esl
rm -f efikeys/noPK.esl
touch efikeys/noPK.esl

sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \
                  -k efikeys/PK.key -c efikeys/PK.crt PK efikeys/PK.esl efikeys/PK.auth
sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \
                  -k efikeys/PK.key -c efikeys/PK.crt PK efikeys/noPK.esl efikeys/noPK.auth
sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \
                  -k efikeys/PK.key -c efikeys/PK.crt KEK efikeys/KEK.esl efikeys/KEK.auth
sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \
                  -k efikeys/KEK.key -c efikeys/KEK.crt db efikeys/DB.esl efikeys/DB.auth

chmod 0600 efikeys/*.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 "but some UEFIs require the *.auth files."
echo ""

cd /opt/fog/secureboot
git clone git://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git

cd /opt/fog/secureboot/efitools
make

mkdir -p /opt/fog/secureboot/hwkeys
#######################################
## Either use the hwkeys from the zip files above or if you have a computer
## That is running in uefi mode with linux install you can run this section to 
# # Extract the needed local keys yourself. You  will need to uncomment these
## lines of code if you want to include it in your script. 
#  cd /opt/fog/secureboot/

#  efi-readvar -v PK -o /opt/fog/secureboot/hwkeys/hw_PK.esl
#  efi-readvar -v KEK -o /opt/fog/secureboot/hwkeys/hw_KEK.esl
#  efi-readvar -v db -o /opt/fog/secureboot/hwkeys/hw_db.esl
#  efi-readvar -v dbx -o /opt/fog/secureboot/hwkeys/hw_dbx.esl 
#  chmod 666 /opt/fog/secureboot/hwkeys/*
#######################################

cp /opt/fog/secureboot/efikeys/* /opt/fog/secureboot/efitools/
cp /opt/fog/secureboot/hwkeys/* /opt/fog/secureboot/efitools/
cd /opt/fog/secureboot/efitools

mv DB.esl DB-fog.esl
mv KEK.esl KEK-fog.esl
mv dbx.esl dbx-fog.esl

cat hw_db.esl DB-fog.esl > DB.esl
cat hw_KEK.esl KEK-fog.esl > KEK.esl
cat hw_dbx.esl > dbx.esl

rm LockDown*efi LockDown.so LockDown.o
make

cp LockDown-signed.efi EnrollKeys.efi

cp /opt/fog/secureboot/efitools/EnrollKeys.efi /tftpboot

mv /var/www/html/fog/service/ipxe/bzImage /var/www/html/fog/service/ipxe/bzImage-unsigned
sbsign --key /opt/fog/secureboot/efikeys/DB.key --cert /opt/fog/secureboot/efikeys/DB.crt --output /var/www/html/fog/service/ipxe/bzImage /var/www/html/fog/service/ipxe/bzImage-unsigned

mv /var/www/html/fog/service/ipxe/bzImage32 /var/www/html/fog/service/ipxe/bzImage32-unsigned
sbsign --key /opt/fog/secureboot/efikeys/DB.key --cert /opt/fog/secureboot/efikeys/DB.crt --output /var/www/html/fog/service/ipxe/bzImage32 /var/www/html/fog/service/ipxe/bzImage32-unsigned

mv /var/www/html/fog/service/ipxe/refind.efi /var/www/html/fog/service/ipxe/refind-unsigned.efi
sbsign --key /opt/fog/secureboot/efikeys/DB.key --cert /opt/fog/secureboot/efikeys/DB.crt --output /var/www/html/fog/service/ipxe/refind.efi /var/www/html/fog/service/ipxe/refind-unsigned.efi


mv /tftpboot/ipxe.efi /tftpboot/ipxe-unsigned.efi
sbsign --key /opt/fog/secureboot/efikeys/DB.key --cert /opt/fog/secureboot/efikeys/DB.crt --output /tftpboot/ipxe.efi /tftpboot/ipxe-unsigned.efi

mv /tftpboot/snponly.efi /tftpboot/snponly-unsigned.efi
sbsign --key /opt/fog/secureboot/efikeys/DB.key --cert /opt/fog/secureboot/efikeys/DB.crt --output /tftpboot/snponly.efi /tftpboot/snponly-unsigned.efi


####### Insert all text STOP #######
Save the contents and exit the editor

chmod a+x /opt/fog/secureboot/buildkeys.sh
cd /opt/fog/secureboot/
./buildkeys.sh

From here you will need to create the EnrollKeys iPXE menu.
Finished with the one time setup actions

Here are the reoccurring actions for a normal intake of a new computer into the FOG Secure boot environment.

1. Enter into the firmware uefi setup.
   1.1 (if you have a Dell) set the disk controller mode to AHCI from Raid-On mode
   1.2 Enable pxe booting in uefi mode
   1.3 Turn off Secure Boot
   1.4 Enter into Secure Boot setup or custom mode
   1.5 Remove the existing Secure Boot certificates
   1.6 Save the firmware settings
   1.7 Reboot
2. PXE boot into FOG (remember we have iPXE signed, but since secure boot is disabled the signature will be ignored)
3. On the FOG iPXE menu select the “FOG Secure Boot Enrollment” menu
   3.1 The EnrollKeys boot loader will apply the certificates and then reboot
4. Enter into the firmware uefi setup
   4.1 Take the secure boot out of setup mode (if that is an option). For custom settings you leave these enabled. On the Dells if you take the firmware out of custom mode the original Dell signed keys will be restored.
   4.2 Turn on Secure Boot if the EnrollKeys did not do that for you
   4.3 Save the firmware settings and reboot
5. PXE boot into FOG (remember this time Secure Boot is enabled. If you get to the iPXE menu then you have SUCCESS!!!)
6. Register the target computer with FOG as you would normal
7. Continue on with your normal FOG imaging tasks.

I know the one time process does add a lot of overhead, but that IS only one time. The reoccurring process does add a few more steps on the intake of a new computer into FOG, but that is only one time. You won’t need to reenroll into this environment until M$ replaces their keys that expire in 2026.

[george1421]

Certificate enrollment

FOG Server setup
In this step we need to create a custom FOG iPXE menu that calls our custom signed efi boot loader (EnrollKeys.efi). This EnrollKeys.efi will apply DB.esl, KEK.esl, and the certificate black list dbx.esl to the uefi firmware. Then finally the EnrollKeys.efi boot loader will lock the certificates in place by applying the PK.esl certificate (again not the right word to call it). Above I mentioned this command which extracted the hw_PK.esl certificate.

sudo efi-readvar -v PK -o /opt/fog/secureboot/hwkeys/hw_PK.esl

I unloaded the esl file back to a certificate that that hw_PK.crt file was a Dell platform signing public key certificate. So the secure boot certificates that were shipped with my Dell Precision 3620 was signed by the platform builder (Dell) with its signing key. The contents of hw_DB.esl and hw_KEK.esl contained the Microsoft public key certificates. One interesting note is that these Microsoft secure boot public keys expire in 2026. Suddenly visions of Y2K just flashed in my head. Every computer that has secure boot enabled will need to have these built in certificates updated before secure boot fails in 2026 when the microsoft secure boot certificates expire. The big question is how will these certificates be released/updated? Via Window 11? Remember Windows 10 dies in 2025. What about the hardware not capable of running windows 11? Or though a firmware update? Is dell going to update the firmware on 10 year old hardware just to update the certificate store in the uefi firmware? On a final cheery note, when this update to the microsoft signing certificates happen, that process will invalidate everything we are taking about in this thread. At that time the FOG admin will need to repeat this thread and extract the current (updated) certificates with the new M$ expiry date and then tack on the FOG Project signing certificate. While we are talking about certificates here, I didn’t mention the FOG Project certificates we built here have a 10 year life span too. It shouldn’t be a concern because the M$ certificates will expire first, but just something that should be documented.

On a small sidebar here: DB.esl, KEK.esl, and dbx-fog.esl are signed by the PK certificate as well as the PK.esl file. DB.esl, KEK.esl, and dbx.esl are uploaded to the UEFI firmware first then the PK.esl file is uploading locking changes to the certificates. The UEFI firmware uses this digital signing to be sure that no one has tampered with the DB, KEK and dbx files. If someone happened to tweak the files the UEFI firmware would detect the change and fail to boot. To be able to change these keys with EnrollKeys.efi the FOG Admin will need to go into each computer’s uefi firmware and either erase the current keys or put the uefi firmware in custom or setup mode where the computer will accept these new certificates. The EnrollKeys.efi will warn you if you don’t have the computer in secure boot setup mode if you fail to do this step. More on that in a bit.

For the FOG server lets create a new iPXE menu. Lets start out by logging into the FOG Web UI and going to FOG Configuration->iPXE New Menu Entry.

Fill in the following:
Menu Item: fog.keyenroll
Description: FOG Secure Boot Enrollment
Parameters:
chain tftp://${fog-ip}/EnrollKeys.efi
echo Rebooting the system in 8 seconds
sleep 5
reboot
Menu Show with: All Hosts

Your completed FOG menu should look like this:

If everything looks good hit the Save Changes button. This completes the setup of the FOG server’s iPXE menu.

The last steps will need to be repeated on each computer you want to secure boot using the FOG server.

I do have to admit that these steps will vary based on the computer manufacturer, but the over all workflow here will be to go into the target computer’s firmware and the secure boot menus. Somewhere there should be a menu to put the firmware into secure boot update, custom, or configuration mode. On some hardware you may have to erase the current secure boot keys, set the firmware to secure boot off and then
I’ve confirmed that from 2013 til 2020 models of Dell enterprise computers almost all of them have this style of menu to updating/changing secure boot keys. The 2021 models with that new/fancy uefi firmware have a slightly different menu structure, but the option is still there.

1. Select the Expert Key Management menu
2. Enable Custom Mode
3. Delete the existing keys from the uefi firmware. This needs to be done to remove the PK certificate that locks changes to the other keys in the uefi firmware. Once the PK certificate is blank you can remove all of the other certificates. This button does everything for you.

Understand this is not a one way street, you wipe the keys and then something happens when you enroll the fog project keys and it fails…, the system is not dead or unusable for windows. All you need to do to reset everything back to “factory” is to reset the existing keys again then press the button with the blue box around it to Reset All Keys back to factory.

Back on the workflow, once the keys (certificates) have been reset, just save the firmware setting and pxe boot the target computer again. This time on the fog iPXE menu pick “FOG Secure Boot Enrollment” menu item. This will launch the enrollment efi program that will quickly update the certificates then reboot the computer. I would go into the uefi firmware again and confirm that secure boot was enabled by the “FOG Secure Boot Enrollment” menu. If it was not enabled, enable secure boot now. Save the uefi settings and reboot. This time pxe boot into the FOG iPXE menu. If you get into the iPXE menu then you have success. Remember we moved the signed ipxe.efi program into the tftp boot directory. Since it was signed with the FOG Project key and we just uploaded our certificate into the uefi firmware we have SUCCESS!!

[george1421]

A (digital) Signing we shall go…

The complete FOG imaging process includes pxe booting into the iPXE boot loader (ipxe.efi or snponly.efi) and then from iPXE we boot the FOS Linux kernel (bzImage) -OR- if we exit from the iPXE menu and boot from disk (in uefi mode) we will chain load into refind.efi. All of these files need to be signed with our custom FOG certificate. If we do not sign these files, they will not boot when secure boot is enabled.

Now that we have all of the required files we can sign each of the above boot files in place.

mv /var/www/html/fog/service/ipxe/bzImage /var/www/html/fog/service/ipxe/bzImage-unsigned
sbsign --key /opt/fog/secureboot/efikeys/DB.key --cert /opt/fog/secureboot/efikeys/DB.crt --output /var/www/html/fog/service/ipxe/bzImage /var/www/html/fog/service/ipxe/bzImage-unsigned

mv /var/www/html/fog/service/ipxe/bzImage32 /var/www/html/fog/service/ipxe/bzImage32-unsigned
sbsign --key /opt/fog/secureboot/efikeys/DB.key --cert /opt/fog/secureboot/efikeys/DB.crt --output /var/www/html/fog/service/ipxe/bzImage32 /var/www/html/fog/service/ipxe/bzImage32-unsigned

mv /var/www/html/fog/service/ipxe/refind.efi /var/www/html/fog/service/ipxe/refind-unsigned.efi
sbsign --key /opt/fog/secureboot/efikeys/DB.key --cert /opt/fog/secureboot/efikeys/DB.crt --output /var/www/html/fog/service/ipxe/refind.efi /var/www/html/fog/service/ipxe/refind-unsigned.efi


mv /tftpboot/ipxe.efi /tftpboot/ipxe-unsigned.efi
sbsign --key /opt/fog/secureboot/efikeys/DB.key --cert /opt/fog/secureboot/efikeys/DB.crt --output /tftpboot/ipxe.efi /tftpboot/ipxe-unsigned.efi

mv /tftpboot/snponly.efi /tftpboot/snponly-unsigned.efi
sbsign --key /opt/fog/secureboot/efikeys/DB.key --cert /opt/fog/secureboot/efikeys/DB.crt --output /tftpboot/snponly.efi /tftpboot/snponly-unsigned.efi

I do have to say this signing section needs a bit more work really if this wasn’t just a proof of concept tutorial. If you think about the realities of the FOG admin workflow, if you were to update the FOS Linux kernel using the web gui, the web gui would faithfully replaced our signed bzImage with the latest (unsigned)bzImage from the FOG Project kernel site. This will effectively bork secure booting. Updating the version of FOG will also blow up secure booting because all of the ipxe as well as kernel files will be updated in one shot. Also if the FOG Admin needed to rebuild the iPXE boot loaders, all of the ipxe efi files will be overwritten loosing the signing. If we went the other route with leaving ipxe.efi unsigned and then signing ipxe-signed.efi file the FOG Admin would need to update dhcp options 67 to ensure ipxe-signed.efi was called instead of the unsigned ipxe.efi file. Lastly the above script does not take in account if bzImage is already signed when it moves the original file and then recreates a signed version of the original file. The bash script needs heavy logic here to first test if the file we are going to sign is already signed before renaming it and signing it.

At this point if you have a signed file like ipxe.efi or bzImage. These files will run perfectly if secure boot is either turned on or off. If secure boot is turned off the signature is simply ignored.

[george1421]

Preparing the FOG server with the prerequisites

sudo apt-get update
sudo apt-get upgrade -y 

Reboot the FOG server and then install the required packages

sudo apt-get install -y openssl efitools gnu-efi git build-essential help2man libssl-dev

sudo perl -e'use CPAN; install "File::Slurp"'

Create the Secure Boot PKI infrastructure

Lets create the working directories

mkdir -p /opt/fog/secureboot/efikeys

Now lets create our bash file to create the PKI infrastructure

vi /opt/fog/secureboot/mkkeys.sh

Insert the following text into that bash script.

#!/bin/bash
# Copyright (c) 2015 by Roderick W. Smith
# Updated 26-Nov-2021 by George1421 for the FOG Project
# Licensed under the terms of the GPL v3

NAME=FOGProjectSB

openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME PK/" -keyout efikeys/PK.key \
        -out efikeys/PK.crt -days 3650 -nodes -sha256
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME KEK/" -keyout efikeys/KEK.key \
        -out efikeys/KEK.crt -days 3650 -nodes -sha256
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME DB/" -keyout efikeys/DB.key \
        -out efikeys/DB.crt -days 3650 -nodes -sha256
openssl x509 -in efikeys/PK.crt -out efikeys/PK.cer -outform DER
openssl x509 -in efikeys/KEK.crt -out efikeys/KEK.cer -outform DER
openssl x509 -in efikeys/DB.crt -out efikeys/DB.cer -outform DER

GUID=`python3 -c 'import uuid; print(str(uuid.uuid1()))'`
echo $GUID > efikeys/myGUID.txt

cert-to-efi-sig-list -g $GUID efikeys/PK.crt efikeys/PK.esl
cert-to-efi-sig-list -g $GUID efikeys/KEK.crt efikeys/KEK.esl
cert-to-efi-sig-list -g $GUID efikeys/DB.crt efikeys/DB.esl
rm -f efikeys/noPK.esl
touch efikeys/noPK.esl

sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \
                  -k efikeys/PK.key -c efikeys/PK.crt PK efikeys/PK.esl efikeys/PK.auth
sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \
                  -k efikeys/PK.key -c efikeys/PK.crt PK efikeys/noPK.esl efikeys/noPK.auth
sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \
                  -k efikeys/PK.key -c efikeys/PK.crt KEK efikeys/KEK.esl efikeys/KEK.auth
sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \
                  -k efikeys/KEK.key -c efikeys/KEK.crt db efikeys/DB.esl efikeys/DB.auth

chmod 0600 efikeys/*.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 "but some UEFIs require the *.auth files."
echo ""

Make the script we just created executable
Change into the secureboot directory and finally run the bash script.

chmod a+x /opt/fog/secureboot/mkkeys.sh
cd /opt/fog/secureboot/
./mkkeys.sh

I will tell you that when you run the mkkeys.sh you may get run time errors. You will need to research on your own what is missing and add that to your fog server using the apt-get package tool. I developed this process and a linux mint server and the duplicated it on a debian 10 fog server. I think I have all of the packages above that is needed. But YMMV.

Create the Secure Boot signed enrollment boot loader

Lets get the efitools package so we can built the enrollment bootloaders

git clone git://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git

Change into the efitools directory and run make to build the templates.

cd /opt/fog/secureboot/efitools
make

I will tell you that when you run the make commandyou may get run time errors. You will need to research on your own what is missing and add that to your fog server’s environment using the apt-get package tool. I developed this process and a linux mint server and the duplicated it on a debian 10 fog server. I think I have all of the packages above that is needed. But YMMV.

Now that we have the templates created we need to download the current secure boot key chains that are created by the hardware manufacture. My plan is to take the original certificate database, tack on the FOG certificates onto the end and then upload the combined certificates back to the target hardware. So for completeness I’ll show you how I downloaded the original certificates. To save you some time, I’ll include these files in a zip file a bit later in this post.

For this bit one of my dev fog servers runs on real hardware. I used these commands under debian to extract these generic certificates from the target computer’s bios. The computer I extracted them from was a Dell Precision 3620. So these certificates and certificate store is fairly new.

mkdir -p /opt/fog/secureboot/hwkeys
cd /opt/fog/secureboot/

sudo efi-readvar -v PK -o /opt/fog/secureboot/hwkeys/hw_PK.esl
sudo efi-readvar -v KEK -o /opt/fog/secureboot/hwkeys/hw_KEK.esl
sudo efi-readvar -v db -o /opt/fog/secureboot/hwkeys/hw_db.esl
sudo efi-readvar -v dbx -o /opt/fog/secureboot/hwkeys/hw_dbx.esl 
sudo chmod 666 /opt/fog/secureboot/hwkeys/*

The following certificates (not really the correct word to use, but for my sanity I’ll call them certificates) are the only ones we are interested in (hw_KEK.esl, hw_db.esl, hw_dbx.esl). As I said above, you don’t need to do the above part because I’ll provide these generic certificates. note: 15-Dec-23 the hw_dbx.esl file might not be created if the dbx database is empty. If this is the case you should ignore the commands that use that file. Thank you @jfernandz for the updated inforamtion

Now lets bring everything together

cp /opt/fog/secureboot/efikeys/* /opt/fog/secureboot/efitools/
cp /opt/fog/secureboot/hwkeys/* /opt/fog/secureboot/efitools/
cd /opt/fog/secureboot/efitools

mv DB.esl DB-fog.esl
mv KEK.esl KEK-fog.esl
mv dbx.esl dbx-fog.esl

At this point we are going to take the hardware certificates we downloaded from the uefi firmware and tag the FOG certificates onto the end.

cat hw_db.esl DB-fog.esl > DB.esl
cat hw_KEK.esl KEK-fog.esl > KEK.esl
cat hw_dbx.esl > dbx.esl

Lets rebuild the signed boot loaders with the updated certificates

rm LockDown*efi LockDown.so LockDown.o
make

cp LockDown-signed.efi EnrollKeys.efi

/opt/fog/secureboot/efitools/EnrollKeys.efi is the boot loader we will use to auto insert the updated security keys into the uefi firmware. So lets copy that file to the /tftpboot

cp /opt/fog/secureboot/efitools/EnrollKeys.efi /tftpboot

The other two key files from this process that we will need is the FOG certificate private and public keys.

/opt/fog/secureboot/efikeys/DB.crt
/opt/fog/secureboot/efikeys/DB.key

In the next post we will go through and sign all of the boot files needed to secure boot into FOG.

Sample download with certificates
Here are the microsoft certificates that I downloaded from my Dell Desktop computer running debian. If you want this file you will need to download it and change the extension to .zip from .txt to be able to extract the contents. These keys are not unique, serialized, or unique. Every computer that is secure boot capable have these default keys installed.

ms_hwcerts.zip.txt