1 About UEFI Secure Boot

For an OS to be secure, every layer below the OS layer must also be secure. Running software on a CPU is unsafe if the software can not be trusted to run code correctly. Likewise, if the boot loader is tampered with or the firmware itself is compromised, the kernel that's booted can not be trusted.

UEFI Secure Boot is a platform feature within the UEFI specification that ensures that the system boots by using only the software that's trusted by the hardware manufacturer. Secure Boot provides a verification mechanism where the firmware validates a boot loader before running the loader. This mechanism checks that the code that's run by a system's firmware is trusted. When the system starts, the firmware checks the signature for each piece of boot software, including the firmware drivers and the OS itself. If the signatures are valid, the system boots, and the firmware relinquishes control to the OS.

Secure Boot uses cryptographic checksums and signatures to prevent malicious code from being loaded and run early in the boot process before the OS has loaded. Every program that's loaded by the firmware includes a signature and a checksum and undergoes the same validation by the firmware. Secure Boot stops all untrusted programs from running to prevent any unexpected or unauthorized code from operating in the UEFI-based environment.

Most UEFI compliant systems ship with Secure Boot enabled. These systems are also loaded with Microsoft keys. Thus, binaries that are signed by Microsoft are also trusted by the firmware. By default, these systems don't run any unsigned code. However, you can change the firmware configuration to either enroll more signing keys or to disable Secure Boot.

Secure Boot doesn't prevent users from controlling their own systems. Users can enroll extra keys into the system to enable the signing of other programs. Further, on some systems with Secure Boot enabled by default, users can also remove platform provided keys to force firmware to trust user signed binaries only.

How the Secure Boot Process Works

Each step in the Secure Boot process checks a cryptographic signature on the executable of the next step. The BIOS checks a signature on the boot loader and then the boot loader checks the signatures on all the kernel objects that the boot loader loads.

Objects in the chain are typically signed by the software manufacturer by using private keys that match the public keys already in the BIOS. Altered modules or objects in the boot chain would have mismatching signatures, which prevents the device from booting the image. Otherwise, the platform boots successfully.

The following are required to meet the goals of Secure Boot:

• The Linux boot loader must provide authentication of the Linux kernel.

• The Linux distribution must provide further security enforcement in the kernels that it distributes.

The Shim first stage boot loader program provides a way to meet both of these goals. For more explanation, see Description of the Shim First Stage Boot Loader.

The following figure illustrates the Secure Boot process:

Figure 1-1 Secure Boot Process

Phase 0: The UEFI checks whether Secure Boot is enabled and loads the keys that it stores for this purpose from the UEFI Secure Boot key database.

Phase 1: The Shim software loads. UEFI first validates the signature that was used to sign the Shim. If the signature is valid, the Shim loading can continue. Otherwise, the Shim is unable to load. Thereafter, the loaded Shim is responsible for validating all code. The Shim maintains its own MOK database, where other keys are stored for validation purposes.

Phase 2: The Shim software validates the key that's used to sign the GRUB2 secondary bootloader. If validation passes, GRUB2 loads. the Shim can then validate the keys that are used to sign the kernel images available to GRUB2.

Phase 3: A valid kernel loads. The kernel has read access to the keys in the UEFI Secure Boot key database and the MOK database. The kernel also has its own set of trusted keys that are built into the kernel image itself.

Phase 4: The kernel validates the keys that are used to sign all other modules that need to be loaded, including signed kernel images on kexec operations. Depending on the kernel implementation, the kernel would trust the keys in the UEFI Secure Boot database or the MOK database. Or, it would only trust the keys that are built into the kernel image itself. Note that for kexec signed kernel images signature validation, the following keys can be used: UEFI, DB/MOK, DB keys, and kernel builtin keys.

Secure Boot Limitations

Secure Boot can impose limitations on the system and its operations. The feature is purposely designed to restrict the applications that can run before the OS is booted because after the system is booted, the OS has no way of identifying any programs that were booted earlier or even whether the system was booted securely. For example, if a boot kit is injected into the system before the system boot, Secure Boot could be rendered useless. Or, if an attacker disables Secure Boot and installs malware that could be interpreted by the OS as platform security, the system is compromised..

Secure Boot can also have an impact on the use of some features and user actions, including the activation of the Kernel Lockdown feature. This feature prevents both direct and indirect access to a running kernel image to protect the kernel image from unauthorized modifications and prevent access to the security and cryptographic data in the kernel's memory.

When Lockdown mode is activated, some features that you typically use to revise the kernel might be affected, including the following:

• Loading of kernel modules that aren't signed by a trusted key.

• Use of kexec tools to start an unsigned kernel image.

• Hibernation and resume from hibernation modes.

• User space access to physical memory and I/O ports.

• Module parameters that enable you to set memory and I/O port addresses.

