4、可信计算基础：可信根（Root of Trust）、信任链（Chain of Trust）、TPM/TCM规范、远程证明（Remote Attestation）核心概念

可信计算（Trusted Computing）是服务器安全架构的基石，其核心思想是“从信任的源头出发，逐级验证，构建一条不被破坏的信任传递路径”。在服务器CPU安全体系中，可信计算并非单一技术，而是一套涵盖硬件锚点、固件校验、系统度量、远程验证的完整闭环。本章将围绕可信根、信任链、TPM/TCM规范与远程证明四大核心概念展开，帮助读者建立从硬件可信锚点到云端验证的完整认知框架。

可信计算核心概念关系与信任链传递模型 可信根 (RoT) 硬件锚点 RTM (度量根) RTS (存储根) RTR (报告根) TPM / TCM 安全密码协处理器 PCR 平台配置寄存器 EK / SRK 密钥 Quote 签名引擎 信任链 (CoT) 逐级度量验证 BIOS Boot Block Option ROM / Bootloader OS Kernel / Hypervisor 远程证明 Remote Attestation Challenge-Response PCR 值 + Nonce 签名 验证方比对基准值 度量 扩展/校验 度量值汇总 签名报告 信任传递逻辑 1. 硬件RoT作为信任锚点 2. 度量值逐级扩展到PCR 3. 信任链覆盖到OS/App 4. 远程证明向外部验证 5. 任何一级失败则拒绝启动 可信根 TPM/TCM 信任链 远程证明

4.1 可信根（Root of Trust）——信任的硬件锚点

4.1.1 核心原理：为什么需要可信根

可信计算的根本问题在于：软件层面的校验无法自证清白。如果攻击者已经篡改了操作系统或BIOS，那么由这些被篡改的软件发起的自检结果就毫无意义。因此，必须存在一个物理上不可篡改、逻辑上不可绕过的硬件锚点，作为所有信任判断的起点。这个锚点就是可信根（Root of Trust, RoT）。在服务器CPU中，可信根通常由CPU内部的安全协处理器（如Intel的CSME、AMD的PSP）或独立的TPM芯片承担。

可信根在功能上分为三个子模块，三者协同工作：

  • 度量根（RTM, Root of Trust for Measurement）：负责执行首次度量动作，即对系统启动的第一段代码（如BIOS Boot Block）进行哈希计算。RTM必须保证自身是“干净的”，通常由CPU微码或ROM中的固件实现。
  • 存储根（RTS, Root of Trust for Storage）：负责安全存储度量值、密钥和证书。RTS必须能够抵抗物理攻击和总线嗅探，通常由TPM芯片内部的非易失性存储器（NVRAM）实现。
  • 报告根（RTR, Root of Trust for Reporting）：负责向外部实体（如远程验证服务器）提供可信的、经过签名的平台状态报告。RTR必须确保报告内容真实反映PCR寄存器的值，且不可被伪造。
关键理解：可信根不是“一个芯片”那么简单，而是一组硬件能力的集合。在x86服务器中，CPU内部的微码负责RTM，TPM芯片负责RTS和RTR；在ARM服务器中，TrustZone技术将安全世界（Secure World）作为RoT的载体。设计服务器安全方案时，必须明确这三个子模块分别由谁承担，以及它们之间的信任边界。

4.1.2 判断方法：如何评估可信根的强度

在实际选型或安全审计中，可以从以下维度评估一个可信根方案的强度：

评估维度强可信根特征弱可信根特征
物理防篡改芯片有主动屏蔽层、总线加密、防侧信道设计仅依赖外部封装，无主动防护
密钥保护私钥永不出芯片，支持直接匿名认证（DAA）私钥可被软件读取或导出
更新机制支持经签名的固件更新，有版本回滚保护固件可被降级或未签名更新
隔离性与主CPU物理隔离或逻辑隔离（如TrustZone）与主CPU共享内存且无隔离
性能开销硬件加速哈希和签名，不影响启动速度依赖软件模拟，启动时间显著增加

4.1.3 实战场景：服务器启动时的可信根调用

