Secure Boot

Secure boot ensures only authenticated software runs on the device and is achieved by verifying digital signatures of the software prior to executing that code.

If data confidentiality and/or anti-counterfeit functionality is needed, then software/user data needs to be encrypted. The key used for encrypting the data also needs to be protected.

Secure Boot and Encrypted Data Storage

Bootloader authentication

Bootloader authentication is processor specific.
However the high level mechanism is usually the same, it involves:

• Creating a public/private key pair
• Computing the hash of the bootloader image
• Signing the hash with private key using vendor-specific code signing tools
• Appending the signature/certificate along with public key to the bootloader image
• Flashing the public key (or hash of public key) onto One-Time programmable (OTP) fuse on the processor

The processor ROM code on power-up loads the bootloader along with the signature/certificate appended to it.
It then verifies the software by performing the following steps:

• Verify the hash of public key appended to bootloader image matches the one stored in OTP fuse
• Extract the hash of bootloader from the signature using the verified public key
• Compare the extracted hash with the computed hash of the bootloader.
If it matches it proceed with the boot process, thus authenticating the bootloader.

Chain of trust

1. ROM verifies signed bootloader
2. bootloader verifies signed kernel
3. kernel verifies/mounts encrypted/signed root filesystem (RFS)

FIT image authentication

FIT stands for Flattened Image Tree and is a single binary that can contain multiple images along with metadata for storing image information along with signatures, thus making it convenient to authenticate.

• A typical secure boot use case is to generate a FIT image containing kernel, device tree and initramfs.
• The FIT image is then signed using a private key, and the signature is embedded inside the FIT image.
• The public key is then embedded inside U-Boot as part of U-Boot device tree.

Since the signed U-Boot is authenticated by the ROM, we can trust the public key inside of U-Boot to verify the FIT image.

Alternate approach

Instead of using a FIT image, a combined kernel/devicetree/initramfs image can be created, and SoC vendor specific APIs (when available) can be used to verify the combined image (similar to how ROM authenticated bootloader).

Secure Boot

UEFI規定，主板出廠的時候，可以內置一些可靠的公鑰。然後，任何想要在這塊主板上加載的作業系統或者硬體驅動程序，都必須通過這些公鑰的認證。
UEFI沒規定哪些公鑰是可靠的，也沒規定誰負責頒發這些公鑰，都讓各個硬體廠商自己決定。

微軟規定：所有預裝Windows 8的OEM廠商必須內置Windows公鑰，前提是必須打開Secure Boot。

如果要在打開Secure Boot的主板上安裝Linux系統，這個系統就必須通過Windows 8的認證。所以很多用戶安裝不了Linux系統都與這個secure root有著直接關係。
因此，在預裝Windows 8的電腦上安裝Linux（或其他作業系統）的最佳做法，就是進入BIOS，關閉Secure Boot。但是，這意味著你花錢買來的Windows 8將無法使用。
UEFI Secure boot is to make sure that a device boots using only software that is trusted by the Original Equipment Manufacturer (OEM).
When the PC starts, the firmware checks the signature of each piece of boot software, including :

• UEFI firmware drivers
• EFI applications
• the operating system

If the signatures are valid, the PC boots, and the firmware gives control to the operating system.
Secure boot works by installing a set of keys into computer’s firmware(BIOS).
When secure boot is enabled on system, a series of verification is done before control is handed over to operating system.

1. When power is turned on, Intel boot-guard verifies the BIOS for integrity using public key burned with it and loads BIOS on successful verification.
2. BOIS then verifies intgrity of SHIM using keys in db and loads it
The UEFI shim is a first-stage boot loader which is signed by Microsoft.
3. SHIM then verifies integrity of GRUB using keys in db or MOK and loads it
4. GRUB then verifies and loads kernel using keys in db or MOK, kernel further loads filesystem

UEFI Secure Boot

The Meaning of all the UEFI Keys

The UEFI specification (2.3.1c) defines several key stores and their formats: The Platform Key (PK), The Key Exchange Key (KEK) The key database (db) and the forbidden signatures database (dbx).

UEFI Secure Variables

All of the keys are stored in UEFI secure variables (see section 7.2 of the UEFI specification).
A secure variable cannot be updated unless the person attempting the update can prove (with a digital signature on a specified payload, called the authentication descriptor) that they possess the private part of the key used to create the variable.
The UEFI specifications only allow two types of signing keys: X509 and RSA2048.
A secure variable may be cleared by writing an empty update (which must still contain a valid authentication descriptor).

Authentication Descriptor

The specifications allow two types of authentication descriptors: time based and monotonic count based.
Once a variable is created, it stores both the key that created it and the initial value for the time or monotonic count and will only accept subsequent updates signed with that key and which have the same update type (time based or monotonic count) that it was created with.
The reason for this is to prevent replay of previous updates, so a newer update must have either a later time or a higher monotonic count.
Once the update is accepted, the time or count is updated as well to the value in the authentication descriptor.

Setup and User Modes

When a platform is in Setup Mode, the secure variables may be altered without the usual authentication checks (although the secure variable writes must still contain an authentication descriptor for the initial key and update type but the actual authentication information isn’t checked).
In this mode, secure boot is turned off.

In user mode, the platform will check that any attempt to write to a secure variable has a validly signed authentication descriptor.
In user mode, the platform will also expose a secure boot flag (which is on by default).
If secure boot is set, it will only execute efi binaries which are:

• unsigned but have a sha-256 hash that is in db and not in dbx or
• signed and have a signature in db but not in dbx or
• signed by either a key in KEK or a key in db and neither the key nor the signature appears in dbx.

Platform Key (PK)

The Platform Key is the key to the platform and is stored in the PK variable.
Its job is to control access to the PK variable and the KEK variable.
In most implementations, only one key at once may be stored in PK and the PK may only be an X509 key.

If the PK variable is cleared (either by an authenticated variable write or by a special user present firmware action), the platform must immediately enter setup mode.

The PK variable may only be updated by an authentication descriptor signed with the platform key.
Note: The platform key may not be used to sign binaries for execution.

Key Exchange Key (KEK)

The Key Exchange Key is used to update the signature database and is stored in the KEK variable. It may be used either to update the current signature databases or to sign binaries for valid execution. In most current implementations, the KEK variable may contain multiple keys which may be of type X509 or RSA2048 any of which may perform the function of the key exchange key.

The KEK variable may only be updated by an authentication descriptor signed with the platform key.

The Forbidden Signatures Database (dbx)

The forbidden signatures database is used to invalidate efi binaries and loadable roms when the platform is operating in secure mode.
It is stored in the dbx variable. The dbx variable may contain either keys, signatures or hashes.
In secure boot mode, the signature stored in the efi binary (or computed using SHA-256 if the binary is unsigned) is compared against the entries in the database.
Execution is refused if either

• The binary is unsigned and the SHA-256 hash of the binary is in dbx or
• The image is signed and the signature matches an entry in dbx or
• The image is signed and the key used to create the signature matches an entry in dbx.

Note: since unsigned binaries are automatically refused execution, the addition of a hash to dbx serves only to prevent that image being authorised by having an entry for its hash in the signature database (see below).

Any binary hash that matches a DBX hash or has a signature verified by a DBX certificate will be prevented from executing at boot time.

The dbx variable may only be updated by an authentication descriptor signed with the key exchange key.

The Signature Database (db)

The signature database is used to validate signed efi binaries and loadable roms when the platform is operating in secure mode. It is stored in the db variable. The db variable may contain a mixed set of keys, signatures or hashes. In secure boot mode, the signature stored in the efi binary (or the SHA-256 hash if there is no signature) is compared against the entries in the database. The image will be executed if either

• the image is unsigned and a SHA-256 hash of the image is in the database or
• the image is signed and the signature itself is in the database or
• the image is signed and the signing key is in the database (and the signature is valid).

The db variable may only be updated by an authentication descriptor signed with the key exchange key.

Some consequences of all of this

As you can see from the above, the holder of the platform key is essentially the owner of the platform.
However, simply knowing the platform key (the private part) isn’t enough because in order to change the platform you have to be able to execute binaries and the platform will only execute binaries signed by a key either in KEK or db.
If you take control of your platform by installing a platform key, you need to ensure that this key (or another you control) is also added to either KEK or db so you can sign binaries with it and have them execute.

Updating PK, KEK, db and dbx in user mode

Linux has the capability to construct runtime updates to the secure variables: kernel/git/jejb/efitools.git

The Microsoft Keys

The Key Exchange Key is a Microsoft X509 certificate with /CN=Microsoft Corporation KEK CA 2011/.
It’s not self signed, it’s signed by /CN=Microsoft Corporation Third Party Marketplace Root/

• signature list
kek.esl
• der
kek.cer

The Signature database contains three microsoft X509 certificates; you can get the signature list here.

• /CN=Microsoft Windows PCA 2010/ signed by /CN=Microsoft Root Certificate Authority 2010/ (db.0.cer).
• /CN=Microsoft Corporation UEFI CA 2011/ signed by /CN=Microsoft Corporation Third Party Marketplace Root/ (db.1.cer)
• /CN=Microsoft Windows Production PCA 2011/ signed by /CN=Microsoft Root Certificate Authority 2010/ (db.2.cer)

Easier Way to take control of UEFI secure boot platform

All the tools are in the git repository.

If you copy all the efi files in /usr/share/efitools/efi/ and the *.auth files from /usr/share/efitools/keys/ into a partition accessible to the efi boot loader.
Then in Setup Mode (must be Setup Mode to alter the keys) do:

UpdateVars db db.auth
UpdateVars KEK KEK.auth
UpdateVars PK PK.auth  
  

After the PK update, the platform should once again be in user mode. Verify by trying to run the HelloWorld efi binary (should fail) and it’s signed counterpart HelloWorld-signed (should print Hello World!).

SecureBoot in Ubuntu: Image Signing

There are two different ways an image can be signed:

• By the Canonical signing private key
which is signed by Canonical's master CA
• By the WinQual signing private key
which is ultimately signed by Microsoft's CA via their WinQual program (our signing certificate proves that the binary came from us, nothing else)

How an image is signed depends on what is available in the UEFI db.

Canonical only

WinQual only

WinQual-signed 1st stage (shim) and Canonical-signed 2nd stage (efilinux/grub2) (default)

Canonical and WinQual (historical)

UEFI Secure Boot

UEFI Secure Boot guarantees that only valid 3rd party firmware code can run in the Original Equipment Manufacturer (OEM) firmware environment.
UEFI Secure Boot assumes :

• the system firmware is a trusted entity.
• Any 3rd party firmware code is not trusted
It includes the bootloader installed by the Operating System Vendor (OSV) and peripherals provided by an Independent Hardware Vendor (IHV).

UEFI Secure Boot includes two parts:

• verification of the boot image
• verification of updates to the image security database

UEFI Secure Boot Customization

National Security Agency
Cybersecurity Technical Report

Executive summary

Secure Boot is a boot integrity feature that is part of the Unified Extensible Firmware Interface (UEFI) industry standard.

1 Unified Extensible Firmware Interface (UEFI)

UEFI defines a consistent Application Programming Interface (API) and a set of environment variables common to all UEFI platforms.

2 UEFI Secure Boot

Secure Boot is a feature added to UEFI specification 2.3.1.
Each binary (module, driver, kernel, etc.) used during boot must be validated before execution. Validation involves checking for the presence of a signature that can be validated by a certificate or by computing a SHA-256 hash that matches a trusted hash.
Several value stores are used to identify content that is trusted or untrusted:

• Platform Key (PK)
This the top level key certificate(RSA-2048 public key certificate) in secure boot architecture.
PK is self signed i.e. PK is signed by its own private key.
The PK cannot be used for signing executable binaries that are checked at boot time.
Keep the PK private key secure.
A unique PK per endpoint provides greater security against UEFI compromise across an infrastructure, but may reduce the speed at which administrators can deploy changes compared to a common/shared PK.

• Key Exchange Keys (KEKs)
KEKs are typically present on a system as RSA-2048 public key certificates.
KEK is signed using PK’s private key.
The KEK’s private key is used to sign DB or DBX.
KEKs are normally used by vendors, such as the system vendor and the OS vendor, who have a need to update the DB or DBX.
Without the KEK, the firmware would have no way of knowing whether the key present in db or dbx was valid or not.
Secure boot is designed in a way that db/dbx can only be updated if signed by KEK.
• Allow list Database (DB)
This can contain trusted SHA-256 hashes or RSA 2048 public key certificates.
Binaries will be allowed to execute at boot time for one of the following condition:

• Binaries that have signatures which can be validated by a certificate
• binaries with computed SHA-256 hashes which match a trusted hash
DB is signed using KEK’s private
• Deny list Database (DBX)
This can contain notn-trusted SHA-256 hashes or RSA 2048 public key certificates.
Binaries will be prevented from executing at boot time for one of the following condition:

• Binaries that have signatures which can be validated by a certificate
• binaries with computed SHA-256 hashes which match a trusted hash
DBXis signed using KEK’s private
• Machine Owner Key (MOK)
MOK is not part of the UEFI Secure Boot standard.
MOK is used by Linux implementations. The functions of MOK is identical to the DB.
MOK is initialized by the pre-bootloader Shim. Shim is signed by Microsoft and therefore works on most computers supporting Secure Boot Standard Mode.
Linux distributions utilize MOK keys to sign their own binaries.
MOK can store SHA-256 hashes and RSA public key certificates.
Some Linux kernels leverage MOK for driver signing checks instead of or in addition to DB, DBX, and KEK.
• Machine Owner Key Deny list (MOKX)
MOKX is also not part of the UEFI Secure Boot standard.
MOKX exists in Linux implementations and functions like the DBX.

The order of operations during UEFI Secure Boot checks.

"Checks contained within dashed lines" only take place when

• the Shim bootloader is used
• after its initialization in the UEFI bootloader phase

Shim

Matthew Garrett created a program called the Shim bootloader, an open source alternative that integrates its own certificates.
Ubuntu, Red Hat, SUSE, and Debian generate their own versions of Shim that include certificates issued by their companies.

After the Shim is signed with Microsoft key, the UEFI firmware will load Shim.
Once Shim is loaded, it operates independently of the Microsoft verification chain.
Shim has built-in certificate management that lets the owner of the computer store certificates called machine owner keys (MOKs).

Using the Canonical certificate stored in Shim, for instance, Ubuntu distros sign the GRUB 2 bootloader. The firmware boots Shim, Shim boots GRUB 2, and GRUB 2 boots the operating system .

If you install Ubuntu on a computer with Secure Boot enabled, the installation routine places the signed Shim bootloader and GRUB 2 on the SSD or hard disk and installs the digitally signed kernel, along with verifiable modules and drivers.
If Secure Boot is not enabled, the operating system installer copies the various components onto the computer without a digital signature.

you can inelegantly deactivate the verification of digital signatures by the Linux kernel with Shim by typing the command:

$ sudo mokutil --disable-validation

The mokutil tool requires you to enter a one-time password. After that, mokutil does not deactivate the check itself, but it sets up the Shim bootloader so that it asks for the password at the next reboot and performs the desired configuration after the correct password is input.
After a reboot, Shim expects you to enter the one-time password within a short time frame.

In Shim, select Change Secure Boot state in the selection box :

After entering the previously defined one-time password, the compulsory verification of digital signatures is deactivated.

If you want to create a Secure Boot-compatible USB stick for UEFI, you should place

• a copy of the shim as EFI\boot\bootx64.efi
• a copy of GRUB as EFI\boot\grubx64.efi
the shim bootloader will look for grubx64.efi in the same directory the shim bootloader is in.

Secure Boot shim bootloader that is used by many major distributions to handle Secure Boot, the source code: https://github.com/rhboot/shim .

While in Secure Boot Setup Mode, all the Secure Boot keystores should be editable by OS-level programs, like efivar or sbsigntools for example.

How to verify signed UEFI binaries?

Export all of the trusted public keys using mokutil:

$ mokutil --export --pk
$ mokutil --export --kek
$ mokutil --export --db
$ mokutil --export
$ ls -l *.der
-rw-r--r-- 1 ubuntu ubuntu 1556 Jun 19 23:55 DB-0001.der
-rw-r--r-- 1 ubuntu ubuntu 1499 Jun 19 23:55 DB-0002.der
-rw-r--r-- 1 ubuntu ubuntu 1233 Jun 19 23:55 DB-0003.der
-rw-r--r-- 1 ubuntu ubuntu 1516 Jun 19 23:55 KEK-0001.der
-rw-r--r-- 1 ubuntu ubuntu 1259 Jun 19 23:55 KEK-0002.der
-rw-r--r-- 1 ubuntu ubuntu 1080 Jun 19 23:55 MOK-0001.der
-rw-r--r-- 1 ubuntu ubuntu 1247 Jun 19 23:55 PK-0001.der

Display the issuer and subject

