Background

Firmware is a special type of software, mainly used for the control and communication of the underlying hardware. The scope of firmware is too broad, different areas of firmware involved in security issues vary greatly. This article only discusses the firmware running on general computer, such as servers, notebooks and desktops.

The current problem

UEFI is still the mainstream firmware solution at the moment. There are several problems in UEFI ecosystem:

• The technical architecture design does not take into account its complex supply chain, while the reference implementation of tianocore/EDK2 differs greatly from the OEM factory implementation. It's not hard to find out that a number of SMM based features implemented in some OEM firmware through reverse engineering and testing. SMM is one of high risk attack surfaces in x86 because the priviledge of its running mode also known as “Ring -2” is even higher than “RING 0”. This is the main reason why the operating system has difficulty detecting threats below Ring 0.

• The flaws of design and implemenation leads to a number of firmware security risks:

The long supply chain makes the bug fix cycle longer. More importantly, the delays or refusals to fix known vulnerabilities increase the risk to the user's production environment.

• Non-auditability, most OEM vendors do not provide source code of the firmware to users. The audit on the source code level is not feasible. Vulnerablity audit can only rely on binary audit or fuzzer. The cost of audit on backdoor or debug features is extremely high without source code. While Intel is trying to address openness with the Minimum platform in 2019, its coverage didn't go well as expected.

"Next-Gen" firmware

In the winter of 1999, Ron Minnich, a researcher at Los Alamos National Laboratory, launched a project called LinuxBIOS, which was designed to replace proprietary firmware with free software, with the philosophical idea of having as less code as possible at the stage of hardware initialization and load a Linux based payload to take care of the rest when the hardware initialization was complete. LinuxBIOS was later renamed as coreboot. Today's coreboot supports a wide range of payloads other than Linux, and this architecture is an important foundation for the industry in the 2020s as it revisits firmware issues and explores “next-generation” firmware, perhaps due to both inevitability and probability.

The industry has begun to explore various firmware security options since 2010s. One of Verified Boot solution from UEFI also known as “Secure Boot” that builds a chain of trust to validate signatures, which has been wide spread in the marketing. Another option is MeasuredBoot but it's not well-known as “Secure Boot”. Because only limited number of chipset support TXT (if the user intend to use DRTM) and other features under TCG specification is hard to implement in UEFI. In 2016, Trammell Hudson, a researcher at hedge fund Two Sigma, drew on LinuxBIOS's philosophy of developing a Linux based payload called heads, which has several security features, including measured boot and loading it with coreboot. This solves the problem that UEFI eco-system has struggled to solve for several years at a low cost, and the industry continues to build on the 1999 version of the “Next Generation Firmware” architecture. In 2017, Google and the heads community jointly developed a payload called NERF, which uses a mode of retaining PEI and minimizing DXE to be OEM-compatible with UEFI firmware, but it didn't work on some machine models due to relocation issues. Another feature of NERF is that the userland is based on Go Runtime, and interestingly, NERF's attempt to take linux-based payload schemes to a more standardized stage: LinuxBoot.

As you can see from the figure above. LinuxBoot, the “next-generation firmware” architecture, is still not beyond the 1999 LinuxBIOS's philosophical idea, but its goal is to support more hardware initialization firmware solutions.

VaultBoot: The heart of Gondor

VaultBoot is a firmware payload highly focused on firmware security, trusted computing, and advanced threat protection. VaultBoot can bring the greatest benefits if it work with coreboot, which co-op on the provisioning stage of CBnT and other tons of ACMs.

VaultBoot is also compatible with OEM's UEFI firmware. HardenedVault is a long-term contributor in heads community. So the public version of VaultBoot is based on heads, but VaultBoot is also compatible with LinuxBoot and offers both C and Go runtime environments.

The key features of VaultBoot:

• Verified boot. Also known as Secure Boot in UEFI circle, this feature means only signed kernel as well as accompanied data (e.g. initrd) could be loaded to boot in normal boot process. In UEFI circle, the signature should be stored in the same file of the kernel, thus dedicated tool is needed, and the signing process is hard to operate. In Vaultboot, signature verification process is done by the bundled gnupg tool. A dedicated gnupg keychain containing the public keys could be bundled into its initrd. The kernel, initrd and boot config of OS would be siged by the corresponding private key stored in a smartcard, and the signature would be stored in the boot partition as a separated file, and the following signing processes could be done in the os, without modifying the kernel file itself. If the signature becomes invalid, the automated boot process will be interrupted, and Vaultboot will provide a recovery shell for the administrator to manually boot the OS, or fix the signing chain.