以一台搭载Intel Xeon Scalable处理器和独立TPM 2.0芯片的服务器为例，其启动过程对可信根的调用如下：

  1. CPU上电后，微码（Microcode）首先执行，这是RTM的起点。微码对BIOS的第一个扇区（Boot Block）进行SHA-256哈希计算。
  2. 哈希结果通过LPC或SPI总线发送给TPM芯片，TPM将值扩展（Extend）到PCR[0]寄存器。
  3. BIOS Boot Block执行后，继续度量BIOS主固件，将结果扩展到PCR[1]。
  4. BIOS主固件度量Option ROM和Bootloader，结果扩展到PCR[2]、PCR[3]等。
  5. 操作系统内核加载时，内核度量自身和关键驱动，扩展到PCR[4]及以后。

整个过程，TPM芯片始终作为“旁观者”记录度量值，不干预执行流程。这种设计保证了即使某个环节被攻破，PCR值也会如实反映异常，为后续的远程证明提供依据。

常见误区：很多运维人员认为“服务器有TPM芯片就安全了”。实际上，如果BIOS没有正确调用TPM的度量功能，或者TPM的PCR值没有被远程验证方检查，那么TPM形同虚设。可信根的价值在于“被使用”，而非“存在”。

4.2 信任链（Chain of Trust）——从锚点到系统的信任传递

4.2.1 核心原理：逐级度量与扩展

信任链解决的是“如何从可信根出发，建立对整个系统的信任”的问题。其核心机制是逐级度量（Measured Boot）：每一级代码在获得执行权之前，先由上一级对其进行完整性度量，度量值记录到PCR寄存器中，然后才移交控制权。这种“先度量、后执行”的模式，确保了任何一级被篡改，都会在PCR值中留下痕迹。

信任链的传递遵循严格的顺序依赖：

信任链传递伪代码：
1. RTM (CPU微码) 度量 BIOS Boot Block
   → 哈希值 H1 扩展到 PCR[0]
   → 若 H1 与基准值一致，执行 Boot Block
2. Boot Block 度量 BIOS 主固件
   → 哈希值 H2 扩展到 PCR[1]
   → 若 H2 与基准值一致，执行 BIOS 主固件
3. BIOS 主固件度量 Option ROM / Bootloader
   → 哈希值 H3 扩展到 PCR[2]
   → 若 H3 与基准值一致，执行 Bootloader
4. Bootloader 度量 OS Kernel
   → 哈希值 H4 扩展到 PCR[3]
   → 若 H4 与基准值一致，执行 OS Kernel
5. 后续应用层度量由 OS 安全机制接管

这里需要特别理解PCR的扩展（Extend）操作：它不是简单的覆盖写，而是 PCR_new = SHA256(PCR_old || 新度量值)。这种链式哈希的特性使得PCR值记录了所有历史度量值的累积指纹，攻击者无法通过“回滚”到某个旧状态来伪造PCR值。

4.2.2 操作流程：构建一条完整的信任链

在实际服务器部署中，构建信任链需要以下步骤：

  1. 启用硬件RoT：在BIOS设置中开启TPM功能，并确保CPU的RTM（微码度量）未被禁用。
  2. 配置Secure Boot：在UEFI设置中启用Secure Boot，确保Bootloader和OS Kernel的签名被验证。
  3. 建立基准值库：在首次干净安装系统后，记录各PCR的基准值，并安全存储（如离线数据库或签名清单）。
  4. 启用完整性度量架构（IMA）：在Linux内核中启用IMA，对可执行文件和关键配置进行运行时度量。
  5. 配置远程验证策略：设置验证服务器，定期或按需获取服务器的PCR值并进行比对。
经验提醒：信任链并非越长越好。每增加一级度量，就增加一个潜在的失败点。在性能敏感的场景（如高频交易服务器），可以考虑“信任链截断”——只度量到OS内核，应用层信任由容器或虚拟化隔离来保证。这需要在安全性和性能之间做出权衡。

4.2.3 案例拆解：一次启动失败的分析

背景：某云服务商在批量更新BIOS固件后，部分物理服务器无法正常启动，且无法通过远程管理卡进入系统。

初始现象：服务器电源指示灯正常，但网络不可达，管理卡日志显示“TPM PCR[0] mismatch”错误。

关键数据：

  • 更新前PCR[0]基准值：0x3A4F8C2B...
  • 更新后PCR[0]实际值：0x7B1E9D45...
  • BIOS版本：从v2.1升级到v2.2

分析判断：PCR[0]度量的是BIOS Boot Block。固件升级后，Boot Block代码发生变化，导致哈希值改变。而服务器的信任链策略配置为“PCR值不匹配则拒绝启动”（严格模式），因此系统被锁定。