$ for derfile in ./*.der; do
>     openssl x509 -inform der -outform pem -in "$derfile" -out "${derfile}.pem"
> done
# re-name *.der.pem to be *.pem
$ rename 's/.der.pem$/.pem/' ./*.der.pem
$ for pemfile in ./*.pem; do
>     echo "$pemfile"
>     openssl x509 -inform pem -in "$pemfile" -text | egrep 'CN ?='
> done
./DB-0001.pem
        Issuer: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Corporation Third Party Marketplace Root
        Subject: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Corporation UEFI CA 2011
./DB-0002.pem
        Issuer: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Root Certificate Authority 2010
        Subject: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Windows Production PCA 2011
./DB-0003.pem
        Issuer: C = US, ST = California, L = Portland, O = Dell Technologies Inc., CN = Dell secure boot db key 2022
        Subject: C = US, ST = California, L = Portland, O = Dell Technologies Inc., CN = Dell secure boot db key 2022
./KEK-0001.pem
        Issuer: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Corporation Third Party Marketplace Root
        Subject: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Corporation KEK CA 2011
./KEK-0002.pem
        Issuer: C = US, ST = California, L = Portland, O = Dell Technologies Inc., CN = Dell secure boot key enrollment key 2022
        Subject: C = US, ST = California, L = Portland, O = Dell Technologies Inc., CN = Dell secure boot key enrollment key 2022
./MOK-0001.pem
        Issuer: C = GB, ST = Isle of Man, L = Douglas, O = Canonical Ltd., CN = Canonical Ltd. Master Certificate Authority
        Subject: C = GB, ST = Isle of Man, L = Douglas, O = Canonical Ltd., CN = Canonical Ltd. Master Certificate Authority
./PK-0001.pem
        Issuer: C = US, ST = California, L = Portland, O = Dell Technologies Inc., CN = Dell secure boot platform key 2022
        Subject: C = US, ST = California, L = Portland, O = Dell Technologies Inc., CN = Dell secure boot platform key 2022

Verify all the relevant files with all of these public keys using sbverify:

# for imgfile in /boot/vmlinuz-* /boot/initrd.img-* /boot/efi/EFI/devuan/*; do
>     for pemfile in ./*.pem; do
>         sbverify --cert "$pemfile" "$imgfile" &> /dev/null && echo "$imgfile is signed with $pemfile"
>     done
> done

• To convert a DER formatted certificate to PEM:

$ openssl x509 -inform DER -in ./DB-0001.der \
               -outform PEM -out ./DB-0001.pem
$ openssl x509 -inform DER -in ./MOK-0001.der \
               -outform PEM -out ./MOK-0001.pem               
	

• To create a PEM certificate chain from DER formatted certificates, convert all the DER certificates to PEM, then concatenate them in one certificate
To verify Microsoft's signature on the signed shim bootloader (must first create the PEM certificate, above):

$ sudo sbverify --cert ./DB-0001.pem /boot/efi/EFI/ubuntu/shimx64.efi
warning: data remaining[830784 vs 955656]: gaps between PE/COFF sections?
Signature verification OK

To verify Canonical's signature on the signed grub bootloader (must first create the PEM certificate, above):

$ sbverify --cert ./MOK-0001.pem  /boot/efi/EFI/ubuntu/grubx64.efi
Signature verification OK

To list signatures:

$ sudo sbverify --list /boot/efi/EFI/ubuntu/grubx64.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

To remove a signature table, you may do this:

$ sbattach --signum 1 --remove /boot/efi/EFI/Grub/grubx64.efi 

To create a detached backup of a signature table in $PWD, you may do this:

$ sbattach --signum 1 --detach grubx64.sig /boot/efi/EFI/Grub/grubx64.efi 

You may also do both (backup and remove) at the same time:

$ sbattach --signum 1 --detach grubx64.sig --remove /boot/efi/EFI/Grub/grubx64.efi 

If all went well, and no other signatures exist in the image, the result will be:

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

A tool named pesign can provide information about signatures contained in a binary.
Use the following command to list the signature of the file shimx64.efi:

$ sudo pesign -S -i=/boot/efi/EFI/ubuntu/shimx64.efi
---------------------------------------------
certificate address is 0x7f6f6d4d53d0
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher
No signer email address.
No signing time included.
There were certs or crls included.
---------------------------------------------

sbsign can sign a variety of EFI files – most importantly bootloaders and kernels – for use with customized Secure Boot.
The following example command signs the shimx64.efi bootloader:

$ sbsign --key dsk1.key --cert dsk1.crt shimx64.efi  

The signed file will be output as shimx64.efi.signed which may need to be renamed because some UEFI implementations ignore bootable files that do not end in .efi.

Owning your Windows 8 UEFI Platform

efitools 1.4 with linux key manipulation utilities released

Calculate and Capture Hashes

Hashes used by Secure Boot must be in the SHA-256 format.

DB allow list hashes should normally be reserved for content that cannot be signed or cannot be altered from the vendor-provided state.
DBX deny list hashes should normally be reserved to remove trust from signed binaries without revoking the corresponding certificate/key.


• To create a text hexadecimal hash:

$ sudo openssl dgst -sha256 -hex -out shim64.txt /boot/efi/EFI/ubuntu/shimx64.efi
$ cat shim64.txt
SHA256(/boot/efi/EFI/ubuntu/shimx64.efi)= f037d2f20ce5d739c95fa71435410f1d71876868b7e635adb23cdb66fcf4619a 
    

• To create a binary hash:

$ openssl dgst -sha256 -binary -out shimx64.hsh shimx64.efi  
	

The above commands create individual hash files.
Some loading methods may require the use of individual hashes.

Extract signature

$ ls -l /usr/lib/shim/shimx64.efi.signed /usr/lib/shim/shimx64.efi
-rw-r--r-- 1 root root 947143 Aug 13  2021 /usr/lib/shim/shimx64.efi
-rw-r--r-- 1 root root 955656 Aug 13  2021 /usr/lib/shim/shimx64.efi.signed

$ openssl dgst -verify foo.pem 

expects that foo.pem contains the "raw" public key in PEM format.
The raw format is an encoding of a SubjectPublicKeyInfo structure, which can be found within a certificate; but openssl dgst cannot process a complete certificate in one go.
1. extract the public key from the certificate

$ openssl x509 -pubkey -noout -in ./DB-0001.pem > ms-pubkey.pem
$ cat ms-pubkey.pem
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApQhsTMdFCWpLDKTAh38G
dQxDAVRk4BZ/B+2SfQuyc78MCsZKRWGgxRYtltP1K6D7TUmbQYCQPLlU/ea80Z3E
pBiKf0GKXFmDaDK7jEfJ7nG8IU+ainz/RD+NjzKyJkiudbXuyUweShl+5IKaHXh3
TQywvfYP0xbTvPorpVE4XfX7utt4Atv/7AobltWDuBkT6bbAe0B74R8oJ8n671Ze
HOZ+lH7A8ESyeTnl2rJii02/OHDiaCQUyTOkCDfVWGle03ztwQRTCOdOsCqHYwhh
b2MVWeqyK3nXDGFnilv9Xq2Hf7qGZ09xWBIiBCIizovvVHEAzlA1WHaVCO5qsaIB
1QIDAQAB
-----END PUBLIC KEY-----    
    

2. use the public key to verify the signature

$ openssl dgst -verify ms-pubkey.pem -signature signature-file datafile
    

GRUB and the boot process on UEFI-based x86 systems

GRUB loads itself into memory in the following stages:
• The UEFI-based platform reads the partition table on the system storage and mounts the EFI System Partition (ESP), a VFAT partition labeled with a particular globally unique identifier (GUID). The ESP contains EFI applications such as bootloaders and utility software, stored in directories specific to software vendors. Viewed from within the Fedora 19 file system, the ESP is /boot/efi/, and EFI software provided by Red Hat is stored in /boot/efi/EFI/fedora/.
• The /boot/efi/EFI/fedora/ directory contains grub.efi, a version of GRUB compiled for the EFI firmware architecture as an EFI application. In the simplest case, the EFI boot manager selects grub.efi as the default bootloader and reads it into memory. If the ESP contains other EFI applications, the EFI boot manager might prompt you to select an application to run, rather than load grub.efi automatically.
• GRUB determines which operating system or kernel to start, loads it into memory, and transfers control of the machine to that operating system.
Because each vendor maintains its own directory of applications in the ESP, chain loading is not normally necessary on UEFI-based systems.
The EFI boot manager can load any of the operating system bootloaders that are present in the ESP.

Secure Boot with GRUB 2 and signed Linux images and initrds

The idea is to create a signed GRUB EFI binary which contains the required modules and base config. Secure boot verifies this binary during boot.
GRUB then loads the signed grub.cfg which contains the available kernels and then loads the selected (signed) kernels and initrds.
GRUB’s verification is based on GPG which is independent of Secure Boot.

Setup Secure Boot

Refer to the efitools README.
Enable Setup Mode in your UEFI firmware (delete all existing keys) to add your custom keys.
• Install efitools and sbsigntool on your system.
• Create the keys

$ openssl req -new -x509 -newkey rsa:2048 -subj "/CN=PK/"  -keyout PK.key  -out PK.crt  -days 7300 -nodes -sha256
$ openssl req -new -x509 -newkey rsa:2048 -subj "/CN=KEK/" -keyout KEK.key -out KEK.crt -days 7300 -nodes -sha256
$ openssl req -new -x509 -newkey rsa:2048 -subj "/CN=db/"  -keyout db.key  -out db.crt  -days 7300 -nodes -sha256
	

• Prepare installation in EFI

$ cert-to-efi-sig-list PK.crt PK.esl
$ sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth
$ cert-to-efi-sig-list KEK.crt KEK.esl
$ sign-efi-sig-list -k PK.key -c PK.crt KEK KEK.esl KEK.auth
$ cert-to-efi-sig-list db.crt db.esl
$ sign-efi-sig-list -k KEK.key -c KEK.crt db db.esl db.auth
	

• Install keys into EFI
PK last as it will enable Custom Mode locking out further unsigned changes.

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

if you can’t update the variables with the commands above, use chattr -i to make EFI variables mutable again :

$ chattr -i /sys/firmware/efi/efivars/{PK,KEK,db,dbx}-*
    

From now on only EFI binaries signed with any db key can be loaded.
To sign a binary use:

$ sbsign --key /path/to/db.key --cert /path/to/db.crt /path/to/efi
 

Then use the .signed file to boot.

GRUB setup

UEFI Secure Boot

The goal is to have a working qemu system with the UEFI secure boot bios as well as various repositories for efi binary signing tools.

Intel and TianoCore

Testing Secure Boot

Introduction

In brief, Secure Boot works by placing the root of trust in firmware, the chain of trust is achieved via x509 certificates.
A root CA is embedded in firmware such that it can then validate the signed bootloader, the signed bootloader can then validate the signed kernel or signed 2nd stage boot loader, and so on.
Various key databases are used :

• DB (aka, 'signature database'):
contains the trusted keys used for authenticating any applications or drivers executed in the UEFI environment
• DBX (aka, 'forbidden signature database' or 'signature database blacklist')
contains a set of explicitly untrusted keys and binary hashes.
Any application or driver signed by these keys or matching these hashes will be blocked from execution.
• KEK (key exchange keys database)
contains the set of keys trusted for updating DB and DBX
• PK (platform key)
The public key owned by OEM.
The suggested implementation by UEFI:
• OEM key in PK
• OS vendor keys in KEK and DB. OEM may also have a key in KEK and DB
Systems shipping with Windows 8 will typically use the following:
• OEM key in PK
• 'Microsoft Corporation KEK CA' key in KEK
• 'Microsoft Windows Production PCA' and 'Microsoft Corporation UEFI CA' keys in DB
In order to boot on the widest range of systems, Ubuntu uses the following chain of trust:
• Canonical's 1st stage bootloader('shim') is signed by 'Microsoft Corporation UEFI CA'.
When the system boots and Secure Boot is enabled, firmware verifies that this 1st stage bootloader (from the 'shim-signed' package) is signed with a key in DB (in this case 'Microsoft Corporation UEFI CA').
• The 2nd stage bootloader (grub-efi-amd64-signed) is signed with Canonical's 'Canonical Ltd. Secure Boot Signing' key.
The shim (1st stage bootloader) verifies that the 2nd stage grub2 bootloader is properly signed.
• The 2nd stage grub2 bootloader boots an Ubuntu kernel which must be signed with the 'Canonical Ltd. Secure Boot Signing' key
• If signed kernel modules are supported, the signed kernel will verify them during kernel boot

$ dpkg -L shim-signed | grep shim
/usr/lib/shim
/usr/lib/shim/BOOTX64.CSV
/usr/lib/shim/fbx64.efi
/usr/lib/shim/mmx64.efi
/usr/lib/shim/mok
/usr/lib/shim/mok/openssl.cnf
/usr/lib/shim/shimx64.efi
/usr/lib/shim/shimx64.efi.dualsigned
/usr/lib/shim/shimx64.efi.signed
/usr/share/apport/package-hooks/source_shim-signed.py
/usr/share/doc/shim-signed
/usr/share/doc/shim-signed/changelog.Debian.gz
/usr/share/doc/shim-signed/copyright
/usr/share/lintian/overrides/shim-signed
/var/lib/shim-signed
/var/lib/shim-signed/mok
/usr/share/apport/package-hooks/source_shim.py

OVMF

UEFI for x86 QEMU/KVM VMs is called OVMF (Open Virtual Machine Firmware). It comes from EDK2 (EFI Development Kit), which is the UEFI reference implementation.
OVMF is a port of Intel's Tianocore (an open source implementation of the UEFI) firmware to the qemu virtual machine.
This allows easy debugging and experimentation with UEFI firmware; either for testing Ubuntu or using the (included) EFI shell.
The ovmf is now a package you can install:

sudo apt-get install qemu qemu-kvm  bridge-utils virt-manager libvirt-daemon ovmf

Verify that an OVMF image capable of performing Secure Boot is installed:

$ ls -al  /usr/share/qemu/OVMF.fd
lrwxrwxrwx 1 root root 15  四  12  2020 /usr/share/qemu/OVMF.fd -> ../ovmf/OVMF.fd

Quick Installation Ubuntu Using virt-manager

• Prepare OVMF_CODE.secboot.fd

$ sudo rm /usr/share/qemu/OVMF.fd
$ sudo ln -s /usr/share/OVMF/OVMF_CODE.secboot.fd /usr/share/qemu/OVMF.fd    
    

• Start creating a new VM in virt-manager

$ sudo systemctl restart libvirtd
$ sudo virt-manager  
    

When you get to the final page of the 'New VM' wizard, do the following:
• Click 'Customize configuration before install', then select 'Finish'

• On the 'Overview' screen, Change the 'Firmware' field to select the 'UEFI x86_64' option (OVMF_CODE.secboot.fd).

• On the IDE CDROM1
Set the ISO image to be mounted.

• Enable the boot from the CDROM

• Click 'Begin Installation'
• The boot screen you'll see should use linuxefi commands to boot the installer, and you should be able to run efibootmgr inside that system, to verify that you're running an UEFI OS.
• Do whatever normal VM things you want to do.
Initial screen when booting should now show TianoCore.

What is UEFI Secure Boot?

UEFI Secure boot is a verification mechanism for ensuring that code launched by firmware is trusted.
Each binary loaded at boot is validated against known keys, located in firmware, that denote trusted vendors and sources for the binaries, or trusted specific binaries that can be identified via cryptographic hashing.

Most x86 hardware comes from the factory pre-loaded with Microsoft keys.
This means we can generally rely on the firmware on these systems to trust binaries(shim-signed) that are signed by Microsoft, and the Linux community heavily relies on this assumption for Secure Boot to work.

Many ARM and other architectures also support UEFI Secure Boot, but may not be pre-loading keys in firmware.
On these architectures, it may be necessary to re-sign boot images with a certificate that is loaded in firmware by the owner of the hardware.

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.

On architectures or systems where pre-loaded signing certificates from Microsoft are not available or loaded in firmware(BIOS), users may replace the existing signatures on shim or grub and load them as they wish, verifying against their own certificates imported in the system's firmware(BIOS).
As the system boots, firmware(BIOS) loads the shim binary as specified in firmware BootEntry variables.
Ubuntu installs its own BootEntry at installation time and may update it any time the GRUB bootloader is updated.
Since the shim binary is signed by Microsoft; it is validated and accepted by the firmware(BIOS) when verifying against certificates already present in firmware(BIOS).
The next thing loaded by shim is the second-stage image. This can be one of two things:

• GRUB
if the system is booting normally;
• MokManager(mm*.efi)
if key management is required, as configured by firmware variables (usually changed when the system was previously running).
To check if the system booted via Secure Boot:

$ sudo mokutil --sb-state
SecureBoot disabled
Platform is in Setup Mode

Check MOK messages:

$ dmesg | grep 509
[    0.031538] On node 0 totalpages: 4115509
[    0.789387] Asymmetric key parser 'x509' registered
[    2.020895] Loading compiled-in X.509 certificates
[    2.021418] Loaded X.509 cert 'Build time autogenerated kernel key: bcd9657eac89fffc938bd1228eeb94381d45b8bf'
[    2.021852] Loaded X.509 cert 'Canonical Ltd. Live Patch Signing: 14df34d1a87cf37625abec039ef2bf521249b969'
[    2.022282] Loaded X.509 cert 'Canonical Ltd. Kernel Module Signing: 88f752e560a1e0737e31163a466ad7b70a850c19'
[    2.022283] blacklist: Loading compiled-in revocation X.509 certificates
[    2.022295] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing: 61482aa2830d0ab2ad5af10b7250da9033ddcef0'
[    2.025028] integrity: Loading X.509 certificate: UEFI:db
[    2.025046] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
[    2.025047] integrity: Loading X.509 certificate: UEFI:db
[    2.025058] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
[    2.025333] integrity: Revoking X.509 certificate: UEFI:dbx
[    2.025345] blacklist: Revoked X.509 cert 'Canonical Ltd. Secure Boot Signing: 61482aa2830d0ab2ad5af10b7250da9033ddcef0'
[    2.025345] integrity: Revoking X.509 certificate: UEFI:dbx
[    2.025355] blacklist: Revoked X.509 cert 'Debian Secure Boot Signer: 00a7468def'
[    2.025678] integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table)
[    2.025900] integrity: Loaded X.509 cert 'Canonical Ltd. Master Certificate Authority: ad91990bc22ab1f517048c23b6655a268e345a63'
[    2.025904] Loading compiled-in module X.509 certificates
[    2.026339] Loaded X.509 cert 'Build time autogenerated kernel key: bcd9657eac89fffc938bd1228eeb94381d45b8bf'

How can I do for non-automated signing of drivers?

Some projects may require the use of custom kernel drivers.
In these cases, people should make use of the tools "update-secureboot-policy" included in the shim-signed package to generate a new MOK.
Use the following command to enroll an existing key into shim:

sudo update-secureboot-policy --enroll-key

• If no MOK exists
the script will exit with a message to that effect.
• If the key is already enrolled
the script will exit, doing nothing.
• If the key exists but it not shown to be enrolled
the user will be prompted for a password to use after reboot, so that the key can be enrolled.
Kernel modules can then be signed with the kmodsign command (see UEFI/SecureBoot/Signing) as part of their build process.

Security implications in Machine-Owner Key management

The MOK generated at installation time or on upgrade is machine-specific.


MOK generation and signing process

The key generation and signing process is slightly different based on whether we are dealing with a brand new installation or an upgrade of system previously running.
• The user installs Ubuntu on a new system
While the system is being installed, a new MOK is automatically generated without further user interaction.
Third-party drivers or kernel modules required by the system will be automatically built when the package is installed, and the build process includes a signing step.
• The user upgrades an UEFI-enabled Ubuntu system to a new release where the system requires third-party drivers
Third-party modules are rebuilt for the new kernels and their post-build process proceeds to automatically sign them with the MOK.

Using mokutil to Manage Validation Keys

Use the command mokutil to manage Machine Owner Keys (MOK) used by the shim layer to validate GRUB and kernel images.


Signing kernel modules for secure boot

If Secure Boot is enabled, the following have to be signed with a private key and authenticated with the corresponding public key:
• the UEFI operating system boot loaders
• the Linux kernel
• all kernel modules
If they are not signed and authenticated, the system will not be allowed to finish the booting process.

In addition, the signed first-stage boot loader and the signed kernel include the distribution's public keys.
These signed executable binaries and embedded keys enable systems to install, boot, and run with the Microsoft UEFI Secure Boot Certification Authority keys that are provided by the UEFI firmware on systems that support UEFI Secure Boot.

Required utilities :

• Build system
• openssl
Generates public and private X.509 key pair
• sign-file
Executable file used to sign a kernel module with the private key
• Target system
• mokutil
Optional utility used to manually enroll the public key.

$ sudo mokutil --list-enrolled
[key 1]
SHA1 Fingerprint: 76:a0:92:06:58:00:bf:37:69:01:c3:72:cd:55:a9:0e:1f:de:d2:e0
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            b9:41:24:a0:18:2c:92:67
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority
        Validity
            Not Before: Apr 12 11:12:51 2012 GMT
            Not After : Apr 11 11:12:51 2042 GMT
        Subject: C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:bf:5b:3a:16:74:ee:21:5d:ae:61:ed:9d:56:ac:
                    bd:de:de:72:f3:dd:7e:2d:4c:62:0f:ac:c0:6d:48:
                    08:11:cf:8d:8b:fb:61:1f:27:cc:11:6e:d9:55:3d:
                    39:54:eb:40:3b:b1:bb:e2:85:34:79:ca:f7:7b:bf:
                    ba:7a:c8:10:2d:19:7d:ad:59:cf:a6:d4:e9:4e:0f:
                    da:ae:52:ea:4c:9e:90:ce:c6:99:0d:4e:67:65:78:
                    5d:f9:d1:d5:38:4a:4a:7a:8f:93:9c:7f:1a:a3:85:
                    db:ce:fa:8b:f7:c2:a2:21:2d:9b:54:41:35:10:57:
                    13:8d:6c:bc:29:06:50:4a:7e:ea:99:a9:68:a7:3b:
                    c7:07:1b:32:9e:a0:19:87:0e:79:bb:68:99:2d:7e:
                    93:52:e5:f6:eb:c9:9b:f9:2b:ed:b8:68:49:bc:d9:
                    95:50:40:5b:c5:b2:71:aa:eb:5c:57:de:71:f9:40:
                    0a:dd:5b:ac:1e:84:2d:50:1a:52:d6:e1:f3:6b:6e:
                    90:64:4f:5b:b4:eb:20:e4:61:10:da:5a:f0:ea:e4:
                    42:d7:01:c4:fe:21:1f:d9:b9:c0:54:95:42:81:52:
                    72:1f:49:64:7a:c8:6c:24:f1:08:70:0b:4d:a5:a0:
                    32:d1:a0:1c:57:a8:4d:e3:af:a5:8e:05:05:3e:10:
                    43:a1
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                AD:91:99:0B:C2:2A:B1:F5:17:04:8C:23:B6:65:5A:26:8E:34:5A:63
            X509v3 Authority Key Identifier: 
                keyid:AD:91:99:0B:C2:2A:B1:F5:17:04:8C:23:B6:65:5A:26:8E:34:5A:63

            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: 
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://www.canonical.com/secure-boot-master-ca.crl

    Signature Algorithm: sha256WithRSAEncryption
         3f:7d:f6:76:a5:b3:83:b4:2b:7a:d0:6d:52:1a:03:83:c4:12:
         a7:50:9c:47:92:cc:c0:94:77:82:d2:ae:57:b3:99:04:f5:32:
         3a:c6:55:1d:07:db:12:a9:56:fa:d8:d4:76:20:eb:e4:c3:51:
         db:9a:5c:9c:92:3f:18:73:da:94:6a:a1:99:38:8c:a4:88:6d:
         c1:fc:39:71:d0:74:76:16:03:3e:56:23:35:d5:55:47:5b:1a:
         1d:41:c2:d3:12:4c:dc:ff:ae:0a:92:9c:62:0a:17:01:9c:73:
         e0:5e:b1:fd:bc:d6:b5:19:11:7a:7e:cd:3e:03:7e:66:db:5b:
         a8:c9:39:48:51:ff:53:e1:9c:31:53:91:1b:3b:10:75:03:17:
         ba:e6:81:02:80:94:70:4c:46:b7:94:b0:3d:15:cd:1f:8e:02:
         e0:68:02:8f:fb:f9:47:1d:7d:a2:01:c6:07:51:c4:9a:cc:ed:
         dd:cf:a3:5d:ed:92:bb:be:d1:fd:e6:ec:1f:33:51:73:04:be:
         3c:72:b0:7d:08:f8:01:ff:98:7d:cb:9c:e0:69:39:77:25:47:
         71:88:b1:8d:27:a5:2e:a8:f7:3f:5f:80:69:97:3e:a9:f4:99:
         14:db:ce:03:0e:0b:66:c4:1c:6d:bd:b8:27:77:c1:42:94:bd:
         fc:6a:0a:bc
        
        

• efi-readvar

$ sudo apt-get install efitools        
$ sudo efi-readvar
Variable PK, length 814
PK: List 0, type X509
    Signature 0, size 786, owner 26dc4851-195f-4ae1-9a19-fbf883bbb35e
        Subject:
            CN=Foo
        Issuer:
            CN=Foo
Variable KEK, length 1560
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
Variable db, length 3143
db: List 0, 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 1, 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
Variable dbx, length 13396
dbx: List 0, type SHA256
    Signature 0, size 48, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Hash:80b4d96931bf0d02fd91a61e19d14f1da452e66db2408ca8604d411f92659f0a
    Signature 76, size 48, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Hash:45c7c8ae750acfbb48fc37527d6412dd644daed8913ccd8a24c94d856967df8e
dbx: List 1, type X509
    Signature 0, size 1076, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Subject:
            C=GB, ST=Isle of Man, O=Canonical Ltd., OU=Secure Boot, CN=Canonical Ltd. Secure Boot Signing
        Issuer:
            C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority
dbx: List 2, type X509
    Signature 0, size 784, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Subject:
            CN=Debian Secure Boot Signer
        Issuer:
            CN=Debian Secure Boot CA
dbx: List 3, type SHA256
    Signature 0, size 48, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Hash:81d8fb4c9e2e7a8225656b4b8273b7cba4b03ef2e9eb20e0a0291624eca1ba86

        

• keyctl
Optional utility used to display public keys in the system keyring

Prerequisites

Secure Boot VM setup

Bootloader signed with user key

This configuration allows the greatest flexibility in testing as we control PK and KEK, so we can update all aspects of Secure Boot as needed.


Unified Extensible Firmware Interface/Secure Boot

Case Study

• db

[key 1]
SHA1 Fingerprint: 46:de:f6:3b:5c:e6:1c:f8:ba:0d:e2:e6:63:9c:10:19:d0:ed:14:f3
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            61:08:d3:c4:00:00:00:00:00:04
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
        Validity
            Not Before: Jun 27 21:22:45 2011 GMT
            Not After : Jun 27 21:32:45 2026 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:a5:08:6c:4c:c7:45:09:6a:4b:0c:a4:c0:87:7f:
                    06:75:0c:43:01:54:64:e0:16:7f:07:ed:92:7d:0b:
                    b2:73:bf:0c:0a:c6:4a:45:61:a0:c5:16:2d:96:d3:
                    f5:2b:a0:fb:4d:49:9b:41:80:90:3c:b9:54:fd:e6:
                    bc:d1:9d:c4:a4:18:8a:7f:41:8a:5c:59:83:68:32:
                    bb:8c:47:c9:ee:71:bc:21:4f:9a:8a:7c:ff:44:3f:
                    8d:8f:32:b2:26:48:ae:75:b5:ee:c9:4c:1e:4a:19:
                    7e:e4:82:9a:1d:78:77:4d:0c:b0:bd:f6:0f:d3:16:
                    d3:bc:fa:2b:a5:51:38:5d:f5:fb:ba:db:78:02:db:
                    ff:ec:0a:1b:96:d5:83:b8:19:13:e9:b6:c0:7b:40:
                    7b:e1:1f:28:27:c9:fa:ef:56:5e:1c:e6:7e:94:7e:
                    c0:f0:44:b2:79:39:e5:da:b2:62:8b:4d:bf:38:70:
                    e2:68:24:14:c9:33:a4:08:37:d5:58:69:5e:d3:7c:
                    ed:c1:04:53:08:e7:4e:b0:2a:87:63:08:61:6f:63:
                    15:59:ea:b2:2b:79:d7:0c:61:67:8a:5b:fd:5e:ad:
                    87:7f:ba:86:67:4f:71:58:12:22:04:22:22:ce:8b:
                    ef:54:71:00:ce:50:35:58:76:95:08:ee:6a:b1:a2:
                    01:d5
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            1.3.6.1.4.1.311.21.1: 
                .....
            1.3.6.1.4.1.311.21.2: 
                ....k..wSJ.%7.N.&{. p.
            X509v3 Subject Key Identifier: 
                13:AD:BF:43:09:BD:82:70:9C:8C:D5:4F:31:6E:D5:22:98:8A:1B:D4
            1.3.6.1.4.1.311.20.2: 
                .
.S.u.b.C.A
            X509v3 Key Usage: 
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Authority Key Identifier: 
                keyid:45:66:52:43:E1:7E:58:11:BF:D6:4E:9E:23:55:08:3B:3A:22:6A:A8

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.microsoft.com/pki/crl/products/MicCorThiParMarRoo_2010-10-05.crl

            Authority Information Access: 
                CA Issuers - URI:http://www.microsoft.com/pki/certs/MicCorThiParMarRoo_2010-10-05.crt

    Signature Algorithm: sha256WithRSAEncryption
         35:08:42:ff:30:cc:ce:f7:76:0c:ad:10:68:58:35:29:46:32:
         76:27:7c:ef:12:41:27:42:1b:4a:aa:6d:81:38:48:59:13:55:
         f3:e9:58:34:a6:16:0b:82:aa:5d:ad:82:da:80:83:41:06:8f:
         b4:1d:f2:03:b9:f3:1a:5d:1b:f1:50:90:f9:b3:55:84:42:28:
         1c:20:bd:b2:ae:51:14:c5:c0:ac:97:95:21:1c:90:db:0f:fc:
         77:9e:95:73:91:88:ca:bd:bd:52:b9:05:50:0d:df:57:9e:a0:
         61:ed:0d:e5:6d:25:d9:40:0f:17:40:c8:ce:a3:4a:c2:4d:af:
         9a:12:1d:08:54:8f:bd:c7:bc:b9:2b:3d:49:2b:1f:32:fc:6a:
         21:69:4f:9b:c8:7e:42:34:fc:36:06:17:8b:8f:20:40:c0:b3:
         9a:25:75:27:cd:c9:03:a3:f6:5d:d1:e7:36:54:7a:b9:50:b5:
         d3:12:d1:07:bf:bb:74:df:dc:1e:8f:80:d5:ed:18:f4:2f:14:
         16:6b:2f:de:66:8c:b0:23:e5:c7:84:d8:ed:ea:c1:33:82:ad:
         56:4b:18:2d:f1:68:95:07:cd:cf:f0:72:f0:ae:bb:dd:86:85:
         98:2c:21:4c:33:2b:f0:0f:4a:f0:68:87:b5:92:55:32:75:a1:
         6a:82:6a:3c:a3:25:11:a4:ed:ad:d7:04:ae:cb:d8:40:59:a0:
         84:d1:95:4c:62:91:22:1a:74:1d:8c:3d:47:0e:44:a6:e4:b0:
         9b:34:35:b1:fa:b6:53:a8:2c:81:ec:a4:05:71:c8:9d:b8:ba:
         e8:1b:44:66:e4:47:54:0e:8e:56:7f:b3:9f:16:98:b2:86:d0:
         68:3e:90:23:b5:2f:5e:8f:50:85:8d:c6:8d:82:5f:41:a1:f4:
         2e:0d:e0:99:d2:6c:75:e4:b6:69:b5:21:86:fa:07:d1:f6:e2:
         4d:d1:da:ad:2c:77:53:1e:25:32:37:c7:6c:52:72:95:86:b0:
         f1:35:61:6a:19:f5:b2:3b:81:50:56:a6:32:2d:fe:a2:89:f9:
         42:86:27:18:55:a1:82:ca:5a:9b:f8:30:98:54:14:a6:47:96:
         25:2f:c8:26:e4:41:94:1a:5c:02:3f:e5:96:e3:85:5b:3c:3e:
         3f:bb:47:16:72:55:e2:25:22:b1:d9:7b:e7:03:06:2a:a3:f7:
         1e:90:46:c3:00:0d:d6:19:89:e3:0e:35:27:62:03:71:15:a6:
         ef:d0:27:a0:a0:59:37:60:f8:38:94:b8:e0:78:70:f8:ba:4c:
         86:87:94:f6:e0:ae:02:45:ee:65:c2:b6:a3:7e:69:16:75:07:
         92:9b:f5:a6:bc:59:83:58

[key 2]
SHA1 Fingerprint: 58:0a:6f:4c:c4:e4:b6:69:b9:eb:dc:1b:2b:3e:08:7b:80:d0:67:8d
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            61:07:76:56:00:00:00:00:00:08
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010
        Validity
            Not Before: Oct 19 18:41:42 2011 GMT
            Not After : Oct 19 18:51:42 2026 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:dd:0c:bb:a2:e4:2e:09:e3:e7:c5:f7:96:69:bc:
                    00:21:bd:69:33:33:ef:ad:04:cb:54:80:ee:06:83:
                    bb:c5:20:84:d9:f7:d2:8b:f3:38:b0:ab:a4:ad:2d:
                    7c:62:79:05:ff:e3:4a:3f:04:35:20:70:e3:c4:e7:
                    6b:e0:9c:c0:36:75:e9:8a:31:dd:8d:70:e5:dc:37:
                    b5:74:46:96:28:5b:87:60:23:2c:bf:dc:47:a5:67:
                    f7:51:27:9e:72:eb:07:a6:c9:b9:1e:3b:53:35:7c:
                    e5:d3:ec:27:b9:87:1c:fe:b9:c9:23:09:6f:a8:46:
                    91:c1:6e:96:3c:41:d3:cb:a3:3f:5d:02:6a:4d:ec:
                    69:1f:25:28:5c:36:ff:fd:43:15:0a:94:e0:19:b4:
                    cf:df:c2:12:e2:c2:5b:27:ee:27:78:30:8b:5b:2a:
                    09:6b:22:89:53:60:16:2c:c0:68:1d:53:ba:ec:49:
                    f3:9d:61:8c:85:68:09:73:44:5d:7d:a2:54:2b:dd:
                    79:f7:15:cf:35:5d:6c:1c:2b:5c:ce:bc:9c:23:8b:
                    6f:6e:b5:26:d9:36:13:c3:4f:d6:27:ae:b9:32:3b:
                    41:92:2c:e1:c7:cd:77:e8:aa:54:4e:f7:5c:0b:04:
                    87:65:b4:43:18:a8:b2:e0:6d:19:77:ec:5a:24:fa:
                    48:03
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            1.3.6.1.4.1.311.21.1: 
                ...
            X509v3 Subject Key Identifier: 
                A9:29:02:39:8E:16:C4:97:78:CD:90:F9:9E:4F:9A:E1:7C:55:AF:53
            1.3.6.1.4.1.311.20.2: 
                .
.S.u.b.C.A
            X509v3 Key Usage: 
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Authority Key Identifier: 
                keyid:D5:F6:56:CB:8F:E8:A2:5C:62:68:D1:3D:94:90:5B:D7:CE:9A:18:C4

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.microsoft.com/pki/crl/products/MicRooCerAut_2010-06-23.crl

            Authority Information Access: 
                CA Issuers - URI:http://www.microsoft.com/pki/certs/MicRooCerAut_2010-06-23.crt

    Signature Algorithm: sha256WithRSAEncryption
         14:fc:7c:71:51:a5:79:c2:6e:b2:ef:39:3e:bc:3c:52:0f:6e:
         2b:3f:10:13:73:fe:a8:68:d0:48:a6:34:4d:8a:96:05:26:ee:
         31:46:90:61:79:d6:ff:38:2e:45:6b:f4:c0:e5:28:b8:da:1d:
         8f:8a:db:09:d7:1a:c7:4c:0a:36:66:6a:8c:ec:1b:d7:04:90:
         a8:18:17:a4:9b:b9:e2:40:32:36:76:c4:c1:5a:c6:bf:e4:04:
         c0:ea:16:d3:ac:c3:68:ef:62:ac:dd:54:6c:50:30:58:a6:eb:
         7c:fe:94:a7:4e:8e:f4:ec:7c:86:73:57:c2:52:21:73:34:5a:
         f3:a3:8a:56:c8:04:da:07:09:ed:f8:8b:e3:ce:f4:7e:8e:ae:
         f0:f6:0b:8a:08:fb:3f:c9:1d:72:7f:53:b8:eb:be:63:e0:e3:
         3d:31:65:b0:81:e5:f2:ac:cd:16:a4:9f:3d:a8:b1:9b:c2:42:
         d0:90:84:5f:54:1d:ff:89:ea:ba:1d:47:90:6f:b0:73:4e:41:
         9f:40:9f:5f:e5:a1:2a:b2:11:91:73:8a:21:28:f0:ce:de:73:
         39:5f:3e:ab:5c:60:ec:df:03:10:a8:d3:09:e9:f4:f6:96:85:
         b6:7f:51:88:66:47:19:8d:a2:b0:12:3d:81:2a:68:05:77:bb:
         91:4c:62:7b:b6:c1:07:c7:ba:7a:87:34:03:0e:4b:62:7a:99:
         e9:ca:fc:ce:4a:37:c9:2d:a4:57:7c:1c:fe:3d:dc:b8:0f:5a:
         fa:d6:c4:b3:02:85:02:3a:ea:b3:d9:6e:e4:69:21:37:de:81:
         d1:f6:75:19:05:67:d3:93:57:5e:29:1b:39:c8:ee:2d:e1:cd:
         e4:45:73:5b:d0:d2:ce:7a:ab:16:19:82:46:58:d0:5e:9d:81:
         b3:67:af:6c:35:f2:bc:e5:3f:24:e2:35:a2:0a:75:06:f6:18:
         56:99:d4:78:2c:d1:05:1b:eb:d0:88:01:9d:aa:10:f1:05:df:
         ba:7e:2c:63:b7:06:9b:23:21:c4:f9:78:6c:e2:58:17:06:36:
         2b:91:12:03:cc:a4:d9:f2:2d:ba:f9:94:9d:40:ed:18:45:f1:
         ce:8a:5c:6b:3e:ab:03:d3:70:18:2a:0a:6a:e0:5f:47:d1:d5:
         63:0a:32:f2:af:d7:36:1f:2a:70:5a:e5:42:59:08:71:4b:57:
         ba:7e:83:81:f0:21:3c:f4:1c:c1:c5:b9:90:93:0e:88:45:93:
         86:e9:b1:20:99:be:98:cb:c5:95:a4:5d:62:d6:a0:63:08:20:
         bd:75:10:77:7d:3d:f3:45:b9:9f:97:9f:cb:57:80:6f:33:a9:
         04:cf:77:a4:62:1c:59:7e

[key 3]
SHA1 Fingerprint: 83:48:15:b2:26:62:54:7e:2f:bc:0f:f9:e1:49:2f:73:67:84:17:5b
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            dd:34:63:72:90:b2:d8:ed
        Signature Algorithm: sha512WithRSAEncryption
        Issuer: C=US, ST=California, L=Portland, O=Dell Technologies Inc., CN=Dell secure boot db key 2022
        Validity
            Not Before: Sep  8 02:18:32 2021 GMT
            Not After : Sep  6 02:18:32 2031 GMT
        Subject: C=US, ST=California, L=Portland, O=Dell Technologies Inc., CN=Dell secure boot db key 2022
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (3072 bit)
                Modulus:
                    00:b8:6c:2d:e9:ab:fd:f8:43:fe:10:50:5f:95:ad:
                    d9:3c:6c:ca:41:35:ee:20:f6:86:90:25:69:b1:82:
                    91:b3:39:f7:3b:7e:bc:20:d2:a8:25:e7:12:6b:e3:
                    09:5f:b3:e7:40:38:89:b1:59:cd:8c:de:62:09:e1:
                    87:53:57:4f:1c:2a:d4:34:95:e6:96:2c:cf:fd:a6:
                    aa:85:f0:5c:6b:45:e8:01:e8:37:3a:eb:ad:ce:79:
                    84:d4:e7:7f:d3:0e:26:87:7d:6d:47:92:f8:fd:64:
                    c0:32:28:4a:55:68:9a:fd:8e:ea:69:7b:94:58:20:
                    7e:99:de:fd:c5:2d:b5:be:9f:89:6a:8e:47:c2:9d:
                    bb:c1:5a:0b:1d:07:da:0c:91:97:60:fd:b6:c1:b5:
                    4f:40:af:00:7c:c3:c1:34:3b:f7:51:4c:2c:b3:26:
                    12:64:af:97:00:a4:49:4e:20:ee:c3:eb:6c:c4:43:
                    09:1c:a8:42:22:0a:37:bb:55:91:8b:66:d2:d6:ec:
                    65:97:9a:4d:26:92:5a:02:b7:ab:77:35:99:cf:7b:
                    9c:b1:18:16:7d:7a:9d:84:48:b2:85:68:65:8d:39:
                    44:fc:c2:c8:3b:64:8b:a0:10:b6:6c:7a:1c:fe:59:
                    c4:3c:96:ec:62:7c:e2:43:6c:b6:46:78:f2:a0:2f:
                    65:70:42:1d:b9:26:67:c5:5c:8c:f6:df:b2:ef:0b:
                    a9:dc:a3:bf:47:a6:4c:11:22:6d:ad:26:74:a8:f7:
                    59:aa:22:f9:18:8a:34:8f:10:1e:f1:c2:26:bb:81:
                    d4:33:2f:2e:26:54:4f:cd:1c:01:06:d8:16:63:71:
                    4b:ba:3c:7b:46:dc:0f:de:53:8c:d7:38:f6:2c:64:
                    f0:84:ab:ec:e4:dc:aa:92:50:2f:d6:a6:c8:b6:75:
                    63:85:27:cf:20:27:55:c0:0a:d3:c5:62:20:81:5f:
                    80:23:7b:9a:25:f7:77:47:2e:e0:dc:7f:ee:93:03:
                    7b:17:dc:78:04:1b:60:ef:56:e7
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                57:9A:57:70:C3:B9:8F:A2:64:E5:E5:19:3C:51:37:8B:D2:7B:6E:C6
            X509v3 Authority Key Identifier: 
                keyid:57:9A:57:70:C3:B9:8F:A2:64:E5:E5:19:3C:51:37:8B:D2:7B:6E:C6

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha512WithRSAEncryption
         45:a7:fa:f7:80:3f:e0:7c:ea:a3:d3:b5:9a:6b:43:66:ec:16:
         c9:c4:01:e0:97:7a:b0:8f:85:7d:26:38:50:13:26:9a:d9:84:
         36:64:45:19:01:eb:d9:b9:a9:f1:a6:4c:7e:b7:f6:f7:48:95:
         67:f1:59:f4:95:6c:8a:f0:01:c0:f1:5c:90:3e:14:7a:09:34:
         c6:1b:e4:22:f2:57:d9:25:65:86:91:eb:13:87:17:81:18:b6:
         d4:b7:02:82:7b:91:3c:9b:78:9d:e1:70:f9:81:89:0d:e1:c8:
         a4:e9:10:9f:06:dd:c5:55:bc:e6:c6:c4:91:b6:db:97:4c:84:
         cf:5e:df:e1:60:50:50:1e:ca:0a:69:07:c6:bf:d5:81:99:e6:
         81:58:f2:97:14:90:a1:19:e4:99:8a:6b:4a:83:49:ad:7c:32:
         21:f6:9b:27:ec:e4:90:51:ad:cc:07:26:c4:4c:c5:c2:47:65:
         d7:f3:c7:a5:3f:fe:c1:1f:9f:b1:a2:ca:bf:d3:89:30:a2:76:
         97:91:20:c9:7d:c5:47:18:6c:30:9c:cb:30:35:c8:2c:9c:44:
         d2:af:f4:95:f4:2c:c3:4c:66:14:ed:b3:ff:de:29:45:22:18:
         c7:59:ae:97:26:60:6a:de:b9:5b:16:10:1a:11:9f:75:0c:2f:
         b6:89:bf:5e:d8:7b:c3:dd:12:ca:af:fe:5c:e9:3c:d8:2e:c8:
         2b:dd:f3:60:c1:38:7b:47:53:e1:c8:cc:38:e1:6d:a5:56:f5:
         ab:34:0d:cb:6a:bd:cd:9e:09:77:be:a4:78:ee:99:a9:c1:f0:
         8a:43:80:fb:3f:b5:0a:ce:d1:54:bb:d5:f8:d0:62:cb:ce:23:
         8d:29:16:85:98:eb:db:86:a0:72:4d:20:d3:30:bb:99:71:51:
         27:00:5f:f5:f3:c3:4d:30:b3:a7:0c:19:d7:fd:13:a7:ad:aa:
         e3:a6:5e:16:b4:b7:87:48:ce:16:11:f6:ee:10:06:be:36:55:
         c3:8a:60:7d:42:07  
         

• dbx

[key 1]
  [SHA-256]
  80b4d96931bf0d02fd91a61e19d14f1da452e66db2408ca8604d411f92659f0a
  f52f83a3fa9cfbd6920f722824dbe4034534d25b8507246b3b957dac6e1bce7a
  c5d9d8a186e2c82d09afaa2a6f7f2e73870d3e64f72c4e08ef67796a840f0fbd
  1aec84b84b6c65a51220a9be7181965230210d62d6d33c48999c6b295a2b0a06
  c3a99a460da464a057c3586d83cef5f4ae08b7103979ed8932742df0ed530c66
  58fb941aef95a25943b3fb5f2510a0df3fe44c58c95e0ab80487297568ab9771
  5391c3a2fb112102a6aa1edc25ae77e19f5d6f09cd09eeb2509922bfcd5992ea
  d626157e1d6a718bc124ab8da27cbb65072ca03a7b6b257dbdcbbd60f65ef3d1
  d063ec28f67eba53f1642dbf7dff33c6a32add869f6013fe162e2c32f1cbe56d
  29c6eb52b43c3aa18b2cd8ed6ea8607cef3cfae1bafe1165755cf2e614844a44
  90fbe70e69d633408d3e170c6832dbb2d209e0272527dfb63d49d29572a6f44c
  106faceacfecfd4e303b74f480a08098e2d0802b936f8ec774ce21f31686689c
  174e3a0b5b43c6a607bbd3404f05341e3dcf396267ce94f8b50e2e23a9da920c
  2b99cf26422e92fe365fbf4bc30d27086c9ee14b7a6fff44fb2f6b9001699939
  2e70916786a6f773511fa7181fab0f1d70b557c6322ea923b2a8d3b92b51af7d
  3fce9b9fdf3ef09d5452b0f95ee481c2b7f06d743a737971558e70136ace3e73
  47cc086127e2069a86e03a6bef2cd410f8c55a6d6bdb362168c31b2ce32a5adf
  71f2906fd222497e54a34662ab2497fcc81020770ff51368e9e3d9bfcbfd6375
  82db3bceb4f60843ce9d97c3d187cd9b5941cd3de8100e586f2bda5637575f67
  8ad64859f195b5f58dafaa940b6a6167acd67a886e8f469364177221c55945b9
  8d8ea289cfe70a1c07ab7365cb28ee51edd33cf2506de888fbadd60ebf80481c
  aeebae3151271273ed95aa2e671139ed31a98567303a332298f83709a9d55aa1
  c409bdac4775add8db92aa22b5b718fb8c94a1462c1fe9a416b95d8a3388c2fc
  c617c1a8b1ee2a811c28b5a81b4c83d7c98b5b0c27281d610207ebe692c2967f
  c90f336617b8e7f983975413c997f10b73eb267fd8a10cb9e3bdbfc667abdb8b
  64575bd912789a2e14ad56f6341f52af6bf80cf94400785975e9f04e2d64d745
  45c7c8ae750acfbb48fc37527d6412dd644daed8913ccd8a24c94d856967df8e
  81d8fb4c9e2e7a8225656b4b8273b7cba4b03ef2e9eb20e0a0291624eca1ba86
  b92af298dc08049b78c77492d6551b710cd72aada3d77be54609e43278ef6e4d
  e19dae83c02e6f281358d4ebd11d7723b4f5ea0e357907d5443decc5f93c1e9d
  39dbc2288ef44b5f95332cb777e31103e840dba680634aa806f5c9b100061802
  32f5940ca29dd812a2c145e6fc89646628ffcc7c7a42cae512337d8d29c40bbd
  10d45fcba396aef3153ee8f6ecae58afe8476a280a2026fc71f6217dcf49ba2f
  4b8668a5d465bcdd9000aa8dfcff42044fcbd0aece32fc7011a83e9160e89f09
  89f3d1f6e485c334cd059d0995e3cdfdc00571b1849854847a44dc5548e2dcfb
  c9ec350406f26e559affb4030de2ebde5435054c35a998605b8fcf04972d8d55
  b3e506340fbf6b5786973393079f24b66ba46507e35e911db0362a2acde97049
  9f1863ed5717c394b42ef10a6607b144a65ba11fb6579df94b8eb2f0c4cd60c1
  dd59af56084406e38c63fbe0850f30a0cd1277462a2192590fb05bc259e61273
  dbaf9e056d3d5b38b68553304abc88827ebc00f80cb9c7e197cdbc5822cd316c
  65f3c0a01b8402d362b9722e98f75e5e991e6c186e934f7b2b2e6be6dec800ec
  5b248e913d71853d3da5aedd8d9a4bc57a917126573817fb5fcb2d86a2f1c886
  2679650fe341f2cf1ea883460b3556aaaf77a70d6b8dc484c9301d1b746cf7b5
  bb1dd16d530008636f232303a7a86f3dff969f848815c0574b12c2d787fec93f
  0ce02100f67c7ef85f4eed368f02bf7092380a3c23ca91fd7f19430d94b00c19
  95049f0e4137c790b0d2767195e56f73807d123adcf8f6e7bf2d4d991d305f89
  02e6216acaef6401401fa555ecbed940b1a5f2569aed92956137ae58482ef1b7
  6efefe0b5b01478b7b944c10d3a8aca2cca4208888e2059f8a06cb5824d7bab0
  9d00ae4cd47a41c783dc48f342c076c2c16f3413f4d2df50d181ca3bb5ad859d
  d8d4e6ddf6e42d74a6a536ea62fd1217e4290b145c9e5c3695a31b42efb5f5a4
  f277af4f9bdc918ae89fa35cc1b34e34984c04ae9765322c3cb049574d36509c
  0dc24c75eb1aef56b9f13ab9de60e2eca1c4510034e290bbb36cf60a549b234c
  835881f2a5572d7059b5c8635018552892e945626f115fc9ca07acf7bde857a4
  badff5e4f0fea711701ca8fb22e4c43821e31e210cf52d1d4f74dd50f1d039bc
  c452ab846073df5ace25cca64d6b7a09d906308a1a65eb5240e3c4ebcaa9cc0c
  f1863ec8b7f43f94ad14fb0b8b4a69497a8c65ecbc2a55e0bb420e772b8cdc91
  7bc9cb5463ce0f011fb5085eb8ba77d1acd283c43f4a57603cc113f22cebc579
  e800395dbe0e045781e8005178b4baf5a257f06e159121a67c595f6ae22506fd
  1cb4dccaf2c812cfa7b4938e1371fe2b96910fe407216fd95428672d6c7e7316
  3ece27cbb3ec4438cce523b927c4f05fdc5c593a3766db984c5e437a3ff6a16b
  68ee4632c7be1c66c83e89dd93eaee1294159abf45b4c2c72d7dc7499aa2a043
  e24b315a551671483d8b9073b32de11b4de1eb2eab211afd2d9c319ff55e08d0
  e7c20b3ab481ec885501eca5293781d84b5a1ac24f88266b5270e7ecb4aa2538
  dccc3ce1c00ee4b0b10487d372a0fa47f5c26f57a359be7b27801e144eacbac4
  0257ff710f2a16e489b37493c07604a7cda96129d8a8fd68d2b6af633904315d
  3a91f0f9e5287fa2994c7d930b2c1a5ee14ce8e1c8304ae495adc58cc4453c0c
  495300790e6c9bf2510daba59db3d57e9d2b85d7d7640434ec75baa3851c74e5
  81a8b2c9751aeb1faba7dbde5ee9691dc0eaee2a31c38b1491a8146756a6b770
  8e53efdc15f852cee5a6e92931bc42e6163cd30ff649cca7e87252c3a459960b
  992d359aa7a5f789d268b94c11b9485a6b1ce64362b0edb4441ccc187c39647b
  9fa4d5023fd43ecaff4200ba7e8d4353259d2b7e5e72b5096eff8027d66d1043
  d372c0d0f4fdc9f52e9e1f23fc56ee72414a17f350d0cea6c26a35a6c3217a13
  5c5805196a85e93789457017d4f9eb6828b97c41cb9ba6d3dc1fcc115f527a55
  03f64a29948a88beffdb035e0b09a7370ccf0cd9ce6bcf8e640c2107318fab87
  05d87e15713454616f5b0ed7849ab5c1712ab84f02349478ec2a38f970c01489
  06eb5badd26e4fae65f9a42358deef7c18e52cc05fbb7fc76776e69d1b982a14
  08bb2289e9e91b4d20ff3f1562516ab07e979b2c6cefe2ab70c6dfc1199f8da5
  0928f0408bf725e61d67d87138a8eebc52962d2847f16e3587163b160e41b6ad
  09f98aa90f85198c0d73f89ba77e87ec6f596c491350fb8f8bba80a62fbb914b
  0a75ea0b1d70eaa4d3f374246db54fc7b43e7f596a353309b9c36b4fd975725e
  0c51d7906fc4931149765da88682426b2cfe9e6aa4f27253eab400111432e3a7
  0fa3a29ad05130d7fe5bf4d2596563cded1d874096aacc181069932a2e49519a
  147730b42f11fe493fe902b6251e97cd2b6f34d36af59330f11d02a42f940d07
  148fe18f715a9fcfe1a444ce0fff7f85869eb422330dc04b314c0f295d6da79e
  1b909115a8d473e51328a87823bd621ce655dfae54fa2bfa72fdc0298611d6b8
  1d8b58c1fdb8da8b33ccee1e5f973af734d90ef317e33f5db1573c2ba088a80c
  1f179186efdf5ef2de018245ba0eae8134868601ba0d35ff3d9865c1537ced93
  270c84b29d86f16312b06aaae4ebb8dff8de7d080d825b8839ff1766274eff47
  29cca4544ea330d61591c784695c149c6b040022ac7b5b89cbd72800d10840ea
  2b2298eaa26b9dc4a4558ae92e7bb0e4f85cf34bf848fdf636c0c11fbec49897
  2dcf8e8d817023d1e8e1451a3d68d6ec30d9bed94cbcb87f19ddc1cc0116ac1a
  311a2ac55b50c09b30b3cc93b994a119153eeeac54ef892fc447bbbd96101aa1
  32ad3296829bc46dcfac5eddcb9dbf2c1eed5c11f83b2210cf9c6e60c798d4a7
  340da32b58331c8e2b561baf300ca9dfd6b91cd2270ee0e2a34958b1c6259e85
  362ed31d20b1e00392281231a96f0a0acfde02618953e695c9ef2eb0bac37550
  367a31e5838831ad2c074647886a6cdff217e6b1ba910bff85dc7a87ae9b5e98
  3765d769c05bf98b427b3511903b2137e8a49b6f859d0af159ed6a86786aa634
  386d695cdf2d4576e01bcaccf5e49e78da51af9955c0b8fa7606373b007994b3
  3a4f74beafae2b9383ad8215d233a6cf3d057fb3c7e213e897beef4255faee9d
  3ae76c45ca70e9180c1559981f42622dd251bca1fbe6b901c52ec11673b03514
  3be8e7eb348d35c1928f19c769846788991641d1f6cf09514ca10269934f7359
  3e3926f0b8a15ad5a14167bb647a843c3d4321e35dbc44dce8c837417f2d28b0
  400ac66d59b7b094a9e30b01a6bd013aff1d30570f83e7592f421dbe5ff4ba8f
  4185821f6dab5ba8347b78a22b5f9a0a7570ca5c93a74d478a793d83bac49805
  41d1eeb177c0324e17dd6557f384e532de0cf51a019a446b01efb351bc259d77
  45876b4dd861d45b3a94800774027a5db45a48b2a729410908b6412f8a87e95d
  4667bf250cd7c1a06b8474c613cdb1df648a7f58736fbf57d05d6f755dab67f4
  47ff1b63b140b6fc04ed79131331e651da5b2e2f170f5daef4153dc2fbc532b1
  57e6913afacc5222bd76cdaf31f8ed88895464255374ef097a82d7f59ad39596
  5890fa227121c76d90ed9e63c87e3a6533eea0f6f0a1a23f1fc445139bc6bcdf
  5d1e9acbbb4a7d024b6852df025970e2ced66ff622ee019cd0ed7fd841ccad02
  61cec4a377bf5902c0feaee37034bf97d5bc6e0615e23a1cdfbae6e3f5fb3cfd
  631f0857b41845362c90c6980b4b10c4b628e23dbe24b6e96c128ae3dcb0d5ac
  65b2e7cc18d903c331df1152df73ca0dc932d29f17997481c56f3087b2dd3147
  66aa13a0edc219384d9c425d3927e6ed4a5d1940c5e7cd4dac88f5770103f2f1
  6873d2f61c29bd52e954eeff5977aa8367439997811a62ff212c948133c68d97
  6dbbead23e8c860cf8b47f74fbfca5204de3e28b881313bb1d1eccdc4747934e
  6dead13257dfc3ccc6a4b37016ba91755fe9e0ec1f415030942e5abc47f07c88
  70a1450af2ad395569ad0afeb1d9c125324ee90aec39c258880134d4892d51ab
  72c26f827ceb92989798961bc6ae748d141e05d3ebcfb65d9041b266c920be82
  781764102188a8b4b173d4a8f5ec94d828647156097f99357a581e624b377509
  788383a4c733bb87d2bf51673dc73e92df15ab7d51dc715627ae77686d8d23bc
  78b4edcaabc8d9093e20e217802caeb4f09e23a3394c4acc6e87e8f35395310f
  7f49ccb309323b1c7ab11c93c955b8c744f0a2b75c311f495e18906070500027
  82acba48d5236ccff7659afc14594dee902bd6082ef1a30a0b9b508628cf34f4
  894d7839368f3298cc915ae8742ef330d7a26699f459478cf22c2b6bb2850166
  8c0349d708571ae5aa21c11363482332073297d868f29058916529efc520ef70
  8d93d60c691959651476e5dc464be12a85fa5280b6f524d4a1c3fcc9d048cfad
  9063f5fbc5e57ab6de6c9488146020e172b176d5ab57d4c89f0f600e17fe2de2
  91656aa4ef493b3824a0b7263248e4e2d657a5c8488d880cb65b01730932fb53
  91971c1497bf8e5bc68439acc48d63ebb8faabfd764dcbe82f3ba977cac8cf6a
  947078f97c6196968c3ae99c9a5d58667e86882cf6c8c9d58967a496bb7af43c
  96e4509450d380dac362ff8e295589128a1f1ce55885d20d89c27ba2a9d00909
  9783b5ee4492e9e891c655f1f48035959dad453c0e623af0fe7bf2c0a57885e3
  97a51a094444620df38cd8c6512cac909a75fd437ae1e4d22929807661238127
  97a8c5ba11d61fefbb5d6a05da4e15ba472dc4c6cd4972fc1a035de321342fe4
  992820e6ec8c41daae4bd8ab48f58268e943a670d35ca5e2bdcd3e7c4c94a072
  9954a1a99d55e8b189ab1bca414b91f6a017191f6c40a86b6f3ef368dd860031
  9baf4f76d76bf5d6a897bfbd5f429ba14d04e08b48c3ee8d76930a828fff3891
  9c259fcb301d5fc7397ed5759963e0ef6b36e42057fd73046e6bd08b149f751c
  9dd2dcb72f5e741627f2e9e03ab18503a3403cf6a904a479a4db05d97e2250a9
  9ed33f0fbc180bc032f8909ca2c4ab3418edc33a45a50d2521a3b5876aa3ea2c
  a4d978b7c4bda15435d508f8b9592ec2a5adfb12ea7bad146a35ecb53094642f
  a924d3cad6da42b7399b96a095a06f18f6b1aba5b873b0d5f3a0ee2173b48b6c
  ad3be589c0474e97de5bb2bf33534948b76bb80376dfdc58b1fed767b5a15bfc
  b8d6b5e7857b45830e017c7be3d856adeb97c7290eb0665a3d473a4beb51dcf3
  b93f0699598f8b20fa0dacc12cfcfc1f2568793f6e779e04795e6d7c22530f75
  bb01da0333bb639c7e1c806db0561dc98a5316f22fef1090fb8d0be46dae499a
  bc75f910ff320f5cb5999e66bbd4034f4ae537a42fdfef35161c5348e366e216
  bdd01126e9d85710d3fe75af1cc1702a29f081b4f6fdf6a2b2135c0297a9cec5
  be435df7cd28aa2a7c8db4fc8173475b77e5abf392f76b7c76fa3f698cb71a9a
  bef7663be5ea4dbfd8686e24701e036f4c03fb7fcd67a6c566ed94ce09c44470
  c2469759c1947e14f4b65f72a9f5b3af8b6f6e727b68bb0d91385cbf42176a8a
  c3505bf3ec10a51dace417c76b8bd10939a065d1f34e75b8a3065ee31cc69b96
  c42d11c70ccf5e8cf3fb91fdf21d884021ad836ca68adf2cbb7995c10bf588d4
  c69d64a5b839e41ba16742527e17056a18ce3c276fd26e34901a1bc7d0e32219
  cb340011afeb0d74c4a588b36ebaa441961608e8d2fa80dca8c13872c850796b
  cc8eec6eb9212cbf897a5ace7e8abeece1079f1a6def0a789591cb1547f1f084
  cf13a243c1cd2e3c8ceb7e70100387cecbfb830525bbf9d0b70c79adf3e84128
  d89a11d16c488dd4fbbc541d4b07faf8670d660994488fe54b1fbff2704e4288
  d9668ab52785086786c134b5e4bddbf72452813b6973229ab92aa1a54d201bf5
  da3560fd0c32b54c83d4f2ff869003d2089369acf2c89608f8afa7436bfa4655
  df02aab48387a9e1d4c65228089cb6abe196c8f4b396c7e4bbc395de136977f6
  df91ac85a94fcd0cfb8155bd7cbefaac14b8c5ee7397fe2cc85984459e2ea14e
  e051b788ecbaeda53046c70e6af6058f95222c046157b8c4c1b9c2cfc65f46e5
  e36dfc719d2114c2e39aea88849e2845ab326f6f7fe74e0e539b7e54d81f3631
  e39891f48bbcc593b8ed86ce82ce666fc1145b9fcbfd2b07bad0a89bf4c7bfbf
  e6856f137f79992dc94fa2f43297ec32d2d9a76f7be66114c6a13efc3bcdf5c8
  eaff8c85c208ba4d5b6b8046f5d6081747d779bada7768e649d047ff9b1f660c
  ee83a566496109a74f6ac6e410df00bb29a290e0021516ae3b8a23288e7e2e72
  eed7e0eff2ed559e2a79ee361f9962af3b1e999131e30bb7fd07546fae0a7267
  f1b4f6513b0d544a688d13adc291efa8c59f420ca5dcb23e0b5a06fa7e0d083d
  f2a16d35b554694187a70d40ca682959f4f35c2ce0eab8fd64f7ac2ab9f5c24a
  f31fd461c5e99510403fc97c1da2d8a9cbe270597d32badf8fd66b77495f8d94
  f48e6dd8718e953b60a24f2cbea60a9521deae67db25425b7d3ace3c517dd9b7
  c805603c4fa038776e42f263c604b49d96840322e1922d5606a9b0bbb5bffe6f
  1f16078cce009df62edb9e7170e66caae670bce71b8f92d38280c56aa372031d
  37a480374daf6202ce790c318a2bb8aa3797311261160a8e30558b7dea78c7a6
  408b8b3df5abb043521a493525023175ab1261b1de21064d6bf247ce142153b9
  540801dd345dc1c33ef431b35bf4c0e68bd319b577b9abe1a9cff1cbc39f548f
  040b3bc339e9b6f9acd828b88f3482a5c3f64e67e5a714ba1da8a70453b34af6
  1142a0cc7c9004dff64c5948484d6a7ec3514e176f5ca6bdeed7a093940b93cc
  288878f12e8b9c6ccbf601c73d5f4e985cac0ff3fcb0c24e4414912b3eb91f15
  2ea4cb6a1f1eb1d3dce82d54fde26ded243ba3e18de7c6d211902a594fe56788
  40d6cae02973789080cf4c3a9ad11b5a0a4d8bba4438ab96e276cc784454dee7
  4f0214fce4fa8897d0c80a46d6dab4124726d136fc2492efd01bfedfa3887a9c
  5c2afe34bd8a7aebbb439c251dfb6a424f00e535ac4df61ec19745b6f10e893a
  99d7ada0d67e5233108dbd76702f4b168087cfc4ec65494d6ca8aba858febada
  a608a87f51bdf7532b4b80fa95eadfdf1bf8b0cbb58a7d3939c9f11c12e71c85
  bdd4086c019f5d388453c6d93475d39a576572baff75612c321b46a35a5329b1
  cb994b400590b66cbf55fc663555caf0d4f1ce267464d0452c2361e05ee1cd50
  d6ee8db782e36caffb4d9f8207900487de930aabcc1d196fa455fbfd6f37273d
  dda0121dcf167db1e2622d10f454701837ac6af304a03ec06b3027904988c56b
  e42572afac720f5d4a1c7aaaf802f094daceb682f4e92783b2bb3fa00862af7f
  e6236dc1ee074c077c7a1c9b3965947430847be125f7aeb71d91a128133aea7f
  ef87be89a413657de8721498552cf9e0f3c1f71bc62dfa63b9f25bbc66e86494
  f5e892dd6ec4c2defa4a495c09219b621379b64da3d1b2e34adf4b5f1102bd39
  d4241190cd5a369d8c344c660e24f3027fb8e7064fab33770e93fa765ffb152e
  23142e14424fb3ff4efc75d00b63867727841aba5005149070ee2417df8ab799
  91721aa76266b5bb2f8009f1188510a36e54afd56e967387ea7d0b114d782089
  dc8aff7faa9d1a00a3e32eefbf899b3059cbb313a48b82fa9c8d931fd58fb69d
  9959ed4e05e548b59f219308a45563ea85bb224c1ad96dec0e96c0e71ffccd81
  47b31a1c7867644b2ee8093b2d5fbe21e21f77c1617a2c08812f57ace0850e9f
  fabc379df395e6f52472b44fa5082f9f0e0da480f05198c66814b7055b03f446
  e37ff3fc0eff20bfc1c060a4bf56885e1efd55a8e9ce3c5f4869444cacffad0b
  4cdae3920a512c9c052a8b4aba9096969b0a0197b614031e4c64a5d898cb09b9
  5b89f1aa2435a03d18d9b203d17fb4fba4f8f5076cf1f9b8d6d9b826222235c1
  007f4c95125713b112093e21663e2d23e3c1ae9ce4b5de0d58a297332336a2d8
  e060da09561ae00dcfb1769d6e8e846868a1e99a54b14aa5d0689f2840cec6df
  48f4584de1c5ec650c25e6c623635ce101bd82617fc400d4150f0aee2355b4ca
  af79b14064601bc0987d4747af1e914a228c05d622ceda03b7a4f67014fee767

[key 2]
  [SHA-256]
  363384d14d1f2e0b7815626484c459ad57a318ef4396266048d058c5a19bbf76
  e6ca68e94146629af03f69c2f86e6bef62f930b37c6fbcc878b78df98c0334e5
  075eea060589548ba060b2feed10da3c20c7fe9b17cd026b94e8a683b8115238
  07e6c6a858646fb1efc67903fe28b116011f2367fe92e6be2b36999eff39d09e
  09df5f4e511208ec78b96d12d08125fdb603868de39f6f72927852599b659c26
  0bbb4392daac7ab89b30a4ac657531b97bfaab04f90b0dafe5f9b6eb90a06374
  0c189339762df336ab3dd006a463df715a39cfb0f492465c600e6c6bd7bd898c
  0d0dbeca6f29eca06f331a7d72e4884b12097fb348983a2a14a0d73f4f10140f
  0dc9f3fb99962148c3ca833632758d3ed4fc8d0b0007b95b31e6528f2acd5bfc
  18333429ff0562ed9f97033e1148dceee52dbe2e496d5410b5cfd6c864d2d10f
  2bbf2ca7b8f1d91f27ee52b6fb2a5dd049b85a2b9b529c5d6662068104b055f8
  2c73d93325ba6dcbe589d4a4c63c5b935559ef92fbf050ed50c4e2085206f17d
  306628fa5477305728ba4a467de7d0387a54f569d3769fce5e75ec89d28d1593
  3608edbaf5ad0f41a414a1777abf2faf5e670334675ec3995e6935829e0caad2
  3841d221368d1583d75c0a02e62160394d6c4e0a6760b6f607b90362bc855b02
  4397daca839e7f63077cb50c92df43bc2d2fb2a8f59f26fc7a0e4bd4d9751692
  518831fe7382b514d03e15c621228b8ab65479bd0cbfa3c5c1d0f48d9c306135
  5ae949ea8855eb93e439dbc65bda2e42852c2fdf6789fa146736e3c3410f2b5c
  6b1d138078e4418aa68deb7bb35e066092cf479eeb8ce4cd12e7d072ccb42f66
  6c8854478dd559e29351b826c06cb8bfef2b94ad3538358772d193f82ed1ca11
  6f1428ff71c9db0ed5af1f2e7bbfcbab647cc265ddf5b293cdb626f50a3a785e
  726b3eb654046a30f3f83d9b96ce03f670e9a806d1708a0371e62dc49d2c23c1
  72e0bd1867cf5d9d56ab158adf3bddbc82bf32a8d8aa1d8c5e2f6df29428d6d8
  7827af99362cfaf0717dade4b1bfe0438ad171c15addc248b75bf8caa44bb2c5
  81a8b965bb84d3876b9429a95481cc955318cfaa1412d808c8a33bfd33fff0e4
  895a9785f617ca1d7ed44fc1a1470b71f3f1223862d9ff9dcc3ae2df92163daf
  8bf434b49e00ccf71502a2cd900865cb01ec3b3da03c35be505fdf7bd563f521
  9998d363c491be16bd74ba10b94d9291001611736fdca643a36664bc0f315a42
  9e4a69173161682e55fde8fef560eb88ec1ffedcaf04001f66c0caf707b2b734
  a6b5151f3655d3a2af0d472759796be4a4200e5495a7d869754c4848857408a7
  a7f32f508d4eb0fead9a087ef94ed1ba0aec5de6f7ef6ff0a62b93bedf5d458d
  ad6826e1946d26d3eaf3685c88d97d85de3b4dcb3d0ee2ae81c70560d13c5720
  afe2030afb7d2cda13f9fa333a02e34f6751afec11b010dbcd441fdf4c4002b3
  b54f1ee636631fad68058d3b0937031ac1b90ccb17062a391cca68afdbe40d55
  b8f078d983a24ac433216393883514cd932c33af18e7dd70884c8235f4275736
  b97a0889059c035ff1d54b6db53b11b9766668d9f955247c028b2837d7a04cd9
  bc87a668e81966489cb508ee805183c19e6acd24cf17799ca062d2e384da0ea7
  cb6b858b40d3a098765815b592c1514a49604fafd60819da88d7a76e9778fef7
  ce3bfabe59d67ce8ac8dfd4a16f7c43ef9c224513fbc655957d735fa29f540ce
  d8cbeb9735f5672b367e4f96cdc74969615d17074ae96c724d42ce0216f8f3fa
  e92c22eb3b5642d65c1ec2caf247d2594738eebb7fb3841a44956f59e2b0d1fa
  fddd6e3d29ea84c7743dad4a1bdbc700b5fec1b391f932409086acc71dd6dbd8
  fe63a84f782cc9d3fcf2ccf9fc11fbd03760878758d26285ed12669bdc6e6d01
  fecfb232d12e994b6d485d2c7167728aa5525984ad5ca61e7516221f079a1436
  ca171d614a8d7e121c93948cd0fe55d39981f9d11aa96e03450a415227c2c65b
  55b99b0de53dbcfe485aa9c737cf3fb616ef3d91fab599aa7cab19eda763b5ba
  77dd190fa30d88ff5e3b011a0ae61e6209780c130b535ecb87e6f0888a0b6b2f
  c83cb13922ad99f560744675dd37cc94dcad5a1fcba6472fee341171d939e884
  3b0287533e0cc3d0ec1aa823cbf0a941aad8721579d1c499802dd1c3a636b8a9
  939aeef4f5fa51e23340c3f2e49048ce8872526afdf752c3a7f3a3f2bc9f6049    
    

### Export the trusted public keys using mokutil: 

$ mokutil --export
$ ls *.der
DB-0001.der  DB-0002.der MOK-0001.der

### Convert .der to .pem format

$ openssl x509 -inform der -outform pem -in DB-0001.der -out DB-0001.pem
$ openssl x509 -inform pem -in DB-0001.pem -text | egrep 'CN ?='
        Issuer: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Corporation Third Party Marketplace Root
        Subject: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Corporation UEFI CA 2011

$ openssl x509 -inform der -outform pem -in DB-0002.der -out DB-0002.pem
$ openssl x509 -inform pem -in DB-0002.pem -text | egrep 'CN ?='
        Issuer: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Root Certificate Authority 2010
        Subject: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Windows Production PCA 2011

$ openssl x509 -inform der -outform pem -in MOK-0001.der -out MOK-0001.pem
$ openssl x509 -inform pem -in MOK-0001.pem -text | egrep 'CN ?='
        Issuer: C = GB, ST = Isle of Man, L = Douglas, O = Canonical Ltd., CN = Canonical Ltd. Master Certificate Authority
        Subject: C = GB, ST = Isle of Man, L = Douglas, O = Canonical Ltd., CN = Canonical Ltd. Master Certificate Authority

### To verify Microsoft's signature on the signed shim bootloader

$ sudo sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi
warning: data remaining[830784 vs 955656]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
 - 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

$ sudo sbverify --cert ./DB-0001.pem /boot/efi/EFI/ubuntu/shimx64.efi
warning: data remaining[830784 vs 955656]: gaps between PE/COFF sections?
Signature verification OK

### To verify Canonical's signature on the signed grubx64.efu bootloader

$ sudo sbverify --list /boot/efi/EFI/ubuntu/grubx64.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

$ sudo sbverify --cert MOK-0001.pem /boot/efi/EFI/ubuntu/grubx64.efi 
Signature verification OK

### To backup and remove a signature table from grubx64.efi

$ sudo cp  /boot/efi/EFI/ubuntu/grubx64.efi .
$ sudo sbattach --signum 1 --detach grubx64.sig --remove grubx64.efi
$ sudo sbverify --list grubx64.efi
No signature table present

### To decrypt the digital signature using the RSA public key so that it gives the SHA-256 hash of signed file

# 0. Dump Canonical's certificate

$ openssl x509 -pubkey -in  MOK-0001.pem 
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv1s6FnTuIV2uYe2dVqy9
3t5y891+LUxiD6zAbUgIEc+Ni/thHyfMEW7ZVT05VOtAO7G74oU0ecr3e7+6esgQ
LRl9rVnPptTpTg/arlLqTJ6QzsaZDU5nZXhd+dHVOEpKeo+TnH8ao4XbzvqL98Ki
IS2bVEE1EFcTjWy8KQZQSn7qmalopzvHBxsynqAZhw55u2iZLX6TUuX268mb+Svt
uGhJvNmVUEBbxbJxqutcV95x+UAK3VusHoQtUBpS1uHza26QZE9btOsg5GEQ2lrw
6uRC1wHE/iEf2bnAVJVCgVJyH0lkeshsJPEIcAtNpaAy0aAcV6hN46+ljgUFPhBD
oQIDAQAB
-----END PUBLIC KEY-----
-----BEGIN CERTIFICATE-----
MIIENDCCAxygAwIBAgIJALlBJKAYLJJnMA0GCSqGSIb3DQEBCwUAMIGEMQswCQYD
VQQGEwJHQjEUMBIGA1UECAwLSXNsZSBvZiBNYW4xEDAOBgNVBAcMB0RvdWdsYXMx
FzAVBgNVBAoMDkNhbm9uaWNhbCBMdGQuMTQwMgYDVQQDDCtDYW5vbmljYWwgTHRk
LiBNYXN0ZXIgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEyMDQxMjExMTI1MVoX
DTQyMDQxMTExMTI1MVowgYQxCzAJBgNVBAYTAkdCMRQwEgYDVQQIDAtJc2xlIG9m
IE1hbjEQMA4GA1UEBwwHRG91Z2xhczEXMBUGA1UECgwOQ2Fub25pY2FsIEx0ZC4x
NDAyBgNVBAMMK0Nhbm9uaWNhbCBMdGQuIE1hc3RlciBDZXJ0aWZpY2F0ZSBBdXRo
b3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC/WzoWdO4hXa5h
7Z1WrL3e3nLz3X4tTGIPrMBtSAgRz42L+2EfJ8wRbtlVPTlU60A7sbvihTR5yvd7
v7p6yBAtGX2tWc+m1OlOD9quUupMnpDOxpkNTmdleF350dU4Skp6j5OcfxqjhdvO
+ov3wqIhLZtUQTUQVxONbLwpBlBKfuqZqWinO8cHGzKeoBmHDnm7aJktfpNS5fbr
yZv5K+24aEm82ZVQQFvFsnGq61xX3nH5QArdW6wehC1QGlLW4fNrbpBkT1u06yDk
YRDaWvDq5ELXAcT+IR/ZucBUlUKBUnIfSWR6yGwk8QhwC02loDLRoBxXqE3jr6WO
BQU+EEOhAgMBAAGjgaYwgaMwHQYDVR0OBBYEFK2RmQvCKrH1FwSMI7ZlWiaONFpj
MB8GA1UdIwQYMBaAFK2RmQvCKrH1FwSMI7ZlWiaONFpjMA8GA1UdEwEB/wQFMAMB
Af8wCwYDVR0PBAQDAgGGMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93d3cuY2Fu
b25pY2FsLmNvbS9zZWN1cmUtYm9vdC1tYXN0ZXItY2EuY3JsMA0GCSqGSIb3DQEB
CwUAA4IBAQA/ffZ2pbODtCt60G1SGgODxBKnUJxHkszAlHeC0q5Xs5kE9TI6xlUd
B9sSqVb62NR2IOvkw1Hbmlyckj8Yc9qUaqGZOIykiG3B/Dlx0HR2FgM+ViM11VVH
WxodQcLTEkzc/64KkpxiChcBnHPgXrH9vNa1GRF6fs0+A35m21uoyTlIUf9T4Zwx
U5EbOxB1Axe65oECgJRwTEa3lLA9Fc0fjgLgaAKP+/lHHX2iAcYHUcSazO3dz6Nd
7ZK7vtH95uwfM1FzBL48crB9CPgB/5h9y5zgaTl3JUdxiLGNJ6UuqPc/X4Bplz6p
9JkU284DDgtmxBxtvbgnd8FClL38agq8
-----END CERTIFICATE-----


# 1. extract the public key from Canonical's certificate

$ openssl x509 -pubkey -noout -in MOK-0001.pem > canonical-pubkey.pem
$ cat canonical-pubkey.pem
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv1s6FnTuIV2uYe2dVqy9
3t5y891+LUxiD6zAbUgIEc+Ni/thHyfMEW7ZVT05VOtAO7G74oU0ecr3e7+6esgQ
LRl9rVnPptTpTg/arlLqTJ6QzsaZDU5nZXhd+dHVOEpKeo+TnH8ao4XbzvqL98Ki
IS2bVEE1EFcTjWy8KQZQSn7qmalopzvHBxsynqAZhw55u2iZLX6TUuX268mb+Svt
uGhJvNmVUEBbxbJxqutcV95x+UAK3VusHoQtUBpS1uHza26QZE9btOsg5GEQ2lrw
6uRC1wHE/iEf2bnAVJVCgVJyH0lkeshsJPEIcAtNpaAy0aAcV6hN46+ljgUFPhBD
oQIDAQAB
-----END PUBLIC KEY-----

# 2. Can NOT use the public key to verify the signature table

$ openssl dgst -sha256 -verify canonical-pubkey.pem -signature grubx64.sig grubx64.efi