信任根三件套：RTM、RTR、RTS与TEE+TPM协作

Posted on In , Views: Word count in article: 4.6k Reading time ≈ 8 mins.

TEE 是黑盒信任根，TPM 是白盒信任根——把它们拼在一起，就拼出了 CCxTrust 协作信任的核心。

📚 基本概念速读

名称 定义 省流
RTM Root of Trust for Measurement，度量信任根 记账员：负责测量
RTR Root of Trust for Report，报告信任根 公证员：负责汇报
RTS Root of Trust for Storage，存储信任根 保险库：负责藏钥匙
黑盒信任根 black-box RoT TEE 的信任根，用户够不着
白盒信任根 white-box RoT TPM 的信任根，用户可访问可配置
TCB Trusted Computing Base，受信计算基 安全所依赖的最小可信组件集合
信任链 chain of trust 从物理锚点逐级验证的链条
信任锚 trust anchor 信任链的起点，物理上不可篡改
PSP Platform Security Processor，平台安全处理器 AMD CPU 里的独立安全协处理器
复合认证 composite attestation TEE 和 TPM 合并出认证报告

🧩 信任根三件套：RTM / RTR / RTS

TCG 把”可信平台”拆成三个信任根。整个 CCxTrust 架构就是围绕这三个根怎么分配展开的：

信任根 全称 干什么 通俗类比
RTM Root of Trust for Measurement，度量信任根 负责测量系统状态，保证”测了、记了、改不了” 记账员
RTR Root of Trust for Report，报告信任根 负责把测量结果可信地报出去（签名） 公证员
RTS Root of Trust for Storage，存储信任根 负责保护密钥等秘密 保险库

一句话：RTM 管”测量”，RTR 管”汇报”，RTS 管”存储”。一台机器可不可信，就是”测得好、报得真、藏得牢”三件事。

⚖️ 黑盒 TEE + 白盒 TPM：各有所长

TEE 和 TPM 是两种完全不同的信任根：

1
2
3
4
5
6
7
8
          TEE（SEV-SNP）                 TPM
       ┌──────────────────┐        ┌──────────────────┐
信任模式│  black-box        │        │  white-box        │
       │  信任根归厂商       │        │  用户可直接访问     │
可访问性│  用户够不着（API 受限）│        │  用户可配置可验证     │
强项   │  强隔离的执行环境    │        │  用户侧密钥/存储/认证 │
短板   │  信任是黑箱         │        │  没有执行环境       │
       └──────────────────┘        └──────────────────┘

关键差异：CPU-TEE 信任根是黑盒的，只能给系统底层（固件、hypervisor、内核）用，用户够不着、验不了；TPM 是白盒的，用户可以直接访问、配置、验证，能补上 TEE 没有的用户侧能力。

三个核心挑战与对应方案：

挑战 问题 方案
Q1 怎么建立用户可控的信任体系？ S1：协作信任根（TEE+TPM）
Q2 怎么弥合 TEE 和 TPM 的技术鸿沟？ S2：机密 TPM（CTPM）
Q3 怎么保证 CVM 敏感数据安全？ S3：复合认证

📐 核心分配：三件套怎么分工

CCxTrust 的原创设计——不搞一家独大，让 TEE 和 TPM 分工协作：

1
2
3
4
5
6
7
8
9
10
RTM（度量）  → TEE 与 TPM 并行独立，各测各的域
              TEE 测：硬件/固件/启动环境（TEE 的 TCB）
              TPM 测：hypervisor、guest OS、工作负载
              → 两块"账本"互不依赖，一份被攻破，另一份还在

RTR（报告）  → TEE 与 TPM 协作，生成"复合认证报告"
              → 单一报告根容易被伪造/拼接攻击（见下）

RTS（存储）  → 完全交给 TPM
              → 用户密钥由 TPM 密封存储，TEE 也把密钥托管给 TPM

为什么这样分？

