As stated in the article, What is the Difference between Secure Boot and Measured Boot, it can be nearly impossible to remove “‘Persistent threats’, where malware is inserted into a system in a way that the platform always boots in a compromised state, even after legitimate software is re-installed.” But how can you tell if this has happened to you? Both Secure Boot and Measured Boot help answer this question. The two complementary technologies can help provide assurance a platform boots with exactly the code and versions and bits you are expecting. They start with the Root of Trust and extend the Chain of Trust through each component up to the Operating System. But once a Root of Trust is established, Secure Boot and Measured Boot do somewhat different things.

Root of Trust

For more details about the Root of Trust, Trusted Platform Module (TPM), Platform Configuration Registries (PCRs), and Chain of Trust it is recommended to read the following blog post: HyTrust and Intel Ease Integration of Trusted Compute. To summarize, the Root of Trust is defined as the start of the Chain of Trust when the platform is powered on, resetting all Platform Configuration Registries (PCRs) to their default values. The first piece of this chain is made by the processor to measure a digitally signed module (called an Authenticated Code Module or ACM) provided by the chipset manufacturer. So can you trust the chipset manufacturer? That is for you and your organization to decide. This includes who might have access to iLO/iDRAC/IPMI credentials or firmware/BIOS settings, or what network may access these interfaces. These all help define your Root of Trust.

Secure Boot and VMware ESXi

Unified Extensible Firmware Interface (UEFI) is a specification between an operating system and platform firmware, the replacement for the traditional Basic Input/Output System (BIOS) firmware interface. As said in this blog on Secure Boot for ESXi 6.5, “In UEFI parlance, Secure Boot is a “protocol” of the UEFI firmware. This capability was designed to ensure that boot loaders are not compromised by validating their digital signature against a digital certificate in the firmware. A typical compromise on your desktop or laptop would be if malware installed a root kit. This would change the digital signature and the UEFI firmware would check and not allow further booting.” Secure Boot for ESXi extends this by cryptographically signing each piece of the boot process and can be determined by values in the TPM:

  • UEFI Firmware validates the ESXi Boot Loader signature against the vendor supplied digital certificate in the UEFI firmware
  • ESXi Boot Loader validates the VM kernel against the VMware digital certificate in the Boot Loader
  • VM Kernel runs the Secure Boot Verifier, which also contains the VMware digital certificate
  • Secure Boot Verifier validates each VIB against the VMware digital certificate in the Secure Boot Verifier
  • Management apps (DCUI, hostd, etc) now run

Basically, the incorporation of an external trust store, in the form of the TPM, provides a method for ensuring that ESXi has booted with Secure Boot enabled, thus we can then ensure that ESXi has booted using only digitally signed code.

Measured Boot with Intel® Trusted Execution Technology (Intel® TXT)

The various Measured Boot options provide a mechanism to externally audit integrity of a platform’s boot process, as well as verify Secure Boot was enabled. While some measurements will happen regardless if a TPM is present; others are extended by Intel® Trusted Execution Technology (Intel® TXT), or BootGuard, or similar technologies. Intel® TXT depends on the same Root of Trust while measuring and creating a hash of each component and config in the boot process, storing it in the TPM:

  • Authenticated Code Modules (ACM), perform the measured launch, starting the dynamic chain of trust
  • Server platform, including BIOS (platform firmware) code, BIOS configuration, SMM code, option ROM code and configuration, system state, master boot record, and boot configuration
  • Initial system software code (referred to as MLE code) that sets up the platform to protect the OS/hypervisor kernel code
  • More detail can be found at Intel Trusted Execution Technology Enabling Guide

These hashes, stored in the PCRs on the TPM, can later be retrieved remotely and verified against any known good values


This doesn’t mean that all implementations of Secure Boot or Measured Boot with Intel® TXT create an entirely safe environment. For example:

  • Microsoft accidentally released a ‘Golden key’ bypassing Secure Boot, allowing any OS to be installed. (Microsoft’s secure boot leak).
    • Measured Boot’s remote accessibility to known good values could be very useful and detecting a malicious system here.
  • UEFI rootkits such as LoJax have been found in the wild. LoJax broke an anti-theft software called LoJack that was designed to resist OS-reinstallation or hard drive replacement so it was implemented as a UEFI/BIOS module. LoJax allows write operations to the SPI flash memory which is outside the scope of Secure Boot therefore the systems root of trust must be moved closer to hardware.
    • “Secure Boot is designed to protect against malicious components coming from outside of the SPI flash memory. To protect against tampering with the SPI flash memory, the system’s root of trust must be moved to hardware.” LoJax
  • Kallenberg also presented a new way to bypass Secure Boot efficiently for OEMs not using the security mechanism SMI_LOCK in their UEFI implementations. (bypass secure boot UEFI)

With many more attack vectors both known and unknown, the differences between Secure Boot and Measured Boot with Intel® TXT can help each other address these problems!


The main differences between Secure Boot and Measure Boot with Intel® TXT are as follows:

Measured Boot with Intel TXT Secure Boot
Mode of verification Measures and hashes each component of its boot process Checks each component for a correct manufacturer signature of its boot process
Boot process config values included in measurements Yes No
Decisions made No decisions on whether a component is trusted or not it only reports to the TPM. Decides if a component is trusted based on if it was signed correctly by the manufacturer.
Unsigned code can run If you wish, you could add unsigned code as a trusted component No possibility to purposely add unsigned code
Accessibility Remote attestation, making it more flexible Local verification



Secure Boot and Measured Boot with Intel® TXT share the same primary goal. They aim to validate that there have been no unauthorized changes to critical parts of the platform code, in order to provide a secure environment for applications. In order to do this, they both rely on the Root of Trust to build a Chain of Trust during a platform boot process so the users may have confidence in a secure environment. In both scenarios, the TPM is used as a cryptographically secure place to store measurements of trust, though Secure Boot only uses it for an enabled flag. Both technologies can and should be used at the same time.

In Summary

BIOS/UEFI attacks and hacks exist in the wild, though rare, can be the most persistent and damaging attacks on an organization. Both Secure Boot and Measured Boot through Intel® TXT help discover and prevent such attacks. The combination of the two further improve the security posture of the system. They have the same goal with two different solutions, covering different attack vectors. They bring your organization’s Root of Trust to the forefront security discussions.  Reach out to your local HyTrust sales person to learn how HyTrust CloudControl can help you.