Secure Boot aims to add an additional layer of protection to the boot process, laying the foundation for overall computer security. Secure Boot technology, much like a vigilant guardian, ensures that only digitally signed and trusted components are allowed to initiate the system boot process, fortifying the system against unauthorized and potentially malicious software. As we bid farewell to the challenges and triumphs of the past year, let’s build trust, proactively defend against uncertainties, and navigate the digital landscape of the coming year with confidence and assurance. Here’s to a secure boot and a prosperous new year ahead!
What is Secure Boot?
Personal computers have been plagued by viruses, worms and other malware for decades. Some of the earliest PC viruses spread in the form of boot sector viruses: they exist as code in the boot sector of a floppy disk, and when a user starts a computer with an infected DOS floppy disk, the virus spreads from one computer to another. Although other modes of virus transmission have gradually received attention with the elimination of floppy disks and the popularity of Internet connections, pre-boot malware still poses a great threat to system security. By executing before the operating system kernel gains control of the computer, the malware can be hidden, making it almost impossible for virus scanners to detect the malware.
BIOS does little to prevent infection with pre-boot malware. In the BIOS boot path, the operating system trusts by default any executable used for boot loading. The purpose of a secure boot is to add a layer of protection to the pre-start process. When a secure boot is activated, the firmware checks for the presence of an encrypted signature in any EFI program being executed. If the cryptographic signature does not exist, is inconsistent with a key in the computer’s NVRAM, or is blacklisted on the NVRAM, the firmware will refuse to execute the program. Of course, this is just the beginning of the process; a trusted EFI bootloader must continue to boot up in a secure manner and ultimately implement an inherently safe operating system.
Secure Boot is the UEFI feature on Windows 8 preinstalled computers that came out in 2012. All current Ubuntu 64-bit (not 32-bit) versions support this feature. In short, the secure boot principle is to enable a trust source mechanism in firmware. This post takes Ubuntu as an example, gives a high-level introduction to the Linux boot process, and then goes on to explore Secure Boot’s role in the startup process. The purpose of this post is to familiarize the reader with some basic concepts, including shim, EFI variables, and MOK.
Understanding the boot process of Linux and Secure Boot is important because without a thorough understanding of how a Linux system works inside, it’s easy to accidentally damage your system when trying to enable settings such as Secure Boot, or even raise a series of security issues.
Traditional Boot Process and Secure Boot
When the Ubuntu machine starts, it goes through 4 steps as follows:
- BIOS/UEFI phase — Firmware on the motherboard, usually stored in read-only memory (ROM), containing code for initializing computer hardware components and fetching bootloader code.
- Bootloader phase — Loads the operating system and initrd into memory together.
- Kernel phase — The kernel executes the init script within the initrd filesystem. This loads the hardware driver and mounts the root partition.
- System startup-The operating system loads the system daemon and services, sets up the network, mounts the file system, starts the system log and performs other initialization tasks
Secure boot is a security standard. When the computer is powered on, the secure boot program starts with the firmware in the motherboard and checks the encrypted signature of each boot file. This includes UEFI firmware drivers (aka optional ROM), EFI applications, and operating systems. Once authenticated, the computer boots up and the firmware turns control over to the operating system.
Key Components of Secure Boot You Should Know
Shim
When enabling secure boot, it is important to understand shim. In the case of SecureBoot, “shim” is a pre-bootloader designed to work with SecureBoot firmware. When Bootloader and kernel modules are not included in the SecureBoot database, shim provides a mechanism to load them. In Ubuntu, the pre-bootloader is preinstalled and signed by Microsoft.
Secure boot uses asymmetric encryption techniques. The key pair can be generated by the user, and the private key is used to sign all programs that are allowed to run, including GRUB. UEFI’s firmware will use the public key to verify the signature, and only after the signature verification is passed can the program be allowed to run. You can use the sbverify command to check your own signature for the shim loader.
UEFI Variables
UEFI variables are stored in firmware non-volatile RAM (NV-RAM). These variables store various data such as boot sequence preferences, timeout values, network settings, storage device details and secure boot settings. Each UEFI variable has its own binary under /sys/firmware/efi/efivars/. The naming convention for these files is variable names followed by vendor GUIDs. For example, SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8cm can be used to store whether a secure boot is enabled (0x01) or disabled (0x00). Some of these variables can be viewed by listing the contents of /sys/firmware/efi/efivars/ or using the efivarfs tool to list and read values.
Secure Boot Database
Four key databases are used for secure boot:
- Allowed Signature Database (db) — contains a list of cryptographic signatures that are allowed to be loaded during startup.
- Disallowed Signature Database (dbx) — Contains a list of cryptographic signatures that are not allowed to load during startup.
- Key Enrollment Key Database (KEK)-Contains key exchange keys used to authenticate other databases.
- Platform Key Database (PK)-Contains the public key used to verify the signature of a bootloader or firmware. UEFI recommends using the RSA-2048 platform key.
The key database mainly specifies which signatures are allowed to be loaded and which are not. These databases are important for secure boot because they help verify the integrity of a module before it is executed.
Machine Owner Keys (MOKs)
Another component of the secure boot process is the Machine Owner Key (MOK). MOK is an additional key database that can be managed by the user. It’s separated from the certificate authorization key that comes with shim. They give the user better control over which modules can be loaded. For example, when a user registers an MOK on the system, the key associated with it is added to the allowed signature database (db). This means that during startup, the firmware will trust any binaries signed with this key. These files are usually located in the /var/lib/shim-signed/mok/ directory and named MOK.der, MOK.pem or MOK.priv.
By default, shim provides an administration tool called MokManager that can be used to “register keys, delete keys, register binary hashes, and switch secure boot validation at the shim level”. Passwords are often required to authenticate users of the tool when using MokManager.
When key management is required, MokManager will help to configure the key correctly. After key management is completed, the system will restart to enable key management changes.
BootLoader Configuration and Information
The /proc/cmdline file contains the kernel boot command line arguments passed to the kernel during boot.
This command will output the path of the kernel image file loaded by bootloader via BOOT_IMAGE.
BOOT_IMAGE is a binary file of the operating system core. It contains the code and data structures needed to start the system, manage memory, handle input/output operations, and execute user programs. The bootloader can use them to start the operating system. The name of BOOT_IMAGE generally represents its version and architecture.
The bootloader contains its own file system driver (initramfs), which can be viewed by viewing the /boot/initrd* file. In initramfs, early and early2 refer to the first and second stages of initramfs. In the first phase, the minimum drivers and tools required to initialize hardware and mount a real root file system are loaded. In the second phase, early2 loads other drivers and tools required for full initramfs.
The home folder of initramfs contains the actual root file system image, as well as any other tools or drivers that may be required during startup. After the root file system is mounted, the system can continue to load the regular services and daemons required to run the operating system.
You can use the modinfo command to check which modules have a digital signature, and the kernel’s signature will appear as a long string of hexadecimal values separated by colons.
Conclusion
This post introduces several key components of Secure Boot, and for Linux users, Secure Boot is somewhere between ” It doesn’t matter. ” and “very troublesome.” Although Secure Boot can improve security, “careless” operations will still cause security risks in operation. Follow-up posts will introduce the precautions for Secure Boot. Please stay tuned.
