.png){kind=small}
What is Boot Guard?
Boot Guard does not mean exactly what its name suggest, it is not protecting
shoes. In firmware and BIOS nomenclature boot means the bootstrap process,
which is the early processor initialization routine. Almost every modern machine
or processor has some kind of firmware which is responsible for the bootstrap
process - booting - which prepares the silicon to load the target application or
operating system. So ‘Boot Guard’ quite literally protects the boot process and
the firmware. But from what should it protect and why? You can find it out by
spending a few minutes to read this post.
Why Boot Guard?
Nowadays security researchers are very focused on the trustworthiness, security, and hardware-level safety of the computers we use everyday. These so-called “white hat” researchers explore every possible vulnerability and attack vector in modern systems to find holes in the security of the most crucial parts of our modern systems, such as Intel ME, UEFI, and others. Conversely, the bad guys, commonly known as “black hats” are constantly trying to find new and innovative ways of gaining access to systems that are harder to detect. Traditionally, the bad guys would find bugs in browsers or network protocols that would give them root access to the operating system and allow them to then install tools to keep their access persistent. Researchers and anti-virus companies would usually detect these exploits by scanning memory or files for known virus signatures, then patch holes and cleanse infected systems. However, this game of security cat and mouse has now evolved to the point where the bad guys are looking for new and interesting ways of not only gaining access to systems, but also maintaining that access undetected. Logically, the place for malicious software to hide and stay undetected is in the part of the system that the operating system and no knowledge of or access to - the system firmware.
How do you know that software you use is trustful, secure and hasn’t been maliciously modified before execution? One can only ensure this by establishing the Root of Trust (ROT) as early as possible.
There are 2 main type of ROTs:
- SRTM - Static Root of Trust for Measurement
- DRTM - Dynamic Root of Trust for Measurement
We will not delve too deep into the measurement process of ROT, as it is not a part of this post, but what we will focus on here is cryptographic verification in the ROT. ROT is the beginning of the verification process, it is considered to be trusted and verifies all components executed by firmware. For DRTM it may be any time after the system has been powered on, because the processor is responsible for establishing a clean environment for ROT to begin the verification process. For SRTM it is the very early moment in the boot process. As soon as firmware sets up temporary memory, it launches an executable module responsible for establishing ROT and further firmware image verification. While this all sounds great, how can one protect this early code responsible for temporary memory setup and ROT establishment?
For more details about ROT refer to NIST.
Some details about DRTM can be found on TrenchBoot GitHub. We are also involved in DRTM development on AMD platforms and contribute actively to TrenchBoot. One may find our achievements on various conferences:
Protecting the ROT can be achieved by locking the SPI flash containing the firmware for example, however this does not protect the SPI from a desoldering attack. Attackers can actually physically solder a new SPI which can contain maliciously modified firmware which compromises the Root of Trust and even install backdoors, keyloggers, RAT’s or other malware.
In order to protect systems from even desoldering attacks, we can use Boot Guard, which verifies the early firmware code responsible for temporary memory setup and ROT establishment before the firmware is able to execute. Because of that Boot Guard is an SRTM solution.
How Boot Guard works?
Intel Boot Guard is a feature that allows firmware verification before the first instructions get executed. How was this achieved? This feature is supported by Intel ME, which instructs the processor to load an Authenticated Code Module (ACM) signed by Intel responsible for manifests validation and boot policy enforcement. During the verification process, ME utilizes the Key Manifest, Boot Policy Manifest (which is a part of Boot Guard) and the Firmware Interface Table (FIT). Before fetching the first firmware instructions, the processor searches for the FIT and applies microcode updates which are pointed by FIT. The microcode verifies the ACM, which verifies the Key Manifest, which verifies Boot Policy Manifest (so complicated right?). In the end the Boot Policy Manifest contains the hashes and signatures of the code regions in firmware that have to be protected and verified. After the firmware verification, ACM allows the processor to fetch the first instructions to be executed.
So in the event that the firmware is maliciously modified, it would not be able to execute. It would fail because the manifest that holds the firmware signing keys would fail the firmware verification. As an added step, the public key hash of the key used to sign the Key Manifest can be burned into the ME and locked permanently to ensure that no one except the key owner can change the firmware signed in the Boot Policy Manifest.
The flow described here is one of the most restrictive profiles that Boot Guard offers - strict verification without remediation. There are less restrictive profiles which allow the platform to keep running for 30 minutes if firmware verification fails in order to restore the system and flash trusted firmware. But the production behavior of Boot Guard ensures that unverified firmware cannot execute on the processor and immediately shuts the platform down.
Where can I get Boot Guard for my platform?
One has to either pay thousands of dollars to a big firmware development company to enable Boot Guard on your hardware or buy costly hardware which has Boot Guard already enabled.
That was true until now. Recently, one of our customers -Protectli - asked us to improve the security of their network focused product called the Vault by implementing Boot Guard. Protectli sells compact network devices running Intel processors and the most powerful of them have Intel processors which are Boot Guard capable. As a matter of fact, 3mdeb had previously implemented coreboot for these platforms, so implementing Boot Guard was a natural enhancement to the overall security of the system.
And today we have succeeded. The first official platform running open-source firmware that has Boot Guard enabled is here. It is possible thanks to the fact that Protectli cares about hardware security and sees value in open-source firmware and software.
This first-of-its-kind platform can be seen in action at the 3mdeb booth at Embedded World 2020, but here is a brief glimpse of what you can expect to see at the Embedded World 2020 exhibition.
Boot Guard and coreboot? Yes, of course
The below asciinema video presents the Protectli FW6B platform booted with Boot
Guard enabled coreboot firmware executing an Intel tool called MEInfo, which
is used to dump information about system and Management Engine.
In the video, we see some interesting detail, including Boot Guard info:
OEM Public Key Hash FPF Not setOEM Public Key Hash ME 7E8E9BF4EF2E3AC831672D0049414081EA8D32C2E36B5D69457D4E3AA0B70517ACM SVN FPF 0x2KM SVN FPF 0x0
The OEM Public Key Hash represents the SHA256 of the key used to verify the
Key Manifest. It is located in the ME and on production devices is is burned
into FPF (Field Programmable Fuses).
ACM SVN FPF describes the ACM security version, 0x2 means it is a production
ACM.
KM SVN FPF is a Key Manifest security version. It is used to revoke Key
Manifests. 0x0 means that no Key Manifest was revoked yet.
There are also some additional variables stored in ME:
|
|
Force Boot Guard ACM, Measured Boot, Verified Boot and
Enforcement Policy make up the Boot Guard profile.
They can be encoded as follows:
Firmware verification with Boot Guard is enabled, Enforcement Policy equal to
1 means “allow remediation”, system will shutdown after 30 minutes if firmware
verification fails. Disabled Force Boot Guard ACM means that if ACM is not
found in firmware, the processor will execute the code from a reset vector. If
enabled, the system will shut down with a delay based on the
Enforcement Policy. It must be noted that not all combinations of these fields
are allowed. Only strictly defined Boot Guard profiles determine these fields'
values.
Other interesting values are CPU Debugging and BSP Initialization which
additionally protect the boot flow from modification via DCI or INIT signal.
Thus far, we have only seen the status of variables. However the status of successful Boot Guard firmware verification lies in the status registers:
-
FW Status Register4: 0x00084000, bit 14 is equal to one indicates that the information contained in this register is valid. Bit 9, which is zero, indicates that the enforcement has not been triggered -
FW Status Register5: 0x00000B01, bit 31 is equal to zero, which means the chipset does not start enforcement logic. Bit 0 is equal to one and indicates that ACM is active (and of course present in firmware).
That means the system will not shutdown after 30 minutes as the Boot Guard profile instructs the processor (if verification fails).
Summing it up: Boot Guard verified the firmware successfully.
Summary
This is just a taste of what Boot Guard can do. The presented information and demonstration show non-production settings and the ME is still in Manufacturing Mode which allows the settings to be reprogrammed. It has been intentionally left enabled for further development.
I encourage you to visit the 3mdeb booth at Embedded World 2020 (25th - 27th of February 2020 in Nuremberg, Germany). There, you will be able to see the Boot Guard demo live. We will be at hall 4 - 666. Also we want to thank The European Regional Development Fund for the subsidy of the “Presentation of 3mdeb Embedded Systems Consulting software solutions for international markets” project realized by the 3mdeb Embedded Systems Consulting company.
If you think we can help in improving the security of your firmware or you
looking for someone who can boost your product by leveraging advanced features
of your hardware platform, feel free to
book a call with us or
drop us email at contact<at>3mdeb<dot>com. If you are interested in similar
content feel free to sign up for our newsletter
