Intel® Boot Guard

UEFI Secure Boot assumes the OEM platform firmware is a Trusted Computing Base (TCB) and trusts it implicitly. A better implementation relies on a smaller TCB to verify the OEM platform firmware. A solution can be implemented using Intel® Boot Guard. This feature verifies the entire OEM platform firmware image using two components:
Authenticated Code Module (ACM) Initial Boot Block (IBB) Verification
Microcode ACM Verification.
Figure 2-4 shows the components involved in Intel® Boot Guard. Table 2-4 shows the key usage in Intel® Boot Guard.
Figure 2-4: Intel® Boot Guard diagram (credit: “CYBER-RESILIENCY IN CHIPSET AND BIOS” by Dell EMC)
Table 2-4: Key Usage in Intel® Boot Guard
Key
Verifies
Storage
Verified By
ACM Key
ACM
CPU
Microcode
Key Hash
Key Manifest
PCH
ACM
BP Key
Boot Policy Manifest
Key Manifest (Flash)
ACM
IBB Hash
IBB
Boot Policy Manifest (Flash)
ACM
Please note that Intel Boot Guard is not the only solution available for OEM platform firmware verification. This document uses it as an example to illustrate the concept.
Table 2-5 shows how to reduce TCB from OEM platform firmware to ACM.
ACM IBB Verification
Table 2-5: ACM IBB Verification
Item
Entity
Provider
Location
TP
ACM IBB Verification
Intel
Originally on flash, loaded into Authenticated Code RAM (AC-RAM)
CDI
ACM Code
Intel
Originally on flash, loaded into AC-RAM
​
Boot Policy Manifest (Policy)
OEM
Originally on flash, loaded into cache
​
Key Manifest (Policy)
OEM
Originally on flash, loaded into cache
​
Key Hash (Policy)
OEM
Write once PCH register, programmed in manufacture fuse.
UDI
Firmware Initial Boot Block, aka IBB
OEM
Originally on flash, loaded into cache
Intel introduced the Intel® Boot Guard Authenticated Code Module (ACM), which is a module signed by Intel. The ACMs modules assume responsibility to verify OEM platform firmware before the host CPU transfers control to OEM firmware. Because verifying the entire image is time-consuming, the ACM only verifies the initial boot block (IBB) code. The IBB is then responsible for verifying the OEM boot block (OBB).
Signing
The UDI here is the firmware IBB, so only the IBB needs to be signed.
Public Key Storage
Intel® Boot Guard defines a set of Manifests to record the signature information.
1.Boot Policy Manifest – It records the hash of IBB and is signed by the Key Manifest Key.
2.Key Manifest – It records a set of hashes for the public key pair which signs the Boot Policy Manifest, and it is signed Boot Guard Key.
3.Key Hash - It records the hash for the public key pair which signs the Key Manifest. It is provisioned into the PCH hardware.
The Key Hash is read-only. It cannot be updated.
The Boot Policy Manifest and Key Manifest can be updated in the firmware.
Verification
During runtime update, the TP – ACM IBB Verification gets the CDI - Key Hash from PCH - and verify the first UDI – the Key Manifest. If the verification passes, the Key Manifest is transformed into a CDI. Then ACM continues to get the key hash from the CDI - Key Manifest - and verify the UDI - Boot Policy Manifest. If the verification passes, the Boot Policy Manifest is transformed into a CDI. Then the ACM gets the final UDI – Firmware IBB code - and verify it according to the CDI – Boot Policy Manifest. If the final verification passes, then the Firmware IBB is transformed into a CDI, and the ACM transfers control to the IBB.
Microcode ACM Verification
The ACM binary is signed by Intel. Now the question becomes who verifies the ACM binary. The answer is the CPU Microcode.
Table 2-6: Microcode ACM Verification
Item
Entity
Provider
Location
TP
Microcode ACM Verification
Intel
CPU
CDI
Microcode
Intel
CPU
​
ACM Key hash
Intel
CPU
UDI
ACM Code
Intel
Originally on flash, loaded into AC-RAM
Signing
The UDI is the ACM binary. As such, the ACM needs to be signed with the Intel key.
Public Key Storage
The hash of the ACM public key is inside of the CPU. A debug ACM is signed with the debug key. A production ACM is signed with the production key.
The policy can NOT be updated.
Verification
During the ACM launch, the CPU Microcode loads the UDI - ACM to authenticated code execution area. Then the TP – ACM verification performs the verification. If the verification passes, then the UDI is transformed to CDI, the ACM starts executing. If the verification fails, the TXT shutdown is signaled.
The Intel® Boot Guard is one implementation to support boot ROM verification. Some other projects may have similar functions, such as Cerberus.
OBB Verification
Intel® Boot Guard only verifies the initial boot block (IBB) of the whole OEM Firmware. To make sure the whole OEM Firmware is unmodified, the IBB needs to verify the reset OEM boot block (OBB).
Table 2-7: OBB Verification
Item
Entity
Provider
Location
TP
OBB Verification
OEM
Originally on flash, loaded into DRAM
CDI
Firmware Initial Boot Block, aka IBB
OEM
Originally on flash, loaded into DRAM
​
OBB Hash, OBB public key hash (Policy)
OEM
Originally on flash, loaded into DRAM
UDI
Firmware OEM Boot Block, aka OBB
OEM
Originally on flash, loaded into DRAM
Signing
The UDI is OBB, which is not verified by IBB. Since both IBB and OBB are provided by OEM, the OEM may define a separate specific format to sign the OBB.
Public Key Storage
The OBB public key hash must be stored into the IBB region to make sure it is validated by ACM. As implementation choice, OEM may store the OBB hash directly to the IBB without using the public key.
Verification
During Firmware boot, the TP is the OBB verification code inside of IBB. If the OBB passes the verification, the OBB is installed by IBB. If the OBB fails the verification, the OBB is skipped.

UEFI Secure Boot

Boot Chain – Putting it all together

Last modified 2yr ago

Copy link

On this page

ACM IBB Verification

Signing

Public Key Storage

Verification

Microcode ACM Verification

Signing

Public Key Storage

Verification

OBB Verification

Signing

Public Key Storage

Verification