基于TDX的机密会议媒体服务器架构：详解可信域隔离下的编解码器卸载与密钥全生命周期托管

在数字化协作深度普及的今天，视频会议已成为企业核心生产力工具。然而，随着数据合规监管趋严（如GDPR、《数据安全法》、《个人信息保护法》）及商业机密保护需求升级，传统“基于边界防御”的媒体服务器架构面临根本性挑战：云上特权用户（Hypervisor/Cloud Admin）与恶意软件可直接访问内存中的明文音视频流与加密密钥。

Intel TDX（Trust Domain Extensions）作为新一代机密计算技术，通过硬件级隔离构建可信域（Trust Domain, TD），为解决上述痛点提供了底层信任锚点。本文将深度解析基于TDX的机密会议媒体服务器架构设计，重点探讨编解码器可信卸载机制与密钥全生命周期托管体系的工程化落地路径。

一、架构总览：从“信任云厂商”到“信任硬件与代码”

1.1 威胁模型重构

传统媒体服务器（如基于Janus、MediaMTX或自研SFU/MCU架构）运行于标准VM或容器中，面临以下核心攻击面：

内存窃取：Hypervisor层面Dump内存获取RTP载荷、SRTP Master Key。
侧信道攻击：共享CPU缓存推断编码参数或关键帧间隔。
控制面劫持：篡改信令逻辑，强制降级加密算法或注入旁路流。

基于TDX的架构将媒体处理核心逻辑（Media Plane）迁移至TD内部，将Hypervisor、Host OS、甚至物理服务器运维人员移出TCB（Trusted Computing Base）。仅保留TDX模块、CPU微代码及TD内部经验证的镜像在信任边界内。

1.2 分层架构设计

+-------------------------------------------------------+
|              非可信宿主环境                           |
|  +----------------+  +----------------+               |
|  | 信令/网关服务   |  | 资源调度/监控   |  (Plaintext)  |
|  +----------------+  +----------------+               |
+--------------------------|----------------------------+
                           | VSOCK / TDG.VP.VMCALL
+--------------------------v----------------------------+
|                   可信域 (TD)                         |
|  +-------------------------------------------------+  |
|  |           TD Guest OS (Minimal Linux/Unikernel) |  |
|  |  +------------+  +------------+  +------------+  |  |
|  |  | 编解码引擎  |  | 密钥管理服务 |  | 远程证明Agent|  |  |
|  |  | (FFmpeg/VA-API)| | (KMS/TPM 2.0)| | (Quote Gen) |  |  |
|  |  +------------+  +------------+  +------------+  |  |
|  +-------------------------------------------------+  |
|              TDX Module (SEAM) / CPU Hardware         |
+-------------------------------------------------------+

二、核心技术突破一：编解码器的可信卸载与硬件加速适配

媒体服务器的计算密集型任务在于编解码。TDX引入的内存加密（MK-TME）与CPU状态隔离带来约5%-15%的性能开销，若全部采用软件编解码（libx264/libvpx），吞吐量将大幅下降。架构设计必须解决“硬件加速器（GPU/VPU/QAT）位于TD边界外”的信任延伸难题。

2.1 设备分配与IOMMU隔离策略

利用Intel VT-d (IOMMU) 与TDX的可信设备接口（TDI, Trust Device Interface）协同：

设备直通：将物理VPU（如Intel VPL/oneVPL设备）或GPU（支持SR-IOV的虚拟功能VF）通过PCIe直通分配给TD。
DMA保护：配置IOMMU上下文条目，限制设备DMA仅能访问TD共享内存区（Shared GPA），私有内存（Private GPA）对设备不可见。
驱动前置化：在TD内部运行精简的用户态驱动（如Intel oneVPL Dispatcher），避免Host Kernel驱动成为攻击面。

2.2 零拷贝安全数据流设计

针对H.264/H.265/VP9/AV1编解码流程，设计“加密内存 -> 共享缓冲区 -> 硬件编解码 -> 共享缓冲区 -> 加密内存”的零拷贝管线：

