技术帮助 · 发布时间：
服务器机箱里装有 TPM 2.0，不等于启动过程可信。固件、引导程序或内核被替换时，单看“TPM 已启用”无法判断节点是否按预期启动。裸机节点的TPM可信启动与远程证明部署，关键是把启动度量、远端校验和访问策略连成一条链：状态不合规时，不应照常释放敏感密钥或加入服务集群。
先区分安全启动与启动度量
Secure Boot依据固件中的信任密钥，检查引导组件的签名，阻止不受信任的组件继续启动；启动度量则把固件、引导程序等启动事件的摘要记录到 TPM 的 PCR（平台配置寄存器）中，供之后验证。两者作用不同：前者侧重拦截，后者留下可核验的启动状态。PCR 编号和度量内容会受平台固件、启动模式及配置影响，不能把某一台机器的数值直接当作所有节点的标准。
因此，裸机节点的TPM可信启动与远程证明部署不能止于 BIOS 中打开 TPM。还需确认操作系统能读取 TPM、启动事件日志可用，并由独立的验证端判断该状态是否符合策略。TPM 本地可用只是前提，不是远程证明结果。
按顺序完成部署
- 核对硬件与固件。在 UEFI 设置中启用 TPM 2.0 和 Secure Boot，记录固件版本、启动模式、引导程序及密钥配置。变更前确认系统盘加密的恢复方式可用，避免启动状态变化后无法解锁。
- 检查操作系统可见性。在 Linux 上可使用 tpm2-tools 查询设备能力，例如运行 tpm2_getcap properties-fixed，并检查内核是否提供 TPM 设备节点。Secure Boot 状态可通过发行版支持的工具核实；部分系统可用 mokutil --sb-state 查看。不同发行版和固件环境下，工具输出及日志路径可能不同。
- 验证度量记录。确认固件生成启动事件日志，检查关键 PCR，并把事件日志与 TPM 报告的 PCR 值一起交给验证端复核。不要只保存一组 PCR 数字：日志有助于解释哪些组件导致状态变化。升级固件、引导程序或内核后，应按变更流程重新评估预期状态。
- 接入远程验证。验证端向节点发起带随机数的挑战，节点通过 TPM 证明当前 PCR 值，并提交相应事件日志。验证端检查挑战的新鲜度、证明密钥身份、PCR 值和日志重放结果，避免接受旧证明或仅凭节点自报状态放行。
- 把结果接入策略。将“通过证明”绑定到具体动作，例如允许节点注册、获取短期凭据或解封受保护密钥；不通过时隔离节点并保留诊断通道。首次部署可先以监测模式收集合法状态，再逐步切换到拒绝不合规状态，避免固件更新造成大面积误拦截。
远程证明要验证什么
远程证明不是传输一个“可信”标志。验证端至少要确认 TPM 证明对应本次挑战，证明密钥与已登记节点身份匹配，PCR 值符合允许策略，并能根据事件日志解释这些值。日志本身不能替代 TPM 签名；若只接收日志而不验证 TPM 对 PCR 的证明，攻击者可能提交伪造记录。
可采用自建验证服务，或评估开源项目 Keylime 等远程证明方案。选择时重点比较硬件与发行版支持、身份登记方式、策略表达能力、密钥释放集成及故障处置方式。若业务需要在证明通过后释放密钥，还应限定密钥用途和有效期，并避免把长期凭据直接交给节点。
更新、异常与恢复不能遗漏
固件、引导程序和内核更新会改变度量结果，升级前应在测试节点采集新状态、审查差异并更新允许策略；不要为了让节点“通过”而无条件放宽 PCR 规则。更换主板、清除 TPM 或重置固件密钥也可能使已登记身份失效，应按重新注册流程处理。
建议保留本地控制台或带外管理作为恢复路径，记录拒绝原因，并区分可批准的计划变更与未知组件变化。裸机节点的TPM可信启动与远程证明部署只有同时具备验证、策略和恢复流程，才能把启动状态转化为可执行的安全控制。
常见问题
只有 TPM 2.0，没有 Secure Boot，可以做远程证明吗？
可以采集 TPM 度量并进行验证，但缺少 Secure Boot 时，对未签名引导组件的启动拦截能力不同。应按风险明确策略，不能把两者视为等价。
PCR 值变化就一定代表攻击吗？
不一定。固件、引导程序或内核的合法更新也会改变度量。应结合事件日志、变更记录和允许策略判断，不宜只按单个数值报警。
节点证明失败时应立即关机吗？
不必一概关机。更稳妥的默认措施是拒绝加入关键服务或获取敏感密钥，同时隔离节点并保留排查与恢复通道。
