摧毁x86最后堡垒：Intel电熔丝e-Fuse加密密钥泄漏

Intel CSME（企业安全管理引擎）可以说是当前最复杂的带外平台之一，然而厂商对此并未提供足够的透明度。Mark Ermolov撰写的这篇出色文章深入揭示了其技术细节，这些细节源于多年的研究、调试和逆向工程。对于x86平台的系统安全防护而言，若不将Intel CSME或AMD PSP等原厂带外系统纳入威胁模型的构建，得出的结论必然会存在偏颇。CSME是“通过模糊性实现安全”的极端案例。自2015年以来，CSME本身提供了众多安全特性，但其内部机制却不透明，攻击者和安全研究人员只能依赖逆向工程和调试来进行研究。这种情况对研究人员而言充满挑战与乐趣，但对企业和个人的安全而言，却是教科书式的灾难。CSME的复杂性即使对大多数安全从业人员来说也依然难以捉摸，更不用说非安全领域的从业人员和普通用户。

换个角度来看，如果带外系统能够有开源实现，将极大减少信息不对称的风险。尽管开源本身带来的透明度并不一定直接转化为安全收益，但它无疑为安全研究提供了更为广阔的视野和更高的参与度。

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

相关议题:

Bootkit Showcase: Real-World Examples of Infrastructure Security Threats
https://github.com/hardenedvault/bootkit-samples

Hunting Shadows in the Era of Covert Warfare: The Counterstrike Against Demons from the "Ring -3" World for Firmware Freedom
https://hardenedlinux.org/blog/2018-07-04-hunting-shadows-in-the-era-of-covert-warfare-the-counterstrike-against-demons-from-the-ring-3-world-for-firmware-freedom/

Neutralize ME firmware on SandyBridge and IvyBridge platforms
https://hardenedlinux.org/blog/2016-11-17-neutralize-me-firmware-on-sandybridge-and-ivybridge-platforms/

Boot Unguarded: x86 Trust Anchor Downfalls to The Leaked OEM Internal Tools and Signing Keys
https://hardenedlinux.org/blog/2023-09-07-boot-unguarded-x86-trust-anchor-downfalls-to-the-leaked-oem-internal-tools-and-signing-keys/

Next Generation Data Center Security: The Cornerstone of Web3?
https://hardenedvault.net/blog/2022-08-05-next-gen-data-center-web3/

What every CISO and security engineer should know about Intel CSME
https://hardenedvault.net/blog/2021-07-16-ciso-seceng_csme/

引言

作为在研究英特尔开发的硬件平台安全性方面拥有多年经验的专家，我们承认英特尔的融合安全与管理引擎（CSME）安全架构是高度可靠的，并由顶尖专业人士设计。

从架构的角度来看，如果其所有个别组件按预期功能正常运行，找到一个漏洞是非常具有挑战性的，即使在假设的情况下，也可能导致不可逆转的后果，从而质疑所做决策的正确性。

毫无疑问，英特尔对其最低级别保护的可靠性（也称为信任根，RoT）的信心可以归因于赋予英特尔CSME子系统的最高权限，包括对包含用户数据的内存和硬件的无限制访问。这个RoT基于密码学，特别是对非对称和对称加密算法的熟练应用，以确保英特尔CSME及其他平台子系统的可执行代码和数据的机密性和完整性。

我们的目标不是重申英特尔CSME的安全性，因为英特尔已经在一份专门的文档中详细审查了他们的安全架构，从最低级别（根加密密钥）开始，涵盖模块完整性控制、远程证明和受信任的平台模块（TPM，[1]）等主题。

在本研究中，我们打算深入探讨具体细节，并展示在整体安全模型的背景下，错误的实现和不一致的使用本应正确且安全的机制如何导致严重后果，从而允许访问根加密密钥并使安全模型失效。

需要注意的是，由于所提议的安全模型的主要目标是确保无法访问根加密密钥，因此该模型的错误实现使其当前应用毫无意义，至少在本研究讨论的缺陷得到解决之前，这些缺陷如下面所示，仅在新平台中才能解决，因为错误的实现是硬编码在不可重新编程的内存中，并作为一些嵌入在英特尔CSME固件中的基本机制的架构基础。

在我们的研究中，我们将频繁引用描述英特尔CSME安全性的文档[2]，使用其术语、概念和图表。

英特尔CSME的信任根

英特尔CSME安全架构基于两个基本元素，这些元素形成了一个不可打破的基础，在任何情况下都不应被妥协。如果这个基础受到损害，整个“建筑”将会崩溃，并且没有机制可以防止这种情况的发生。这两个根本元素有不同的目的，但相辅相成，只有它们完全被妥协，才能绕过嵌入在英特尔CSME安全模型中的所有防御机制。

这两个元素是英特尔CSME信任根的基础：

1. 安全保险丝，每个晶体实例（无论是芯片组还是系统单芯片（SoC））都是独特的。它们由一个称为密钥生成设施（KGF）的特殊实体生成，KGF确保它们的唯一性、机密性和完整性，直到它们被编程到晶体的一次性编程（OTP）配置中。KGF可能是一个通过安全通道与工厂编程器连接的安全服务器，在高产制造（HVM）过程的最后阶段运行。

2. 保险丝加密密钥（FEK），在安全保险丝写入OTP配置之前，使用对称加密算法AES对其进行加密。该密钥并不唯一，而是在特定微架构的所有实例之间共享。例如，所有Tiger Point代的芯片组或所有Goldmont微架构的SoC共享相同的FEK。

图1展示了安全保险丝和保险丝加密密钥，以及它们在实现各种机制并确保英特尔CSME安全性的整体加密密钥层次结构中的位置。该图基于英特尔文档[2]，第15页，图4，“密钥派生概念密钥”。