阶段	内存属性	关键操作	安全保障
输入缓冲	Private GPA	SRTP解密 -> 原始YUV/PCM	仅TD CPU可访问，Hypervisor不可见
共享准备	Shared GPA (TDG.MEM.PAGE.ACCEPT)	`mmap`映射至用户态，标记为`UNCACHED`/`WC`	显式接受页面，防止恶意Host注入脏数据
硬件处理	Shared GPA (DMA Buffer)	VPU/GPU 读取编码/解码	IOMMU限制DMA范围；设备固件需可信启动验证
输出回收	Private GPA	编码后流打包 -> SRTP加密	硬件写回后，TD主动拷贝至私有内存并撤销共享映射

关键优化点：利用TDX 1.5+支持的可信I/O（TDX-IO）特性，实现设备侧的内存加密引擎（IDE, Integrity and Data Encryption），在PCIe链路层面加密DMA流量，彻底杜绝总线窃听。

2.3 异常与熔断机制

超时监控：TD内部Watchdog监控硬件编解码耗时，防止设备挂起导致TD死锁。
错误隔离：硬件返回错误码（如编码器过载）时，TD内部自动降级至软件编解码（libx264快速预设），保障会议连续性，并上报遥测日志（经脱敏后通过VSOCK发送至非可信监控面）。

三、核心技术突破二：密钥全生命周期托管体系

机密会议的核心资产是SRTP Master Key/Salt及E2EE（端到端加密）媒体密钥。TDX架构下，密钥全生命周期（生成、分发、使用、轮换、销毁）均在TD边界内完成，实现“密钥不出域、明文不落盘”。

3.1 密钥分级与派生体系

采用三层密钥树结构，符合NIST SP 800-57 Part 1规范：

根密钥：
- 来源：TD初始化时通过远程证明向密钥管理中心（KMS）证明身份，由KMS派生并加密传输（基于TDX Quote的ECDH P-384密钥协商）。
- 存储：仅存在于TD CPU寄存器与加密内存中，受TDX MK-TME保护。
会话密钥：
- 派生：Session_Key = HKDF(Root_Key, Conference_ID || Epoch || "media")。
- 用途：加密信令面下发的SDP参数、生成SRTP Master Key。
媒体流密钥：
- 派生：SRTP_Key = HKDF(Session_Key, SSRC || "SRTP")。
- 特性：每路媒体流（音频/视频/屏幕共享）独立密钥，支持RFC 3711标准推导。

3.2 硬件绑定与密钥封存

利用TDX虚拟TPM（vTPM）或CPU指令（TDG.MR.SEAL/TDG.MR.UNSEAL）实现密钥与TD实例绑定：

Seal策略：绑定MRTD（初始镜像度量）、RTMR[0-3]（运行时动态度量，含编解码器二进制Hash）、TDINFO（CPU SVN版本）。
效果：镜像篡改、恶意模块注入、CPU微代码降级均会导致RTMR变化，导致Unseal失败，密钥自动失效。

3.3 密钥轮换与前向保密

针对长会议场景，设计双轨轮换机制：

定时轮换：每90分钟（可配）触发Epoch递增，TD内部自派生新Session Key，通过信令面下发新SRTP参数（利用SDP a=crypto属性或SFrame信令）。
事件驱动轮换：检测到成员加入/离开、网络切换、远程证明状态变更（如TCB版本过期）时，立即触发重协商。
销毁保障：旧密钥内存区显式调用memzero_explicit并执行CLFLUSH/WBINVD指令，防止冷启动攻击残留。

3.4 远程证明集成

部署基于ECDSA P-256/P-384的Quote生成流程：

TD启动 -> TDX Module测量镜像 -> 生成REPORT。
TD内Quote Provider (QP) 请求PCE (Provisioning Certification Enclave) 签名 -> 生成Quote。
验证方（客户端/网关/审计系统）校验Quote签名链（Intel Root CA -> PCK Cert -> Quote），对比MRTD/RTMR黄金值。
策略引擎：仅当Quote验证通过且TCB状态为Up to date时，KMS释放Root Key密文。

四、工程化落地关键点与性能调优

4.1 TD镜像构建与最小化

基础镜像：采用Distroless或Alpine精简发行版，移除Shell、Systemd、SSH等非必要组件，TCB代码行数控制在500万行以内。
编译加固：全模块开启-fstack-protector-strong -D_FORTIFY_SOURCE=2 -fcf-protection=full -fPIE -pie，启用CET（Control-flow Enforcement Technology）Shadow Stacks。
确定性构建：使用Bazel/Nix实现可复现构建，确保MRTD在CI/CD流水线中固化，便于审计。

4.2 网络与信令面协同

