G.O.S.S.I.P 阅读推荐 2025-04-13 摧毁Intel 熔丝加密密钥安全防护

想象一下，你在家中安装了世界上最先进的安全系统——钛合金大门、生物识别锁、红外线警报器，甚至还有激光防盗网，但有一天，安全专家告诉你：你知道吗？这套系统的万能钥匙其实压在家门口的花盆下面！这大概就是 Intel 面临的尴尬处境——我们今天要给大家介绍的这篇技术博客文章 Last barrier destroyed, or compromise of Fuse Encryption Key for Intel Security Fuses，分析了攻击者如何利用 Intel 处理器中的不安全访问控制策略，获取处理器中极为关键的 Fuse Encryption Key：

对于不熟悉底层硬件机制的读者，我们首先要介绍一下相关的背景知识。首先需要了解的概念是Intel 芯片组管理引擎（Converged Security and Management Engine，CSME），它是 Intel 处理器中的一个独立子系统，运行在主处理器之外。它负责系统启动验证、平台完整性检查、固件认证等关键安全功能，可以把它看成 Intel 处理器的安全信任根基。

为了确保CSME系统的安全性，Intel 处理器在构建整个信任链时，主要依赖于两个关键元素来生成信任根：

• Security Fuses（安全熔丝）：这是存在于芯片 ROM 中的特殊区域（及其携带的数据）。
• Fuse Encryption Key（FEK）：用于加密和解密 Security Fuses 携带数据的关键密钥。

如果要用通俗的解释方式来说明的话，那就可以认为 Intel 处理器在运行时通过读取 Security Fuses 携带的数据，然后使用上述的FEK做一个变换（加密解密），变换得到的输出就是整个处理器所依赖的信任根密钥数据，构成了整个安全信任链的基础。大家可能会问，这里为什么不直接使用 Security Fuses 携带的数据，还要做一个额外变换呢？因为我们实际上也要考虑到攻击者可以物理访问处理器，对其进行显微镜底下的逆向分析，提取相关 Security Fuses 携带的数据。

在实际的硬件中，读取 Security Fuses 携带数据并生成初始信任根密钥相关的操作，要比上面的描述复杂许多，正是这里面的复杂性，最终带来了严重的安全问题。在 Intel 处理器中，整个CSME中各部分的关系如下图所示。我们接下来详细为大家解读相关的设计及其安全漏洞。

下图是2019年在Black Hat USA是上的一个技术报告披露的CSME中相关的密钥管理的机制（注意到这个图中的一些名词和今天的文章的技术名词有所出入，我们下面会注释）。我们注意到，在CSME中，生成各类相关的密钥（例如CSE Wrapping Key、CSE Suspend Key等等）的操作并不是一蹴而就的，而是依赖于前面两个初始化操作（图中的 HW key generation 和 Decryption of Chipset Key）。这两个初始化操作涉及的数据包括 Chipset Key Fuses（也就是前面说的 Security Fuses 携带的数据）以及 HW key（就是前面介绍的Fuse Encryption Key，FEK），这些数据是CSME不能直接读取的。

实际上，我们看到上图中有两个名词——SKS 和 OCS，SKS 代表的是 Secure Key Storage，是一个专门负责使用安全密钥的特定模块，而 OCS 指的是 Offload & Cryptography Subsystem，是一个专门负责密钥派生和密码学操作的安全子系统。正是由于 OCS 和 SKS 提供的访问控制，让CSME不能直接获取整个信任根密钥的中间信息（包括图中显示的 HW key、Chipset Key Fuses，以及最后算出来的 Chipset Key）。

那大家可能要问，既然 CSME 都无法访问相关的密钥数据，那它是怎么使用这些机密信息的呢？具体来说，CSME 在需要执行相关的密码学运算的时候，首先通过 OCS 去指定 SKS 中特定的槽位（指定存放不同密钥的安全内存位置）和命令（指定了使用的密码算法）来间接使用密钥（但不会知道密钥内容是什么），整个密码学运算都是在 SKS 模块内部安全地执行的，结果则会直接保存到指定 SKS 槽位，再由 CSME 后续使用，这和现在移动操作系统的KeyStore的设计有点相似。

除了对敏感数据的内存区域进行保护外，处理器还要额外考虑在运算中，寄存器本身也可能泄露相关信息。这个本质上是因为 SKS 模块和 CSME 共用了一组寄存器（据说是因为 OCS 要遵循一套叫做 Open Core Protocol 的协议和其他模块通信，SKS 模块在读取 OCS 模块送进来的数据时候也得遵循这个协议，这样就没法把 SKS 模块设计成一个完全隔绝的安全模块了）。因此，为了防止 CSME 去访问或者修改和 SKS 操作的相关寄存器，Intel（不得不）给处理器再引入了一个 SKS Mode，在此模式下，只有 SKS 可以通过总线来读取 OCS 设备的结果；当 CSME 尝试去修改 SKS 写过的寄存器时，会启动保护逻辑，清空所有密钥相关的内容。

然而，Intel 处理器这个看似安全的设计中存在一个关键缺陷，最终导致了密钥安全不复存在。这个问题是什么呢？它源于处理器为了处理 SKS 与 OCS 之间的安全通信做出的妥协：在下图中，我们看到，除了红色的内容（一些敏感的 key）以外，OCS 也需要去访问一些不是那么高权限的密钥，比如下图中在执行HMAC-SHA256的运算结果），于是 CSME 又给每个密钥设置了三个不同的属性（注意到下图中最左边，每个密钥对应有 Privileged Level、Locked 和 Secure Mode 三个属性）。正是这里的不严谨的设置，最终导致了核心的 FEK 的泄露。

当某个密钥的 Secure Mode 属性设置为0的时候，系统就不会进入到 SKS 模式，当然这并不意味着 CSME 可以直接读取该密钥，但是它可以通过一种间接的方式去推测出密钥的值。注意到在 CSME 系统中，由于每次对密钥寄存器的修改可以按照1字节进行的，那么攻击者可以在 CSME 的非 SKS 模式下，通过尝试去重写密钥的一个字节来观察输入输出的情况，如果重写之后的输入输出和之前的输入输出关系一致，就说明这个重写尝试的值和原始的密钥对应的那个字节是一样的，这样就猜出来了密钥的一个字节内容。

对于32字节的AES密钥来说，攻击者只要控制输入的明文，检查输出的密文是否为之前不改变密钥时的加密结果来爆破密钥1字节的内容，并重复32次，即可恢复出完整的32字节密钥，最多也就只需要尝试256 * 32次。

在 Intel 文档中，记录了处理器对各个密钥所使用的 Secure Mode 的设置，其中最关键的 HW Key（也就是FEK）的 Secure Mode 被设置为了 0！这样，攻击者在获得 CSME 系统的代码执行权限的基础下，就可以恢复出相关的秘密信息，而由于 HW Key 在所有的 CSME 中均相同，这意味着任意一个处理器泄露了该密钥，则所有的处理器都不再安全。更糟糕的是，由于这一问题是硬件设计上的问题，并不能通过修改 CSME 的固件代码来解决。

Appllo Lake 的 FEK

Gemini Lake 的 FEK

原文：https://swarm.ptsecurity.com/last-barrier-destroyed-or-compromise-of-fuse-encryption-key-for-intel-security-fuses/

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2025-04-13 摧毁Intel 熔丝加密密钥安全防护