机密计算入门：数据使用中的安全与TEE

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

硬盘加密了、网络加密了，可数据一进内存就是明文——谁来保护”正在被计算的数据”？

📚 基本概念速读

名称 定义 省流
数据三态 静态、传输中、使用中三种数据状态 内存里的数据最危险
TEE Trusted Execution Environment，可信执行环境 CPU 里的硬件保险箱
CVM Confidential Virtual Machine，机密虚拟机 内存被硬件加密的虚拟机
SEV-SNP AMD 的 CVM 技术（安全加密虚拟化-安全嵌套分页） AMD 系机密虚拟机
TDX Intel 的 CVM 技术（信任域扩展） Intel 系机密虚拟机
CCA ARM 的 CVM 技术（机密计算架构） ARM 系机密虚拟机
内存加密 数据在内存里以密文形式存储 明文只在 CPU 芯片内出现
信任根（RoT） Root of Trust，信任链的起点 安全体系的”根”
黑盒信任根 用户无法直接验证的信任根 信任全押在厂商身上
信任缺口 trust gap，用户与云平台间的信任落差 数据你说了不算
TLS Transport Layer Security，传输层安全协议 加密管道本身
HTTPS HTTP over TLS 加密管道送 HTTP

🧩 数据三态：为什么内存里的数据最难保护

任何数据在生命周期里都有三种状态：

1
2
3
4
5
┌─────────────────────────────────────────────────┐
│  ① 静态数据 (Data at Rest)   → 存在硬盘/磁盘里     │
│  ② 传输中数据 (Data in Transit) → 网络上传输       │
│  ③ 使用中数据 (Data in Use)  → 在内存里被 CPU 计算  │
└─────────────────────────────────────────────────┘

传统加密方案只保护前两种：

状态 保护手段 例子
静态 磁盘加密 BitLocker、LUKS
传输中 网络加密 HTTPS/TLS
使用中 ❌ 传统方案管不了 内存里的明文

第 ③ 种状态是真正的盲区：数据在内存里被 CPU 处理时是明文。在传统云环境里，云服务商的运维人员、管理员、甚至被攻破的虚拟机监控器（hypervisor）都能看到内存里的明文数据。

典型场景：云端跑 AI 推理，模型权重和用户数据在内存里参与计算。磁盘加密管静态、HTTPS 管传输，唯独”正在计算”这一头是裸奔的。

🏦 TEE：给 CPU 装一个保险箱

TEE（Trusted Execution Environment，可信执行环境） 的思路：在 CPU 硬件层面划出一块隔离区域，里面的数据和代码连操作系统、hypervisor、甚至物理上能摸到内存条的人都读不走。

1
2
3
4
5
6
7
普通虚拟机 vs 机密虚拟机（CVM）
┌─────────────────────┐   ┌─────────────────────┐
│   普通 VM            │   │  CVM（机密虚拟机）    │
│  内存 = 明文         │   │  内存 = 硬件加密      │
│  hypervisor 能读     │   │  hypervisor 读不了    │
│  管理员能读          │   │  物理攻击也读不了     │
└─────────────────────┘   └─────────────────────┘

主流的 CVM 技术：

技术 厂商 特点
AMD SEV-SNP AMD 内存加密 + SNP（安全嵌套分页）防篡改，生态最成熟
Intel TDX Intel 类似思路，生态还在早期
ARM CCA ARM 面向 ARM 芯片，适合移动/嵌入式

一句话：TEE = 硬件帮你把”正在计算的数据”锁进保险箱。

🔐 内存加密：计算时不还是要解密吗？

这是最常问的问题。答案：要解密，但解密发生在 CPU 芯片”内部”，明文永远不出芯片。

1
2
3
4
5
6
7
8
9
10
传统（无内存加密）：
  DRAM(明文) ──内存总线──> CPU 计算 ──> DRAM(明文)
  ▲                                ▲
  └─ 总线嗅探、插内存条、冷启动都能读到明文 ─┘

内存加密后（SEV）：
  DRAM(密文) ──内存总线──> CPU 内部解密 → 明文只存在于芯片内 ──> 重新加密写回 DRAM
                    │        （缓存/寄存器/执行单元）
                    │
                    └─ 总线上的、DRAM 里的，全是密文 AES(key)