Figure 1. Security Fuses and Fuse Encryption Key

在上面的图中，安全保险丝由右侧的红色矩形表示，标有“芯片组密钥保险丝（256位）”。然而，芯片组密钥保险丝仅是安全保险丝的一部分，安全保险丝还包括EPID私钥、EPID组ID、PTT背书密钥计数器和调试启用的芯片组密钥（见[2]，第4.1.1.1节，“保险丝加密硬件密钥、芯片组密钥及其衍生物”）。

不难猜测，这些根加密密钥构成了英特尔CSME中实现的技术的信任基础，英特尔在各种演示中自信地展示这些技术，毫不怀疑它们被妥协的可能性。实际上，“硬件信任根”这一短语旨在激发普通用户的信心，这些用户对硬件组件的实现和操作细节并不熟悉，并使公众相信硬件的可靠性总是高于软件系统。但事实真的是这样吗？

让我们看看构成安全保险丝保护的主要要点。

图1仅显示芯片组密钥保险丝是AES解密过程的输入，使用128位加密密钥（蓝色圆圈标有数字4），但省略了与存储和提取构成安全保险丝的二进制数据相关的所有细节。正是这些具体细节的实现决定了安全保险丝及整个平台的安全性。

安全保险丝的安全性基于：

1. 使用一次性编程内存，基于E-FUSE技术，将安全保险丝编程到晶体中。在光刻阶段，E-FUSE电路图以初始（未编程）状态呈现，允许写入任何二进制数据——包括零和一。在制造处理器或系统逻辑芯片的工厂生产线的最终阶段之一，使用电气连接到成品芯片接触点的工业编程器写入OTP配置。这允许为每个晶体实例设置唯一配置，这正是将生成的安全保险丝分配给每个芯片所需的。

一旦E-FUSE数据被写入，就无法重新编程，因为编程过程会导致晶体内部导体因E-FUSE控制器产生的高电流而烧毁。这个控制器称为保险丝控制器，负责编程安全保险丝以及安全地读取和传输它们到被授权请求的硬件模块。

2. 在密钥生成设施中生成后立即加密安全保险丝。

这一保护级别确保数据的安全：首先，在从KGF传输到工厂的HVM生产线期间，其次，在使用逆向工程技术从工作芯片实例中提取安全保险丝的情况下。攻击者将无法使用构成安全保险丝的根密钥来解密英特尔CSME固件的工作数据（该固件曾在经过此类分析的芯片上执行），因为这需要知道安全保险丝本身的加密密钥。

这个密钥称为保险丝加密密钥，或在图1中简单称为硬件密钥（左侧的红色矩形，标有箭头），正如上面提到的，它是英特尔CSME安全模型的重要组成部分，英特尔使用特殊方法来保护它，下面将单独描述。

前面提到的逆向工程技术基于使用扫描电子显微镜（SEM）和逐层分析构成硅晶体逻辑的CMOS元件，这可以检测到编程的E-FUSE数据，因为其烧毁的导体以在电子显微镜下可见的方式改变其结构（见图2）。

尽管这种分析比逆向工程硬件逻辑或读取集成电路的ROM数据更复杂，但在具备适当技能和高分辨率设备的情况下是完全可能的。

需要注意的是，这种分析本质上是破坏性的，会使微芯片失效，但提取的加密密钥（如果以明文存储在E-FUSE中）可以用于访问使用该芯片创建的信息，以及冒充该芯片——即在基于远程认证的互联网服务中模拟该芯片，以获取仅供在真实英特尔设备上受控使用的受保护数据，例如在数字版权管理（DRM）等技术中。这些技术不会将受保护的数据传递给用户，而是直接传输到硬件播放设备，允许用户查看数据，但无法复制。

Figure 2. E-FUSE cell under an electron microscope

3. 集中机制，在保险丝控制器硬件逻辑中实现，处理读取请求并将安全保险丝传输到英特尔CSME子系统内的内部设备。该平台设备位于英特尔CSME域之外，因为它不仅提供和保护安全保险丝，还执行存储设备配置（硬件OTP配置）信息的功能。不仅英特尔CSME子系统内的设备，还有主平台设备，如CPU核心、内存控制器、USB控制器等，都有自己的OTP配置，这些配置在英特尔芯片生产的最终阶段进行编程。

此外，一些设备，如CPU核心和电源管理微控制器（PCU或P-UNIT），也使用加密并将其根密钥存储在OTP内存中，例如，用于实现英特尔软件保护扩展（Intel SGX）技术。因此，保险丝控制器IP块是一个通用设备，所有具有特定配置要求的平台设备都可以访问。

这些配置信息通过一种称为IOSF侧带的特殊服务总线传输。IOSF，即英特尔片上系统结构，是一种专有规范，适用于多个数据总线和协议，设备在英特尔平台内相互交互时使用。这组IOSF总线（包括IOSF主总线、IOSF侧带和IOSF DFX）已取代PCI Express总线，用于在单个晶体内实现IP块之间的内部交互。IOSF规范最初为超移动平台（基于英特尔Atom SoC）开发，但迅速成为桌面和服务器系统中系统逻辑芯片组和处理器晶体的主要通信机制。

因此，迄今为止发布的所有英特尔平台都基于IOSF，而PCI Express总线现在仅用于将外部设备连接到平台。

在IOSF总线内，每个设备都分配一个唯一标识符，即SAI（发起者的安全属性），即使在不同平台类型之间，同一设备的SAI也保持不变。例如，从英特尔CSME域到主平台设备的ATT桥在Atom和桌面/服务器平台上始终具有0x20的SAI（在DFX绿色/锁定模式下）。