VSOCK高性能通道：TD与Host信令服务通信采用AF_VSOCK，避免虚拟网卡开销，延迟< 50μs。
连接迁移：媒体平面（TD）无状态化设计，信令面维护会话状态。TD重启/扩容时，仅需同步当前Epoch Key与序列号，实现秒级无感迁移。

4.3 可观测性与合规审计

结构化日志：TD内部输出JSON格式日志（无敏感字段），通过VSOCK推送至Host侧日志代理，字段包含：trace_id, conference_id, epoch, codec_type, hw_accel_status, key_rotation_trigger。
审计日志不可篡改：关键操作（密钥导入、轮换、设备直通变更）记录至TD内受保护的环形缓冲区，定期生成Merkle Tree根哈希上链或写入WORM存储。

五、部署模型与合规价值

5.1 适用场景矩阵

场景	传统架构风险	TDX架构收益
公有云敏感会议	云管平台特权访问风险	物理隔离，云厂商不可见明文/密钥
混合云/多云统一管控	密钥分发跨域信任复杂	统一硬件信任根，简化跨云密钥同步
金融/政企私有化部署	运维人员内部威胁	运维与数据使用分离，满足等保三级/密评要求

5.2 合规映射

数据安全法/个保法：实现“数据可用不可见”，满足最小化处理、加密保护法定义务。
商密合规：支持对接国密算法（SM4/SM3/SM2）硬件加速引擎，满足国产化替代需求。
国际标准：架构设计参考ISO/IEC 19670 (Confidential Computing)、TCG TEEP协议规范。

六、总结与展望

基于TDX的机密会议媒体服务器架构，通过硬件级内存加密构建物理隔离边界，结合TDX-IO可信设备直通解决编解码硬件加速的信任延伸难题，并建立基于远程证明的密钥全生命周期托管体系，实现了从“信任云基础设施”到“信任硬件与可验证代码”的安全范式转移。

当前工程实践中，需重点关注：

TDX-IO生态成熟度：VPU/GPU厂商固件签名与IDE使能支持情况。
冷启动性能：TD页面接受（Page Accept）在大内存（>64GB）媒体服务器上的延迟优化。
跨代迁移：TD迁移时CPU SVN变更导致的密钥Seal策略兼容性设计。

随着Intel TDX 1.5（支持TD迁移、可信I/O）生态完善及AMD SEV-SNP、ARM CCA等异构机密计算技术的趋同，机密媒体处理将成为下一代实时通信基础设施的标配能力，为数字化协作筑牢“零信任”的数据底座。

基于TDX的机密会议媒体服务器架构（下）：侧信道缓解、有状态迁移与零信任运维体系

承接上篇对编解码卸载与密钥托管核心链路的剖析，本文将深入探讨侧信道攻击缓解工程实践、有状态媒体平面的可信迁移与高可用设计、异构算力统一调度接口，以及面向合规审计的零信任运维与供应链安全体系，构建生产级可交付的机密会议基础设施。

一、侧信道攻击缓解：从理论模型到工程化加固

TDX通过MK-TME（Multi-Key Total Memory Encryption）解决了物理内存窃取，但共享CPU微架构资源（L1/L2/L3 Cache、TLB、分支预测器、内存控制器）仍构成侧信道攻击面。针对媒体服务器“高并发、实时流、数据依赖分支多”特性，需分层部署缓解策略。

1.1 缓存侧信道：恒定时间编码与Cache Allocation Technology (CAT)

关键路径恒时化：SRTP解密、SFrame解封、密钥派生（HKDF）等密码学原语，强制使用恒定时间实现（如BoringSSL/liboqs常数时间模块），消除数据依赖的分支与内存访问模式。
Intel CAT/RDT-A隔离：利用pqos工具在TD启动阶段配置Class of Service (CLOS)，将L3 Cache划分为：
- CLOS_HIGH (Media Plane)：独占 70% LLC Ways，绑定编解码线程、加密线程，防止噪声线程（如日志压缩、Metrics采集）驱逐热点数据引发时序泄露。
- CLOS_LOW (Control Plane)：共享剩余 30% Ways，运行信令处理、gRPC框架、VSOCK通信线程。
页表隔离优化：开启KPTI（Kernel Page Table Isolation）并配合TDX EPTP Switching，确保用户态媒体处理线程与内核态中断处理路径页表彻底分离，缓解Meltdown类变种风险。

