• The integrity of the software we have just downloaded.
• The authenticity of the package.

Checking these two things will ensure that the download went well, and that the software is authentic (and not malware, for example).

For the impatient, here is the process assuming that we have downloaded:

• A software package we want to use, in the example software.pkg
• A file containing the reference hash; in the example, software.pkg.sha256
• A file containing the signature of the Software Author; in the example, software.sig
• The public keys of the Software Author; in the example, author.gpg

    $ sha256sum -c software.pkg.sha256          # 1. Check the download integrity
    $ gpg --import author.gpg                   # 2a) Import downloaded public keys
    $ gpg --keyserver hkp://<server> \
                   --search-keys <shortID>      # 2b) Import public keys from a server
    $ gpg --verify software.sig software.pkg    # 3) Verify signatures
    $ gpg --list-public-keys --with-sig-check   # 4) If needed, check web of trust

These commands, why we run them, how they work, and how we should understand them, are discussed next. All the commands are Linux-specific, but information on Windows equivalents can be found in plenty of sites and I will probably write other post in the next few days.

Checking the Integrity of a Download

We want to check the integrity of a downloaded package to ensure that there were no transmission errors, and that nobody between our computer and the server exchanged the package for something else. We are checking that the download went well and we obtained whatever there was in the server: no more, and no less.

To do this, we verify the checksums of the files. Checksums are representations of the content smaller than the content itself, calculated by algorithms that ensure a stupidly small probability of two different files producing the same result. Some of those algorithms are members of a family called “hashes”. Most useful checksums, and hashes particularly, always have the same length.

If there was a single bit of the file that got changed over the wire, the checksum calculated in our computer over the corrupted file would be different than the checksum of the server’s file: the checksum wouldn’t verify.

In order to calculate a checksum we only need the file itself, and the right program installed.

For example, if we go to the downloads page for VSCodium, a fully Open Source version of Visual Studio Code, we can see that for every package there is an extra file, ending in .sha256:

codium-1.55.2-1618361370.el8.x86_64.rpm
codium-1.55.2-1618361370.el8.x86_64.rpm.sha256

This extra file contains the reference checksum calculated over the server’s file, and that is the exact same value that we should obtain in our computer from the downloaded copy.

The idea is to download both files to the same directory, and run the following command sha256sum -c over the checksums file:

$ sha256sum -c codium-1.55.2-1618361370.el8.x86_64.rpm.sha256 
codium-1.55.2-1618361370.el8.x86_64.rpm: OK

What happened here is that the program sha256sum checked (-c) that the reference checksums present in the file codium-1.55.2-1618361370.el8.x86_64.rpm.sha256 could be calculated locally using the downloaded file. The .sha256 file content is the following:

75b9f844c22c98d4da33e64b6c7c49e8b4d0d94a438e4f8ce976e7e54b40a682  codium-1.55.2-1618361370.el8.x86_64.rpm

That line is a “properly formatted SHA256 checksum line”, which is built by a SHA256 hash, two (2) spaces, and the name of the file the hash was calculated from in the server. From there, the check sha256sum -c performs is just to find a file that has the same name as in that line, calculate its SHA256 hash, and compare it with the first part of the line.

In this case the verification was complete and correct.

A file like that can have plenty of lines, not just one, and sha256sum -c will run all the checks in a batch.

Another possibility can be to have only the file to download, and the SHA256 line in the website, for you to see. In that case, we’d download the file and get the SHA256 locally by executing the sha256sum over the downloaded file, without -c:

$ sha256sum codium-1.55.2-1618361370.el8.x86_64.rpm
75b9f844c22c98d4da33e64b6c7c49e8b4d0d94a438e4f8ce976e7e54b40a682  codium-1.55.2-1618361370.el8.x86_64.rpm

That would give us the previously mentioned line, and we should just visually compare the hashes.