除了SAI，每个连接到IOSF侧带的设备还有一个唯一的端口ID，用于数据包路由目的。

然而，IOSF SB上设备的端口ID在不同平台和处理器/芯片组模型之间并不匹配。因此，SAI用于安全和访问控制目的来识别设备，而端口ID则用于总线上的寻址。

需要注意的是，IOSF SB上有特殊的桥接器，例如在处理器和芯片组之间，它们根据预定义的表格转换端口ID，但设备请求的SAI在这种转换过程中保持不变。

例如，在访问英特尔Rocket Lake平台上的P-UNIT时，英特尔CSME固件使用其端口ID为0x90，但PCH与CPU之间的SB_BRIDGE将此标识符转换为0xe2，该标识符在CPU域（北部复杂）内本地使用，而0x20的SAI保持不变。这使得设备能够基于通用访问掩码（用于读取、写入和配置权限）实施访问控制，而无需担心特定客户端设备在给定平台上的端口ID。

    Figure 3. IOSF buses from the Intel patent [3]

熔断器控制器设备包含一个特殊的表，称为熔断器分配查找表（FDLT），该表指定了在请求安全熔断器或硬件配置时，从公共E-FUSE阵列传输特定安全属性的发起者（SAI）和端口ID的数据的地址和长度。

如果请求的SAI根据该表不应来自指定的端口ID，或者根本没有在表中提到，则请求将被拒绝（以特殊错误状态完成）。同时，使用IOSF侧带总线的特殊操作码请求硬件配置和安全熔断器（0xb8和0xba用于硬件配置，0xbb用于安全熔断器）。此外，熔断器控制器分析当前的DFX安全策略值，该值指示不同的平台调试级别，例如红色和橙色解锁（见[4]，第6页），并仅在平台处于绿色/锁定模式下传输安全熔断器。

更具体地说，DFX安全策略值也是FDLT表数据的一个关键属性，在解锁模式下，发放的是一个特殊的调试启用密钥，尽管该密钥对平台是唯一的，但不允许在英特尔EPID远程证明技术中进行验证，并且不提供对在锁定模式下运行的固件数据的访问。这就是熔断器控制器如何实现CSME安全熔断器的保护：它们只能通过请求从英特尔CSME硬件域（通过适当的SAI）获得，并且仅在DFX安全策略绿色模式下。

4. 限制访问原始安全熔断器的英特尔CSME固件可执行代码的范围。

在检查存储在不可重编程内存（ROM）中的英特尔CSME固件部分时，该部分在CSME子系统启动后立即开始执行，可以清楚地看到，只有一小部分代码被允许访问原始安全熔断器，而所有其他存储在SPI闪存中的固件模块只能访问派生密钥（来自芯片组密钥和EPID根密钥），这些密钥也以某种方式受到保护（见[2]，第15页，段落——ROM可以从芯片组密钥创建多个密钥，特别是包装密钥和内存保护密钥）。

此外，表示安全熔断器的原始数据在CSME内存中存储的时间非常有限，位于CSME硬件域中的CSE熔断器提取器（FP）设备负责从熔断器控制器（如上所述）获取它们。

FP设计为在CSME子系统重置后立即处于工作状态，使其能够请求安全熔断器，这一请求由CSME ROM完成。在从熔断器控制器获取安全熔断器后，FP将其存储在其内部内存中，并允许CSME ROM通过MMIO机制访问它们。

CSME ROM将安全熔断器从FP读取到本地SRAM内存中，使用熔断器加密密钥对其进行解密，并将结果直接放入SKS中。这个过程在下一章中将更详细地描述，展示了OCS架构中的一个缺陷，允许提取FEK。在这里，我们强调，CSME ROM在生成第一层密钥层次结构（各种模块/机制的根密钥，如包装密钥、IVB根密钥或英特尔/非英特尔根密钥，其中一些甚至不依赖于安全版本号（见[2]，第15页，注释“熔断器被锁定后……”和段落“ROM可以从芯片组密钥创建多个密钥……”，以及下面关于供应密钥的段落））后，执行清除FP的程序，将其内部内存中的安全熔断器归零，然后阻止FP，防止后续请求熔断器控制器。

因此，所有后续的CSME固件模块，即使是以内核模式（零特权级x86）运行的模块，如rbe和内核，也对FP设备具有物理访问权限，但无法再请求安全熔断器，因为FP已被阻止。因此，任何固件模块中的漏洞都无法访问FP，因此无法访问安全熔断器，而只能访问派生加密密钥，这些密钥在漏洞修复后完全更新，并且安全版本号被递增，因为SVN值被用作生成这些加密密钥过程中的初始数据的组成部分之一。只有在CSME ROM中的假设错误，在相当有限的代码区域，才允许访问存储在FP中的加密安全熔断器。

这种保护方法显示了安全熔断器在安全角度上的关键资源性——整个安全模型基于它们，如果它们被提取（并解密），那么后续生成的新SVN的派生密钥将不再有意义（攻击者可以为任何SVN重新计算它们），安全性将受到损害，且无法恢复。

在此背景下，值得注意的是CSME固件中的一个特殊模块，称为英特尔调试启动模块（IDLM）。

该模块是上述一般规则的例外：当其运行时，CSME ROM不会阻止或清除FP内存，从而为该模块提供对安全熔断器的访问。同时，IDLM模块不包含在英特尔分发给平台开发者（OEM、ODM）的库存生产固件中。我们认为IDLM旨在用于平台调试，仅由英特尔工程师用于查找硬件故障的原因。尽管我们从未遇到过实际的IDLM模块，也未研究其所有功能，但我们可以毫不夸张地说，其固有属性——对安全熔断器的潜在访问，使IDLM成为一个真正的后门：英特尔工程师可以从任何平台提取安全熔断器，拥有本地甚至可能的远程访问（通过英特尔CSME固件更新机制），从而解密使用英特尔固件TPM（fTPM）的用户数据，该TPM在PTT（平台信任技术）固件模块中实现，作为加密密钥存储。