分配 原因
RTM 并行独立 两者测的域不同、互不依赖，形成”双保险”（dual insurance）
RTR 协作 单一报告根容易被伪造/拼接攻击，合并成一份报告才能防拼接
RTS 归 TPM TEE 没有持久存储能力（内存加密但掉电即失），TPM 有 NVRAM + 密钥树，天生是保险库

📏 三阶段测量：RTM 的具体落地

CVM 的信任链从启动到运行分成三个阶段：

1
2
3
4
5
6
7
8
9
10
11
12
13
┌─────────────────────────────────────────────────────────────┐
│ Stage 1：Host 静态测量（CVM 启动前）                          │
│   测 hypervisor、host 内核、虚拟化服务                        │
│   → 保证"我住的房子是干净的"                                 │
├─────────────────────────────────────────────────────────────┤
│ Stage 2：CVM 启动测量                                        │
│   测 guest 固件、内核、initrd、根文件系统、镜像签名            │
│   → 保证"住进来的这个租客是预期的"                            │
├─────────────────────────────────────────────────────────────┤
│ Stage 3：运行时测量（动态）                                   │
│   TEE 对 CVM 内工作负载做完整性校验                           │
│   → 保证"运行过程中没被篡改"                                 │
└─────────────────────────────────────────────────────────────┘

前两阶段偏静态（启动时测一次），第三阶段偏动态（运行中持续测）。也就是”静态 + 动态信任链结合”。

顺带澄清一个容易混的概念：hypervisor 不是固件。层次是：应用 → Guest OS → hypervisor（软件）→ 固件 Firmware（UEFI/BIOS、PSP 等，烧在只读存储里）→ CPU 硬件。固件启动 hypervisor，hypervisor 启动 guest。

🔗 度量分工重合吗？——这是”双保险”不是 bug

设计上”TEE 测固件、TPM 测 hypervisor”，但现实中 TPM 的启动链本来也测固件（UEFI 启动时自己 Extend PCR）。实践中有重叠，但这是刻意为之：

1
2
3
4
5
设计意图 = 双保险（redundancy）：
· 两个独立的测量源（TEE 的 PSP 侧 vs TPM 芯片侧），互不信任、互不依赖
· TEE 的测量域 = "TEE 自己的启动信任链"（PSP→SEV 固件→OVMF 等）
· TPM 的测量域 = "平台全局启动链"（UEFI→hypervisor→guest）
· 哪怕一条链被攻破/伪造，另一条链的账本仍然可信

概念上分工（各测各的域），实践上有重叠（都碰固件），重叠是刻意的冗余设计。

🔑 信任链与信任锚：固件为什么改不了

PCR 的”固件逻辑强制”依赖一个前提：固件本身不能被恶意修改。这靠两道防线，不是靠”加载时度量”一次解决：

1
2
3
4
5
6
7
8
9
10
① 物理防护（第一道，硬件级）：
   · dTPM 是独立芯片，固件写在一次性熔丝/受保护闪存里，
     常规软件攻击根本写不进去
   · fTPM 在 CPU 的 PSP 里，PSP 固件有签名校验 + 只读存储
   → "改 TPM 固件"不是软件层能做到的事，物理防护兜底

② 信任链（第二道，启动级）：
   从"绝对可信的起点"逐级验证：
   硬件（RoT 芯片）→ 验证固件 → 固件验证 bootloader → bootloader 验证内核 → ...
   每一步都由前一步验证

所以准确表述是：

防护对象 防护手段
TPM 固件本身不可改 物理防护（熔丝、受保护存储、签名校验）
系统软件（内核等）不被篡改 信任链（启动时逐级度量 + 签名校验）

信任链的起点（信任锚）是谁？ 是硬件本身（RoT，Root of Trust，信任根）——它是物理上无法篡改的，比如 TPM 芯片内部逻辑、CPU 内部的 PSP ROM。信任链不是无限的，它终止于一个”物理可信”的锚点，这就是”根（Root）“的含义。

