机密计算 —— Confidential VM 与 Confidential Container

第 8.3 讲了 TEE 技术（SGX / TDX / SEV / TrustZone）。本篇讲它们的”产品形态”——云上的 Confidential VM、Confidential Container，以及实际业务应用。

Confidential Computing 的定义

1
2
3
4
5
6
7
8
9
Confidential Computing Consortium 定义：     
  "Protection of data in use by performing 
   computation in a hardware-based, 
   attested Trusted Execution Environment."

核心三要素：     
  1. 硬件 TEE
  2. 远程证明（attested）
  3. 运行时数据保护（data in use）

数据三种状态

graph TB
  D[数据]
  D --> R1[At Rest 静态
磁盘加密 LUKS / S3]
  D --> R2[In Transit 传输
TLS / IPsec]
  D --> R3[In Use 使用
过去无解 → 现在 TEE]

数据”使用中”加密——这是机密计算填补的空白。

Confidential VM（CVM）

主流云的 CVM 产品

云 产品 底层
Microsoft Azure DCe / DCa / ECe / ECa 系列 Intel TDX / AMD SEV-SNP
Google Cloud Confidential VM C2D / N2D AMD SEV / SEV-SNP / TDX
AWS Nitro Enclaves（限制版本） Nitro 自家 + SEV
阿里云 ECS 安全增强型 TDX / SEV / 海光 CSV
腾讯云 TKE 机密计算 SEV / 海光 CSV
华为云 鲲鹏 + iTrustee TrustZone

启动 Confidential VM 的流程

graph LR
  U[用户提交 VM 模板] --> H[CSP Hypervisor]
  H --> CR[创建加密 VM
注入 vTPM / TDX module]
  CR --> BOOT[VM 启动 + Measured Boot]
  BOOT --> AT[VM 调 Quote API
得到 Attestation Report]
  AT --> US[用户拿到 Report]
  US --> VER[用户验证签名 + PCR]
  VER --> KEY[确认可信 → 注入业务密钥]
  KEY --> APP[业务运行]

关键点：

1
2
3
4
1. 用户不信任 CSP / Hypervisor
2. CSP 看不到 VM 内存
3. 用户先验证 attestation，再决定是否注入数据 / 密钥
4. 整个流程"硬件 + 协议"保证

简单 Demo：Azure Confidential VM

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Azure CLI 创建 Confidential VM
az vm create \
  --resource-group myRG \
  --name myCVM \
  --image Ubuntu2204 \
  --size Standard_DC4ads_v5 \  # SEV-SNP
  --security-type ConfidentialVM \
  --enable-vtpm true \
  --enable-secure-boot true

# 在 VM 内取 attestation
sudo apt install snp-guest-tools
snp-guest-report report.bin

# 验证
snp-guest verify report.bin

Confidential Container（CoCo）

容器粒度的机密计算：

graph TB
  K8S[K8s API]
  K8S --> CC[Confidential Container]
  CC --> KATA[Kata Container 运行时]
  KATA --> TDX_VM[TDX / SEV-SNP VM]
  TDX_VM --> POD[Pod 容器]

CoCo 项目（CNCF）

1
2
3
4
5
6
7
8
9
10
11
12
Confidential Containers（CoCo）：     
  - K8s 上跑机密容器的开源项目
  - 基于 Kata Containers 改造
  - 支持 SGX / TDX / SEV-SNP / CCA
  - 红帽 / Intel / IBM / Microsoft 共同推动
  
工作流：     
  1. K8s 调度 Pod
  2. CoCo 运行时启动加密 VM
  3. VM 内 kata-agent 启动容器
  4. 远程证明触发
  5. 业务镜像解密 + 运行

CoCo 与普通容器对比

1
2
3
4
5
6
7
8
9
10
11
12
普通容器：     
  - 共享内核
  - Host root 能 dump 进程内存
  - 不可信

CoCo（基于 TDX/SEV-SNP）：     
  - 每 Pod 一个加密 VM
  - 内核独立
  - Host 看不到 VM 内存
  - 远程证明
  - 启动比普通容器慢 2-5 秒
  - 资源占用比普通容器多一些

镜像保护

