可信系统与可信计算：把“相信”变成可验证证据

可信系统不是宣称“绝对不会被攻破”，而是明确哪些组件必须被信任、它们执行什么策略、信任边界在哪里，以及我们凭什么相信这些结论。可信计算把抽象策略、最小 TCB、硬件信任根、启动度量和评估证据连接成一条可检查的链。

学习目标：可信不等于安全

学完后，你应能区分 trusted、trustworthy 与 secure；界定 TCB 和信任边界；解释参考监控器的完全中介、抗篡改和可验证；比较安全启动与度量启动；推导 PCR 扩展、密封和远程证明；解释 MLS 的信息流约束；读懂 TOE、功能要求、保障要求和 EAL。

“可信”表示系统被依赖来执行某组安全属性；若它失败，目标会失守。“值得信赖”强调有足够保障证据支持这种依赖。“安全”则是相对于明确策略、威胁和环境而言的状态，不是一个脱离上下文的绝对标签。

TCB、信任边界与参考监控器

TCB 包含执行安全策略所必需的硬件、固件、安全内核、策略数据和管理机制。缩小 TCB 能减少需要审计、验证和更新的代码，但不能把关键依赖假装移出边界：DMA、固件、虚拟机监控器、密钥服务或管理平面若能绕过策略，也属于实际信任面。

参考监控器是所有主体访问客体的逻辑中介，要求：

• 完全中介：每次访问都检查，任何路径都不能绕过；
• 抗篡改：主体不能修改监控器或策略数据库；
• 可验证：足够小而清晰，可以通过分析和测试建立正确性信心。

安全内核是参考监控器概念的一种实现。审计不是替代完全中介，而是记录决策和管理变化，支持发现绕过与追责。

多级安全：用标签约束信息流

多级安全同时处理不同安全级别的主体与客体。机密性导向模型中，主体不能读取高于自身许可的客体，即“禁止向上读”；主体也不能把信息写入更低级客体，即“禁止向下写”，以阻止高敏感信息泄漏。

级别之外还可有类别集合，只有许可级别和类别都支配客体标签时才满足规则。受控降级必须由经过授权的可信过程完成并留下审计，不能让普通高权限应用随意改标签。MLS 主要保护机密性；完整性、可用性和隐蔽信道还需其他模型与控制。

安全启动与度量启动

安全启动在执行前验证代码签名，未被授权的固件、引导器或内核会被阻止；它是执行控制。度量启动则对每个阶段计算哈希并记录事件，再扩展 PCR；它提供可审计状态，不一定阻止代码运行。二者结合比单独使用更强。

签名有效只说明代码由受信任密钥授权，并不自动证明代码无漏洞。事件日志解释“测量了什么”，PCR 提供难以任意改写的汇总；只有 PCR 没有日志，验证者无法定位差异；只有日志没有受保护汇总，日志可被替换。

TPM、PCR扩展与密封

TPM 提供受保护密钥操作、随机数、PCR、签名引用和密封等能力。PCR 通常不能任意写入，而是扩展：

PCR_new = H(PCR_old || measurement)

顺序或任一度量改变，最终值都会不同。密封把密钥或秘密绑定到指定 PCR 策略及授权条件；当前状态不匹配时，TPM 拒绝解封。它适合保护磁盘密钥，却需要恢复方案，否则合法固件更新也可能触发恢复。

远程证明：验证某时刻的状态

验证者发送随机 nonce，平台返回 TPM 证明密钥签名的 Quote，其中绑定 nonce、选定 PCR 和算法信息，并附事件日志。验证者检查证明密钥身份、签名、新鲜性，重放事件日志得到 PCR，再与允许策略比较。

nonce 防止重放旧证明；事件日志让 PCR 可解释；策略决定哪些版本和配置可接受。证明只反映被度量范围与某一时刻，不能证明未被测量的外设、运行后漏洞或业务逻辑永远安全，因此仍需最小权限和持续监控。

信任链、更新与恢复

信任链从不可变或受保护的根开始，每阶段验证或度量下一阶段。强度取决于最弱环节，也取决于更新、密钥轮换、撤销和恢复过程。若签名密钥泄露，攻击者可让恶意代码看似“合法”；若旧漏洞版本仍在允许列表，证明通过也不代表风险可接受。

更新应先在测试策略中加入新度量，再分阶段部署并保留受控回滚；回滚不能允许降级到已撤销版本。恢复密钥应分权保管并审计使用，避免 TPM 状态变化造成永久数据丢失。

TXT、SGX与隔离技术的正确边界

TXT 类技术可建立动态度量的启动环境，缩小某次启动所依赖的初始软件；虚拟化扩展帮助监控器隔离虚拟机。SGX 类 enclave 试图保护特定进程的代码和数据，使高权限系统软件也难直接读取 enclave 内存。

这些技术不是 TPM 的同义词。TPM 更偏向受保护密钥、平台度量、密封与证明；TXT 关注受控启动环境；SGX 关注应用级隔离。enclave 仍依赖其代码、接口和硬件实现，也可能受侧信道、回滚、拒绝服务和供应链问题影响。把更多业务代码塞入 enclave 会扩大新的 TCB。

保障与评估：功能存在不等于正确可靠

评估首先界定 TOE 边界和运行环境，再写安全目标。功能要求描述产品必须做什么，保障要求描述凭什么相信它正确实现。证据包括架构与详细设计、实现映射、测试、漏洞分析、配置管理、安全交付、运维指南和生命周期过程。

EAL 从较低到较高代表评估严谨度与证据深度增加，不是跨产品的简单“安全分数”。高 EAL 的狭窄 TOE 也不能自动保证包含它的整体系统安全；评估只对指定版本、配置、假设和威胁成立。保障是一项持续过程，更新后还要维护证据。

本机实践：模拟PCR链式验证

本机用 SHA-256 对四个模拟启动组件度量，从全零初值依次扩展：

固件: measure=6e3f0e339b964d74 PCR=c430fb34eaabd098
引导器: measure=dfec0367841bfdca PCR=673a9d77159faa2a
内核: measure=6deb84a66480eaed PCR=3a24de6046ebb379
策略: measure=5085282b6d85bfe9 PCR=d6939ccbd87e90f5

只把内核内容改为模拟篡改版本，其他阶段不变，最终 PCR 立即改变：

基线PCR= d6939ccbd87e90f5
篡改PCR= ab00e0ac3a63b8f4
验证结果= 拒绝

这说明链能检测差异，但真实验证仍需可信事件日志、签名 Quote、nonce 和版本策略，不能只比较截短字符串。

小结与设计检查表

可信系统从明确策略与边界开始，以最小 TCB 和参考监控器执行访问，以 MLS 约束敏感信息流，以安全启动阻止未授权代码，以度量启动、PCR 和远程证明产生状态证据，并通过保障评估建立对设计、实现和运维的信心。

检查时确认：TCB 是否包含所有可绕过策略的依赖；参考监控器是否完全中介；根密钥能否轮换撤销；PCR 是否配套事件日志；证明是否绑定 nonce；密封是否有恢复；允许列表是否拒绝旧漏洞版本；TOE、环境假设和证据是否与实际部署一致；SGX/TXT 等隔离是否被错误当成整体安全证明。