1.2 内存总线与行锤攻击防御

MK-TME密钥轮换策略：配置TDX Module TDH.MNG.KEY.CONFIG，设置内存加密密钥周期性轮换周期（建议 24h），并结合CLFLUSHOPT指令在密钥轮换窗口前强制刷新缓存行，增加行锤攻击构建稳定位翻转的难度。
ECC内存强制模式：BIOS层面强制开启Patrol Scrubbing与Demand Scrubbing，TD内部通过MCE（Machine Check Exception）处理器订阅硬件纠错日志，一旦检测到可纠错错误（CE）频率超阈值，触发TD主动熔断并上报硬件故障，防止不可纠错错误（UE）导致密钥翻转。

1.3 投机执行与微架构数据采样 (MDS/TSX) 缓解

编译器级加固：全模块开启 -mharden-sls=all（Straight Line Speculation）与 -mfunction-return=thunk-extern（Retpoline增强），针对switch-case密集的RTP/RTCP解析逻辑插入LFENCE屏障。
TSX禁用与RTM替代：媒体服务器无事务内存需求，在TD Guest Kernel命令行添加 tsx=off tsx_async_abort=full,nosmt，彻底关闭TSX，规避TSX Asynchronous Abort (TAA) 漏洞利用链。
SMT策略：强制关闭超线程（SMT/HT）。媒体服务器通常部署在独占物理核心实例上，通过cpuinfo与lscpu在TD内二次校验Thread(s) per core = 1，消除同核兄弟线程间的端口争用侧信道。

二、有状态媒体平面的可信迁移与高可用架构

媒体服务器（SFU/MCU）本质是有状态网络中间件：维护着SSRC映射表、RTP序列号/时间戳状态、NACK/PLI反馈缓冲、Simulcast/SVC分层转发树。TDX 1.5引入的TD迁移特性为高可用提供了硬件原语，但需解决“状态一致性”与“密钥连续性”双重挑战。

2.1 迁移架构：控制面解耦与数据面检查点

采用“控制面无状态、数据面检查点”分离架构：

graph LR
    subgraph Source Host
        TD_S[Source TD] -->|1. Quiesce & Checkpoint| CKPT[(Checkpoint Storage<br/>Encrypted by Migration Key)]
        TD_S -->|2. Live Migration Stream| TD_D
    end
    subgraph Dest Host
        TD_D[Destination TD] -->|3. Restore & Resume| CKPT
    end
    KMS[KMS/HSM] -->|Migration Key Wrap/Unwrap| TD_S
    KMS -->|Migration Key Wrap/Unwrap| TD_D
    Orch[Orchestrator] -->|Attestation & Policy| TD_S
    Orch -->|Attestation & Policy| TD_D

检查点内容：
- 媒体状态：每路流的SSRC -> {SeqNum, TS_Offset, Last_RTCP_SR, Jitter_Buf_State, PLI_Timer}。
- 密钥状态：当前Epoch、所有活跃流的SRTP_Rollover_Counter (ROC)、下一轮换时间戳。
- 拓扑状态：Simulcast层级订阅关系图、SVC时间/空间层依赖图。
加密传输：迁移流通过TDX Migration Key加密（AES-256-GCM），密钥由KMS基于源/目标TD的Quote动态派生，迁移过程中明文不落盘、不经Host内存。

2.2 秒级无感切换的关键技术

预拷贝与脏页追踪：利用TDX TDH.MIG.START / TDH.MIG.MEM 指令流，配合EPT Accessed/Dirty位硬件加速脏页扫描。媒体内存模式为“大页（1GB HugePages）+ 少量频繁写共享缓冲区”，预拷贝轮次通常 2-3 次即可收敛至 < 50MB 脏页。
网络连接迁移：
- 方案A（推荐）：SR-IOV VF 热迁移。网卡固件支持VF状态迁移，TD迁移同步VF上下文（队列指针、中断向量），客户端TCP/UDP连接无感知，仅丢失迁移窗口内 < 100ms 的包（由NACK/ARQ恢复）。
- 方案B：用户态协议栈。TD内集成DPDK/F-Stack，迁移时同步TCP控制块（TCB）与发送/接收窗口，配合Gratuitous ARP/NDP刷新网关表。
时钟同步连续性：TD内部使用CLOCK_MONOTONIC_RAW（基于TSC）驱动媒体定时器。迁移前校验源/目标宿主机TSC频率偏移 < 10ppm，迁移后通过KVM_SET_TSC_KHZ同步TSC偏移量，避免RTP时间戳跳变导致接收端抖动缓冲区重置。