When the checksums are correct, we are sure that the download went well, but nothing else. It’s up to us whether or not we trust that the publisher of the software is publishing authentic software, made by its true authors.

Checking the Authorship and Authenticity of the Software

If we don’t trust the Software Publisher, that is to say, the website or the server we downloaded the package from, then checking the integrity of the download is not enough. The Publisher could have offered anything else in that file, and calculate a perfect valid reference checksum for a counterfeit package.

In such case of distrust, we want to check the software authorship, and therefore its authenticity. We can do that by obtaining a cryptographic signature of the package, created by the Software Author, and verifying it cryptographically.

There are many cryptographic signature mechanisms and algorithms, but here we will focus on signatures produced using asymmetric cryptography because they are the ones used most often, if not the only ones used to sign software.

In most asymmetric cryptography frameworks like PGP and GPG, the signature works as follows:

• A Software Author would have two keys: Private or Secret key, and Public Key. They are generated in the same process and they are inextricably linked.

• The Public Key is generally available; the Secret Key is never shared with anyone.

• Using their Secret Key, the software author produce a cryptographic signature, which in the case of PGP (or GPG), it consists in:

• calculating a hash, similar that the ones we’ve just discussed,

• signing the hash using the Secret Key and a cryptographic singing algorithm.

The idea of signing a hash and not the file itself is that a file can have a size from a few bytes to Gigabytes or Terabytes. By signing the hash, which is much smaller and has a fixed length, the result is produced in a predictable amount of time.

As the Secret and Public Keys are an inextricable pair, only the Public Key of the software Author will verify correctly the signature produced with the corresponding Secret Key. As the Public Key is made available, everybody can verify the signatures using the right software.

Here’s what we need to do to check a signature with a real example, a Manjaro GNU/Linux ISO file.

First: Download the software from an, in principle, trusted server. In this case, we will download a file named manjaro-xfce-21.0.2-210419-linux510.iso from the Manjaro XFCE download page. This file has an associated GPG signature that we will also download, manjaro-xfce-21.0.2-210419-linux510.iso.sig, and a SHA1 hash printed in the web page, 7d9d5d886188ebb0a05c9ceeabdb068fb2544feb.

Second: Check the hash as we discussed earlier in this post, to make sure that the package is uncorrupted. In this case we need to compute the hash and compare it visually with the reference one, present in the download page.

$ sha1sum manjaro manjaro-xfce-21.0.2-210419-linux510.iso
7d9d5d886188ebb0a05c9ceeabdb068fb2544feb  manjaro-xfce-21.0.2-210419-linux510.iso

It verifies, so let’s go with the GPG signature.

Third: For us to be able to verify a GPG signature, we first need to obtain the public keys of the Software Author. In this case, Manjaro offers two sets of public keys, the general Manjaro ones, and Philip Müller’s, “just in case we didn’t trust the server where Manjaro made the general keys file available”. That statement is a bit of food for thought that we’ll discuss later, and a good example because it shows two ways for obtaining public keys.

First, we download and import the Manjaro general keys.

$ wget https://[url to the manjaro keys]/manjaro.gpg -O manjaro.gpg
$ gpg --import manjaro.gpg

On April 28th 2021 this imported 22 keys into the keyring, allowing us to verify packages signed by several people and machines at Manjaro.

To download Philip Müller’s keys from a public PGP Key Server, use the following:

$ gpg --keyserver hkp://pool.sks-keyservers.net --search-keys 11C7F07E
gpg: data source: http://194.95.66.28:11371
(1) Philip Müller (Called Little) <REDACTED@manjaro.org>
      2048 bit RSA key CAA6A59611C7F07E, created: 2012-05-05
Keys 1-1 of 1 for "11C7F07E".  Enter number(s), N)ext, or Q)uit > 1
gpg: key CAA6A59611C7F07E: "Philip Müller (Called Little) <REDACTED@manjaro.org>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

