3. Boot Guard与硬件信任根
Intel Boot Guard 是 Intel 平台在 UEFI 固件之前建立的第一道硬件级信任锚。它把信任根从可被替换的固件 Flash 芯片，下沉到 CPU 内部一次性可编程（OTP）的熔断区（Field Programmable Fuses，FPF）。理解 Boot Guard，关键要抓住三件事：密钥如何被"烧死"在芯片里、ACM 如何用这些密钥验证固件、以及 OEM 如何通过策略配置决定"验不过时怎么办"。
一、硬件信任根：为什么是熔断而不是 Flash
传统启动链中，CPU 复位后从 Flash 的固定地址取第一条指令，这段代码本身没有任何密码学校验，攻击者只要改写 Flash 就能植入持久化恶意代码。Boot Guard 的思路是：在 CPU 内部预置一段由 Intel 签名、不可修改的微码——认证代码模块（Authenticated Code Module，ACM），由它作为"根"，去验证 Flash 中的初始启动块（Initial Boot Block，IBB）。
信任的起点是熔断区中的几组关键 FPF：
- Boot Guard 使能熔断：标记平台是否启用 Boot Guard，以及采用哪种模式（Verified Boot 或 Measured Boot）。
- OEM 公钥哈希熔断：存放 OEM 签名公钥的 SHA-256 哈希（通常 32 字节），是整条链的信任锚。
- Profile 与策略熔断：决定失败时的行为（关机、降级或仅记录）。
熔断的本质是"一次性、不可逆"。一旦 OEM 公钥哈希被烧入，CPU 在后续每次启动时都会用这个哈希去比对 ACM 中携带的公钥。如果攻击者替换了 Flash 中的公钥，哈希对不上，验证直接失败。这就是"密钥熔断"作为硬件信任根的核心价值——它把信任从可写介质转移到了物理不可逆的硅片状态。
二、ACM 验证流程：从复位向量到 IBB
上电复位后，CPU 首先执行的是 Intel 微码中的 ACM。ACM 内部携带了 Intel 的签名和 OEM 公钥（或其哈希），验证流程大致如下：
- CPU 从 Flash 读取 Boot Guard 相关 FPF，确认使能状态与模式。
- ACM 计算自身携带的 OEM 公钥哈希，与 FPF 中烧入的哈希比对。不一致则立即终止启动。
- ACM 读取 Flash 中的 IBB（通常包含 UEFI SEC/PEI 阶段代码），计算其哈希。
- 用 OEM 公钥验证 IBB 的 RSA/ECDSA 签名，确认代码未被篡改。
- 验证通过后，ACM 将控制权交给 IBB；失败则按策略熔断配置执行关机或降级。
这里有一个容易混淆的点：ACM 验证的是 IBB 的签名，而不是整个 Flash。IBB 之后的 PEI、DXE、BDS 阶段由 UEFI 自身的信任链（如 PEI 验证 DXE、DXE 验证驱动）继续保障。Boot Guard 只负责"第一跳"，但这一跳决定了后续所有代码是否可信。
三、OEM 公钥哈希与启动策略配置
OEM 在量产阶段需要完成两项关键配置：把公钥哈希烧入 FPF，以及选择启动策略。这两者共同决定了平台的信任行为。
公钥哈希的生成与烧录。OEM 首先生成一对签名密钥（通常 RSA-2048 或 ECDSA P-256），私钥保存在 HSM 中用于签名 IBB，公钥则用于计算哈希。哈希算法固定为 SHA-256，计算对象是公钥的 DER 编码。示例流程如下：
# 1. 生成 OEM 签名密钥对（示例）
openssl genrsa -out oem_priv.pem 2048
openssl rsa -in oem_priv.pem -pubout -out oem_pub.pem
# 2. 计算公钥 DER 编码的 SHA-256 哈希
openssl rsa -in oem_priv.pem -pubout -outform DER -out oem_pub.der
sha256sum oem_pub.der
# 输出示例：a3f1c9...（32 字节，即烧入 FPF 的值）
# 3. 用私钥对 IBB 签名
openssl dgst -sha256 -sign oem_priv.pem -out ibb.sig ibb.bin烧录通常通过 Intel 提供的 FIT（Firmware Interface Table）工具或主板厂商的产线工具完成。烧录后必须回读校验，确认 FPF 中的哈希与预期一致。
启动策略配置。Boot Guard 提供两种主要模式：
| 模式 | 行为 | 适用场景 |
|---|---|---|
| Verified Boot | 验证失败则强制关机，不进入固件 | 高安全要求设备，如支付终端、服务器 |
| Measured Boot | 不阻断启动，但将度量值记入 TPM PCR | 需要远程证明、审计的场景 |
此外还有"失败策略"配置：验证失败时是立即关机、降级到无 Boot Guard 模式，还是仅记录事件。降级模式会削弱安全性，一般只在调试阶段使用。量产设备应配置为强制关机。
四、验证与排障要点
判断 Boot Guard 是否生效，可以从几个角度观察：启动日志中是否出现 ACM 相关条目；用 Intel 提供的工具读取 FPF 状态，确认使能位与哈希值；故意篡改 IBB 的一个字节，观察平台是否按策略拒绝启动。如果篡改后仍能正常启动，说明 Boot Guard 未真正使能或策略被配置为降级，需要立即排查。
常见问题包括：公钥哈希烧录错误导致所有设备无法启动；签名算法与 FPF 配置不匹配；IBB 范围定义过小，导致部分早期代码未被覆盖。这些都需要在产线配置阶段通过回读和样机验证来提前发现。
Boot Guard 把信任根牢牢钉在 CPU 的熔断区里，ACM 用这个根去验证第一段固件，OEM 则通过公钥哈希和策略配置决定整条链的起点是否可信。三者缺一不可：没有熔断，信任可被替换；没有 ACM，验证无从执行；没有正确的策略，验证通过与否都无法转化为实际的安全行为。