因此，我们认为，IDLM机制在迄今为止发布的所有英特尔平台中的存在，是反对将英特尔fTPM用作软件产品（如微软BitLocker）加密密钥存储的有力论据。

允许访问安全熔断器的漏洞

截至目前，已知有两个漏洞允许以加密形式提取安全熔断器。这些漏洞各自具有有限的受影响平台集，以及根本性修复的不可行性——本质上，英特尔为每个漏洞发布的修复是一组“补丁”，旨在尽可能降低成功利用它们的风险。只有在较新的平台（基于新微架构）中，这些漏洞才在硬件级别上得到了完全修复。让我们快速看一下每个漏洞：

1. CVE-2019-0090。CSME系统代理的IOMMU硬件漏洞。描述在英特尔安全公告INTEL-SA-00213中[5]。英特尔发布了一份单独的白皮书[6]，详细说明了该漏洞的技术方面：问题的本质、受影响的平台、成功利用的后果以及防止方法。由于英特尔通常不披露已发布漏洞的技术细节，因此在这种情况下对这一做法的例外显示了CVE-2019-0090的严重性，即访问加密安全熔断器的可能性。然而，尽管在[6]中并不明显，但在利用所描述的漏洞时，无法直接访问熔断器加密密钥（FEK）——FEK是在卸载和加密子系统硬件模块内部生成和使用的（将在下一章中描述），CSME并不直接处理其二进制数据，而是通过对安全密钥存储的命令进行操作，其中存储了FEK。因此，CVE-2019-0090仅允许突破英特尔CSME安全模型的第一层，如前一章所述。然而，我们后来发现了SKS模块中的一个硬件缺陷，允许在SKS被清除之前提取FEK。这个缺陷将在下一章中详细描述。通过利用一系列漏洞，CVE-2019-0090与SKS密钥不安全性结合，使得完全破坏CSME成为可能，即访问所有受影响平台上的解密芯片组密钥、EPID根密钥和其他密钥（见上文“英特尔CSME安全信任根”章节）。值得注意的是，利用此CSME系统代理IOMMU漏洞并非易事。尽管我们成功地在Cannon Lake平台上利用了此漏洞并以此方式提取了CSME ROM，但由于漏洞的性质——设备初始化期间的竞争条件（见[6]，第6页关于CVE-2019-0090的段落），创建一个有效的概念验证（PoC）以访问安全熔断器对我们来说似乎很困难。稍后，我们发现了一个更“稳定”的漏洞（如下所述），允许访问安全熔断器，因此我们将精力集中在利用新漏洞上。因此，目前CVE-2019-0090的PoC问题仍然开放，尽管考虑到接下来将讨论的漏洞，这已不再有太大意义。

1. CVE-2021-0146。此漏洞由英特尔在安全公告 INTEL-SA-00528 [7] 中描述。它允许从基于 SoC Atom Apollo Lake 代的设备（CPUID 506C9、506CA 和 506F1）中提取安全熔丝。尽管英特尔还指出更新的 SoC Gemini Lake 和 Gemini Lake Refresh 也容易受到此漏洞的影响，但最初的概念验证（PoC）在 Gemini Lake/Refresh 上并不适用。此漏洞的本质是一种电压故障注入类型的硬件攻击，允许干扰控制平台调试解锁级别的内部 DFX 聚合器设备的逻辑（红色和橙色，见 [4]，第 6 页）。DFX 聚合器管理 DFX 安全策略，该策略通过 DFX 调试总线传输到平台上每个存储重要安全数据（平台资产）的设备。这些数据包括存储在熔丝控制器设备中的 CSME 安全熔丝（见“英特尔 CSME 安全信任根”一章）。DFX 聚合器的设计使得在红色或橙色模式下调试解锁后，或在激活延迟认证模式（DAM，见 [4]，第 6 页，“下表中指示了四个主要的 DFX 策略级别”）后，DFX 安全策略被固定，以至于在不完全关闭平台的情况下无法返回到初始的锁定状态（绿色）。否则，在调试模式下，可以对设备的硬件配置进行更改（例如，更改 SAI 访问掩码），这将允许在返回到绿色/锁定模式后访问平台资产。然而，通过电压故障注入，可以对 DFX 聚合器设备进行硬件重置，然后利用其内部机制的某些特性，创建一种情况，使 DFX 安全策略返回到绿色/锁定状态，但在调试模式下所做的硬件更改（DFX 安全策略为红色时）不会被重置。

   我们计划发布一份单独的白皮书，详细描述基于电压故障注入的硬件攻击的细节，但就本研究而言，仅需说明此攻击完全使用平台的内部手段进行，而不使用外部电源、设备或物理修改系统的印刷电路板。在红色解锁模式下，集成电压调节器 LDO（采用低压差电路实现）VNNLDO 通过访问平台的电源管理控制器（PMC）微控制器进行编程。该 PMC 微控制器在红色解锁模式下通过连接到直接控制接口（DCI）的 JTAG 调试接口完全控制。在重置 DFX 安全策略后，修改后的硬件环境允许访问安全熔丝，因为熔丝控制器继续响应来自 CSME 的请求提供它们，而不识别到妥协，因为系统再次在绿色/锁定模式下运行。CVE-2021-0146 的初始 PoC 使用英特尔的 VISA（内部信号架构可视化，见 [8]）技术捕获熔丝控制器与 CSME 域中的熔丝提取器之间交互的调试跟踪，其中包括通过 IOSF SB 总线传输安全熔丝。由于可以使用英特尔 VISA 技术分析的内部硬件信号集是平台特定的（对于基于英特尔 Core 处理器的桌面平台，VISA 信号列表不包括 IOSF SB 总线数据信号），因此此 PoC 最初仅限于基于 Atom 的平台：Apollo Lake 和 Gemini Lake/Refresh。然而，对于 Gemini Lake/Refresh，英特尔从最初的产品版本开始就对某些英特尔 VISA 功能进行了硬件限制，使得在绿色/锁定模式下原则上无法获得 IOSF SB 总线数据信号。英特尔工程师严格阻止在所有 Gemini Lake/Refresh 平台上使用一种称为安全访问位的特殊机制，使得 PoC 无法正常工作。然而，主要问题——DFX 聚合器对电压故障注入攻击的脆弱性——并未得到修复，因为这需要对基于 VNNAON 的该 IP 块的电源子系统进行完全重新设计，而这在新的晶体版本框架内是不可能的，只能在新平台中重新设计电路图后实现。

   因此，我们创建了一个新的概念验证（PoC），它不使用英特尔的 VISA 来捕获 IOSF SB 总线的跟踪，而是允许在 CSME ROM 清除之前访问 CSME 熔丝提取器的硬件寄存器。这使得在 Gemini Lake/Refresh 平台上也能够获取安全熔丝。然而，访问加密的安全熔丝并没有立即导致平台的完全妥协，因为用于加密它们的密钥（熔丝加密密钥）并不存储在 CSME 内存中，而是存储在一个称为安全密钥存储的特殊设备中，该设备在没有直接访问其二进制数据和不将其传输到 CSME RAM 的情况下处理加密密钥。因此，似乎 CSME 安全模型实际上是有效的：安全熔丝被提取，第一层保护被绕过，但平台并未被妥协，因为实际的加密密钥无法获得。

   但不幸的是，SKS 的实现中存在一个严重缺陷，允许提取熔丝加密密钥的二进制数据，从而解密安全熔丝，这已经意味着平台的完全妥协。此外，由于熔丝加密密钥对于每个晶体实例并不唯一，而是对所有 Apollo Lake 系统相同，并且对所有 Gemini Lake/Refresh 系统也是如此，因此只需在每个微架构的一个代表上绕过 CSME 安全模型的第二层，这正是我们在本研究中所做的，我们还发布了 Apollo Lake 和 Gemini Lake/Refresh 的熔丝加密密钥。下一章将对此进行讨论。

