1 About UEFI Secure Boot

For an operating system 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 implement 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 hasn't been revised and also to verify that the file was signed with a key that matches the public key that's being used.

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

The following figure more 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 Oracle Linux kernel image:

Platform Key (PK)

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)

Signs keys so that the firmware accepts the keys as valid when entering them into the database. Without the KEK, the firmware can't detect whether a new key is valid or introduced by Malware. If KEK were absent, Secure Boot would require that the databases remain static. However, because DBX is a critical point of Secure Boot, a static database would become 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)

Often associated with 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. Most hardware is shipped with two Microsoft keys installed, one for Microsoft 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 multiple 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 to sign several legitimate binaries.

Machine Owner Key (MOK)

Equivalent of 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

Keys that can be built into the OS for checking the signatures as kernel modules are loaded. Normally, when the CONFIG_MODULE_SIG_KEY parameter is unchanged from the default, the kernel build automatically generates a new key pair by using OpenSSL, if one doesn't exist. Then, when vmlinux is built, the public key is built into the kernel. Note that the Secure Boot implementation in UEK R6 up to UEK R6U2 requires that all modules are signed using a key that's built into the kernel. These earlier UEK R6 kernels don't apply the same level of trust to kernel modules that are signed using a key that's only present in the MOK database.

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 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 contain the forbidden MOK keys. Simlarly, 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.

On UEK R6 releases before UEK R6U3, the implementation is slightly varied. At the final stage when the kernel modules are loaded, the Secure Boot implementation doesn't trust kernel modules that are signed only with the keys that are stored in the MOK list or in the UEFI Secure Boot key database. Instead, all kernel modules must be signed with a key that's compiled into the kernel before the kernel can load the module. More information on this process is provided in unresolvable-reference.html#sb-mod-sign-kernel. From UEK R6U3 onward, kernel modules signed with keys stored in the MOK list are trusted.

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 the previous two keys would 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 2nd 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 and thus would break the Secure Boot chain of trust. The restrictions, which were originally referred to as securelevel and more recently 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 Unbreakable Enterprise Kernel (UEK) and Oracle Linux releases:

• Unbreakable Enterprise Kernel (UEK)

  The following information applies to Secure Boot enforcement in UEK releases:

  • UEK R4 (Securelevel)

    UEK R4 contains out-of-tree patches that are based on the addition of a course-grained, runtime configuration option for restricting the ability of user space to edit the running kernel with a BSD-style securelevel. It provides a runtime configuration variable at /sys/kernel/security/securelevel, which can be written to by root.

  • UEK R5 (Lockdown)

    The Kernel Lockdown feature is designed to prevent both direct and indirect access to a running kernel image. The feature protects against unauthorised modification of the kernel image. It also prevents access to security and cryptographic data that's stored in kernel memory, while still letting driver modules to be loaded. When Secure Boot is enabled in UEK R5, lockdown is automatically enabled.

  • UEK R6 and R7 (Lockdown)

    UEK R6 uses the Lockdown feature that's contained within the mainline Linux 5.4 kernel . The 5.4 Lockdown contains three different modes: none, integrity, and confidentiality. If set to integrity, kernel features that enable user space to edit the running kernel are disabled. If set to confidentiality, kernel features that enable user space to extract confidential information from the kernel are also disabled. When Secure Boot is enabled in UEK R6, lockdown integrity mode is automatically enabled.

    Note:

    On aarch64 platforms, Secure Boot has been implemented and kernel images are signed starting with UEK R7 U1.

• Red Hat Compatible Kernel (RHCK)

  The following information applies to the Secure Boot implementation on RHCK for Oracle Linux:

  • Oracle Linux 7 (Lockdown)

    RHCK for Oracle Linux 7 uses the same course-grained, runtime configuration option for restringing user space's ability to revise the running kernel with a BSD-style securelevel, as in UEK R4.

  • Oracle Linux 8 (Lockdown)

    RHCK for Oracle Linux 8 uses an older implementation of Lockdown than is enabled in UEK R5, but is more recent than the BSD-style securelevel implementation in UEK R4.

Enabling and Disabling Secure Boot

You can enable and disable Secure Boot by accessing the system's EFI setup program. For instructions on enabling and disabling Secure Boot through the EFI setup program for a 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.

About the MOK Database

MOK keys are stored in the MOK list or database. Use the database for adding certificates for custom built kernels or kernel modules, where either the keys that are used to sign these 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 the key chain back to another key that's already in the KEK database. When a key is on the MOK list, 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.

A MOK Forbidden Signature Database (MOKx) that's similar to the DBX also exists. MOKx features enable a user to forbid a particular kernel or kernel module from being loaded, as identified by the public key or the signature. The MOKx also forbids any second stage boot loader or binary that Shim boots, similar to grub2/fwupd/mmx64/mmaa64/etc.

With the MOK database, you can insert keys into the trusted keys within the UEFI Shim directly from user space. Using the MOK database to insert keys is easier than manually adding keys to the UEFI Secure Boot Key Database. As an option, you can manually add keys to the UEFI Secure Boot Key Database. However, with the MOK database approach, the instructions aren't tied to particular hardware and you don't have to copy keys to storage that's accessible to UEFI.

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