2025 年 4 月，知名硬件信息工具 CPU-Z 与 HWMonitor 的分发渠道遭遇供应链攻击，攻击者短暂篡改下载链接，将正常安装包替换为木马化版本。尽管厂商在数小时内完成修复，此次事件再次暴露了二进制分发链路中的信任断裂问题。对于企业安全团队而言，事件响应不仅是封堵 IOC，更应系统性构建固件与 BIOS 的完整性验证体系。本文从工程实践角度，阐述如何利用 TPM 证明、UEFI Secure Boot 审计及代码签名验证，构建可落地的二进制完整性验证流程。
TPM 证明与平台配置寄存器机制
可信平台模块（TPM 2.0）提供了硬件级别的度量框架，是固件完整性验证的核心支柱。TPM 在系统启动过程中会对每个阶段的加载组件计算哈希值，并将结果存储在平台配置寄存器（PCR）中。PCR 是一种只能扩展（extend）但不可逆写入的寄存器，每次扩展操作会将新度量值与当前 PCR 值拼接后再次哈希，确保任何对历史状态的篡改都会导致最终值不可预测。这一设计使得攻击者无法在不留下痕迹的情况下修改启动链中的任意环节。
在实际工程部署中，PCR 索引通常按功能划分：PCR0 用于平台固件初始化代码，PCR1 包含平台配置变量，PCR4 记录启动加载程序（Boot Loader），PCR7 则存储 Secure Boot 状态。对于固件完整性验证场景，核心关注点是 PCR0、PCR4、PCR7 的组合状态。以 TPM 2.0 为例，验证流程如下：远程证明服务器向目标设备发送随机 nonce 作为挑战（Challenge），设备使用 TPM2_Quote 命令将指定 PCR 索引的值与 nonce 进行签名，返回包含签名、PCR 值及事件日志的证明数据。证明服务器使用 TPM 的公钥验证签名有效性，随后比对 PCR 值与已知良好基线（Known-Good Baseline）。
关键工程参数包括：PCR 选择通常采用 PCR0+PCR4+PCR7 的组合，覆盖固件、启动加载程序和 Secure Boot 状态；nonce 长度应不少于 32 字节以防止重放攻击；TPM 密钥应存储在 TPM 的持久存储（Persistent Handle）或使用 TPM2_Create 命令生成的绑定密钥。企业在实施时应确保 TPM 已启用且版本不低于 2.0，同时配置 TPM 策略以限制签名操作的授权条件。
UEFI Secure Boot 签名链审计
UEFI Secure Boot 通过验证固件、启动加载程序、内核及驱动程序的数字签名，构建从硬件到操作系统的信任链。启用 Secure Boot 后，系统仅执行携带有效签名的二进制组件，签名验证失败将直接终止启动流程。这一机制从根本上遏制了启动前阶段的恶意代码注入，但同时也要求运维团队建立严格的签名管理流程。
签名链审计的核心关注点包括：平台密钥（PK）、密钥交换密钥（KEK）、签名数据库（DB）与撤销列表（DBX）的完整性；各签名阶段使用的证书链是否完整；固件更新包是否经过厂商签名且签名算法符合预期。实践中建议定期导出 UEFI 变量并与基线比对，审计频率不低于每季度一次。对于高安全环境，可通过 tpm2-tools 套件中的 tpm2_pcrread 结合 tpm2_quote 实现自动化基线比对。
具体审计命令示例：首先使用 efi-readvar 工具提取当前 Secure Boot 变量状态，记录 PK、KEK、DB、DBX 的证书指纹；随后将提取结果与配置管理系统中的基线进行差异比对；发现不匹配时触发告警并自动进入事件响应流程。值得注意的是，Secure Boot 状态本身也会被记录在 TPM PCR7 中，这意味着 Secure Boot 的开启状态同样纳入完整性验证范畴。
代码签名验证与供应链审计方案
固件与应用程序的代码签名验证是供应链安全的最后一道防线。针对 CPU-Z/HWMonitor 此类工具类软件的供应链攻击，核心防御手段是建立基于哈希比对与签名验证的双重确认机制。
工程实践中建议采用以下验证层级：下载阶段使用 HTTPS 并强制校验服务器证书域名；获取二进制后立即计算 SHA-256 哈希并与厂商发布的安全哈希清单比对；对于包含嵌入式签名的文件（如 PE、ELF、SIGNATURE 文件），使用对应平台的签名验证工具提取签名信息并确认签发者身份。以 Windows 环境下验证 CPU-Z 为例，可使用 PowerShell 的 Get-AuthenticodeSignature cmdlet 检查签名状态，使用 signtool verify /pa/v cpuz.exe 验证签名链完整性。
企业级部署应构建自动化签名审计管道：CI/CD 阶段对所有引入的第三方二进制进行哈希登记；部署阶段强制校验哈希匹配；运行时通过端点检测与响应（EDR）系统监控二进制文件的写入行为。建议的哈希基线更新周期为重大版本发布后 24 小时内，审计日志保留周期不少于 12 个月。
验证阈值与监控清单
为确保验证体系的有效运行，以下提供可直接落地的工程阈值与监控清单。TPM 证明验证的超时建议设为 10 秒，重试次数不超过 3 次，超过阈值则标记为验证失败并触发工单。PCR 比对应支持白名单模式：任何未列入基线的 PCR 值变化均视为异常。Secure Boot 审计应监控变量写入事件，DBX 更新需经过审批流程。代码签名验证的强制检查点包括：签名存在性、签名链完整性和签发者白名单。
监控告警应覆盖以下场景：TPM 证明失败、PCR 值偏离基线、Secure Boot 状态变更、代码签名哈希不匹配、可执行文件被异常替换。告警级别划分建议如下：PCR 偏离为高危、TPM 证明失败为紧急、签名哈希不匹配为严重、Secure Boot 状态变更为警告。
回滚与事件响应策略
完整性验证体系的有效性取决于事件响应能力的完备性。当检测到固件或二进制异常时，应立即执行以下回滚流程：第一步是隔离受影响系统，切断网络连接以防止横向移动；第二步是利用 TPM 事件日志进行根因分析，定位篡改发生的具体阶段；第三步是从可信恢复介质启动，执行固件或系统的完整恢复。
对于供应链攻击场景下的软件回滚，建议维护最近三个版本的官方安装包存档，并建立与厂商安全公告的实时同步机制。回滚后应重新执行完整的完整性验证流程，确认所有 PCR 值与签名状态恢复正常后方可重新接入生产网络。
小结
固件与 BIOS 二进制完整性验证是供应链安全的基础设施。TPM 证明提供了硬件绑定的度量能力，UEFI Secure Boot 构建了启动阶段的签名链，二者结合形成从硬件信任根到操作系统的完整防护。代码签名审计则将验证范围扩展至应用层，形成多层防御体系。企业在实施时应关注自动化基线管理、告警阈值调优和事件响应流程的持续演练，将防御能力转化为可运营的安全工程实践。
资料来源：The Register 报道 CPU-Z/HWMonitor 供应链攻击事件；Trusted Computing Group 发布的 TPM 远程平台完整性证明规范；Oracle UEFI Secure Boot 官方文档。