硬核拆解 Intel CSME：当硬件信任根本身不可信任

从 CVE-2019-0090 的 IOMMU race condition，到 2025 年 FEK（熔丝加密密钥）被彻底破解——Intel 花了六年时间构建的"硬件隔离"安全模型，被一个根本性的设计悖论击碎：你把密钥藏进了保险箱，却把保险箱的密码写在了保险箱门上。

一、漏洞不是代码写错了，是硬件设计时就埋下的

2025 年 3 月 20 日，Positive Technologies 发布了一篇标题极具冲击力的报告：《Last barrier destroyed, or compromise of Fuse Encryption Key for Intel Security Fuses》。这不是又发现了一个缓冲区溢出，而是宣布：Intel CSME 安全体系的最后一道防线，已经被物理层面的设计缺陷彻底击穿。

要理解这个结论的可怕之处，我们需要回到 2019 年。

CVE-2019-0090：一个 race condition 窗口，打开了潘多拉魔盒

Intel CSME（Converged Security and Management Engine）作为平台的 Root of Trust，其核心安全假设是：CSME 的 SRAM 和内存区域对主机 CPU 和其他 IP 块不可见。这个隔离由 IOMMU（Input-Output Memory Management Unit）强制执行。

但 CVE-2019-0090 揭示了一个致命事实：

当 CSME 退出重置状态时，IOMMU 默认是禁用的。只有在 CSME ROM 执行后，IOMMU 保护才会被打开。

这意味着存在一个时间窗口——在 CSME 退出重置到 ROM 启用 IOMMU 之间的微秒级间隙——任何具有 RS1（Root Space 1）DMA 能力的 IP 块都可以直接读写 CSME 的 SRAM。

Positive Technologies 在 Cannon Lake 平台上成功利用了这一漏洞：

1. 植入恶意固件：在集成传感器集线器（ISH）上加载攻击者控制的固件
2. 触发 CSME 重置：通过制造命令或等待 CSME 从低功耗状态恢复
3. DMA 攻击窗口：在 IOMMU 尚未启用时，通过 RS1 DMA 事务读取 CSME SRAM
4. ROP 链执行：利用读取到的数据构建 ROP 攻击，控制 CSME ROM 执行流

Intel 的缓解措施简单粗暴：在新平台（Ice Lake、Comet Lake、Tiger Lake 等）上，IOMMU 默认启用。但老平台无法硬件修复，只能依赖固件补丁——而固件补丁无法消除硬件层面的 race condition。

但 CVE-2019-0090 只是第一级

Positive Technologies 最初认为，CVE-2019-0090 只能绕过 CSME 安全模型的第一级保护。虽然可以读取加密的 Security Fuses，但 Fuse Encryption Key（FEK）存储在 Secure Key Storage（SKS）硬件模块中，CSME 固件无法直接访问其明文。

SKS 的设计哲学是：密钥在硬件中生成和使用，但永远不暴露其明文到 CSME SRAM。这类似于硬件安全模块（HSM）的思路——你可以用密钥做加密操作，但拿不到密钥本身。

如果这套设计有效，CVE-2019-0090 就只是"有限危害"的漏洞。

但 2025 年的研究证明：SKS 本身存在一个架构级缺陷，让 FEK 可以被完整提取。

二、FEK 破解：从"不可访问"到"已知明文攻击"

SKS 的双重模式灾难

Intel 的 Secure Key Storage 支持两种密钥模式：

• Secure Mode：密钥激活 SKS 保护，CSME 无法读取明文，只能使用密钥执行加密操作
• Non-Secure Mode：密钥不激活 SKS 保护，允许 CSME 读取加密操作的结果数据

Non-Secure Mode 的设计初衷是支持 SHA/HMAC 等哈希操作——这些操作的结果需要被 CSME 固件读取。但问题在于：Non-Secure Mode 下的密钥可以被覆盖，而且加密设备不保护原始密钥。

FEK 的 Secure Mode = 0

Positive Technologies 在研究中发现，FEK（Fuse Encryption Key，熔丝加密密钥）的 Secure Mode 属性被设置为 0，即 Non-Secure Mode。

