TEE 与 SVP：DRM 硬件级安全的两大基石
DRM中的TEE和SVP具体指什么，它们在DRM体系中起到什么作用？
这两个概念是理解"为什么商用 DRM 能被好莱坞认可、而 JS 层加密不行"的核心。它们一个管计算侧的可信隔离，一个管数据通路上的防拷贝，合起来构成了"明文永远不出安全域"这一 DRM 的终极承诺。
一、TEE（Trusted Execution Environment，可信执行环境）
1. 定义
TEE 是主处理器（CPU/SoC）内部独立于普通操作系统（REE, Rich Execution Environment）的一块隔离执行区域，拥有自己的内存、存储和代码执行空间，由硬件强制隔离，即便主 OS（Android/Linux/Windows）被 root 或被内核级恶意软件攻破，也无法读取或篡改 TEE 内部的数据和代码。
通俗比喻：手机/电脑里有两台计算机——一台是你看得到的"大 OS"（REE），一台是你看不到的"保险箱 OS"（TEE）。两者之间只能通过极少数经过签名校验的消息接口通信。
2. 主流实现
| 架构 | TEE 技术 | 典型场景 |
|---|---|---|
| ARM（手机/机顶盒/智能电视） | TrustZone（Secure World vs Normal World） | Widevine L1、FairPlay、智能卡 |
| Intel x86 | SGX（Enclave）、TDX（机密 VM）、早期 ME/CSME | PlayReady SL3000、服务器机密计算 |
| AMD x86 | SEV / SEV-SNP、PSP (Platform Security Processor) | 服务器、部分 PC DRM |
| Apple | Secure Enclave Processor (SEP) + T2/M 系列协处理器 | FairPlay Streaming |
| Titan M / StrongBox（Pixel）、Trusty TEE（AOSP 通用 TEE OS） | Android 内容保护 | |
| Qualcomm | QSEE / QTEE | 大部分安卓旗舰 |
| MediaTek | GenieZone / MTEE | 电视盒子、中端安卓 |
3. TEE 在 DRM 中承担的职责
一条完整的 DRM 授权+解密链路里，下列敏感环节全部在 TEE 内完成，主 OS/浏览器/JS 完全接触不到：
- 设备身份证明（Provisioning / Attestation）
- 出厂时厂商写入的设备根证书私钥永久保存在 TEE 的安全存储（RPMB / eFuse）中，永不出 TEE
- License Server 通过验证这把证书判断"你是一台合法的、未 root 的设备"
- License 解密
- License Server 下发的 License 里包含用 TEE 公钥加密的 Content Key
- CDM 把 License 投递到 TEE，TEE 内部用设备私钥解出 Content Key
- Content Key 保管
- Content Key 以密文形式躺在 TEE 的安全内存里，从不出现在普通内存（DDR 主存可被 DMA 读取的区域）
- 媒体样本解密
- CDM 把加密的 fMP4 sample 交给 TEE，TEE 用 Content Key 执行 AES-CTR / CBC 解密
- 解密后的 ES（H.264/H.265/AV1 裸流）依然停留在 TEE 的安全内存缓冲区
- 策略执行（Policy Enforcement）
- License 里的
HDCP 级别要求、输出分辨率限制、是否允许录制、时长/次数限制、地理围栏等策略在 TEE 内判定，主 OS 无权绕过
- License 里的
4. TEE 的安全分级（以 Widevine 为例）
| 等级 | 密钥处理 | 解密 | 解码/渲染 | 典型能力 |
|---|---|---|---|---|
| L1 | TEE 内 | TEE 内 | TEE 内或安全硬件 | 可播 1080P/4K/HDR 高价值内容 |
| L2 | TEE 内 | TEE 内 | 普通 OS | 一般不被内容方接受 |
| L3 | 软件（白盒） | 软件 | 普通 OS | 只允许 480P/SD，相当于"礼貌性合规" |
关键点：L1/L2 的差别不在于有没有 TEE，而在于解码和渲染是否也在安全域里——这就引出了下面的 SVP。
二、SVP（Secure Video Path，安全视频通路）
1. 定义
SVP 是指从解密后的 ES（压缩明文）→ 解码后的 YUV（未压缩明文）→ 合成/混合 → 显示输出这条数据通路上，所有中间数据全部存放在硬件强制隔离的"安全内存（Secure Memory / Protected Memory）"中，普通 CPU、主 OS、GPU 通用着色器、DMA 控制器都无法读取，只有被授权的安全硬件模块（安全解码器、安全合成器、HDCP 加密引擎）才能访问。
通俗比喻：TEE 管"小黑屋里算密码"，SVP 管"从小黑屋通到屏幕的那条专用管道，全程焊死、不留窃听口"。
2. SVP 的完整链路
[TEE 解密]
│ (明文 H.265 ES 进入安全内存)
▼
[Secure Video Decoder] —— 硬件解码器读取安全内存中的 ES，输出 YUV 仍写回安全内存
│
▼
[Secure Composer / SurfaceFlinger 安全通路]
│ (与普通 UI 图层混合时，安全图层只暴露一个"黑色代理"给普通 GPU)
▼
[Display Controller + HDCP 加密引擎]
│ (输出到 HDMI/DP 前，按 HDCP 2.2/2.3 重新加密)
▼
[显示器 / TV] —— HDCP 解密后直接驱动面板3. SVP 需要的硬件能力
| 组件 | 作用 |
|---|---|
| Secure Memory Region | 内存控制器（SMMU / IOMMU）划出的保护区域，打了 NS-bit（TrustZone）或 MKTME key，普通 DMA 读会被拒绝或返回全 0 |
| Secure Video Decoder（如 Mali-V、VPU、VideoToolbox Secure） | 接收安全内存输入、产出安全内存输出的硬件解码器 |
| Secure Composer / Secure SurfaceFlinger | Android HWC2 中的 Protected Content 图层；macOS/iOS 的 IOSurface kIOSurfaceProtected |
| HDCP 加密引擎 | 在 HDMI/DisplayPort 输出前对帧做二次加密，防止 HDMI 采集卡抓录 |
| 截屏/录屏拦截 | 系统在合成阶段识别到 Protected Surface，强制把这块区域在截屏/投屏输出中涂黑（比如 Netflix 截图全黑就是这个机制） |
4. SVP 在 DRM 中承担的职责
- 防止解密后的明文 ES 被 dump
- 没有 SVP，即便解密在 TEE 做了，明文 ES 也得交给主 OS 里的软/硬解码器 → 可被 hook → 功亏一篑
- 防止解码后的 YUV 被截取
- GPU 通用 shader、
glReadPixels、IOSurfaceLock、AndroidMediaProjection等常规路径都拿不到安全 surface 的像素
- GPU 通用 shader、
- 强制 HDCP 输出保护
- 好莱坞对 4K/HDR 内容要求 HDCP 2.2+，SVP 确保信号离开 SoC 前必然被 HDCP 重新加密
- 截屏/投屏黑屏
- 这是用户侧最直观的感知：Netflix、Disney+、爱奇艺付费内容在安卓/Windows 上截屏是黑的，就是 SVP + Protected Surface 的合力
- 防止 GPU 侧信道
- 现代 SVP 还会禁用某些 GPU 调试特性、性能计数器，避免通过功耗/时序侧信道还原像素
三、TEE 与 SVP 的关系：分工与协作
可以用一张对比表说清：
| 维度 | TEE | SVP |
|---|---|---|
| 保护对象 | 密钥 + 策略 + 解密前后的压缩数据 | 解码后的未压缩像素 + 显示通路 |
| 所在位置 | CPU/SoC 内的隔离执行域 | 内存子系统 + 视频硬件 + 显示控制器 |
| 核心机制 | 代码 & 数据隔离（TrustZone/SGX/SEP） | 安全内存 + 安全硬件 + HDCP |
| 失效后果 | Content Key 泄露 → 全量内容被破解 | 单次播放被录屏 → 单片泄露（可被水印追溯） |
| 是否够用 | 只有 TEE 没 SVP → 解密后明文仍可能被偷 → 降级到 L3/SL150 | 只有 SVP 没 TEE → 密钥无处安放 → 根本立不住 |
协作流程（以 Android + Widevine L1 播放 4K HDR 为例）：
① EME 协商 License，CDM 把 License 投入 TrustZone
② TEE 内解出 Content Key，留在 TEE 安全内存
③ 播放器把加密 fMP4 sample 通过共享内存交给 TEE
④ TEE 解密 → 明文 ES 写入"Secure Memory"（不是 TEE 内存，是受保护的主存区域，硬件解码器可读）
⑤ Secure Video Decoder 读 Secure Memory，解出 YUV 继续写回 Secure Memory
⑥ Secure Composer 把解码输出标记为 Protected Surface，与 UI 合成
⑦ Display Controller 输出前，HDCP 引擎加密 → HDMI → 电视解密 → 面板显示
⑧ 全程任何一步若检测到不合规（HDCP 不足、非安全路径、调试器接入），直接降级到 540P 或黑屏四、为什么"JS 层自研 DRM"无法替代 TEE + SVP
回到上一轮讨论的 FLV 自研加密场景，对照就一目了然：
| 安全能力 | 商用 DRM (TEE+SVP) | JS/Wasm 自研加密 |
|---|---|---|
| 密钥存储 | 硬件私钥 + TEE 安全存储 | JS 变量 / Wasm 线性内存，可被 dump |
| 解密执行 | TEE 内专用指令 | SubtleCrypto / Wasm，用户态可调试 |
| 解密后数据 | 安全内存，主 OS 不可见 | JS 可 new Uint8Array() 直接访问 |
| 解码数据 | Secure Video Decoder | 普通 VideoDecoder / MSE，明文 YUV 可达 GPU 普通纹理 |
| 截屏防护 | Protected Surface 强制黑屏 | 浏览器无此能力 |
| HDMI 输出 | 强制 HDCP 2.2+ | 依赖 OS，无强制能力 |
| 合规背书 | 好莱坞 MPA、DVB-CSA 认证 | 无 |
这就是为什么商用 DRM 必须由浏览器内置的 CDM + 操作系统 + SoC 厂商三方联合实现，任何纯前端 JS 方案都只能是"对称加密 + 代码混淆"，在法律与商业合规层面根本不被视作 DRM。
五、速记
- TEE = "保险箱 CPU"：装密钥、跑解密、执行策略
- SVP = "防弹运钞车"：把解密后的明文像素安全送到屏幕，全程不落地
- DRM = License 协议 + TEE 保管密钥 + SVP 护送像素 + HDCP 保护输出，四件套缺一不可；HLS/DASH + CENC + fMP4 只是"兼容这四件套的载体格式"，而 FLV 缺的不只是格式，而是整个硬件信任链的入口。