硬核拆解 Intel CSME：当硬件信任根本身不可信任——从 CVE-2019-0090 到 2025 年 FEK 彻底沦陷

# 硬核拆解 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 #硬核拆解