这是 Intel 官方文档中明确记录的事实。Intel 的解释是：FEK 需要用于解密 EPID 私钥（椭圆曲线数字签名算法的私钥），而 OCS（Offload and Crypto Subsystem）的硬件不支持 ECDSA，所以 EPID 私钥必须在 CSME 内存中软件实现。因此 FEK 不能被锁死在 Secure Mode 中。

但这个解释掩盖了真正的问题：AES 加密设备（AES_A、AES_P）实际上支持 Secure Mode 下读取结果数据。FEK 完全可以设置为 Secure Mode，同时允许解密后的数据被读取。Intel 的固件开发者和硬件工程师之间出现了严重的协调失误。

已知明文攻击：256 × 32 次尝试提取 32 字节密钥

既然 FEK 处于 Non-Secure Mode，攻击者可以：

1. 控制输入明文：向 AES 设备发送任意明文进行加密
2. 观察输出密文：对比密钥被覆盖前后的加密结果
3. 逐字节爆破：对于 32 字节的 AES 密钥，逐字节尝试（256 种可能），检查密文是否变化
4. 完整提取：最多需要 256 × 32 = 8192 次尝试，即可恢复完整的 32 字节 FEK

Positive Technologies 在 Apollo Lake 和 Gemini Lake 平台上成功演示了这一攻击，并在报告中直接公布了这两个平台的 FEK 值。

最致命的一点：FEK 不是唯一的

FEK 对于同一微架构的所有处理器都是相同的。

这意味着：攻击者只需要破解一台 Apollo Lake 设备，就能获得所有 Apollo Lake 设备的 FEK。同理适用于 Gemini Lake/Refresh。

一旦 FEK 泄露，加密的 Security Fuses 就不再安全。攻击者可以：

• 解密 Chipset Key（芯片组密钥）
• 提取 EPID 私钥（增强隐私 ID 的私钥，用于证明平台真实性）
• 伪造 CSME 固件签名
• 绕过 Boot Guard、PTT/TPM 等所有基于 CSME 的安全机制

Intel 的安全模型依赖 SVN（Security Version Number）进行 TCB 恢复——当漏洞被发现时，升级固件版本号，旧的密钥被撤销，新的密钥被分发。但如果 FEK 泄露，攻击者可以为任意 SVN 重新计算所有派生密钥。TCB 恢复机制彻底失效。

三、硬件安全模型的根本性悖论

Intel CSME 的设计体现了"纵深防御"（Defense-in-Depth）的理想：

• 硬件隔离（独立处理器、SRAM、IOMMU）
• 信任链（ROM → RBE → 内核，逐级签名验证）
• 密钥层次（FEK → Chipset Key → Wrapping Key → 各模块密钥）
• 反回滚（SVN 版本控制，防固件降级）

但 2025 年的研究证明，这个模型有一个致命弱点：根密钥本身不可升级。

FEK 是烧录在硬件熔丝（Fuse）中的，一旦出厂就无法更改。如果 FEK 泄露，整个信任链的根就被拔掉了——就像你把房子的地基密码告诉了所有人，然后发现地基本身无法更换。

为什么 Intel 无法修复？

Intel 在 2025 年 4 月 3 日的安全公告中回应：

"All reported vulnerabilities have been mitigated. Systems with all firmware updates applied... are not susceptible."

但 Positive Technologies 立即指出：

"This is a hardware design problem and cannot be fixed by modifying CSME firmware."

Intel 的"缓解"实际上是降低可利用性，而非消除漏洞：

1. End of Manufacturing（EOM）：系统制造商必须启用 Flash Descriptor 写保护、禁用 CSME 制造 API
2. 固件更新：修补 CVE-2019-0090 的利用链
3. 物理访问要求：强调攻击需要物理接触

但这些缓解措施不改变一个事实：受影响平台的 FEK 已经泄露，且永远无法更换。只要攻击者拥有 FEK 和加密的 Security Fuses（可通过电压故障注入提取），就可以完全 compromise 平台。

四、影响评估：谁该担心？

直接影响范围

Positive Technologies 的研究主要针对 Apollo Lake、Gemini Lake/Refresh 等 Atom 平台。这些平台广泛应用于：