OCS (Offload and Crypto Subsystem)模块架构中的漏洞可以泄漏熔丝加密密钥

英特尔CSME的子系统除了其固件外，还包括一个硬件组件，该组件由一组设备（IP块）组成，这些设备实现了CSME在硬件层面上运行所需的某些功能。CSME的硬件环境与集成到平台中的其他设备（如PCI-E、USB和SPI控制器）隔离，只有通过运行CSME固件的微控制器的地址空间（物理内存）才能直接访问它们。某些CSME设备也可以通过主处理器（主机）的地址空间访问，但只能通过一个称为ATT（地址转换表）的特殊桥接器进行，该桥接器在主机的PCI配置空间中表示这些设备。

英特尔CSME子系统中的一个设备是卸载和加密子系统（OCS），它为CSME的软件组件提供加密功能和基于DMA（直接内存访问）的内存复制机制。OCS中的加密和DMA机制是以硬件形式实现的，这大大加速了在相对较弱的微控制器（Minute IA，一种与x86兼容的微处理器，采用Lakemont微架构，其计算能力大致相当于1990年代的英特尔486）上执行固件的速度。下图来自[2]（第12页，图2，硬件架构概念图），展示了OCS在CSME域中的位置。

Figure 4. CSME hardware environment

OCS的内部实现是非同质化的，因为它不是一个单一的IP块，而是一组通过称为OCP（开放核心协议）的特殊总线相互作用的IP块。OCP总线是OCP-IP（开放核心协议国际合作伙伴关系[9]）工作组的开放标准，受Accellera系统倡议的管理。OCP的主要目的是为独立公司开发的IP块提供统一的接口。如前所述（见第1章，描述CSME安全架构），英特尔处理器和芯片组中的集成设备通过一种称为IOSF（英特尔片上系统结构）的专有（在规范方面）总线相互作用，而不是PCI/PCI-Express总线。因此，OCS选择非单一设计和开放的OCP总线，表明OCS中的加密IP块可能是由第三方公司开发的，可能使用了可供硬件逻辑开发者使用的商业硬件库。或者，英特尔可能将OCS设计为可供第三方使用的组件，这也解释了选择模块化架构和开放接口的原因。

无论如何，正如下面将要展示的，OCS的非单一设计和IP块之间所需的交互方式导致了一个严重的架构问题，这一问题在OCS的实现过程中被英特尔工程师忽视。这个架构缺陷导致了一个漏洞，使我们能够提取Fuse加密密钥，并完全破坏英特尔CSME的安全模型。

OCS由以下设备组成：

• AES_A和AES_P：两个实现对称加密的IP块，使用AES算法，一个用于一般的CSME固件任务，另一个用于作为页面管理（Paging）机制一部分的页面加密和解密操作。AES_P具有支持代码/数据页面完整性控制值（ICV）的附加功能。

• HCU（哈希控制单元）：实现SHA256/348哈希算法和基于SHA的HMAC（基于哈希的消息认证码）算法的设备。

• RC4：RC4对称加密协议的实现。

• GPDMA：执行与加密无关的DMA操作的IP块。

• EAU：实现RSA-2048/3096非对称加密算法以用于数字签名实现的模块。

