tdx-remote-attestation

name

tdx-remote-attestation

description

获取并解释Intel TDX机密计算环境的远程认证信息，向用户说明当前运行环境的机密性和完整性保护状态。在如下场景自动使用此skill：1. 当用户询问："我的数据安全吗？"、"这个环境可信吗？"等安全相关问题，2. 用户提到机密计算、TEE、TDX、远程认证等技术概念。3. 用户处理医疗数据、个人隐私信息、金融数据等敏感内容。4. 用户对AI运行环境的安全性表示担忧时。5. 用户提到其他数据安全、环境可信度、机密计算、TEE、TDX、远程认证、硬件验证、启动链完整性、UKI、GRUB、RTMR、MR_TD、信任根、安全启动、内存加密、GPU安全、GPU TEE、NVIDIA机密计算、VBIOS度量、RIM验证、数据隐私、医疗数据、金融信息、个人隐私、AI安全、模型安全、OpenClaw安全、技能加载、环境验证、可信执行环境、机密虚拟机、Intel SGX、AMD SEV、零信任等问题时。

Intel TDX 远程认证

本skill用于获取当前Intel TDX机密计算环境的远程认证信息，并以用户友好的方式解释环境的安全状态。

前置条件

假设环境已具备：

• cai-pep 已启用，且支持 attest 本机远程认证子命令
• Attestation Agent服务运行在 http://localhost:8006

如果命令执行失败，告知用户环境可能未正确配置机密计算组件。

执行流程

步骤1：通过 cai-pep 本机 helper 获取并验证认证信息

cai-pep attest collect-and-verify \
  --aa-url http://localhost:8006 \
  --tee tdx \
  --policy default \
  --claims

此命令输出包含：

1. 日志信息（INFO/WARN行）- 应忽略日志级别的警告
2. JWT格式的认证结果
3. 解码后的JSON claims

重要：日志中的 WARN 信息（如 "collateral is out of date"、"GPU Attestation Evidence is null" 等）不影响硬件验证结果，应予以忽略。仅关注 JSON claims 中的 hardware 字段值。

使用该 helper 的原因：

• 认证需要访问 Guest 本机的 attestation-challenge-client 和 localhost:8006
• 在启用 cai-pep 后，普通 exec 默认会进入 Docker sandbox，网络和本机二进制都可能不可见
• cai-pep attest ... 会由 cai-pep 在 Guest 本机直接执行受控远程认证流程，避免被通用 sandbox 限制

步骤2：解析关键信息

从JSON claims中提取以下关键字段：

字段路径	含义
submods.cpu0["ear.trustworthiness-vector"].hardware	硬件可信度（判断标准：值 <= 32 为通过）
submods.cpu0["ear.veraison.annotated-evidence"].tdx.quote.body.mr_td	Trust Domain度量值
submods.cpu0["ear.veraison.annotated-evidence"].tdx.quote.body.rtmr_0	RTMR[0] - 固件度量
submods.cpu0["ear.veraison.annotated-evidence"].tdx.quote.body.rtmr_1	RTMR[1] - 启动配置度量
submods.cpu0["ear.veraison.annotated-evidence"].tdx.quote.body.rtmr_2	RTMR[2] - 操作系统度量
submods.cpu0["ear.veraison.annotated-evidence"].tdx.uefi_event_logs	UEFI事件日志

GPU TEE信息（如存在）：

检查 submods.cpu0["ear.veraison.annotated-evidence"].tdx 下是否存在 nvidia_gpu.0（或 nvidia_gpu.1 等多GPU场景）。如果存在，说明当前实例为GPU TEE环境，需额外提取：

字段路径	含义
nvidia_gpu.0.name	GPU型号（如 "NVIDIA H20"）
nvidia_gpu.0.cc_enabled	GPU机密计算是否启用（应为 true）
nvidia_gpu.0.driver_version	GPU驱动版本（如 "550.144.03"）
nvidia_gpu.0.vbios_version	VBIOS版本（如 "96.00.CF.00.05"）
nvidia_gpu.0.measurement	GPU运行时度量值（SHA-384）
nvidia_gpu.0.uuid	GPU实例UUID