Note that Enter number(s), N)ext, or Q)uit > is an actual prompt and we have to select the key, 1 in this case. Pay attention to the CAA6A59611C7F07E part: is an identifier for the key. Another thing to note is that the string we used to search the key (11C7F07E) is part of the key identifier. The lower part of a key’s ID is often referred to as “short identifier of the key” for obvious reasons.

The keys can also be searched by some other identificative fields, for example an email (real email omitted for privacy reasons!):

$ gpg --keyserver hkp://pool.sks-keyservers.net --search-keys "REDACTED@manjaro.org"

gpg: data source: http://194.95.66.28:11371
(1) Philip Müller (Called Little) <REDACTED@manjaro.org>
      2048 bit RSA key CAA6A59611C7F07E, created: 2012-05-05
...

The key ID identifies the pair of keys, not just the Public Key. It is important to know the ID of key pair, as it is the only way to really identify a key used to produce a signature and therefore the key needed to verify it. There can be many keys for a single email address, not all of them legit. The way to know the key needed to verify a signature is try to verify it without importing any key, as it will output the ID of the key pair that was used:

gpg: Signature made Mon 19 Apr 2021 18:47:28 AEST
gpg:                using RSA key 3B794DE6D4320FCE594F4171279E7CF5D8D56EC8
gpg: Can't check signature: No public key

Fourth: If the download of the iso verified the hash on previous steps, then check the signatures:

$ gpg --verify manjaro-xfce-21.0.2-210419-linux510.iso.sig  manjaro-xfce-21.0.2-210419-linux510.iso
gpg: Signature made Mon 19 Apr 2021 18:47:28 AEST
gpg:                using RSA key 3B794DE6D4320FCE594F4171279E7CF5D8D56EC8
gpg: Good signature from "Manjaro Build Server <build@manjaro.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3B79 4DE6 D432 0FCE 594F  4171 279E 7CF5 D8D5 6EC8

In this case, the signing key was one of the keys present in the file manjaro.gpg, the one for the Manjaro Build Server with identifier 3B794DE6D4320FCE594F4171279E7CF5D8D56EC8. The verification process was correct, so we need that something called Manjaro Build Server is the creator of the ISO we’ve just downloaded.

Fifth: If we want to check the authenticity of such Manjaro Build Server dude, we can do so by validating its key using Philip Müller’s key (provided we trust him). That can be done by check the web of trust for Manjaro Build Server key, and see whether Philip is part of that web of trust. For this one, issue the following command:

$ gpg --list-public-keys --with-sig-check

Within the output of this command we can see all the public keys we have in our keyring, and who has signed them. Signing a Public Key with your own secret key is, in this context, the ultimate vouching act. In the case of the Manjaro Build Server, which we can identify by looking at its identifier, we can see that within its signers there is Philip Müller (the ID is the same previously imported CAA6A59611C7F07E):

pub   rsa3072 2020-10-28 [SC] [expires: 2022-10-28]
      3B794DE6D4320FCE594F4171279E7CF5D8D56EC8
uid           [ unknown] Manjaro Build Server <build@manjaro.org>
sig!         8238651DDF5E0594 2020-10-29  Matti Hyttinen <REDACTED@manjaro.org>
sig!         DAD3B211663CA268 2020-10-29  Bernhard Landauer <REDACTED@manjaro.org>
sig!         084A7FC0035B1D49 2020-10-29  Dan Johansen (Manjaro) <REDACTED@manjaro.org>
sig!         CAA6A59611C7F07E 2020-10-29  Philip Müller (Called Little) <REDACTED@manjaro.org>
sig!3        279E7CF5D8D56EC8 2020-10-28  Manjaro Build Server <build@manjaro.org>
sub   rsa3072 2020-10-28 [E] [expires: 2022-10-28]
sig!         279E7CF5D8D56EC8 2020-10-28  Manjaro Build Server <build@manjaro.org>

Therefore, if we trust Philip Müller, we can trust the downloaded ISO signature because Philip has endorsed the Manjaro Build Server by signing its key with his own.