2.3 故障域隔离与多AZ部署

反亲和性调度：Orchestrator强制主/备TD分布在不同物理机架、不同电源域、不同CPU微代码版本批次的宿主机上。
Split-Brain防护：引入外部仲裁服务（基于etcd/Raft），TD启动时获取Lease，心跳丢失超时（建议 3s）自动触发备节点接管，避免双主导致媒体流撕裂。

三、异构算力统一调度：QAT/AMX/VPU的可信资源池化

单一VPU编解码资源在突发大型会议（>500方）下易成瓶颈。架构需将CPU集成加速器（QAT、AMX、GNA）、离散VPU/GPU纳入TD可信资源池统一调度。

3.1 统一设备抽象层：TDX-IO Device Interface (TDI) 适配

定义MediaAccel 抽象接口，屏蔽底层硬件差异：

type MediaAccel interface {
    // 编解码能力声明
    Caps() CodecCaps // {H264: {MaxWidth, MaxFPS, Profile}, AV1: {...}, Encode/Decode}
    // 会话绑定：返回设备侧句柄，绑定特定Shared GPA Buffer Pool
    CreateSession(ctx Context, params SessionParams) (SessionHandle, error)
    // 异步提交任务，支持零拷贝DMA Bucket
    SubmitTask(handle SessionHandle, task *CodecTask) error
    // 事件回调：完成/错误/参数变更
    SetCallback(cb EventCallback)
}

3.2 硬件资源拓扑感知调度

NUMA亲和性绑定：Orchestrator通过virsh nodedev-dumpxml采集宿主机拓扑，生成Device Topology Manifest（PCIe拓扑、NUMA节点、IOMMU组）。TD启动时通过TDH.MNG.INIT参数指定CPUID掩码与PCIe Root Port分配，确保VPU/QAT/CPU Core位于同一NUMA节点，PCIe延迟 < 2μs。
动态分区与时分复用：
- VPU/GPU：利用SR-IOV VF或Intel GVT-g（vGPU）切分，每个TD独占VF，硬件级隔离上下文。
- QAT/AMX：CPU共享资源。TD内通过user-space driver (usdm_drv)直接操作MMIO寄存器，无需Host Kernel驱动中介。调度器根据实时负载（QAT队列深度、AMX Tile利用率）动态调整TD vCPU绑定与优先级。

3.3 智能降级与算力兜底策略

资源压力级别	触发条件	降级动作	用户感知
L1 (Warning)	VPU队列延迟 > 10ms	新增流优先分配CPU AMX编码 (libsvtav1/AMX)	无感（码率微增 < 5%）
L2 (Critical)	VPU显存 OOM / QAT错误率 > 1%	强制现有1080p流降级至720p/30fps；关闭屏幕共享高帧率	轻微清晰度下降
L3 (Emergency)	物理设备故障 / TD迁移中	触发TD迁移至健康节点；或切换纯软件编解码集群	短暂黑屏/花屏 (< 2s)，自动恢复

四、零信任运维体系：不可变基础设施与供应链完整性

机密计算的核心假设是“代码即信任锚点”。任何运维操作（补丁、配置变更、扩容）均等同于TCB变更，必须纳入远程证明验证链。

4.1 镜像构建管道：SLSA Level 3+ 合规流水线

# .gitlab-ci.yml / Tekton Pipeline 片段
stages:
  - build: # 可复现构建
      image: gcr.io/distroless/cc-debian12:nonroot
      script:
        - bazel build --stamp --workspace_status_command=./stamp.sh //media_server:td_image
        - cosign sign --yes --predicate slsa-provenance.intoto.json $IMAGE_URI
  - attest: # 生成部署证明
      script:
        - tdxtctl measure --image $IMAGE_URI --output manifest.json
        - rekor upload --artifact manifest.json --public-key cosign.pub
  - deploy: # GitOps 部署
      environment: production
      rules:
        - if: $CI_COMMIT_TAG =~ /^vd+.d+.d+$/
      script:
        - argocd app set media-server-td --parameter image.tag=$CI_COMMIT_TAG
        - argocd app sync media-server-td --prune --auto-prune