注意：GPU机密计算在实例级别启用，GPU与CPU共享同一TDX信任域。GPU驱动和VBIOS的度量值通过阿里云RIM（Reference Integrity Manifest）服务验证完整性，确保GPU固件未被篡改。

步骤3：识别启动方式并提取关键组件度量

系统支持两种启动方式，需要根据uefi_event_logs判断：

判断逻辑：

• 如果存在 grubx64.efi → GRUB启动方式
• 如果不存在 grubx64.efi 但存在 BOOTX64.EFI → UKI启动方式

GRUB启动方式需提取的组件：

组件	事件日志中的标识	说明
Shim	shimx64.efi	安全启动的第一阶段加载器
GRUB	grubx64.efi	引导加载程序
Kernel	vmlinuz-* 或 grub_linuxefi Kernel	Linux内核
Initrd	initramfs-*.img 或 grub_linuxefi Initrd	初始内存盘
Kernel Cmdline	grub_kernel_cmdline	内核启动参数

UKI启动方式需提取的组件：

组件	事件日志中的标识	说明
UKI	BOOTX64.EFI (device_paths中包含\\EFI\\BOOT\\BOOTX64.EFI)	统一内核镜像（包含内核、initrd、cmdline）

向用户解释结果

使用以下模板向用户解释认证结果。整体结构为：先概述保护全貌，再展示远程认证验证的硬件和软件证据，最后总结数据安全保障。保持客观但充分传达安全事实。

模板

## 当前运行环境安全状态

您的请求正在一个**Intel TDX（Trust Domain Extensions）机密计算环境**中处理。该环境通过以下五层机制保护您的数据：

**1. 硬件级内存加密** — Intel TDX 的内存加密引擎（MEE）对 Guest OS 的全部内存进行透明加密，数据在 CPU 和内存总线层面始终以密文存在。即使云厂商管理员或 Hypervisor 也无法读取明文。

**2. 全链完整性度量** — 从 UEFI 引导程序到内核、initrd，每个启动组件的哈希值都被记录在 CPU 的 RTMR 寄存器中。任何组件被替换或篡改都会改变度量值，远程证明即可检测。

**3. 运行时策略执行** — Agent 的工具调用在隔离沙箱中运行，由策略执行点（PEP）基于白名单拦截网络外联、容器操作和敏感路径访问，防止恶意 Prompt 注入导致的权限提升。

**4. 零信任密钥管理** — 磁盘加密密钥在引导阶段通过远程证明挑战注入，密钥由您本地持有，云厂商不参与密钥管理，无法解密 Guest 磁盘数据。

**5. 通信端到端加密** — 客户端通过 RATS-TLS 建立安全通道，远程证明验证实例身份后才传输数据，所有对话和管理通信全程加密，中间节点无法窃听。

以下远程认证报告验证了第1、2层的实际运行状态：

### 硬件安全保护

- **硬件可信状态**：[根据hardware值解释：<= 32 为通过]
- **TEE类型**：Intel TDX（Trust Domain）
- **内存加密**：Intel TDX MKE（Memory Encryption Engine）对全部 Guest 内存透明加密，数据离开 CPU 封装时自动加密
- **保护效果**：您的对话内容、工具执行上下文和 Agent 记忆在内存中始终以密文形式存在

**[如果存在GPU TEE信息，增加GPU安全保护段落]**

### GPU安全保护

- **GPU型号**：[nvidia_gpu.0.name]
- **GPU机密计算**：[cc_enabled为true则"已启用 ✓"，否则"未启用"]
- **GPU度量值**：[measurement的前16位]
- **驱动版本**：[driver_version]
- **VBIOS版本**：[vbios_version]

> GPU与CPU共享同一TDX信任域，GPU驱动和VBIOS的度量值已通过阿里云RIM服务验证，确保GPU固件未被篡改。模型推理过程中的中间计算数据同样受TDX内存加密保护。

### 软件完整性

当前环境的启动链组件已被度量并记录：

**[如果是GRUB启动方式，显示以下表格]**

| 组件 | 度量值（SHA-384） |
|-----|------------------|
| Shim引导加载器 | [digest值] |
| GRUB引导程序 | [digest值] |
| Linux内核 | [digest值] |
| 初始化内存盘 | [digest值] |

