Why Secure Boot Is A Good Idea

Despite the fact that Microsoft have abused the term "secure boot" for a long time to regain exclusive control over a computer's boot process, there are some very good reasons for improving the Linux boot sequence to meet privacy concerns. I will insist to call one of these improvements secure boot.

I've developed a secureboot Linux package that basically makes an encrypted container available during the boot process, so that confidential user data can be locked inside this container in one big encrypted file. This package is available as RPM for RedHat-like Linux systems and as a DEB package for all the others as well.

You might think that there is already such an option, as many Linux distributions offer "encrypt my files" or allow to encrypt entire disk partitions. Of course there is nothing wrong with these tools, it might just be what you are looking for.

In my opinion there is still a need to handle encrypted containers separately, because encrypting a whole partition does not distinguish between sensitive data on the one hand and a whole bunch of publicly known files that don't need protection on the other hand. After a while sensitive data tends to spread over the whole file system and it is very important to confine valuable data into one spot, the one single, encrypted container.

One Encrypted Container For Your Valuable Data

And it helps to make your backups much simpler, as you don't have to worry about your essential data being lost. All you need to recover a broken system lives inside your big encrypted file. Once you have a copy of your container - on a portable hard disk, your smartphone or in the cloud - with a fresh, clean Linux system on new hardware you'll be up and running in no time when you are able to mount your container into your new file system and everything is in place again.

If you're traveling a lot, the benefits of a single encrypted container are obvious. You can even travel without your files and your own hardware knowing that you'll be able to download a smaller version of your big file containing the essential part of your data you'll need at your destination from the cloud.

No more worries about your files being seized or stolen on your journey or being concerned about accidental damage to your laptop by the airport x-ray or bumping of your hardware in flight.

Restrict Access With Your Secure Boot Container

When I first developed the secureboot package years ago the Linux boot process was a linear sequence and I could stop it in a very early stage to prompt for a password that was used to decrypt my container. If someone else used my laptop this was the point where the boot process would end, because with an incorrect password the system would clean up and simply reboot. The original idea was to prevent the use of the system by unauthorized persons by stopping the boot process if the container cannot be decrypted.

With the changes systemd and upstart introduced to replace the good old runlevel-driven boot process, it was no longer possible to stop the boot process at a single point and reading a passphrase from the keyboard proved to become difficult too.

That's why I have updated the original code base to work in such new environments and for the first time I provide the solution as rpm and deb packages that are ready to install with the standard tools rpm and dpkg.

Passphrase or Memory Key?

Over time I got used to providing my passphrase during the boot process, but sometimes I wished there was a shortcut that would safe me the hassle to open up my container with the information inside my head. At times when my laptop was safely located in a place where surely nobody else would use it, being prompted for a passphrase seemed to be an unnecessary precaution. So I included the option to provide the passphrase by inserting a memory key into the computer.

This is of course a weaker procedure and the circumstances have to be considered to justify such a shortcut, but I designed this option in a way that the passphrase can only be replaced if two separate pieces of information are used together. If someone stole my laptop without the memory key, it should be infeasible to gain any knowledge of the passphrase that protects my encrypted container.

The secureboot package installs without activating this option, but if you wish to configure the memory key procedure safely, I'd advise you to follow this tutorial.

Protect Your Own Files With Secureboot

It's about time to get secureboot up and running on your own computer and to create the necessary space for your essential files inside the container.

No matter what kind of Linux distribution you're using, there are RPM, DEB and SOURCE packages that install and configure a small encrypted container of 2 MByte in your file system. The passphrase for this small container is "secureboot". If everything is working well after a reboot you can go ahead and expand the container to your desired size and most importantly, change the passphrase that protects your new large encrypted container. All these tasks are supported by scripts that you'll find in the directory "/usr/lib/secureboot".

So let's get started.

File Description Size Fingerprint
secureboot-2.1-1.noarch.rpm Secureboot 2.1 for Fedora, RedHat, Suse and other rpm-based Linux distributions 2084709 Bytes sha256
secureboot-2.1-1.src.rpm Secureboot 2.1 source for rpm-based Linux distributions 2086206 Bytes sha256
secureboot_2.1-1_all.deb Secureboot 2.1 for Ubuntu and other debian-based Linux distributions 2076878 Bytes sha256
secureboot-2.1-1.tar.gz Secureboot 2.1 source tarball to be installed into / 2077811 Bytes sha256

The new version of secureboot has been tested to work on Fedora 40 and on Ubuntu 24.04, where a cryptsetup version 2.7.0 is installed. This cryptsetup version breaks backward compatibility with the default values used in the past. As a consequence of this change secureboot-2.1 is designed to provide backwards compatibility by specifying the defaults used in the past explicitly:

/sbin/cryptsetup open --type plain --cipher="aes-cbc-essiv:sha256" --key-size=256 --hash=ripemd160

The good news is, that you can use your old encrypted filesystems without any change as you'd expect.

The RPM and DEB package installs secureboot as a service via systemd. The passphrase is prompted on the terminal 8.

The main script /usr/lib/secureboot/secureboot2 has been signed with my codesigning key to ensure authenticity of the core software.

When you see your encrypted container mounted on the directory "/secure", you can use the shell script "/usr/lib/secureboot/secureboot-encrypt" to create a new encrypted container with a passphrase of your own choice.

The following command will create a new big file of 5 GByte size, populating the new container with the files found in the "defaultfilesystem". The script "/usr/lib/secureboot/secureboot-replace" will then replace the old small container with the new one.

#> /usr/lib/secureboot/secureboot-encrypt --grow 5000000
#> /usr/lib/secureboot/secureboot-replace

Use the script "/usr/lib/secureboot/secureboot-backup" with care as it creates sizable copies of your container and may fill up your file system very fast.

Using The Protected Space For User Homes

When you think about which data should find its permanent home inside the container, user home directories are the obvious choice. You can safely transfer the user homes to /secure by creating links from /home, but be aware that without a default home directory in /secure there will be no login if the container fails to decrypt. But this may as well be the desired way it should be.

Be careful if you think about transferring system services to the new directory /secure as the services will most certainly be started seconds before a user has entered the correct passphrase to enable the use of the encrypted container.