实际操作：

  1. 通过带外管理（如iLO/IDRAC）进入BIOS设置，临时关闭“TPM强制校验”选项。
  2. 正常启动系统，确认新固件运行稳定。
  3. 重新采集PCR[0]的新基准值，更新到验证服务器的基准值库中。
  4. 重新启用“TPM强制校验”，并验证系统可正常启动。

结果对比：恢复时间从预期的“每台2小时”缩短到“每台15分钟”。风险与代价：在关闭校验的窗口期内，服务器面临固件被篡改的风险，因此操作必须在隔离网络中进行。

复盘经验：固件升级必须与PCR基准值更新同步进行，建议在变更流程中加入“TPM基准值重采集”步骤。

4.3 TPM/TCM规范——可信计算的硬件载体

4.3.1 核心原理：TPM与TCM的架构对比

TPM（Trusted Platform Module）是国际主流的可信计算芯片规范，由TCG（Trusted Computing Group）制定，当前主流版本为TPM 2.0。TCM（Trusted Cryptography Module）是中国制定的可信计算芯片规范，由国密局主导，其密码算法基于SM2/SM3/SM4国密算法。两者在架构上有相似之处，但在算法支持和合规要求上存在显著差异。

对比维度TPM 2.0TCM
制定组织TCG（国际）中国国家密码管理局
核心算法RSA/ECC/SHA-256/HMACSM2/SM3/SM4
密钥类型EK、SRK、Attestation KeyEK、SMK（存储主密钥）
PCR数量至少24个（TPM2.0）至少16个
授权机制Password/PIN/PCR PolicyPassword/国密算法签名
合规要求国际通用，无国内合规要求满足等保2.0和密评要求
生态支持Windows/Linux原生支持需安装国密驱动和中间件

TPM 2.0相比1.2版本，在算法灵活性、授权策略、密钥层次等方面有大幅改进。其核心组件包括：

  • PCR（Platform Configuration Register）：至少24个，用于存储度量值。
  • EK（Endorsement Key）：出厂时写入的不可迁移密钥，代表芯片身份。
  • SRK（Storage Root Key）：保护其他密钥的根密钥，存储在芯片内部。
  • Quote引擎：对PCR值进行签名的功能模块，用于远程证明。
  • NVRAM：安全存储区，用于保存证书、策略等数据。

4.3.2 操作流程：TPM的初始化与使用

在服务器上启用TPM的典型流程如下：

# 1. 检查TPM状态（Linux）
cat /sys/class/tpm/tpm0/device/description
# 输出示例：TPM 2.0 Device

# 2. 安装tpm2-tools工具包
apt install tpm2-tools

# 3. 获取TPM随机数（验证基本功能）
tpm2_getrandom 16 --hex

# 4. 创建主密钥（SRK）
tpm2_createprimary -C e -c primary.ctx

# 5. 创建子密钥
tpm2_create -C primary.ctx -u key.pub -r key.priv

# 6. 加载密钥
tpm2_load -C primary.ctx -u key.pub -r key.priv -c key.ctx

# 7. 使用密钥签名
echo "test data" | tpm2_sign -c key.ctx -g sha256 -o sig.bin
风险说明：TPM的NVRAM空间有限（通常64KB~128KB），且写入次数有限制（约10万次）。不要将频繁更新的数据写入TPM NVRAM，应使用TPM保护的文件加密密钥（如LUKS密钥），而非直接存储业务数据。

4.3.3 实战场景：TCM在等保合规中的应用

在中国境内的政务云或金融云场景中，等保2.0三级及以上要求使用国密算法。某政务云平台在等保测评中，被要求“可信计算基使用国密算法”。该平台原使用TPM 1.2芯片，无法满足要求。

改造方案：

  1. 硬件层面：将服务器主板上的TPM芯片更换为TCM芯片（如国民技术Z32H330TC）。
  2. 驱动层面：安装TCM驱动和国密中间件（如三未信安、江南天安的产品）。
  3. 应用层面：将LUKS磁盘加密的密钥保护从TPM切换到TCM，使用SM4算法加密。
  4. 远程证明：将验证服务器的签名算法从RSA/SHA-256切换为SM2/SM3。

结果：顺利通过等保测评，且性能开销增加不到5%。复盘经验：TCM的生态不如TPM成熟，部分开源工具（如tpm2-tools）不直接支持TCM，需要厂商提供配套工具链。

4.4 远程证明（Remote Attestation）——向外部验证平台可信状态

4.4.1 核心原理：挑战-响应机制