确定性构建：Bazel/Nix锁定所有依赖哈希，stamp.sh注入Git Commit、Build Time、Builder ID，确保同源码产出逐比特一致的TD镜像（MRTD固化）。
签名透明度：cosign + Rekor 将镜像摘要、SBOM (SPDX/JSON)、Provenance 记录至不可篡改透明度日志，审计时可验证“运行代码 == 审计代码”。

4.2 运行时完整性度量：RTMR 扩展策略

TDX提供 4 个运行时度量寄存器，规划如下：

RTMR 索引	度量对象	扩展时机	策略引擎判定逻辑
RTMR[0]	Kernel & Initrd	TD启动 (TDH.MR.EXTEND)	必须匹配黄金值；任何内核模块加载、kexec 均导致不匹配
RTMR[1]	系统配置与策略	`systemd` 启动早期	包含：内核命令行、SELinux/AppArmor策略哈希、TD配置文件哈希
RTMR[2]	媒体业务二进制	主进程 `execve` 前	度量 `media_server` 二进制、依赖库、插件目录 Merkle Root
RTMR[3]	动态插件/规则	热加载插件/更新规则时	仅允许签名验证通过的 WASM/eBPF 插件扩展；配置变更需双人复核签名

策略引擎：验证方（客户端SDK/网关/审计平台）拉取 Reference Values（参考值库），对比 Quote 中的 RTMR 值。任一 RTMR 偏离，拒绝建立媒体会话、拒绝下发密钥、触发告警。

4.3 可信运维操作：无 SSH、无特权、全审计

弃用 SSH/Bastion：TD 内不运行 SSH Server，不开放 22 端口。运维操作仅通过 VSOCK Agent 暴露 gRPC 接口（GetMetrics, TriggerHeapDump, RotateLogLevel），接口需 mTLS 认证且绑定 RTMR[1] 策略。
秘钥轮换自动化：证书轮换（TLS Cert、SRTP Master Key）由 TD 内部 CertManager 基于 cron + Vault Agent 自动完成，人工不接触私钥。
应急只读诊断：故障排查时，仅允许通过 TDG.VP.VMCALL 触发 Core Dump 生成（加密导出至指定 KMS 解密的存储桶），禁止任何交互式调试（GDB/ptrace）。

五、合规审计与数据主权：可验证的“数据可用不可见”

5.1 隐私计算接口：联邦学习/内容审核的可信外包

企业会议常需“智能纪要”、“敏感词审核”、“发言人分离”。架构提供可信数据沙箱能力：

数据不出 TD：ASR/ NLP 模型作为 WASM 模块 或 eBPF 程序 下发至 TD 内运行（度量进 RTMR[3]）。
结果脱敏输出：模型仅输出结构化文本/标签，不输出原始音视频片段。
算子签名验证：模型文件需经模型供应商私钥签名，TD 内验证签名后加载，防止供应链投毒。

5.2 审计日志链上存证

关键审计事件（会议创建、成员加入、密钥轮换、迁移、配置变更）采用 W3C DID + Verifiable Credentials (VC) 格式：

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential", "ConfidentialMeetingAudit"],
  "issuer": "did:tdx:td-<MRTD_HASH>",
  "issuanceDate": "2024-01-15T08:00:00Z",
  "credentialSubject": {
    "conferenceId": "conf_abc123",
    "event": "KEY_ROTATION",
    "epoch": 5,
    "trigger": "MEMBER_JOIN",
    "newKeyCommitment": "sha256:..."
  },
  "proof": { "type": "EcdsaSecp256r1Signature2019", "verificationMethod": "did:tdx:td-...#key-1", "proofValue": "..." }
}

日志经 TD 内部签名后写入仅追加存储（WORM 对象存储/区块链），满足《网络安全法》留存六个月及金融级审计要求。

5.3 数据主权与跨境合规

密钥地理围栏：KMS 部署在数据合规要求的司法管辖区（如中国大陆、欧盟、新加坡）。TD 远程证明时携带 Location Claim（基于云厂商 Zone 认证），KMS 仅向合规区域内的 TD 释放 Root Key。
密文数据流转：跨区媒体转发（如北京节点转发至新加坡节点）仅传输 SRTP 密文，中转节点 TD 无解密密钥，实现“管道不可见明文”，符合《数据出境安全评估办法》中“去标识化/加密传输”路径。