1
2
3
4
5
6
7
8
9
普通容器镜像：     公开（registry 直接拉）
CoCo 加密镜像：     
  - 用密钥加密 layer
  - 远程证明通过后才下发解密 key
  - 镜像层只在 enclave 内解密
  
工具：     
  Skopeo + ocicrypt：    加密 OCI 镜像
  KBS（Key Broker Service）：    远程证明 + key 分发

Nitro Enclaves（AWS）

AWS 走的是不一样的路线：

1
2
3
4
5
6
7
8
9
10
11
12
13
Nitro Enclaves：     
  - 不基于 SGX / TDX / SEV
  - 基于 AWS Nitro 自研 Hypervisor
  - 隔离 vCPU + RAM 给 enclave
  - 无网络、无持久化（只 vsock）
  - 通过 Nitro 远程证明 API

应用：     
  - 金融业（合规要求高）
  - 区块链私钥
  - DRM 内容保护

特点：     不需要特殊 CPU，只要 EC2

待补充：Nitro Enclaves 与 SEV-SNP 实测对比。

NVIDIA Confidential Computing（GPU TEE）

H100 引入的 GPU 机密计算：

graph LR
  CVM[Confidential VM
TDX/SEV-SNP] -.- |加密 PCIe| GPU[H100/B200
Confidential Mode]
  GPU --> ENC[GPU 显存加密]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
H100 Confidential Mode：     
  - GPU 内存加密
  - PCIe 总线密文
  - 与 TDX VM 配合
  - vGPU 内 attest GPU 状态
  - 性能损失 ~5-10%

应用：     
  - 多方训练（数据所有者不信 CSP）
  - 模型权重保护
  - 监管 / 合规 AI

支持栈：     
  CUDA 12.x+
  NVIDIA Driver R535+
  与 Microsoft Azure / GCP 联动

业务应用

1. 多方计算（MPC）/ 联邦学习

graph TB
  P1[参与方 A 数据]
  P2[参与方 B 数据]
  P3[参与方 C 数据]
  
  P1 --> CVM[Confidential VM
多方都不信任的 CSP]
  P2 --> CVM
  P3 --> CVM
  
  CVM --> RESULT[联合训练结果]
1
2
3
4
5
6
传统 MPC：     全密文计算（HE / 秘密分享），慢
TEE 替代：     明文进 enclave，性能近原生
应用：     
  - 银行间联合反欺诈
  - 医院联合医疗 AI
  - 跨集团 / 跨国数据合作

2. 数据安全屋（Data Clean Room）

1
2
3
4
5
6
7
8
9
10
11
12
广告主 + 媒体方：     
  - 双方都有用户数据
  - 想合并分析但不公开各自数据
  - 把数据进 Confidential VM
  - 在里面联合查询 / 建模
  - 输出仅汇总结果
  
代表产品：     
  AWS Clean Rooms
  Snowflake Data Clean Room
  Google Ads Data Hub
  阿里云 / 腾讯云的 Privacy-Preserving Computing

3. 区块链 / Web3 私钥

1
2
3
4
5
6
7
8
9
10
传统区块链节点：     私钥在内存 → 攻击面大
TEE 节点：     
  - 私钥永远不出 enclave
  - 签交易在 enclave 内
  - 即使 root 也偷不到

代表：     
  - Hyperledger Avalon
  - Microsoft Confidential Consortium Framework (CCF)
  - 各家区块链的"硬件钱包"

4. 监管合规

1
2
3
4
5
6
7
8
9
GDPR / HIPAA / 金融数据保护法：     
  - "数据所有者不信任云"是常见诉求
  - Confidential VM 提供"我可以用云但不让 CSP 看见"
  - 部分行业法规已认可 Confidential Computing 为合规手段
  
中国：     
  - 个人信息保护法（PIPL）
  - 关键信息基础设施保护
  - 信创 + 等保对机密计算有要求

5. 大模型推理保护

1
2
3
4
5
6
7
8
9
10
11
12
13
14
场景：     
  - 客户上传数据用 LLM 推理
  - 不希望 CSP / 服务商看到 prompt 和结果
  - 也不希望模型被偷
  
解决：     
  - Confidential VM + Confidential GPU
  - prompt / model / output 全程加密
  - 远程证明保证

