可信计算、TPM

可信计算核心机制精要：从静态度量到动态信任

---

1. 信任的建立：信任链与度量的本质

• 核心问题：如何确保从硬件到操作系统的每个步骤都可信？

• 精要回答：

  • 信任链：系统启动是一个“安全接力赛”。从不可篡改的硬件信任根（CRTM） 开始，每一级代码（BIOS -> 引导程序 -> OS内核）在将控制权交给下一级之前，都必须先对其进行度量。

  • 度量什么：计算下一级完整二进制代码的密码学哈希值（如SHA-256）。这个哈希值相当于其唯一的“数字指纹”。

  • 如何记录：哈希值被立即传递给TPM芯片，通过 “扩展”操作 写入PCR寄存器。扩展是一种密码学操作，公式为 新PCR值 = Hash(旧PCR值 || 新哈希值)，使得PCR值成为整个启动序列不可逆、不可篡改的最终摘要。

---

2. 信任的基准：初始参考值从何而来并防篡改？

• 核心问题：用来比对的“正确”哈希值在哪里？如何保证它自身安全？

• 精要回答：

  • 来源：参考值由软件/硬件供应商（如微软、主板制造商）或企业IT管理员预先计算并提供。

  • 防篡改机制：

    1. 密码学签名：参考值或包含它的清单文件，由供应商的私钥进行数字签名。验证方使用对应的公钥进行验证，确保其真实性和完整性。

    2. 安全存储：参考值存储在远程验证服务器或受保护的UEFI固件数据库中，与容易被攻击的客户端环境分离。攻击者无法篡改服务器上的参考值。

---

3. 系统的演变：操作系统升级如何处理？

• 核心问题：OS升级后哈希值变了，如何不破坏可信链？

• 精要回答：

  • 签名更新：微软用新私钥为新OS内核签名。主板制造商通过固件胶囊更新（经Windows Update安全推送）将新公钥或哈希值加入UEFI安全启动的信任数据库（DB）。

  • 状态更新：

    • 本地：BitLocker等会在更新前/后重新密封密钥到新的PCR状态，或通过恢复密码流程进行过渡。

    • 远程：验证服务器更新其策略，将新OS状态纳入可信列表。

---

4. 应用的海洋：应用安装与升级如何管理？

• 核心问题：应用数量庞大且频繁变更，如何验证？

• 精要回答：范式转变——从“信哈希”到“信身份”。

  • 静态验证（执行前）：系统检查应用的代码签名。只要签名来自策略中信任的发布者（如微软商店证书），无论版本新旧，都允许运行。它不关心具体哈希值，只关心发布者身份。

  • 动态记录（运行时）：所有被加载的应用都会被度量，其哈希值被扩展到少数几个指定的PCR中（如PCR 10）。

  • 解决海量问题：

    • PCR不存单个哈希，而是所有度量的聚合摘要。

    • 验证时，验证方检查度量日志，但只验证日志中每个文件的代码签名，而非比对具体哈希值。只要所有应用都来自可信发布者，其PCR状态就是合法的。

---

5. 关键的枢纽：远程验证方如何工作？

• 核心问题：验证方是谁？它如何高效、准确地裁决？

• 精要回答：

  • 身份：是企业策略服务器或云服务商的证明服务。

  • 流程：

    1. 接收客户端的TPM签名PCR报告和度量日志。

    2. 验证PCR签名，确认报告来自真实TPM。

    3. 分析度量日志，逐一验证每个组件的代码签名（而非哈希值）。

    4. 用日志中的哈希序列本地重现PCR计算，与报告的PCR值比对。一致则证明成功。

---

6. 现实的考量：性能与用户体验

• 核心问题：复杂的验证过程会拖慢系统吗？

• 精要回答：完全不会。

  • 按需触发：验证仅在访问受保护资源（如公司内网）时发生，而非每次启动。

  • 异步操作：客户端发送报告后，系统继续正常运行，用户无感知。验证在服务器后台进行，完成后只对当次访问请求做出“允许/拒绝”的裁决。

总结

可信计算通过一个环环相扣的体系实现了动态安全：以硬件TPM为信任锚点，通过信任链传递和动态度量，客观记录系统状态；再通过基于密码学身份（代码签名）的灵活策略，而非固定的哈希白名单，来裁决状态的合法性。 这套机制在提供强大安全保证的同时，完美适应了现实世界中软件必须不断更新和变化的本质需求。

信任根 vs. 厂商公钥：信任的基石与执法的工具

这是两个不同层次、不同职责的信任起点，它们的关系是“授权”与“执行”的关系。

1. 硬件信任根：终极的“信任锚点”

• 它是什么：一段被硬编码或熔断在CPU或主板芯片中的、不可修改的代码或数据。它是系统通电后运行的第一段代码。

• 它的核心职责：

  1. 初始化信任链：它是度量BIOS/UEFI固件的起点，是整个信任链的发起者。

  2. 验证TPM：它负责初始化和验证TPM芯片的真实性。

  3. 持有最顶级的密钥：在某些实现中，它持有验证平台最核心固件（如Intel Boot Guard）的根公钥。

简单说，信任根是系统唯一无条件信任的“上帝”。它的唯一性保证了信任链起点的纯洁。

2. 厂商公钥：被授权的“执法官”

• 它是什么：主板制造商（如Dell、华硕）的公钥，通常被安全地存储在UEFI固件的安全启动数据库中。

• 它的核心职责：验证并执行。它负责在启动过程中，验证下一级组件（如操作系统引导程序、驱动程序）的数字签名是否由对应的厂商私钥生成。

  • 验证通过 -> 允许执行。

  • 验证失败 -> 拒绝并报错。

简单说，厂商公钥是“上帝”任命的“警察”，负责日常的执法工作。

3. 两者的关系：授权链

硬件信任根授权了厂商公钥。

这个授权关系是在电脑出厂时建立的：

1. 主板制造商生成自己的密钥对（公钥和私钥）。

2. 制造商通过安全流程，将他们的公钥置入UEFI安全启动数据库。

3. 这个“将公钥写入数据库”的动作，其合法性和最终安全性，是由更深层的硬件信任根（如UEFI的Platform Key, PK） 来保障和授权的。

因此，整个信任路径是：
硬件信任根 → 授权/验证 → 平台/制造商公钥 → 授权/验证 → 操作系统引导程序 → ...

精要总结

• 信任根是源头，是信任的原因。它本身不直接验证应用，它只确保整个信任体系从一个纯净的起点开始。

• 厂商公钥是工具，是信任的结果和延伸。它在信任根建立的纯净环境下，具体执行“允许/拒绝”的决策。

有了信任根为什么还需要厂商公钥？
因为信任根是固定、稀缺且不灵活的。它无法直接认知成千上万不断变化的软件。需要厂商公钥这样一个灵活的、可更新的策略执行者，来将顶层的信任传递到动态的软件世界中去。两者分工协作，缺一不可。