OpenCore shim-to-cert.tool

[miliuco]

Note: This tool is designed to be used in a Linux environment* but, since it is included in the OpenCore package, I publish the post here. If a moderator sees more appropriate moving to another sub-forum, go ahead.

* (it works also on Windows and macOS).

 

UEFI firmware has the ability to enable Secure Boot so that only digitally signed boot loader files with the same keys embedded in the firmware are allowed. At the moment, with UEFI Secure Boot enabled:

• Windows is able to boot since motherboards usually incorporate Microsoft certificates (sometimes also manufacturer's certificates)
• macOS can boot but requires a hard work for inexperienced users (on a Linux system >> generate the keys and sign OpenCore .efi files with them)
• Linux can boot but first it is necessary to embed in the firmware the digital signature embedded in the bootloader files (especially shimx64.efi).

In last step, booting Linux with UEFI Secure Boot enabled, is where shim-to-cert.tool plays its part. shim-to-cert.tool is designed to extract OEM signing certificate public key (and full db, dbx if present) from grub shim file. I have used a current version of Ubuntu (20.04.3 LTS) but I suppose this is valid for other distributions.

 

These are the instructions:

• Boot Ubuntu 20.04.3 LTS
• Run Terminal in home folder
• Create working dir (this makes subsequent work easier).
  mkdir /home/yo/Shim-to-cert
• Copy Grub shim file into working dir. We are not really going to make any modification in shimx64.efi, we only need it to extract its keys.
  sudo cp /boot/efi/EFI/ubuntu/shimx64.efi /home/yo/Shim-to-cert/
• Copy shim-to-cert.tool from OpenCore into working dir. The only files required in this folder are the tool and the grub shim file.
  cp OpenCore-0.7.4-RELEASE/Utilities/ShimToCert/shim-to-cert.tool /home/yo/Shim-to-cert/
• Cd to working dir.
  cd Shim-to-cert
• Run the tool. It needs the shim file as argument. In this way, we extract the signing certificate from grub shim file.
  sudo ./shim-to-cert.tool shimx64.efi
• If everything went well, this is the Terminal output.
  Secure Boot block list found and saved as vendor.dbx.
  Certificate extracted as CanonicalLtd.MasterCertificateAuthority.pem.

We need CanonicalLtd.MasterCertificateAuthority.pem (Canonical digital signature ) and vendor.dbx file (blocking blacklist, sites which match the block list are known unsafe or hackable by a malicious actor).

 

The next step is to shove CanonicalLtd.MasterCertificateAuthority.pem and vendor.dbx into the firmware. This can be done from the firmware BIOS or with KeyTool that is copied to the EFI folder of a USB device with the name bootx64.efi. This task is outside the scope of this post whose purpose is to describe OpenCore shim-to-cert.tool. It can be detailed in a future post.

 

After including .pem and .dbx files into the firmware, Ubuntu can boot with UEFI Secure Boot enabled.

 

Note: as @Bmju says, "the signature (.pem) is the part that is required to make secure boot work, whereas the blacklist (.dbx) is what is recommended in addition to make the machine more secure".

 

I would like OpenCore developers to comment if the process I have described has any mistakes that need to be corrected. Either way, thank you all for your work.

 

Edited October 21, 2021 by miliuco

[Bmju]

TL/DR: What @miliuco said, more or less!

 

But for some more info.

 

Firstly, you can use shim-to-cert.tool on macOS or Windows, not just Linux:

 

Spoiler

 

You can run `shim-to-cert.tool` on macOS if you install the packages `binutils`, `openssl` and (possibly, the tool will warn if it is required) `efitools`, e.g. using `brew`.

 

You can also run the tool on WSL/WSL2 under Windows, with the same dependencies.

 

Note: if you run it on macOS you need the installed `binutils` package in your path to run `shim-to-cert.tool` but you want it _not_ in your path if building OC (as it puts the wrong version of the `strip` utility in the path).

If using on macOS or Windows, you most likely need access to the ESP partition to get at the shim for your Linux distro, e.g. with `mountvol /S E:` on Windows elevated command prompt (works but does not appear in file explorer unless this is also elevated), or `sudo mount -t msdos /dev/disk0s1 /Volumes/efi` on macOS (where you need to create the dir first, and you need to double-check that `/dev/disk0s1` is correct for your system).

 

Also, I would warn, if you really want as _secure_ a boot as possible - as opposed to just making Secure Boot work - then you should not ignore any block lists which are found, as their meaning is: "things signed by the key are safe ... except for things which match the block list, which are known unsafe" ... where "unsafe" doesn't usually mean malicious, it means "known hackable by a malicious actor".

Edited October 21, 2021 by Bmju

[miliuco]

Thank you @Bmju for the info. 

I haven’t tried the tool on macOS or Windows, I didn’t thought it. 
But as we need shim file from grub, and it’s intended to boot Linux with secure boot enabled, it seems good idea to do it on Linux.

I see the importance of the vendor.dbx blacklist being underestimated, you have convinced me that it's important also to shove it into the firmware.

I’ll correct the text as per your comments. 
 

[Bmju]

43 minutes ago, miliuco said:

... it seems good idea to do it on Linux. ...

Partly depends what you are doing with it. Windows has some useful PowerShell secure boot variable commands, though so does Linux. And you can at least imagine a case where you want to enable secure boot for Linux ... before you can boot it. So for those kind of reasons, I just wanted to clarify that running it on the other OSes is an option.

For 'playing around' with Secure Boot, the dbx is ofc not so important, for really trying to make your machine as secure as possible, it is. So it's maybe worth clarifying that the signature is the part that is required to make secure boot work, whereas the blacklist is what is recommended in addition to make the machine more secure? 🙂

[miliuco]

1 hour ago, Bmju said:

Partly depends what you are doing with it. Windows has some useful PowerShell secure boot variable commands, though so does Linux. And you can at least imagine a case where you want to enable secure boot for Linux ... before you can boot it. So for those kind of reasons, I just wanted to clarify that running it on the other OSes is an option.

For 'playing around' with Secure Boot, the dbx is ofc not so important, for really trying to make your machine as secure as possible, it is. So it's maybe worth clarifying that the signature is the part that is required to make secure boot work, whereas the blacklist is what is recommended in addition to make the machine more secure? 🙂

 

Well written to be well understood, clarifying...

Thanks again!

Edited October 21, 2021 by miliuco

[miliuco]

@Bmju

I have tested the tool on macOS and Windows. I'm sure sure you know what I'm posting here, but it's what I've learned today and I think it can be useful to other users.

 

Both operating systems have binutils as dependency (collection of binary tools to give the GNU system the facility to compile and link programs).

 

Windows 10 / 11

 

There is an infrastructure within Windows 10 and 11 which is not widely used: the Windows Subsystem for Linux (WSL), upon which we run a genuine Ubuntu user-mode image provided by Canonical. This adds native Bash with support for Linux command-line tools which run directly on Windows in an environment that behaves like Linux.

 

How to install WSL

• Run PowerShell as administrator.
• Run wsl --install

  PS C:\Users\miliuco> wsl --install
  Installing: Virtual Machine Platform
  Virtual Machine Platform has been installed.
  Installing: Windows Subsystem for Linux
  Windows Subsystem for Linux has been installed.
  Downloading: WSL Kernel
  Installing: WSL Kernel
  WSL Kernel has been installed.
  Downloading: GUI App Technical Support
  Installing: GUI application technical support
  GUI Application Support has been installed.
  Downloading: Ubuntu
  The requested operation was successful. The changes will take effect after the system reboots.

   

On WSL, Windows disks are in the path /mnt/c, /mnt/d and so on. Windows files and folders can be accessed from here.
 

Run Ubuntu app >> a bash Terminal windows is displayed >> run sudo apt-get install binutils >> move to the directory containing shim-to-cert.tool and shimx64.efi >> run ./shim-to-cert.tool shimx64.efi >> output:

Secure Boot block list found and saved as vendor.dbx.
Certificate extracted as CanonicalLtd.MasterCertificateAuthority.pem.

We can quit Ubuntu app with exit + ENTER.

 

macOS

 

Current version of binutils source code is binutils-2.36.tar.gz.

https://ftpmirror.gnu.org/binutils  >> binutils-2.36.tar.gz >> ./configure >> make >> sudo make install.

 

Running the tool gives to me an error: objcopy: shimx64.efi: file format not recognized.

 

EDIT: But if binutils are installed through Homebrew instead of compiling the code, all work fine.

 

Edited October 21, 2021 by miliuco

[Bmju]

You need to install Homebrew (https://brew.sh/), then install binutils with Homebrew, i.e. `brew install binutils`. You're installing a copy of the GNU binutils which are not the Mac binutils; in this case because you want to extract bits from a PE/COFF file (I guess they deal with ELF as well) not a macOS Mach-O file. When you install binutils with brew you'll see a message saying that it is not adding binutils to the path - this is why, because it will break the (already installed) macOS binutils which deal with Mach-O format.

 

As per the message from Homebrew, you can permanently install the GNU binutils first in your path by adding `export PATH="/usr/local/opt/binutils/bin:$PATH"` to `.profile` - but better is to just run `PATH="/usr/local/opt/binutils/bin:$PATH"` once in your current shell, which will add the GNU binutils first in your path, just until you quit the shell.

 

After all that, `shim-to-cert.tool` should run on macOS.

 

(EDIT: I assume there's some way to make the GNU binutils which you downloaded directly work ... but I don't know what it is, it's easier to let the people who maintain the Homebrew package do that... 😉)

Edited October 21, 2021 by Bmju

[miliuco]

@Bmju

Thank you again for all the info.

Today has been a productive day for me (thanks to you).