远程证明解决的是“如何让远程的验证方相信本平台处于可信状态”的问题。其核心是挑战-响应（Challenge-Response）机制：验证方发送一个随机数（Nonce），被验证方使用TPM的Quote引擎对当前PCR值进行签名，并将签名结果返回。验证方通过验证签名和比对PCR基准值，判断平台是否可信。

完整的远程证明流程包含以下步骤：

  1. 挑战阶段：验证方生成随机数Nonce，发送给被验证方。
  2. 收集阶段：被验证方读取当前PCR值（如PCR[0]-PCR[7]）。
  3. 签名阶段：TPM使用Attestation Key（AK）对“PCR值 + Nonce”进行签名，生成Quote数据。
  4. 响应阶段：被验证方将Quote数据、PCR值、AK证书发送给验证方。
  5. 验证阶段：验证方执行以下检查：
    • 验证AK证书的合法性（是否由可信CA签发）；
    • 使用AK公钥验证Quote签名；
    • 检查Nonce是否与挑战时一致（防重放攻击）；
    • 将PCR值与基准值库比对，判断是否匹配。
重要概念：远程证明中的“证明”不是证明“平台没有被攻击”，而是证明“平台当前处于某个已知状态”。如果基准值库中的PCR值本身就是被攻击后的状态，那么远程证明依然会通过。因此，基准值库的建立和维护是远程证明安全性的关键。

4.4.2 判断方法：远程证明的信任模型

远程证明的信任模型分为三种，适用于不同场景：

信任模型验证方式适用场景优点缺点
直接匿名证明（DAA）使用DAA签名，不暴露EK身份公有云、隐私敏感场景保护平台隐私实现复杂，性能开销大
Privacy CA通过第三方CA签发AK证书企业内网、私有云实现简单，兼容性好依赖CA可用性
直接验证验证方直接信任EK小规模、高信任环境无需额外CA扩展性差，EK暴露风险

4.4.3 案例拆解：零信任架构中的远程证明实践

背景：某大型互联网公司实施零信任架构，要求所有接入内部网络的服务器必须通过远程证明，否则拒绝接入。

初始目标：在30分钟内完成1000台服务器的远程证明改造。

关键输入：

  • 服务器配置：Intel Xeon Gold 6248R，TPM 2.0芯片
  • 操作系统：Ubuntu 20.04 LTS
  • 验证服务器：独立的Raspberry Pi 4B（用于测试），生产环境使用高可用集群

实施步骤：

  1. 在每台服务器上安装 tpm2-tools 和 tpm2-tss 引擎。
  2. 编写脚本采集PCR基准值，并上传到验证服务器。
  3. 配置 systemd 服务，在启动时自动执行远程证明客户端。
  4. 验证服务器部署 libtpm 和自定义验证逻辑，支持批量验证。
  5. 在交换机上配置802.1X，只有通过远程证明的服务器才能获得网络访问权限。

结果对比：

指标改造前改造后
服务器接入时间即时接入平均3.2秒（含证明时间）
异常检测率依赖传统IDS，滞后实时检测，篡改即拒绝接入
运维复杂度低需维护基准值库，定期更新

风险与代价：远程证明增加了启动时间（约3秒），且基准值库需要随系统更新而同步更新。如果基准值库维护不及时，会导致大量服务器被误拒绝。复盘经验：建议将基准值库的更新纳入CI/CD流程，与系统镜像更新同步。

最佳实践：远程证明不应只做“一次性验证”，而应结合周期性验证（如每24小时）和事件驱动验证（如检测到关键文件变更时）。同时，建议将远程证明与SIEM系统集成，实现安全事件的自动化响应。

4.5 总结与常见误区

可信计算基础是服务器CPU安全架构的“信任起点”，其核心逻辑可以概括为：硬件锚定、逐级度量、密码签名、远程验证。在实际部署中，需要特别注意以下常见误区：

  • 误区一：认为TPM芯片等于安全。TPM只是提供密码学功能的硬件，如果上层软件不调用其度量功能，或者验证方不检查PCR值，TPM就只是一个“昂贵的随机数发生器”。
  • 误区二：忽视基准值库的维护。远程证明的强度完全取决于基准值库的准确性。系统更新、固件升级、驱动变更都会导致PCR值变化，必须同步更新基准值库。
  • 误区三：信任链越长越好。过长的信任链会增加启动失败的风险和性能开销。应根据业务安全需求，合理选择信任链的
    ← 上一章 📖 返回目录 下一章 →