Package Managers

The above process is what we need to do for the software we download manually, from the web.

Package Managers for GNU/Linux, as apt, pacman or yum among others, for Windows as Chocolatey, and for macOS as homebrew, should do all the avobe automatically, transparently and by default. Check the documentation of the system and package manager you use (and trust) to check specific details.

This is All About Who We Trust

If we pay attention to how this works, we’ll se that all this is about trust. There is no technique that would give us 100% certainty of the authenticity of a software package. We need to judge if we trust the Software Publisher, and if we trust the Software Author, and if we believe their public keys really belong to them –the actual persons or companies. Check after check, we are traversing a web of trust that is effective as long as we can find a point we can trust.

Further Reading

A good introduction of the web of trust, and links to further material, can be found in the Wikipedia.

More on the cryptographic suite used by most software publishers, authors and distribution channels can be found in the GNU Privacy Handbook.

I came across the cause of the problem and its solution; keep reading to know more.

The Symptoms

At some point you need to activate User Home service as per the requirements of some other package (for example, Synology Mail), or just because you want to work through SSH, or any other valid reason. Although you activate it, the dependent package keeps asking you to enable it. Or, if you just enabled it to use home folders via SSH, although you land on a home directory when you log in through SSH, you can’t see it through DS File or File Station:

In the above picture you should see a folder for each user under homes, plus a home directory that would host your files (it’s like a symbolic link dynamically created when you log in to the NAS through DSM or DS File).

If you try to disable and re-enable User Homes Service, DSM shows a sad and brief “Operation Failed” error pop up, and in Log Center you just see a useless message “User home service disable failed” like the one below:

The Problem

The problem is that the user homes’ hosting folder, named homes, should be created in one of the main volumes inside the disk array, for instance, /volume1/homes, and a symbolic link back should be created at /var/services/homes. Instead, in this case the homes folder was created in that location directly, as a regular folder (/var/services/homes). We can check it by doing SSH to the NAS:

user@hostname:~$ pwd
/var/services/homes/user
user@hostname:~$ cd ../..
user@hostname:/var/services$ ls -lda homes
drwxr-xr-x 6 root root 4096 Feb 5 08:00 homes 

The expected result of a successful User Home service activation is this one instead:

user@hostname:/var/services$ ls -lda homes
lrwxr-xr-x 6 root root 4096 Feb 5 08:10 homes -> /volume1/homes 

Not only you can see where it points, but also the l flag on the folder permissions, meaning link, instead of a d from directory.

It is important to note that, although the user still has its home folder that works, the user homes created this way are outside the disk array and in the operating system’s filesystem. This fact have several consequences, all of them dangerous for our files, for DSM’s stability, and therefore for our NAS reliability.

In the first place, it causes almost every Synology package that depends on the User Home service to fail. Synology packages usually operate with directories under the volumes created inside the disk array, not under /var/services/, and that’s why Synology Mail didn’t detect the user homes directories and kept asking for User Home service to be enabled. As with Synology Mail, if the NAS is kept in this situation, the files in those directories won’t be accessible by any backup or synchronisation service, and something as simple as updating DSM can have all the files under /var/services/homes/ wiped, and lost forever.

Another consequence is that all user home directories will be lost in the event of machine upgrades or replacement, meaning that in the event of moving the disks to a new NAS, those user home directories won’t be carried over.

A much worse scenario would be the one where we run out of space in the system’s partitions because we put too many files under our home directories, phisically located under /var, causing DSM to crash and, probably, to have problems to boot.

The Solution

Solving the problem is as easy as login in through SSH to back up our files and delete the /var/services/homes folder:

user@hostname:~$ cd /var/services
user@hostname:/var/services$ tar cfz /volume1/[dest. folder]/homes-backup.tgz homes
user@hostname:/var/services$ sudo rm -rf homes

After that, we create a symbolic link to /volume1/homes:

user@hostname:/var/services$ sudo ln -s /volume1/homes homes
user@hostname:/var/services$ ls -lda homes
lrwxr-xr-x 6 root root 4096 Feb 5 08:10 homes -> /volume1/homes

Finally, we log into the DSM web interface, to disable without error and re-enable the User Home service.

No services should fail on activation, and the DSM File Station should show all users’ home directories; time to restore the previous users’ home folders contents if needed.

Contrary to the mainstream trend of such a disablement and proceeding with an outdated bootstrap, security-wise, many distributions do support Secure Boot since a while ago.

In this post I will provide some links, references, and “glue text to make sense” in order to provide clarity about Secure Boot: what it is, what it provides, and what it takes from us –mostly in terms of user experience, or friction.

I do not want to reinvent the wheel or take credit for the existing state of the art, but to provide some insight that I hope it will be easy to understand to the Linux novel users. Or at least, to provide a lead that can be followed to read more and understand what’s happening.

Structure

You will find:

1. What I assume you know, or a list of things for you to search about.
2. A process to install a Linux system with Secure Boot enabled.
3. Post-Install situations affected by Secure Boot
4. What is Secure Boot, and what’s it based on.

What I assume you already know (a.k.a., what you’re supposed to search in the interwebs if not!)

I assume that you are familiar with the following concepts, which I try to summarise. But, please: use your search engine.

• Kernel: it’s the hert of the operating system. It provides the applications with access to the hardware.
• Modules: specialised code that the Kernel will load to tailor its capabilities to very specific hardware or configurations. Many times, when it allows the Kernel to understand a piece of hardware, it can be called “a driver” like in Windows lingo, but there are modules for many other things.
• Root password: it’s the password of the root user, which is the most powerful authority in a Unix or Unix-like system, as GNU/Linux for instance. Absolute privileges.
• BIOS: stands for Basic Input and Ouput System, and it was the way that older (early 2000’s and before) computers had to connect the Operating Systems to the hardware. This included a boot menu and a very few more options, and many specialised configurations for some hardware devices had to be done by plugging, unplugging or changing physical jumpers in the motherboard.
• (U)EFI: stands for (Unified) Extensible Firmware Interface. It’s the evolution of BIOS, looks after the same hardware to operating system bridge. It is much more advanced and comes with many more options, many of them enabled for modern system by default, like the GUID Partition Table for the Disks, and the Secure Boot.
• GUID Partition Table. A modern partition schema that identifies partitions on the disk by giving them Globally Unique IDentifiers, rather than names. Amongst other things, supports much larger disk sizes.
• Secure Boot deserves a whole section on its own. Go and check “What is Secure Boot” at the end of this post.

Installation Process

Check whether you actually have UEFI

First of all, have a look at what you have in your computer: whether BIOS or EFI. If you have BIOS you can skip the whole article, because Secure Boot was introduced in the UEFI.

If you’re not sure which system your motherboard uses, and if you still have Windows there, check the following:

• Look for an EFI folder within c:\windows\boot
• Open the Disk Management Utility and check if you have a partition labeled EFI in your system disk, like this one:

If you don’t have Windows or you are unsure,

• Reboot the computer and look for a message telling you to press a key to enter setup.
• Press that key, quick!
• No worries, it happens to everybody. Reboot and try again.
• Once inside, and without changing anything, look for indications of an EFI system: search for options like “Secure Boot”, “Legacy/UEFI” boot mode.

If your system shows any of the above symptoms, you have an UEFI.

Choosing a distribution that supports Secure Boot

There is a way to query distrowatch to get a list of the distributions that may support Secure Boot by searching included packages like shim or efibootmgr, but the best way is to check your favourite distribution’s documentation (kudos to firmwaresecurity.com for the queries hint).

The good news is that the support of Secure Boot is already in the Kernel and the base system for all of them, so it would be a matter of time and ideology for it to arrive to your computer. If you want to install a different distribution than those, you’ll have to disable Secure Boot in your EFI.