• Measured boot. If the mainboard is equipped with a TPM, coreboot could also be built to measure all components it loads (including the payload). Vaultboot could also be built with TPM (1 or 2) capability. If so, it can seal a random secret into the TPM, against the PCRs coreboot uses to measure itself, and present the random secret as a TOTP in the boot process for the administrator to verify. If the firmware is altered, the PCRs will change, and the sealed secret verified by the administrator can no longer be unsealed out of the TPM, in order to alert the administrator for unintended modifications of the firmware. This could be a form of local attestation. If verifing the TOTP in the boot process is inconvenient, remote attestation could be used. If the secret failed to be unsealed, the automated boot process will be interrupted, and a recovery shell will be provided.

• Vault_SMM. This is the unique hardening mode developed by HardenedVault, which delays the enablement of hardening features provided by the chipset to the payload stage and VaultBoot utilizes SMM to perform the operations. It ensures security while also taking into account maintainability and this design endorsed by the founders of LinuxBIOS in 2019. VaultBoot uses the SMM as a high-risk priviledged mode for security hardening only, but it's worth noting that this solution must work with coreboot to take advantage of it.

• TPM-based FDE (Full-disk encryption). If TPM is available, and the OS has a LUKS to unlock during the boot process, Vaultboot can add a random key to the LUKS, and seal the key into the TPM (with or without a passphrase). If the key could be successfully unsealed, Vaultboot will copy the initrd of the OS to its tmpfs, append the key and a crypttab item into the copied initrd, and boot the OS with the modified initrd, so the LUKS will be unlocked by the key during the boot process. After adding the key, the LUKS header will be measured into a PCR, which is one of the PCRs against which the unlocking key is sealed. Thus if the firmware or the LUKS header is altered, the key will not be unsealed anymore and the automated boot process will be interrupted. Of course, if the firmware is updated and/or the LUKS header is altered by user intentionally, a new key could be generated and sealed for the LUKS, if there are other means to unlock the LUKS to add the new key.

• Parameter encryption via hardware built-in key exchange. In TPMv2, a new feature is introduced to encrypt the sensitive parameters (e.g. the plaintext to seal/unseal) with a session key exchanged with keys generated inside TPM. Vaultboot will make use of this feature to defend physical attacks such as TPM Genie.

• Intel CSME. It depends on the use-case. For more detail, please read our study report.

Conclusion

Firmware runs at a higher level than RING 0, where the operating system is located. If the user's threat model includes the attacker persistence, firmware security cannot be ignored. Both offsensive and defensive sides in this area are receiving increasing industry attention. The National Institute of Standards and Technology (NIST) issued 4 special publications about firmware security:

• NIST SP 800-147: BIOS Protection Guide, April 2011
• NIST SP 800-155: BIOS Integrity Measurement Guide, December 2011
• NIST SP 800-147B: Server BIOS Protection Guide, August 2014
• NIST SP 800-193: BIOS Platform Firmware Resilience Guide, May 2018

On May 26, 2021, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) unveiled the VBOS (Vulnerablity below the OS program at the RSA 2021 conference, which aims to protect the security of both operating systems and lower-level components, even though the confrontations at firmware level have never stopped in past 15 years. The VBOS program drag the covert warfare out on the table now. Although there are no systematic firmware security compliance guidelines in EU like those in the United States. But European Commission has funded a large number of open source chip and firmware security projects via Horizon 2020 which was launched in 2014. The German Federal Office for Information Security (BSI) has repeatedly publicly mentioned support and follow-up work for open source firmware. In 2019, BSI certified the network security products of genua GmbH, a German security vendor (no. BSI-DSZ-CC-1085-2019), to support open firmware system.

In the global trend of advanced threat protection, firmware is one of the core in overall defense. VaultBoot has developed a several of securit features based on the current attack surfaces. HardenedVault currently offers security firmware solution for KabyLake/CoffeeLake server platform for x86 and the support of arm64 should be come out in FY2022.