修正一个常见说法：不是”加载时度量保证固件不可改”——UEFI 是第一级软件，加载时已经没人能度量它了，它靠的是硬件锚点 + 物理防护。

🔩 PSP：AMD 芯片里的”先于一切”的安全小电脑

PSP（Platform Security Processor，平台安全处理器） 是 AMD CPU 里的独立 ARM 安全协处理器，相当于”CPU 里的一个小电脑”：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
┌─────────────────────────────┐
│ AMD CPU 芯片                 │
│  ┌─────────────────────────┐ │
│  │ x86 主核（跑你的系统）     │ │
│  └─────────────────────────┘ │
│  ┌─────────────────────────┐ │
│  │ PSP（独立 ARM 核）        │ │
│  │ · 芯片上电先于 x86 主核   │ │
│  │ · 跑在隔离的安全环境里    │ │
│  │ · 管理：SEV 内存加密密钥、 │ │
│  │   RMP 表、固件签名校验、  │ │
│  │   fTPM、DMA 保护          │ │
│  └─────────────────────────┘ │
└─────────────────────────────┘

PSP 的核心角色：

场景 PSP 干什么
“TEE 通过 PSP 进行信任初始化” PSP 是 TEE 信任链的起点（锚点）
内存加密 PSP 生成和管理内存加密密钥
RMP 归属分配 PSP 固件执行 RMPUPDATE，锁定页归属
fTPM AMD 的 fTPM 就跑在 PSP 里

一句话：PSP 是 AMD 芯片里”先于一切、独立于一切”的安全小电脑，TEE 的信任锚就是它。 类似地，Intel 有 Intel ME/CSE，ARM 有 TrustZone 的 secure world。

🔭 展望：RTR 协作 = 复合认证

本篇已建立完整骨架，最后预告 CCxTrust 最核心的一环——RTR 协作。

为什么独立认证不够：TEE 和 TPM 各自单独出认证报告时：

1
2
3
4
5
· 攻击者可能伪造 CVM 的 ID 发起攻击
· 攻击者可能做"报告拼接攻击"（report concatenation）：
  把 A 机器的 TPM 报告 + B 机器的 TEE 报告拼成"完整报告"
  → 验证方以为是一台可信机器的完整状态，实际是两台机器拼的
· 独立认证需要两次交互（两个数据拷贝、两次签名、两次报告返回），效率低

CCxTrust 的解法：复合认证协议——把 TEE 报告嵌进 TPM Quote（或反过来），生成一份不可拆分的复合报告，一次交互完成认证。拼接攻击的根基（两份独立报告）被直接消灭，认证效率还提升了 24%。

⚠️ 常见误区

误区 正解
RTM/RTR/RTS 是 CCxTrust 发明的 是 TCG 标准术语，CCxTrust 的创新在于”怎么分配”
TEE 比 TPM 强，全都用 TEE TEE 是黑盒、无持久存储、用户够不着；TPM 是白盒、有存储，两者互补
度量分工必须严格不重合 实践中有重叠，这是刻意的双保险冗余设计
固件不可篡改靠启动时度量 固件本身靠物理防护（熔丝/受保护存储），度量管的是系统软件
信任链可以无限延伸 信任链终止于物理锚点（TPM 芯片、PSP），根不需要被验证
hypervisor 是底层固件 hypervisor 是软件层，固件在它下面一层
TEE 和 TPM 各自出报告就行 独立报告可被拼接攻击利用，复合认证才能防拼接

✅ 总结

信任根三件套中，RTM 管测量、RTR 管报告、RTS 管存储；CCxTrust 让 TEE 和 TPM 分工协作——RTM 并行独立（双保险）、RTR 复合认证（防拼接）、RTS 归 TPM（用白盒补黑盒），通过三阶段测量覆盖从启动到运行的完整信任链，信任锚则落在 PSP 等物理硬件上。这就是 CCxTrust 协作信任的全貌。

Happy Hacking! 🎉