Download and verify an ISO, preferably a Live one with non-free firmware and modules included

It is advisable, always, to download an ISO installation image that offers you the possibility of trying Linux in your system without installing it first. This will give you an idea of whether or not your installation media will have the required modules for your hardware, most precisely (and critically neccessary) one module for the graphics adapter and another one for the network. Also, depending on your hardware and distribution, you may have to download specifically an ISO with non-free software included for it to work! This is almost always necessary (99%+ cases) in the case of Debian and most laptops.

Download your distribution in ISO format, as usual, and look for a way to verify the files you download. Most every website that offers free or open source software these days will have a side or footnote telling offering you “the hashes” or the “sums”: MD5 or SHA checksum strings.

Checksums are strings that represent the contents of a file, much smaller than the files they represent. They are generated by a mathematical algorithm that ensures that the probability of getting the same result with different files is ridiculously small. So ridiculous that it’s difficult to explain, but the chances are cosmically low.

These are techniques that allow you to check that the ISO you downloaded has not been corrupted by the download process, and more importantly, that they are authentic. It helps you know that the mirror or the server where the actual file is hosted, usually different than the server that publishes the checksums, has not been compromised: you’re downloading an authentic image, without any malware with it. What they do is run the same procedures that you’re about to run, in their side, and tell you to check that you get the same results.

If your distribution publisher offers you SHA verification sums, open Windows PowerShell and run Get-FileHash over the ISO you just downloaded:

If your distribution publisher if offering MD5 sums, then open the regular command prompt and use certutil -hashfile over the file.

Whichever method you use, your local result should match with the check sums provided by the software publisher (leaving uppercase or lowercase aside).

If they provided some other methods, check their documentation.

Creating a USB that boots under UEFI conditions

In order to create a bootable USB drive under UEFI’s newer boot schema, that USB has to be formatted using GPT (Guid Partition Table), as the MBR (Master Boot Record) drives are considered legacy!

To do that, you can use Rufus to create the USB. Rufus is an open source program that you can download from its official site https://rufus.ie/, and will offer you a simple, but powerful interface to create the bootable thumbdrive. Just make sure that you select GPT as Partition Scheme, and UEFI as Target System, leaving all other options by default (unless you wanted a persistent partition to use in a Live System):

Reboot in Linux

• Reboot the computer and look for a message telling you to press a key to show the boot menu.

• Press that key, quick!

• No worries, it happens to everybody. Reboot and try again.

• Search for your USB drive.

• They are usually by the EFI the word “USB” and the brand of the device, plus some other model numbers and maybe the capacity.

• Select it and press the Enter key.

Select the option to run Linux, or to try Linux without installing.

If everything works, specially the graphics and the network, then you’re good to go and install it.

Installing with Secure Boot: things that can happen.

In most of the cases, the installation process will be smooth and without any surprise. But, in some cases, either:

• The installation would remain stopped in a package for too long. If you expand the details of the installation process, you may see something like the below image.
• You will prompted by the system that some third party software needs to be installed and you will to do some funky stuff for it to work, something similar to this:

This is caused by Secure Boot, and nothing is wrong. What is happening is the following: the system found that it needs to install a package that will be loaded at boot time, but it is not signed. Secure Boot requires the software that runs at boot to be signed by a trusted key. The installation process can create a key for you, called “Machine Owner Key”, and sign the software with it, but in order to make the EFI trust the signature, it needs you to collaborate.

• Press the Enter key, or the tab key to focus OK and then Enter, or click OK if the prompt is run in a graphical environment.
• In the next screen, you will be prompted to set a password: do it and jot it down in a paper, as you will prompted to write it in the first reboot.

Here be dragons: if you have a non-english keyboard, refrain yourself from using symbols that may be in a different key than the one in a US layout keyboard, as they can cause problems when typing the password later.