• SKS（安全密钥存储）：一个模块，允许在OCS中存储加密密钥，而无需通过CSME内存交换二进制数据，并使用包含相应密钥的整数槽号对其进行操作。

• Bridge：一个特殊的桥接器，将OCS的内部OCP总线连接到CSME硬件环境的IOSF总线。

这些设备在OCP总线上都有专用的地址范围，用于编程由设备实现的硬件功能。例如，HCU IP块的硬件寄存器可在地址0xB000-0xC000访问，而AES_A保留的地址为0x8000-0x9000，AES_P的地址为0xA000-0xB000，SKS可在地址0xF000-0x10000访问，如下图所示，该图来自用于模拟英特尔平台的Wind River Simics软件。

   Figure 5. Intel OCS integrated devices and their address ranges on the OCP bus

OCS的加密模块（即执行根据特定算法进行编码、解码和哈希功能的设备，如AES、HCU和EAU）在其地址空间中包含一组寄存器，用于设置初始加密/认证密钥。在执行加密/解密/哈希请求之前，英特尔CSME固件会设置初始密钥，以实现确保基于密码学的认证和机密性的机制。

Figure 6. Setting the initial encryption key in CSME firmware

OCS加密模块的硬件寄存器用于设置加密密钥，仅可进行写入访问。因此，即使恶意代码破坏了CSME固件并获得了对OCS地址空间的访问，最后一次加密操作中使用的加密密钥也无法被提取。然而，OCS并未对写入密钥数据的顺序施加任何硬件级别的限制。因此，CSME固件可以以任意顺序传输密钥数据，针对几个字节或逐字节地对寄存器进行写入操作。也就是说，每个4字节寄存器（或某些加密模块的单字节寄存器）根据其地址包含特定的密钥字节，保留来自最后一次写入操作的数据，CSME固件通过多次写入硬件密钥寄存器来形成密钥，直到传输完整的16或32字节密钥，具体取决于所使用的算法。在执行加密操作请求时，可以在直接使用该寄存器之前多次重写同一寄存器地址。OCS加密模块的这一硬件特性（能够对密钥寄存器进行多次写入）在CSME固件是唯一拥有原始加密密钥的实体时不会造成任何安全问题，因此其代码有权以任何方式形成该密钥。然而，当加密密钥不是由CSME固件设置，而是由OCS自身建立时（这一情况将在下文中讨论），这一特性会导致一个严重的安全问题，因为它允许通过重写其单个字节来猜测已建立的密钥（并对已知数据执行相应的加密操作）。这种对加密密钥的攻击可以被视为已知明文攻击的一种变体[10]，攻击者控制着明文和密文，以及大部分加密密钥，而直接暴力破解未知部分密钥的复杂性取决于重写的粒度，即可以在设置加密密钥的硬件寄存器中重写的最小数据长度。对于AES_A和AES_P加密设备，密钥重写的粒度为一个字节，如果密钥大小为32字节，则找到加密密钥的复杂性将是256*32次加密文本的比较。对于HCU加密模块，密钥重写仅能以4字节字的形式进行，找到32字节密钥的复杂性将是(2^32) * 8次比较。

如果我们仔细检查图1中生成根加密密钥的方案，就会发现CSME固件无法直接访问安全熔丝加密密钥（Fuse Encryption Key，或图中的HW Key），也无法访问由该密钥解密的芯片组密钥。为了在OCS中生成和存储这些密钥，有一个特殊的设备称为安全密钥存储（SKS）。从图中可以看出，SKS基于两个组件生成FEK密钥：一个384位的硬件向量和一个128位的ROM向量。这两个组件经过称为HW Shuffle的过程，生成一个128位的FEK密钥。该密钥仅存在于SKS中，CSME固件无法访问其二进制数据：它可以通过传输不同的ROM向量来修改它，但并不知道生成的密钥，因为它无法访问嵌入在SKS硬件逻辑中的硬件向量。同时，SKS命令接口使用密钥的数字标识符——存储相应密钥的单元或槽的地址来操作加密密钥。FEK密钥始终存储在槽1中。然后，SKS可以使用其标识符将密钥从任何槽传输到指定的加密模块（AES或HCU），并可以从加密设备中提取加密操作的结果并放置在指定的槽中。因此，CSME固件通过请求必要的SKS操作并操作槽标识符，无法访问存储在相应槽中的密钥的二进制数据。需要注意的是，CSME固件可以将其拥有的密钥字节直接传输到SKS槽（对此有相应的命令），但正是SKS与OCS的加密设备交互的能力，绕过CSME，使得构建安全的根加密密钥生成方案成为可能，这也是SKS创建的初衷。然而，正如我们在开头提到的，尽管安全模型没有引发任何担忧，但其实现包含关键错误，我们希望更详细地分析这些错误发生的原因。

为了演示这个问题，让我们更详细地考虑SKS与加密模块之间的交互。因此，为了将密钥传输到加密设备以及从中提取数据，SKS必须能够以某种方式对OCS加密模块的硬件寄存器执行读写操作。在单一的OCS设计中，组织这样的事务可以在内部RTL逻辑层面上轻松完成。然而，在我们的情况下，由于每个OCS设备都是一个独立的硬件模块，具有连接到公共总线的各自接口，SKS被迫使用OCP总线上的标准读/写内存事务来写入和读取加密设备的MMIO。同时，它可以访问与CSME固件相同的设备接口（即一组寄存器），而唯一将SKS与CSME区分开来的，是根据OCP总线协议提供的唯一设备标识符。显然，加密设备需要对SKS提供特殊支持，以区分其事务并赋予其比CSME更高的权限，否则，冲突是不可避免的，这无疑会影响SKS与加密设备之间交互的安全性。所有这些都大大复杂化了OCS内部设备的硬件逻辑，这些设备必须清晰划分访问寄存器的优先级和顺序，通过这些寄存器设置加密操作的密钥。因此，我们看到，放弃单一的OCS设计使得设备在安全性最关键的领域（即传输秘密数据，如加密密钥）中的逻辑变得复杂。最终，为了保护SKS密钥，加密模块引入了一种特殊的操作模式，即SKS模式。