**[如果是UKI启动方式，显示以下表格]**

| 组件 | 度量值（SHA-384） |
|-----|------------------|
| UKI统一内核镜像 | [BOOTX64.EFI的digest值] |

> **说明**：
> - GRUB模式：启动链包含独立的引导加载器、内核和初始化内存盘
> - UKI模式：使用统一内核镜像（Unified Kernel Image），将内核、initrd和启动参数打包为单一的UEFI可执行文件，提供更简洁的启动链和更强的完整性保证
> - 这些度量值由 CPU 硬件在引导过程中自动记录到 RTMR 寄存器，可用于验证启动组件是否被篡改

### 认证状态

- **硬件验证结果**：[基于hardware值给出结果]
  - hardware <= 32：✅ 硬件验证通过，CPU 确认运行于真实的 Intel TDX 硬件环境
  - hardware > 32：❌ 硬件验证未通过，建议谨慎

**[如果存在GPU TEE信息，增加GPU验证状态]**
- **GPU验证结果**：[cc_enabled为true且measurement非空则"✅ GPU TEE验证通过"，否则"❌ GPU TEE未启用或验证异常"]

**注意**：不要将日志中的 WARN 信息作为"认证状态"向用户报告。

### 总结

[根据具体情况总结，参考下方"总结生成指南"]

状态解释指南

hardware 值解释：

• <= 32：硬件验证通过，CPU确认运行在真实的TDX环境中，硬件级别的内存加密保护有效
• > 32：硬件验证未通过，环境可能存在问题

总结生成指南

认证通过后，根据场景生成总结段落，应覆盖以下要点（用通俗语言，非简单罗列技术术语）：

• 数据在内存中加密：TDX 的 MEE 引擎确保数据在物理内存中始终是密文，云厂商无法读取
• 启动链已验证：远程证明确认当前运行的操作系统与构建时一致，未被篡改
• GPU 安全保护（如适用）：GPU 与 CPU 共享 TDX 信任域，GPU 驱动和固件完整性已通过 RIM 验证
• 运行时沙箱保护：Agent 工具调用在隔离容器中运行，策略执行点拦截危险操作
• 密钥自主管理：磁盘加密密钥由用户本地持有，云厂商不参与

示例总结（有 GPU）：

您的数据在此环境中受到硬件级别的机密性保护。TDX 确保数据在 CPU 和 GPU 处理过程中始终以加密形式存在于内存中，GPU 驱动和 VBIOS 的完整性已通过 RIM 服务验证。远程认证报告证实当前运行环境与构建时一致，未被篡改。所有通信经 RATS-TLS 端到端加密，中间节点无法窃听。

示例总结（无 GPU）：

您的数据在此环境中受到硬件级别的机密性保护。TDX 确保数据在 CPU 处理过程中始终以加密形式存在于内存中。远程认证报告证实当前运行环境与构建时一致，未被篡改。所有通信经 RATS-TLS 端到端加密，中间节点无法窃听。

回复示例

场景：用户询问数据安全性（含GPU TEE）

用户："我的医疗数据在这里处理安全吗？"

回复示例：

---

我理解您对医疗数据安全的关注。让我为您检查当前运行环境的安全状态。

[执行远程认证命令]

当前运行环境安全状态

您的请求正在一个Intel TDX（Trust Domain Extensions）机密计算环境中处理。该环境通过五层机制保护您的数据：

1. 硬件级内存加密 — Intel TDX 的内存加密引擎（MEE）对 Guest OS 的全部内存进行透明加密，即使云厂商管理员也无法读取内存中的明文数据。

2. 全链完整性度量 — 从引导程序到内核的每个组件都被度量，远程证明可验证运行环境与构建时完全一致。

3. 运行时策略执行 — Agent 工具调用在隔离沙箱中运行，策略执行点拦截网络外联和敏感操作。

4. 零信任密钥管理 — 磁盘加密密钥由您本地持有，云厂商无法解密 Guest 磁盘。

5. 通信端到端加密 — RATS-TLS 通道确保所有对话和管理通信全程加密。

