Secure Boot lays the foundation for the security of the entire computer system. However, in practice, there are potential security risks in secure boot.

I. Overview

In the previous post “Secure Boot 101: Getting Started with Secure Boot”, we introduced several core concepts of Secure Boot. In reality, users’ computers are often encrypted, and using TPM (Trusted Platform Module) to store encryption keys is a good solution — users can have an encrypted disk without having to enter the password each time the computer restarts. Additionally, this ensures that if the hard drive is maliciously removed from the computer, the key will not be leaked as it is stored in TPM.

However, relying solely on TPM to store keys is far from sufficient. Attackers can remove the hard drive and replace it with another one. If the password is directly stored in the TPM chip without verifying the system state, there is a security issue: any user with physical access to the machine from the operating system level can obtain the key. Furthermore, attackers can replace the disk, extract the key, or even request the key from TPM by changing the initramfs/initrd or modifying the GRUB boot process. Therefore, a system relying solely on TPM is not as secure, at least not meeting our objectives.

II. Secure Boot in the Ideal State

The ideal trust chain should ensure that each step is trusted by the previous one and establishes the trust foundation for the next step. For Secure Boot, the ideal steps should be:

• UEFI is password-protected and cannot be modified without credentials.
• UEFI only allows booting from a single disk device and specific boot files.
• Secure Boot permits only signed and unaltered binary files (e.g., GRUB2).
• GRUB2 EFI executable configuration is embedded, preventing modification or addition of extra parameters during the boot process.
• GRUB2 is password-protected and allows only a single entry to be booted, disallowing additional parameters.
• GRUB2 loads only signed kernels.
• GRUB2 trusts initramfs/initrd, and they are also signed.
• initramfs/initrd requests the key from TPM, ensuring the integrity of UEFI, as resetting UEFI passwords also resets TPM content.
• System continues normal boot.

This process ensures that each step in the boot process is trusted by the previous one and endorses trust for the next one. The trust begins by signing the GRUB2 EFI executable file with a self-signed certificate, overriding other “ordinary” certificates in UEFI. Using grub-standalone instead of regular GRUB2 means that GRUB configuration files and modules are embedded into a signed single executable file. This prevents the injection of GRUB modules (drivers) or changes to parameters. Additionally, GRUB should be password-protected and then calls signed and verified kernels and initramfs/initrd.

This trust chain seems reasonable as it prevents interference with the boot order and ensures that the unencrypted portion of the partition is not replaced. Attackers cannot load any different GRUB, nor can they modify the configuration, initramfs/initrd, or the kernel.

However, the weak link in the above process is the boot loader. Attackers may attempt to inject kernel drivers or malicious code when GRUB is called. To address this, Ubuntu enforces the use of SHIM, a pre-loader mechanism. In this scenario, the operation of the trust chain is slightly different:

• BIOS trusts SHIM, which uses Microsoft certificates.
• SHIM, signed with Microsoft certificates, trusts another set of certificates—self-signed certificates or Canonical certificates. SHIM acts as the bootloader before GRUB.
• SHIM trusts the GRUB EFI binary file signed by Canonical.
• GRUB trusts the kernel signed by Canonical (all stock kernels are signed by Canonical) or custom kernels (and modules) signed with self-signed certificates. However, each kernel and its associated modules need to be signed with self-signed certificates.
• GRUB trusts initramfs/initrd.

The problem with this process is that there are external sources in the trust chain, and different components may be replaced or patched. The issues are as follows:

• SHIM can be replaced with other EFI binaries trusted by Microsoft (such as the Windows loader). This would skip the entire trust chain, entering another process we cannot control.
• SHIM can be compiled using self-signed certificates (then input as trusted certificates in BIOS SecureBoot). However, this complicates the deployment of SHIM, requiring recompilation with each update.
• Using grub-standalone requires either Canonical certificates or self-signed certificates. If self-signed certificates are used, we would remove Canonical certificates from SHIM, but then we must re-sign the kernel using our certificates. Alternatively, adding self-signed certificates to SHIM would allow our locked GRUB to be replaced with a regular GRUB2 signed by Canonical, easily bypassing the lock.
• By default, initramfs signatures are not checked. Attackers can use GURB EFI at any point before this to extract our key.

III. Firmly Control Your Secure Boot

SHIM, by default, trusts Microsoft certificates, meaning your computer will trust all Microsoft-signed boot loaders and content.

Taking control of Secure Boot has several advantages:

• Eliminates security risks associated with default keys: While Secure Boot theoretically prevents malicious software, attackers may deceive Microsoft-signed malware or exploit vulnerabilities in signed software. Using the default key in SHIM exposes the computer to these threats.
• Eliminates security risks associated with operating system keys: Similarly, operating system keys could be leaked, and attackers might distribute malicious software signed with the leaked keys.
• No need for MOKs: SHIM and Pre Loader tools depend on Machine Owner Keys (MOK), similar to Secure Boot keys but easier to install. Canceling MOK can enhance security, as they are more susceptible to abuse through social engineering or other means because they are easier to install.
• Convenient for testing and development: If you want to develop your own bootloader, the process of signing files with Microsoft Secure Boot keys is tedious and time-consuming. Therefore, it’s necessary to sign binary files with your own keys. Once the software runs as expected, you can then submit it to Microsoft for signing.

IV. Conclusion

This post discussed potential security risks in Secure Boot. In practice, instead of self-signing all content, using TPM PCR (Platform Configuration Register) for better protection of encryption keys is an alternative. PCR contains hash values of all content during the boot process, such as firmware settings, boot order, boot loader content (like SHIM, GRUB), kernel, and initrd. TPM can be configured to release the encryption key only when PCR contains specific values (or matches the state before boot). This helps prevent data theft because if an attacker replaces the hard drive or modifies the bootloader, it disrupts PCR, and TPM will refuse to release the key, ensuring the security of the data.

Secure Boot and TPM can establish a secure foundation for the computer’s boot process, but Secure Boot is not a cure-all. In execution, security needs to be safeguarded from multiple perspectives to avoid neglecting the fundamental trust roots while introducing advanced technologies.

The post Making Secure Boot Even More Secure appeared first on NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks..

*** This is a Security Bloggers Network syndicated blog from NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks. authored by NSFOCUS. Read the original post at: https://nsfocusglobal.com/making-secure-boot-even-more-secure/