Blog Viewer

What’s the Difference between Secure Boot and Measured Boot?

By Erdem posted 09-17-2015 06:51

  

It seems that every day, we hear of new methods of exploiting vulnerabilities in computer systems. Most of the high-profile attacks go after servers and laptops, but embedded equipment such as networking gear is not immune. Fortunately, while the attackers get more sophisticated, the defenders aren’t standing still either.

 

Especially valuable attack vectors are ‘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. To combat these attacks, system vendors are turning to two technologies, Secure Boot and Measured Boot, to provide assurance that when a platform boots, it’s running code that hasn’t been compromised.

 

The terms Secure Boot and Measured Boot are often seen together, and they can be complementary, but they’re not at all the same. Let’s compare them…

 

Both technologies rely on a “Root of Trust”, that is, some piece of code or hardware that’s been hardened well enough that it’s not likely to be compromised, and either can’t be modified at all, or else can’t be modified without cryptographic credentials. For many systems, that Root of Trust is provided by the Unified Extended Firmware Interface (UEFI) BIOS (http://www.uefi.org/), code that takes the place of the ad-hoc “legacy” BIOS that’s been in use for years. The UEFI BIOS works with platform hardware to ensure that the flash memory that contains the BIOS can’t be modified without cryptographic authority, forming the Root of Trust.

 

A UEFI BIOS depends on several elements to ensure the Root of Trust is not compromised:

  • The BIOS contains a public key that’s controlled by the equipment manufacturer. Any authorized change to the BIOS must be signed with the corresponding private key
  • The BIOS itself is required to check the validity of the signature on a proposed update, using the public key stored in a protected part of the BIOS flash.
  • And the BIOS must configure processor hardware features to block any unauthorized writes to the flash. In an x86 design, Protected Range Registers are one line of defense, with other mechanisms also available.

Both Secure and Measured Boot start with the Root of Trust and extend a ‘chain of trust’, starting in the root, through each component, to the Operating System (and in embedded systems, often to the application itself). But once a Root of Trust is established, Secure Boot and Measured Boot do somewhat different things.

 

Modern platforms of all sorts often use a multi-stage boot, where firmware in flash launches an OS Loader (such as Grub2), which then loads and launches a series of OS components.

 

  • In a Secure Boot chain, each step in the process checks a cryptographic signature on the executable of the next step before it’s launched. Thus, the BIOS will check a signature on the loader, and the loader will check signatures on all the kernel objects that it loads. The objects in the chain are usually signed by the software manufacturer, using private keys that match up with public keys already in the BIOS. If any of the software modules in the boot chain have been hacked, then the signatures won’t match, and the device won’t boot the image.
    Because the images must be signed by the manufacturer, it’s generally impractical to sign any files generated by the platform user (such as config files).
  • In a Measured Boot chain, we still depend on a Root of Trust as the starting point for a chain of trust. But in this case, prior to launching the next object, the currently-running object “measures” or computes the hash of, the next object(s) in the chain, and stores the hashes in a way that they can be securely retrieved later to find out what objects were encountered. Measured Boot doesn’t make an implicit value judgement as to good or bad, and it doesn’t stop the platform from running, so Measured Boot can be much more liberal about what it checks. This can include all kinds of platform configuration information such as which was the boot device, what was in the loader config file, or anything else that might be of interest.

Secure Boot is relatively self-contained. If the handful of signed objects haven’t been tampered with, the platform boots, and secure boot is done. If objects have been changed so the signature is no longer valid, the platform doesn’t boot and a re-installation is indicated.

Secure-boot-chain.JPG

 

Measured Boot is more flexible, but also requires an important step... Somehow all those hashes have to be stored in a way that there’s very little chance that they can be manipulated, and a very high likelihood that they can be reliably reported to a management station, using a process called Attestation. Since Measured Boot doesn’t stop the platform from booting, the host OS can’t be relied upon to report the hashes.

 

In the case of Measure Boot, the Trusted Platform Module is used to record these hashes. The TPM is a small self-contained security processor that can be attached to a system bus as a simple peripheral. (See http://forums.juniper.net/t5/Security-Now/What-is-a-Trusted-Platform-Module-TPM/ba-p/281128 for more on TPM technology.)  Of the many functions a TPM can provide, one is the facility called Platform Configuration Registers (PCRs), used for storing hashes.

Measured-Boot-chain.JPG

 

PCRs are registers in the TPM that are cleared only at hardware reset, and cannot be directly written. What one can do is “extend” values in PCRs, that is, to hash a new value into whatever was previously in the PCR. Thus, as the platform boots, each measurement can be accumulated in the PCRs in a way that unambiguously demonstrates which modules were loaded.

 

Once the PCRs have been collected, the second trick is for the TPM to report the values, signed by a key that only the TPM can access. The resulting data structure, called a Quote, gives the PCR values and a signature, allowing them to be sent to a Remote Attestation server via an untrusted channel. The server can examine the PCRs and associated logs to determine if the platform is running an acceptable image.

 

Can Secure Boot and Measured Boot both be used at the same time? Indeed they can, and that may be a good idea for some applications, as Secure Boot ensures that the system only runs authentic software, but Measured Boot can give a much more detailed picture of how the platform is configured.

 

And that gives the Defenders a whole new toolkit to turn aside evolving attacks!

 

 

Permalink