• 嵌入式设备
• 工业控制
• 物联网网关
• 低端笔记本

但威胁模型远不止于此。

虽然 FEK 泄露目前只在 Atom 平台上被证实，但 Positive Technologies 指出：

"The insecure FEK problem exists at the hardware level and is an architectural problem."

如果 Intel 在其他平台（Core 系列、Xeon 系列）上使用了相同的 SKS/OCS 设计哲学，类似的漏洞可能存在。目前尚无公开证据表明 Core 平台的 FEK 也被提取，但设计层面的风险不可忽视。

实际攻击场景

1. 供应链攻击：攻击者在工厂或物流环节获取设备，提取 FEK，植入不可检测的恶意 CSME 固件
2. 二手设备风险：购买的"全新"设备可能已被 compromise，且没有任何软件工具可以检测
3. 企业环境：vPro/AMT 远程管理功能一旦被控制，攻击者可以绕过所有操作系统级安全监控
4. DRM/内容保护：HDCP、SGX 等依赖 EPID 私钥证明平台真实性的机制失效

五、缓解现实：用户能做什么？

立即行动

1. 检查设备平台：如果是 Apollo Lake / Gemini Lake / Gemini Lake Refresh，风险最高
2. 更新 BIOS/ME 固件：虽然无法修复 FEK 泄露，但可以堵住 CVE-2019-0090 等利用链
3. 确认 EOM 完成：检查 Flash Descriptor 是否被锁定、CSME 制造 API 是否被禁用
4. 物理安全：防止未授权物理接触——FEK 提取需要物理访问

长期选择

1. me_cleaner 中性化：对非 vPro 设备，使用 me_cleaner 移除 AMT、网络等功能，大幅降低攻击面
2. 平台迁移：考虑 AMD（PSP 攻击面更小，但同样 closed-source）或 ARM 平台
3. 关注开源替代：如 RISC-V + 开源固件（coreboot、Oreboot），虽然生态不成熟，但透明度高

六、结论：当"信任根"本身需要被信任

Intel CSME 的故事揭示了一个关于"安全"的深刻悖论：

你构建了一个完美的保险箱来保护密钥，但保护保险箱的密码本身，却被设计成了不可升级、且可以被提取的。

CVE-2019-0090 打开了第一扇门——IOMMU 的 race condition 让攻击者可以读取加密的 Security Fuses。而 2025 年的 FEK 破解则证明：即使那扇门被关上，保险箱的设计本身就存在缺陷。

这不是代码 bug，这是架构级别的设计失误：

1. FEK 不应该被设置为 Non-Secure Mode
2. Non-Secure Mode 不应该允许密钥被覆盖和提取
3. 根密钥应该是唯一的、可轮换的，或者至少在不同平台间不同

Intel 花了六年时间构建的"Below-OS"安全堡垒，被一个 32 字节的 AES 密钥和一段 race condition 窗口彻底瓦解。这不是因为攻击者太强，而是因为防御者在设计根信任机制时，没有真正理解"根"的不可妥协性。

对于普通用户，这意味着：你的设备可能有一个永远修不好的漏洞，而且这个漏洞存在于你无法看到、无法控制的硬件层面。

对于安全研究者，这意味着：硬件安全评估不能再停留在"有隔离就安全"的层面，必须深入到密钥生命周期管理、架构级威胁建模，以及——最重要的——根密钥的不可撤销性问题。

对于 Intel，这意味着：closed-source + 不可审计 + 根密钥不可升级 = 系统性风险。

参考来源：

• Positive Technologies: "Last barrier destroyed, or compromise of Fuse Encryption Key for Intel Security Fuses" (2025-03-20)
• Intel Security Announcement 2025-04-03-001
• Intel CSME Security White Paper 14.0/15.0/16.0
• INTEL-SA-00213 (CVE-2019-0090)
• 安全研究 GoSSIP: "摧毁 Intel 熔丝加密密钥安全防护" (2025-04-13)
• 163.com / 4hou.com / cn-sec.com 技术分析 (2021)

#IntelCSME #硬件安全 #信任根 #CVE-2019-0090 #FEK #PositiveTechnologies #硬核拆解