四个关键点：

  1. 密钥永远在 CPU 内部，由 CPU 的专用安全处理器（AMD 是 PSP，Platform Security Processor）生成和管理，外界拿不到。
  2. 解密点 = 内存控制器，它就在 CPU 芯片上。数据从 DRAM 进入芯片后才被解密；离开芯片写回内存前被加密。
  3. 攻击者能接触到的所有地方——内存条、总线、DMA 设备——看到的都是密文。“计算”这个动作发生在芯片内部，外人看不到明文。
  4. 类比：CPU 是个保密工厂。仓库（DRAM）里堆的全是加密原料，原料进车间（芯片内部）才解锁加工，成品出车间前重新上锁。你能抢仓库、能蹲在传送带（总线）旁边，但看到的永远是锁着的东西。

边界提醒：这个模型防的是”外部窃读”。如果攻击者攻破了 CVM 内部的软件（guest kernel 漏洞），明文当然还是会被读到——这要靠后面讲的远程认证来保证 CVM 内部没被装后门。

🧷 HTTPS 和 TLS 的区别

TLS 是”加密管道”协议本身，HTTPS 是”HTTP 跑在 TLS 管道里”这个组合。

1
2
3
HTTP ──┐
TLS  ──┼──> HTTPS = HTTP over TLS（https:// 前缀）
TCP/IP─┘
概念 是什么
TLS 独立的加密协议：握手、证书验证、密钥协商、加密传输。不关心上面跑的是什么
HTTPS “HTTP + TLS”的固定组合，是 TLS 最常见的应用场景
SSL TLS 的前身（SSL 3.0 → TLS 1.0），现在说”SSL 证书”其实都是 TLS 证书

TLS 不只服务 HTTP：比如内核里可以直接跑 TLS（kernel TLS），给特定通道做端到端加密，这是机密计算里的常见性能优化点。

🔮 黑盒信任根：TEE 的信任缺口

TEE 的保险箱钥匙（信任根）捏在芯片厂商手里：

  • 你要相信 AMD/Intel 的密钥管理、固件、证书链全都没问题
  • 用户无法直接验证，只能”信任厂商”，这叫 black-box trust root（黑盒信任根）
  • 用户和云平台之间存在 trust gap（信任缺口）：数据在你云上跑，但你说了不算
1
2
3
4
5
传统 TEE 信任模型：
  用户 → 信任 → 云平台 → 信任 → 芯片厂商
        └──────────────────────────┘
        信任链全部建立在"厂商没毛病"上，
        用户没有独立验证的入口，这叫黑盒

三个具体痛点：

痛点 说明
厂商依赖 用户必须信任制造商，制造商出问题或作恶，安全就崩
无法独立验证 验证服务本身也是厂商/平台提供的，用户只能被动接受结论
多租户复杂 多租户云环境虚拟化栈复杂，漏洞不可避免，风险放大

这正是 TEE 与 TPM 协作信任的切入点：TPM 是用户能直接访问、能自己配置的”白盒”信任根，用它来制衡 TEE 的黑盒信任根。

⚠️ 常见误区

误区 正解
磁盘加密 + HTTPS 就能保护云端数据 只保护静态和传输两种状态，内存里的使用中数据仍是明文
内存加密后 CPU 计算会暴露明文 解密只在 CPU 芯片内部，外部看到的永远是密文
TEE 是纯软件方案 TEE 依赖 CPU 硬件隔离和内存加密，密钥由芯片内安全处理器管理
信任厂商 = 安全 黑盒信任根意味着用户无法独立验证，存在信任缺口
HTTPS 和 TLS 是两种加密技术 HTTPS = HTTP over TLS，TLS 才是底层协议
SSL 和 TLS 没关系 TLS 是 SSL 的继任者，本质同一套体系

✅ 总结

数据在使用中（内存里）是明文，传统加密管不了，需要 TEE 这类硬件级隔离；TEE 靠”内存加密 + 解密只在芯片内”保护使用中数据，但它的信任根归厂商、用户无法验证，形成了黑盒信任缺口——这正是 TEE + TPM 协作信任要解决的问题。

下一站：SEV-SNP 的隔离到底怎么做到的（NPT、RMP、ASID）。

Happy Hacking! 🎉