Once done, the installation should continue.

When you finish installing the system, it will reboot.

If you were prompted with such an ugly message, you will see a succession of screens like the following (taken from this Gist, as they are the same in any case) in this first reboot:

Select Enroll and press Enter.

Press Continue. Yes, it is a weird screen. If you press View key 0 you’ll see some information about the key you are enrolling, but it’s quite technical and can be nonsense, specially if it was the installation program who created the MOK key.

Select Yes.

Type the password you’ve in your piece of paper and press Enter.

Press Enter

When the system reboot, and provided that the installation program meets its quality goals, things should work.

Post-Install Miscellanea

Manually signing binaries (e.g.: modules)

This is the case of a module compiled by hand, or when you install unsigned modules with Secure Boot installed, in more crude distributions like Debian.

The steps for Debian (credit to its official documentation and to my experience) are:

• Compile your software.
• modprobe will fail. Check that it is due to a Kernel Lockdown state imposed by the Secure Boot, to discard other errors. In dmesg, search for something with similar semantics to this:

Lockdown: modprobe: Loading of unsigned module is restricted; see man kernel_lockdown.7

• If you have already enrolled a Machine Owner Key (MOK) yourself, and it is available for you, put it in your home directory and jump to step “Open a terminal to sign the binary”. Otherwise, continue here.
• Install the packages mokutil and openssl.
• Open a terminal and create a MOK (Machine Owner Key) with the following process (# commented), documented here:

    # Go to your home folder
    cd ~
    # Create a Machine Owner Key pair valid for 100 years. 
    # In the following, replace "gabriel" for your user name
    openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -days 36500 -subj "/CN=gabriel/" -nodes

• You will obtain two files, MOK.der and MOK.priv in your home folder. Enroll the keys in your EFI

    # If you don't have sudo installed, run `su` and type the root password
    # before the following commands without sudo
    sudo mokutil --import MOK.der
    # This will prompt for a one time password to set up.

• Reboot the computer. You will be promted with the blue screens of section “Installing with Secure Boot: things that can happen”. In this case, if you select the options to View Key 0, you will be able to see your name and the name of your computer. In my example, I saw “gabriel@rodas”, and rodas is my computer named after this beach very close to my hometown.
• Open a terminal to sign the binary. Follow the process changing the /path/to/file.ko with the path to the file you need to sign.

    # Assuming that you have kernel version X.Y.Z
    # Replace "gabriel" by your username.
    cd /lib/linux-kbuild-X-Y/
    sudo scripts/sign-file sha256 /home/gabriel/MOK.priv /home/gabriel/MOK.der /path/to/your/file.ko

• Try to load again the module

  sudo modprobe /path/to/your/file.ko

It should work now. This is the most common use case for this.

Here be dragons: hold your horses, one last thing before you go. Take these two files, MOK.der and MOK.priv, away from your user directory, hide them in a safe place. Personally, I keep them attached to an entry in my password manager, well encrypted. They are the door for someone to sign any malware so it can run at your computer’s boot!

What about signing a custom Kernel?

If you need to sign a Kernel, the /path/to/your/file.ko looks like /boot/vmlinuz-[KERNEL-VERSION], and probably you will have to follow more steps. Although I haven’t had the need for it, I found several forum and Stack Overflow questions that pointed to this document as a valid process to do it.

What is Secure Boot

Secure Boot is a mechanism designed to protect the process of booting your computer, that is to say, making your boot secure. It is not a very creative name.

It was introduced at some point in the UEFI specifications, and it made a weird entrance in the scene because some poor communications skills and shady decisions from Microsoft. They told at some point that, for any PC machine to be Windows-Certified, they should pre-ship a cryptographic key (similar to the Machine Owner Key we’ve used before in this post, but Microsoft’s) to digitally verify the Windows bootable parts and the Kernel. They didn’t specify at the point that they didn’t care whether the Secure Boot could be disabled, or that many other keys should be able to be shipped or installed alonside Microsoft’s! Thanks to that narrow statement, the community went crazy and, although they fixed the statement pretty much immediately, for many time Secure Boot was seen as a Microsoft attempt to close PC hardware to them. You can check this story here. It is true that the controversy continued for a while, specially related to ARM devices, but as always: technology isn’t bad by itself, it is us who make good or bad use of it.

Indeed, Secure Boot is (to me) pretty awesome as it is a simple but powerful way to protect the boot sequence of your system against malware.

The “Secure” word of Secure Boot comes from Information Security, as it is based on asymmetric criptography. It works in such a way that, for the EFI to load any code at boot time, being it a Kernel, modules, or the GRUB itself, such code has to be cryptoraphically signed by a trusted key. Let’s decypher such two sentences.

• Asymmetric cryptography refers to a compendium of techniques that are based in a pair of keys, public key and secret key. They public key is meant to be available to everybody, while the secret key has to be kept secret to its owner.

• That par of keys are often packed in a single software artefact called “certificate”, in such a way that the private part is protected by a passphrase. It can also be splitted in such a way that you can produce a certificate that will only contain the public key, to be able to share it. It provides two operations: encryption and signature.

• Asymmetric Encryption works the following way: if I want to encrypt a message for you, so that only you are able to understand it, I will use your public key and a lot of standard maths. Once done, only your private key, plus a lot of standard maths, can decrypt it!

• Asymmetric Signature works the opposite: if I want to prove you that it was me who wrote a message, I will sign it using my private key and a lot of standard maths. You will be able to check the signature using my public key and a lot of standard maths.

• If someone changes a single character of that message, the signature won’t be valid anymore.

• The last point is great: a signature identifies the author of a message, and protects the communication against tampering.

• We can cryptographically sign a message, or a binary file like a Kernel, or a module.

• According to the above, when we sign some code and install it to be loaded at boot time, like a Kernel or a module, the EFI need to have available the public key to check the signatures. This defines the need of enrolling public keys in the EFI.

• You can create a pair of keys, enroll the public key, and use them to sign software you create or compile, if you are the root user of a GNU/Linux system. When you create your own pair of keys, they are together called a Machine Owner Key, or MOK.

• Enrolling a public key in the EFI is a process not only means to make available the public key to the EFI: it also makes the EFI trust that signature. Practically speaking, it will ultimately trust the software that is signed with a trusted key, and load and execute it with all the consequences.

• Only a trusted software manudacturer, or an administrator of an operating system (root user in Linux) can enroll a key in the EFI and manually sign software.

• Enrolling a key in the EFI is a process that requires such an administrator to collaborate and actively accept and prove his or her identity after a reboot. It cannot be automated by a malware process.

A bit of recap. If you have the system bootstrap process checking signatures of the binary code that it loads, this means a lot of security.

Let’s understand the two main vectors of attack it mitigates.

1. Only trusted signers (meaning software manufaturers, or you) can install code that runs automatically in the bootstrap of the system. That means, that if some random guy comes to your desk with a USB while you’re away, he won’t be able to infect your computer’s bootstrap by putting some modules or writing code in the bootable partitions. He or she would have to enroll a key, too, and that requires (in Linux) to know the root password, which is meant to be secret and complex. They will have to be able not only to write code to the EFI, which may or may not be a challenge, but to hack the operating system they want to compromise.
2. If you accidentally allow a malware to run in your computer, that malware cannot infect the bootstrap chain even if it has the maximum privileges, as it will require active cooperation by an admin user to create and enroll its own MOK: check back the rest of the article at the point we set up a password, reboot, and type the password when enrolling the key. The only thing you have to do is to never leave your MOK private key in the computer to prevent the malware to sign itself with your own keys!

I hope you didn’t have to search many terms, and that this article was, at least, easy to follow. Feel free to send me some comments to comments (at) gvisoc (dot) com!