代表：     
  Microsoft Azure Confidential AI
  NVIDIA Confidential AI
  阿里云、华为云类似产品

CoCo 与 Service Mesh

graph TB
  CL[客户端]
  CL -->|TLS| GW[网关]
  GW -->|mTLS| SVC1[CoCo Pod 1]
  GW -->|mTLS| SVC2[CoCo Pod 2]
  
  SVC1 -.- AT[Attestation Service]
  SVC2 -.- AT
1
2
3
4
5
6
7
8
9
机密计算 + Service Mesh：     
  - 每个微服务跑在 CoCo
  - 服务间 mTLS + attestation 双重验证
  - 端到端加密 + 端到端可信
  
挑战：     
  - 启动慢（每 Pod 一 VM）
  - 资源开销
  - 调试困难

远程证明的”两层”

graph TB
  L1[第一层：硬件 attestation]
  L1 --> Q1[Intel TDX Quote / AMD SEV-SNP Report]
  Q1 --> CPU[CPU 厂家签名]
  CPU --> ROOT[Intel / AMD 根证书]
  
  L2[第二层：业务 attestation]
  L2 --> Q2[包含业务公钥 / hash]
  Q2 --> APP[应用层验证]

第一层硬件证明 + 第二层业务证明 = 端到端可信。

标准化进展

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
IETF RATS（Remote ATtestation procedureS）：     
  - 跨厂家 attestation 协议
  - EAT（Entity Attestation Token）
  - CWT / JWT 风格

CCC（Confidential Computing Consortium）：     
  - Open Enclave SDK
  - Veracruz
  - Confidential Containers
  - 跨平台 SDK

Linux Kernel：     
  - kvm/coco：    内核 CoCo 子系统
  - tdx-guest / sev-guest 驱动

国内标准：     
  - GB/T 41388（机密计算技术框架）
  - 工信部、信通院推
  - 国家可信云体系

部署的几个老坑

坑 1：性能预期错位

1
2
3
4
5
6
7
8
9
Confidential VM：     
  - 内存加密：    带宽降 5-10%
  - 启动慢：     +几秒
  - 适合稳态业务，不适合频繁启停
  
CoCo（每 Pod 一 VM）：     
  - 启动 2-5 秒
  - 资源占用比普通 Pod 多
  - 大规模 Job 调度成本高

坑 2：迁移复杂

1
2
3
4
5
6
普通 VM → Confidential VM：     
  - 部分老镜像不兼容（缺驱动）
  - kernel 要支持 TDX guest / SEV guest
  - GRUB / initrd 要支持 attestation 流程
  
建议：     用 CSP 提供的官方镜像起步

坑 3：远程证明实现门槛高

1
2
3
4
5
6
7
8
9
10
11
12
要正确实现：     
  - Attestation 库（rats / ratls）
  - 签名链验证
  - 撤销列表查询
  - TCB 版本管理
  - Nonce 防重放
  
开源工具：     
  Veraison（Linux Foundation）
  Microsoft Maa
  Intel Trust Authority
  阿里 vSGX / 龙蜥 attestation

坑 4：密钥分发服务（KBS）

1
2
3
4
5
6
7
8
"远程证明通过 → 给密钥"——这个 KBS 怎么部署？     
  - 自建：     高可用 + 安全（KBS 本身要 TEE）
  - 用 CSP 服务：    依赖 CSP

正确实现：     
  - KBS 自己跑在 Confidential VM
  - 密钥分级（root key 在 HSM，业务 key 派生）
  - 严格审计

坑 5：调试困难

1
2
3
4
5
6
7
8
9
Confidential VM 内：     
  - 无法 console attach
  - 无法 strace / gdb（attestation 不通过会拒）
  - dmesg 看不到内核启动
  
调试模式：     
  - SEV-SNP / TDX 都有 "debug" 选项
  - 但 attestation TCB level 不一样
  - 不能用于生产

监控与可观测

1
2
3
4
5
6
7
8
9
10
11
12
传统 VM：     
  Hypervisor 看 / IPMI / cAdvisor

Confidential VM：     
  - Hypervisor 看不到内部
  - 必须从内部上报 metrics
  - 但要保护 metrics 不被监控泄露