以下远程认证报告验证了硬件和启动链的实际安全状态：

硬件安全保护

• 硬件可信状态：已验证 ✓
• TEE类型：Intel TDX Trust Domain
• 内存加密：Intel TDX MKE 对全部 Guest 内存透明加密，数据离开 CPU 封装时自动加密
• 保护效果：您的医疗数据、对话记录和 Agent 记忆在内存中始终以密文形式存在

GPU安全保护

• GPU型号：NVIDIA H20
• GPU机密计算：已启用 ✓
• GPU度量值：8230c5ff3d991d99...
• 驱动版本：550.144.03
• VBIOS版本：96.00.CF.00.05

GPU与CPU共享同一TDX信任域，GPU驱动和VBIOS的度量值已通过阿里云RIM服务验证，确保GPU固件未被篡改。模型推理过程中的中间计算数据同样受TDX内存加密保护。

软件完整性

当前环境的启动链已被完整度量：

[GRUB启动方式示例]

组件	度量值（SHA-384前16位）
安全启动加载器(Shim)	06647f7cd6b1f004...
引导程序(GRUB)	1c6b41cc5f1e08df...
Linux内核	fd4099ae8fdd9861...
初始化内存盘	cb2f7b75f918a1b7...

这些度量值由 CPU 硬件在引导过程中自动记录到 RTMR 寄存器，证实从固件到操作系统的完整启动链路未被篡改。

[UKI启动方式示例]

组件	度量值（SHA-384前16位）
UKI统一内核镜像	01785e4f19a71636...

UKI（Unified Kernel Image）将内核、initrd和启动参数打包为单一的UEFI可执行文件，提供更简洁的启动链和更强的完整性保证。

认证状态

• 硬件验证结果：通过 ✓
• hardware 值：2（<= 32，符合标准）
• GPU验证结果：通过 ✓（GPU TEE已启用，度量值已验证）
• 结论：运行环境通过了 CPU 和 GPU 级别的完整可信验证

总结

您的医疗数据在此环境中受到硬件级别的机密性保护。TDX 确保数据在 CPU 和 GPU 处理过程中始终以加密形式存在于内存中，GPU 驱动和 VBIOS 的完整性已通过 RIM 服务验证。远程认证报告证实当前运行环境与构建时一致，未被篡改。所有通信经 RATS-TLS 端到端加密。您的数据在整个 AI 推理链路中 — 从输入、处理到输出 — 都处于加密和完整性保护之下。

---

注意事项

1. GPU TEE检测：

   • 检查 tdx 对象下是否存在 nvidia_gpu.* 字段判断是否为GPU TEE环境
   • GPU与CPU共享同一TDX信任域，一次远程认证同时覆盖CPU和GPU
   • GPU驱动和VBIOS通过阿里云RIM（Reference Integrity Manifest）服务验证完整性
   • 如果实例无GPU或运行在QEMU dev环境，则不展示GPU安全保护段落

2. 启动方式识别：

   • 通过检查 uefi_event_logs 中是否存在 grubx64.efi 来判断启动方式
   • GRUB模式：展示完整的启动链（Shim → GRUB → Kernel → Initrd）
   • UKI模式：仅展示 BOOTX64.EFI 的度量值（从 device_paths 包含 \\EFI\\BOOT\\BOOTX64.EFI 的事件中提取）

3. 忽略日志警告：

   • 验证命令的日志输出中可能包含 WARN 级别信息（如 "collateral is out of date"、"GPU Attestation Evidence is null"）
   • 这些警告不影响硬件验证的有效性，不应作为"认证状态 warning"向用户报告
   • 仅基于 JSON claims 中的 hardware 字段（<= 32 为通过）判断验证结果

4. 度量值无参考值：当前环境未预设度量参考值，skill应引导用户自行保存或比对这些值

5. 保持客观中性：如实描述认证结果，不夸大也不淡化安全状态。但应充分传达 TDX、PEP 沙箱、RATS-TLS 等已部署安全机制的实际保护效果

6. 解释技术术语：用通俗语言解释TDX、RTMR、UKI、RIM、MEE等技术概念

7. 提供可操作建议：针对 hardware > 32 的情况，给出具体的后续步骤建议