Creating Your Own Certificate

A better way to add some flexibility to your Secure Boot configuration is to store your own certificates in the kernel and sign the modules yourself. The problem is that the new key must be signed with a key whose signature already exists in the certificate store, and only the key of the distributor – Canonical – is in the certificate store. Because the private key is (one hopes) known only to Canonical, you can't make modifications. To solve this problem, you must generate the kernel yourself and store the certificate used in the Shim bootloader as a MOK.

Figure 4 shows the procedure. First, you have to generate the new key pair. Second, the private key signs your or third-party modules. The third step is to secure the private key, and the fourth step is to give Shim the public key as the MOK. When you reboot, the Shim certificate manager pops up; use the certificate manager to validate and import the certificate. After the next startup, Linux can use the signed modules.

Figure 4: If you have physical access to the computer, you can integrate your own certificates. The not-particularly-intuitive individual steps toward this objective are summarized here.

To generate the required key pair at the command line, use the following long command:

openssl req -new -x509 -newkey rsa:2048 -keyout ownerkey.priv -outform DER -out ownerkey.der -nodes -days 36500 -subj "/CN=Machine Owner Key of My Company/

Now in the current directory are the private key (ownerkey.priv) and the certificate with the public key (i.e., the owner certificate ownerkey.der). (See also the "Keys, Passwords, and Certificates" box.)

Keys, Passwords, and Certificates

Even the experts sometimes use the terms key, password, and certificate incorrectly. A key is a byte sequence for encrypting data. If your encryption algorithm uses block encryption, the key has a length of one block. In the case of character-by-character encryption, the ideal key is as long as the character string you are encrypting; otherwise, the key is used repeatedly.

Password or Key. A password is a character string that produces a key. For example, if you generate an infinitely long key using a pseudo-random number generator, you can use the initialization value of the random number generator as a password.

In symmetric encryption, a single key is used both to encrypt and to decrypt. The key is a shared secret – a secret known to all encrypters and decrypters. It is often necessary to transport the key to the receiver, which creates the risk that a third party will read the key.

Asymmetric encryption, on the other hand, relies on a mathematically coherent key pair. The private key is used for decryption and digital signing. A third party requires the public key for encrypting and for verifying a digital signature.

Using symmetric encryption, you can digitally sign data, and you can encrypt specifically for individual recipients. The public key is worthy of its name because it does not have to be kept locked up and can be transported safely.

Key with a Fob. It makes sense to add information about the owner to the public key and sign it all digitally so that it is tamper-proof. This digitally signed combination of metadata (name, company, address) plus the public key is known as a certificate (Figure 5).

Whether the public key comes alone or as a certificate, the owner needs to protect it because of its importance. It is quite common to encrypt it symmetrically and secure it with a password.

Figure 5: A certificate comprises a public key, metadata about the owner of the private key, and a digital signature.

You need to keep the private key safe, because anyone who can read it can use it for digital signing. It makes sense to move the private key onto an external drive, such as a USB stick. Additionally, we recommend that you encrypt the USB stick using an encryption tool such as VeraCrypt [1].

Self-Signing Modules

Unsigned modules must be digitally signed, for which you can use the sign-file command of the kernel build system. The command is in the kernel sources, and you can call it as follows:

sudo /lib/modules/$(uname -r)/build/scripts/sign-file sha256 ./ownerkey.priv ./ownerkey.der <Name_of_the_Module>

Using the script from Listing 1, you can sign all VirtualBox modules. The $(modinfo -n vboxdrv) loop returns the path to the VirtualBox module (e.g., to vboxdrv.ko). Alternatively, if you want to self-sign your kernel module, specify the path, including file name of the module.

A simple command hands over the sample signature, which you do not need to protect against unauthorized access, to Shim's certificate manager:

sudo mokutil --import ownerkey.der

As usual, after a reboot, you have to enter a one-time password within a short time window to enable certificate management.

To activate the recently created certificate (Figure 6) in Shim, choose Enroll MOK. View Key checks the key, and the two steps after choosing the Continue menu item finally activate it.

Figure 6: (a) Shim lets you enable a self-generated certificate. The issuer of the digital certificate can tell at a glance (b) that the certificate (c) really is their own. (d) Choosing Continue starts activating the certificate for the boot system, (e) proceeds with a functional but fairly unnecessary security prompt, and (f) ends with the entry of the previously stipulated one-time password.

Back on Linux again, the command

mokutil --list-enrolled

outputs a list of registered certificates, including self-generated certificates. The command to load the VirtualBox kernel module

sudo modprobe vboxdrv

now runs successfully. However, be careful: With each update of the kernel, you have to digitally sign the new modules by again accessing the (one hopes) well-secured private key.

Incidentally, the command

sudo mokutil --delete ownerkey.der

tells the Shim certificate manager to remove a certificate from certificate management during the next reboot – as always under the protection of a one-time password. The menu item in Shim is Delete MOK.

More Secure Is Not 100% Secure

Installing the Shim UEFI bootloader and, with all the effort it involves, signing the kernel and its modules certainly makes the computer more secure. It is far more difficult for script kiddies and hackers to install and launch malicious software on the computer. However, you have no reason to celebrate when you look at, and into, the various certificate stores on the computer: As the manufacturer of the computer, Microsoft, Verisign, Symantec, and Canonical now have branches into the "secure" machine (Table 1).

First, it would be naive to believe that all employees in all companies are immune to the offer of doing someone a little favor in exchange for an impressive number of bitcoins. Second, the consequences of a letter from a national security organization, subject to confidentiality clauses and penalties, could force companies to make concessions in terms of data protection. In the end, only one Public Key Infrastructure (PKI) is secure, and that's the one that you operate yourself.

If you store your own key in UEFI, blacklist the existing keys, compile and self-sign the bootloader, compile and self-sign the kernel, and then do the same with all the modules and drivers, you can put considerably more trust in your system. If you have even higher security demands, the next step is to secure the individual applications running on your system.