• On x86_64 systems only, writing to MSRs through /dev/cpu/*/msr. On Arm platforms, /dev/cpu/* isn't implemented.

• Use of custom ACPI methods and tables.

• Advanced Configuration and Power Interface (ACPI) and ACPI Platform Error Interface (APEI) error injection.

If you need to use any of these features, you can disable Secure Boot through the system's Extensible Firmware Interface (EFI) setup program. For further information, see Enabling and Disabling Secure Boot.

About Secure Boot Keys

All Secure Boot key types are examples of the Public Key Infrastructure (PKI). Each key includes two long numbers that are used for encryption and, in the case of Secure Boot, for data authentication.

Secure Boot uses a private key and a public key.

• The private key is used to sign a file, which is an EFI program. That signature is then appended to the program.

• The public key must be publicly available. For Secure Boot, this key is embedded in the firmware itself or is stored in NVRAM. You can use the public key along with the signature to verify that the file was signed with that public key and that the file hasn't been changed.

For more information about PKI, see Oracle Linux: Managing Certificates and Public Key Infrastructure.

The following figure illustrates Secure Boot's key signing and verification process.

Figure 1-2 Secure Boot Key Signing and Verification Process

The data is signed with a private key. This process generates a hash of the data and uses the signer's private key to encrypt the hash. When the data needs validation, the signer's public key is used to decrypt the signature to obtain the hash of the data that was signed. The hash of the data is generated and compared with the hash that was decrypted from the signature. A match between the hashes indicates that the data is unchanged from when the was signed.

Although UEFI specification handles several key types, the X.509 key is commonly used. X.509 is a standard format for public key certificates and digital documents that securely associate cryptographic key pairs with identities, individuals, and organizations. The platform key (PK) must be an X.509 key. The X.509 key is stored in DER (Distinguished Encoding Rules) format. The DER key can be base64 encoded and stored as text in a PEM file.

The X.509 certificate includes a public key, a digital signature, and information about the identity that's associated with the certificate and its issuing certificate authority (CA). The public key and a private key form a key pair. The private key is kept secure, while the public key is included in the certificate. With the key pair, the owner of the private key can digitally sign documents that can be verified by anyone with the corresponding public key. By using the key pair, third parties can send messages that are encrypted with the public key that only be decrypted by the owner of the private key.

Note:

UEFI specifications use the terms key and public key to mean the public part of the key pair, or the X.509 certificate. However, in OpenSSL, the term key is the private key that's used for signing. Thus, all Secure Boot keys must be X.509 keys and not OpenSSL keys.

More recent kernel images use the PKCS#7 key type. PKCS (Public Key Cryptography Standards) is a set of standards for the generation and verification of digital signatures and certificates. PKCS#7 is a method of storing signed or encrypted data, including X.509 certificates. This point can be confusing because the key that's stored within a PKCS#7 structured DER or PEM formatted file is still an X.509 key. However, the type, and therefore the expected format when processing the file, is different. You must be aware of this distinction when signing kernel modules because the correct tool must be used when you perform the signing operation.

Four types of Secure Boot keys are built into the firmware. However, a fifth key can be used by the Secure Boot Shim, while a sixth key can be built into the Oracle Linux kernel image:

Platform Key (PK)

This is the top level key type that's used in Secure Boot. The PK offers complete control of the secure boot key hierarchy. The holder of the PK can install a new PK and update the Key Encryption Key (KEK). UEFI Secure Boot handles a single PK that's typically provided by the motherboard manufacturer. Thus, only the motherboard manufacturer has complete control over the system. You can control the Secure Boot process by replacing the PK with a version that you generate yourself.

Key Exchange Key (KEK)

The KEK signs keys so that the firmware accepts those keys as valid when entering them into the database. Without the KEK, the firmware can't detect whether a new key is valid or has been introduced by malware. If the KEK was absent, Secure Boot would require that the databases remain static. However, because the DBX is a critical element of Secure Boot, a static database would be unworkable. Hardware often ships with two KEKs: one from Microsoft and one from the motherboard manufacturer. Thus, either party can issue KEK updates.

UEFI Secure Boot Database Key (DB)

The DB key is important to Secure Boot because this key is used to sign or verify the binaries that you run, such as boot loaders, boot managers, shells, drivers, and so on. Most hardware is shipped with two Microsoft keys installed, one for Microsoft's use and the other for signing third-party software, such as Shim. Some hardware is also shipped with keys that are created by the computer manufacturer or other parties. Note that the database can hold several keys, for different purposes. Moreover, the database can contain both public keys that are matched to private keys, which can be used to sign several binaries, and hashes that describe individual binaries.

Forbidden Signature Database Key (DBX)

Contains keys and hashes that correspond to known malware or other unwanted software. If a binary matches a key or hash that's in both the UEFI Secure Boot key database and the DBX, the DBX takes precedence. This facility prevents the use of a single binary even if the binary is signed by a key that you don't want to revoke because it has been used before to sign several legitimate binaries.

Machine Owner Key (MOK)

Similar to DBX, this key type signs boot loaders and other EFI executables and can also be used to store hashes that correspond to individual programs. MOKs aren't a standard part of Secure Boot. However, they're used by the Shim and PreLoader programs to store keys and hashes. The MOK facility is an ideal way to test newly generated key pairs and the kernel modules that are signed with them. MOK keys are stored in the MOK database. See About the MOK Database.

Public Key in the kernel

These keys can be built into the OS and they check signatures as kernel modules are loaded. Normally, when the CONFIG_MODULE_SIG_KEY parameter is unchanged from the default and a key pair doesn't already exist, the kernel build automatically generates a new key pair by using OpenSSL. Then, when vmlinux is built, the public key is built into the kernel.

Description of the Secure Boot Key Implementation

The following figure shows how the Secure Boot key implementation works in Oracle Linux.

Secure Boot Key Implementation

At the UEFI firmware level, the Platform Key (PK) is used to validate the Key Exchange Key (KEK), which is in turn used to validate all Database Keys (DB) and all DBX Keys (DBX). The DB keys are used with the DBX keys to validate the key used to sign the Shim binary. After the Shim is validated, keys stored within the MOK list and loaded by the Shim can be trusted to perform validation for the later loading operations that follow. The GRUB2 secondary bootloader is validated by using a key within the MOK list and by the MokListX that contains the forbidden MOK keys. Similarly, before the kernel is loaded, validation of the kernel image binary is first performed against the keys in the MOK list. Finally, after the kernel is loaded, the Linux kernel modules or Linux kernel images that are used for kexec operations can be validated, either against the MOK list or against any public keys that are compiled directly into the Linux kernel.

Description of the Shim First Stage Boot Loader

Shim is a basic software package that's designed to work as a first-stage boot loader on UEFI-based systems.

Systems that can use UEFI Secure boot typically ship with the following two keys:

• Microsoft Windows Production PCA 2011

• Microsoft Corporation UEFI CA 2011

When Secure Boot is enabled on the system, only those programs that are signed with either of these keys can boot. For the Shim first stage boot loader, Oracle uses a process that's agreed upon with Microsoft to sign Oracle’s version of Shim with the Microsoft Corporation UEFI CA 2011 CA key. Embedded certificates within the Oracle shim validate the signed second stage boot loader and the kernel. See Description of the Secure Boot Key Implementation.

How Secure Boot Is Enforced Within Oracle Linux

The enforcement of Secure Boot within Oracle Linux includes certain restrictions, most of which are implemented to prevent Oracle Linux from being used as a boot loader through the kexec tool, which would break the Secure Boot chain of trust. The restrictions, which are referred to as lockdown, prevent access to Ring-0 when Secure Boot is enabled, even by the root user.

The following are details of the how Secure Boot is enforced in Oracle Linux 10 kernel releases:

Unbreakable Enterprise Kernel (UEK)

The UEK uses the Kernel Lockdown feature. This feature prevents both direct and indirect access to a running kernel image, which protects the kernel image from unauthorized modifications. It also prevents access to the security and cryptographic data in the kernel's memory.

Lockdown restrictions are applied using three different modes:

• none: No restrictions apply.

• integrity: Disables kernel features that let user space edit the running kernel. This mode is automatically enabled when Secure Boot is enabled in UEK.

• confidentiality: Also disables kernel features that enable user space to extract confidential information from the kernel.

Red Hat Compatible Kernel (RHCK)

When Secure Boot is enabled in Oracle Linux 10 with RHCK, the kernel is automatically put into Lockdown mode. This restricts certain kernel capabilities that could be used to perform unauthorized modification of the kernel.

Enabling and Disabling Secure Boot

You can enable and disable Secure Boot by accessing the system's UEFI setup program. For instructions on enabling and disabling Secure Boot through the UEFI setup program for specific hardware, see the manufacturer's instructions.

Note that if you're having trouble working with the system UEFI, you can disable any further validation for Secure Boot at the level of the Shim. Although you can disable further validation for Secure Boot from user space, you still need physical access to the system at boot so that you can access the MokManager utility when the Shim loads. For more information, see Disabling Secure Boot at Shim Level.

About the MOK Database

MOK keys are stored in the MOK database, or "MOK list." Add certificates for custom built kernels or kernel modules to the MOK database if the keys that are used to sign those components or the CA certificate for those keys aren't present in the UEFI Secure Boot key database. You can add these keys without requiring that a key chains back to another key that's already in the KEK database. When a key is in the MOK database, it's automatically propagated to the system key ring on every boot when UEFI Secure Boot is enabled.

To enroll a MOK key, you must manually do so on each target system by using the MOK Manager Utility on the UEFI system console.

You can also use the MOK Forbidden Signature Database (MOKx), which is similar to the DBX. MOKx features let a user prevent a specific kernel or kernel module from being loaded, as identified by that component's public key or the signature. The MOKx also forbids any second stage boot loader or binary from being booted by Shim, similar to GRUB2's provided file paths grub2, fwupd, mmx64, mmaa64, and etc.

You can use the MOK database to insert keys into the UEFI Shim's trusted keys directly from user space. This is easier than manually adding keys to the UEFI Secure Boot Key Database, which is another option. However, with the MOK database approach, the instructions aren't tied to particular hardware and you don't have to copy keys somewhere that's accessible to UEFI.

The tool to manage the MOK database is the mokutil utility, with which you access the MOK Manager. See About the mokutil Utility.