实践：     
  - Prometheus 客户端跑在 CVM 内
  - 加密上报到外部存储
  - 业务侧分析

CSP 信任假设

graph TB
  T1[传统 VM]
  T1 --> N1[Trust 链：你 → CSP → 物理机]
  
  T2[Confidential VM]
  T2 --> N2[Trust 链：你 → CPU 厂家 → 物理机硬件]
  T2 -.- |不 trust| CSP[CSP 软件 / Hypervisor / Host OS]
1
2
3
4
5
6
7
8
9
10
11
Confidential Computing 不能：     
  - 防御 CPU 厂家后门
  - 防御 Quote 服务被劫持
  - 防御侧信道（理论上）
  - 抵抗物理 / 实验室级攻击
  
能做的：     
  - 防御 CSP 内部威胁（恶意管理员）
  - 防御 Hypervisor 入侵
  - 防御 Host OS 入侵
  - 满足合规要求

监管 / 合规中的位置

1
2
3
4
5
6
7
8
9
10
11
12
13
中国：     
  - 关基设施保护：     等保 3+ 鼓励 TEE
  - 个保法：    敏感数据处理推荐
  - 信创目录：    部分项目要求

欧洲：     
  - GDPR：    Confidential Computing 是隐私技术
  - eIDAS 2.0：    欧盟数字身份
  
美国：     
  - HIPAA / SOC2：    医疗 / 金融
  - FedRAMP：    政府云
  - DoD IL5/IL6：    国防场景

价格

1
2
3
4
5
6
7
8
9
10
11
Microsoft Azure Confidential VM：     
  - 标准 VM 价格 + 10-20% 溢价
  
Google Confidential VM：     
  - 标准 VM 价格 + 5-15%
  
阿里云 / 腾讯云：     
  - 类似溢价

CoCo 容器：     
  - 同价但资源占用多

待补充：实际项目机密计算的成本预算。

一些查询命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Confidential VM 内部：     
# AMD SEV-SNP
sudo dmesg | grep -i sev
ls /dev/sev-guest
snp-guest-report report.bin

# Intel TDX
sudo dmesg | grep -i tdx
ls /dev/tdx_guest

# CoCo 项目
kubectl get nodes -L node.kubernetes.io/instance-type
kubectl get runtimeclass

# Pod yaml 用 CoCo：     
spec:
  runtimeClassName: kata-qemu-tdx
  containers:
  - image: <encrypted-image>

# 远程证明
veraison-verify report.bin

几个权威资源

1
2
3
4
5
6
7
8
9
10
11
12
13
Confidential Computing Consortium：     
  https://confidentialcomputing.io/

Linux Kernel CoCo 文档：     
  Documentation/virt/coco/

Project documentation：     
  - Intel TDX：    intel.com/sgx
  - AMD SEV：     developer.amd.com/sev/
  - ARM CCA：     developer.arm.com/cca

学术论文：     
  IEEE S&P / USENIX Security 上每年都有 TEE 攻击 / 防御论文

一些数字直觉

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Confidential VM 启动：     
  Azure DCa：    +3-5 秒（attestation）
  GCP C2D：     +2-3 秒
  
CoCo Pod 启动：     
  +5-10 秒（VM + attestation + 解密镜像）
  
性能：     
  纯 CPU 业务：    < 5% 损失
  内存密集：     5-10% 损失
  IO 密集：     可能更高（vsock）
  GPU 业务（H100 confidential）：    +5-10%

实际可用规模（2026）：     
  Confidential VM：    数十万节点（Azure / GCP / 阿里）
  CoCo：              小规模（几千 Pod）
  Confidential GPU：    刚起步

小结

  • 机密计算 = TEE 的产品形态
  • Confidential VM 是主流方向（TDX / SEV-SNP）
  • Confidential Container 是 K8s 上的探索（CoCo）
  • 远程证明 + KBS 是核心信任链
  • 多方计算 / 联邦学习 / 数据安全屋是主要业务场景
  • NVIDIA H100 Confidential Mode 是 GPU TEE 起点
  • 性能开销 < 10%，启动慢几秒
  • 满足 GDPR / HIPAA / 信创 等合规需求

下一篇讲国产可信计算——海光 CSV、鲲鹏 iTrustee、TPCM、TCM 等国密路线。