Figure 7. VISA signals for HCU demonstrating the presence of SKS mode

图7显示了OCS中HCU加密设备的一部分内部信号，这些信号可以通过英特尔VISA技术进行分析。我们看到一个名为sks_mode的信号，当该模式被激活时，其值为1。通过对该信号的运行时分析，我们确定当使用来自SKS的请求向包含加密密钥的HCU寄存器写入第一个4字节数据时，该信号被激活。同时，如果HCU处于SKS模式，从CSME侧对密钥寄存器的任何写入都会导致HCU退出SKS模式并清除来自SKS的当前密钥。non_secured_key_wr信号的值变为1，并保持激活状态，直到通过HCU状态寄存器显式重置。这意味着对覆盖秘密密钥的保护已实现并正常工作。然而，从图5所示的信号可以得出结论，SKS模式不仅意味着密钥保护，还防止任何OCP客户端（除了SKS）读取输出数据，这些数据是执行加密操作（在我们的案例中是根据SHA算法的哈希计算）时的结果。在HCU硬件逻辑中，这由read_chains_allowed信号处理，该信号在SKS模式下的值为0（禁止读取）。因此，只有SKS可以使用OCP总线读取事务读取加密设备的结果数据，如果read_chains_allowed信号为0。当然，在HCU的SKS模式不活跃的情况下（当原始HMAC密钥由CSME固件设置时），SKS也可以读取输出数据。在这两种情况下，结果数据被放置在指定的SKS槽中，并可以在后续的加密操作中用作密钥。在这里，我们遇到了OCS的一个严重架构问题：CSME无法获取使用来自SKS的密钥执行的加密哈希操作的结果。尽管这种保护在某些情况下是必要的，例如在密钥派生过程中，当通过使用基础密钥处理附加数据生成新密钥时，但在其他情况下应用加密操作（例如，哈希CSME固件的运行时数据以检查其完整性）时，需要放弃SKS模式，因为结果哈希必须以某种方式读取到CSME内存中以供后续使用。

这导致了一个大问题：如果原始密钥必须保护以防止CSME访问，但在使用过程中获得的数据必须可访问，该怎么办？答案是：HCU加密模块的SKS模式并不适用于这种应用，必须放弃该模式。但是在这种情况下如何保护加密密钥呢？英特尔工程师找到了解决方案：他们在SKS中添加了一种安全密钥和非安全密钥的模式，但这实际上并没有解决任何问题，因为传输非安全密钥的SKS事务不会激活HCU中的SKS模式，这导致CSME侧可以覆盖已建立的密钥（如上所述，CSME有权覆盖其密钥的字节）。正确的解决方案应该是在SKS模式下分离对加密密钥的覆盖保护和读取结果数据的可选可能性，但HCU并未实现此功能。值得注意的是，AES_A/AES_P加密设备确实允许读取使用SKS密钥获得的结果编码/解码数据，并保护它们不被覆盖，因此HCU中缺乏这一高度需求的功能强烈暗示了OCS的非英特尔设计。

因此，我们已经识别出SKS的主要问题：其部分密钥，即存储在非安全槽中的密钥，尽管从SKS命令接口的角度来看对CSME不可访问，但实际上可以通过应用已知明文攻击的变体轻松提取，并且可以在AES_A、AES_P和HCU加密设备中覆盖密钥。这是一个架构问题，存在于硬件层面，即无法通过对CSME固件进行更改来修复。

在图1中，对于每个密钥，左侧列出了其属性，其中之一是安全模式（Secure Mode），该属性控制在使用此密钥时加密设备的SKS模式，如上所述。这些SKS槽属性，包括特权级别（Privilege Level）、锁定（Locked）和安全模式（Secure Mode），在每次将新密钥添加到指定槽时设置：当它由SKS自身生成时（FEK的情况）、当数据直接从CSME固件传输时，以及当加密操作的结果数据用于创建新密钥时（例如，密钥派生或密钥解密）。

然而，图1清楚地显示，对于FEK（HW Key，槽#1）和芯片组密钥（槽#12，图1中的槽#0标记不正确），安全模式属性均等于0——这是第二个架构错误，破坏了整个CSME安全模型，因为它允许提取FEK。根据文档[6]（第14页，段落——安全密钥存储（SKS）硬件的使用），FEK不能具有安全模式属性，因为它不仅用于解密芯片组密钥（安全熔丝的前32字节），还用于解密EPID私钥，后者也是安全熔丝的一部分。同时，使用EPID私钥的加密操作在OCS中不受硬件级别的支持，因为它们是根据椭圆曲线数字签名算法（ECDSA，Elliptic Curve Digital Signature Algorithm，见[11]）执行的，并在软件层面实现，即EPID私钥必须读取到CSME内存中。但这个论点并不正确，无法证明FEK选择不安全模式的合理性，因为AES设备的结果数据可以安全地读取回CSME内存！在这里，我们可以看到英特尔CSME固件开发人员与硬件工程师之间缺乏协调：不安全的密钥仅用于HCU加密操作，在其结果必须读取到CSME内存的情况下，而对于直接通过AES解密获得的EPID私钥（使用FEK对其安全熔丝部分进行解密），则并非如此。

英特尔在文档[2]（第15页，注释1）和[6]（第11页，段落“注意熔丝加密硬件密钥...”）中简单地声明，FEK并不旨在保护芯片组密钥和EPID私钥免受CSME ROM的访问。即使如此，不安全的FEK最可怕的后果是可能从SKS中提取它，这与我们在第2章中讨论的安全熔丝的妥协一起，完全摧毁了英特尔CSME的安全模型。在我们的研究中，为了提取FEK，我们使用了AES_A加密设备，并成功在英特尔Apollo Lake和Gemini Lake平台上恢复了FEK。以下是证据：

Figure 9. FEK extraction on the Gemini Lake platform

如果我们谈论导致这种致命缺陷出现的原因，那么在理解我们后续陈述的推测性特征的同时，我们仍然会尝试回答这个紧迫的问题：像英特尔这样拥有丰富可靠硬件设计和开发经验的公司，为什么在其平台上无法实现从安全角度来看最关键的子系统之一的安全性？

因此，我们看到导致不安全FEK及其结果——英特尔CSME完全妥协的以下原因：

1. 开发CSME子系统硬件环境的英特尔工程师团队决定使用第三方库来实现加密的硬件支持，但该库并未完全满足必要的功能标准。具体而言，它不支持ECDSA椭圆曲线加密算法，并且为HCU加密设备提供的SKS模式不便，仅适用于密钥派生过程，而不适用于使用完整性密钥进行普通数据哈希。

2. 决定在SKS设备中添加非安全密钥模式，以支持基于SHA算法的加密操作，这些操作使用CSME固件的普通数据，而这些操作并未使用为库的加密设备实现的SKS模式。

3. 安全架构师忽视或简单地忽略了库的加密模块在未激活SKS模式的情况下不提供对原始密钥的保护，因此SKS的非安全密钥模式非常危险，应该仅在派生密钥的情况下谨慎使用。实际上，完全不在SKS中设置非安全密钥模式，并直接在CSME内存中存储具有此类要求的密钥会更为正确，以免误导固件开发人员。

4. CSME固件开发人员错误地选择了FEK的非安全SKS模式。他们错误地认为，AES加密设备类似于HCU设备，阻止将结果数据读取到CSME内存中。实际上，AES设备允许这种使用。开发人员本可以简单地为FEK选择安全SKS模式，而没有任何功能限制，从而防止本文中描述的灾难性后果。他们声称FEK并不旨在保护芯片组密钥免受CSME ROM的访问，但他们忽视了一个关键点：他们将FEK本身置于风险之中，FEK并不是每个SoC/系统逻辑芯片唯一的，而是所有版本的CSME固件在相同ROM向量下都是相同的。这意味着FEK在属于同一代的所有平台上都是相同的，其妥协不仅意味着特定平台实例的问题，还意味着该系列所有芯片的问题。

最后，需要指出的是，在可以执行任意代码和妥协安全熔丝的旧平台上，英特尔CSME完全被妥协（参见SA-00086、SA-00213和SA-00528）。然而，较新的系统也容易受到上述FEK架构缺陷的影响。如果发现新的漏洞允许在CSME内执行代码，这可能会变得至关重要。还应注意，上述公告中提到的被妥协系统现在应被视为不安全，所有软件补丁对安全熔丝和FEK的妥协无能为力。尽管这些平台不再生产并且官方已进入生命周期结束（End-Of-Life），但许多仍在嵌入式系统中被积极使用，影响来自不同供应商的平台。

引用

1. Trusted Platform Module Library Specification, Family “2.0”, Level 00, Revision 01.83. https://trustedcomputinggroup.org/resource/tpm-library-specification. March 2024

2. Intel Corp. Intel® Converged Security and Management Engine (Intel® CSME) Security, Technical White Paper. https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/intel-csme-security-white-paper.pdf. Oct. 2022

3. Patent Application Publication US 2013/0138858 A1. PROVIDINGA SIDEBAND MESSAGE INTERFACE FOR SYSTEM ON A CHIP (SOC). May 2013

4. Intel Corp. The Intel® Converged Security Management Engine (CSME) Delayed Authentication Mode (DAM) vulnerability – CVE-2018-3659 and CVE-2018-3643, White Paper. https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/the-intel-csme-dam-vulnerability-cve-2018-3659-and-cve-2018-3643-whitepaper.pdf. Jun. 2020

5. Intel Corp. INTEL-SA-00213. Intel® CSME, Intel® SPS, Intel® TXE, Intel® DAL, and Intel® AMT 2019.1 QSR Advisory. https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00213.html. May 2019

6. Intel Corp. The Intel® Converged Security Management Engine IOMMU Hardware Issue – CVE-2019-0090 and CVE-2020-0566, White Paper, Version 1.1. https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/cve-2019-0090-whitepaper.pdf. Jun. 2020

7. Intel Corp. INTEL-SA-00528. Intel® Processor Advisory. https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00528.html. Sep. 2021

8. M. Ermolov M. Goryachy. Intel VISA: Through the Rabbit Hole. https://i.blackhat.com/asia-19/Thu-March-28/bh-asia-Goryachy-Ermolov-Intel-Visa-Through-the-Rabbit-Hole.pdf. 2019

9. Accellera Systems Initiative. Download the OCP (Open Core Protocol) Specification. https://accellera.org/downloads/standards/ocp. 2024

10. Wikipedia. Known-plaintext attack. https://en.wikipedia.org/wiki/Known-plaintext_attack. Jan. 2024

11. Don Johnson, Alfred Menezes and Scott Vanstone. The Elliptic Curve Digital Signature Algorithm (ECDSA). https://www.cs.miami.edu/home/burt/learning/Csc609.142/ecdsa-cert.pdf. 2001

原文始发于微信公众号（赛博堡垒）：摧毁x86最后堡垒：Intel电熔丝e-Fuse加密密钥泄漏