Last barrier destroyed, or compromise of Fuse Encryption Key for Intel Security Fuses

Introduction

As experts who have spent years researching the security of hardware platforms developed by Intel, we acknowledge that Intel’s Converged Security and Management Engine security architecture is highly reliable and was designed by top-notch professionals.

From an architectural perspective, if all its individual components function as intended, it is challenging to find a vulnerability, that, even hypothetically, could lead to irreparable consequences, calling into question the correctness of the decisions made.

Undoubtedly, Intel’s confidence in the reliability of its lowest-level protection, also known as the Root of Trust (RoT), can be attributed to the highest level of privileges granted to the Intel CSME subsystem, including unrestricted access to memory and hardware containing user data. This RoT is based on cryptography, specifically the skilled application of asymmetric and symmetric encryption algorithms, to ensure the confidentiality and integrity of the executable code and data of Intel CSME and other platform subsystems.

Our goal is not to reiterate the security of Intel CSME, as Intel has already done so in a dedicated document that thoroughly examines their security architecture, starting from the lowest level (root encryption keys) and covering topics such as module integrity control, remote attestation, and the Trusted Platform Module (TPM, [1]).

In this study, we intend to delve into specific details and demonstrate how incorrect implementation and inconsistent use of otherwise correct and secure mechanisms, in the context of the overall security model, can lead to severe consequences, allowing access to root encryption keys and rendering the security model ineffective.

It is essential to note that, since the primary objective of the proposed security model is to guarantee the infeasibility of accessing root encryption keys, an incorrect implementation of this model renders its current application meaningless, at least until the flaws discussed in this study are addressed, which, as will be shown below, is only possible in new platforms, as the incorrect implementation is hardcoded in non-reprogrammable memory and serves as the architectural foundation for some fundamental mechanisms embedded in the Intel CSME firmware.

In our study, we will frequently refer to the document describing Intel CSME security [2], using its terminology, concepts, and diagrams.

Intel CSME’s Root of Trust

The Intel CSME security architecture is based on two fundamental elements that form an unbreakable foundation, which should not be compromised under any circumstances. If this foundation is damaged, the entire “building” will collapse, and there are no mechanisms to prevent this from happening. These two root elements have different purposes but complement each other, and only their complete compromise makes it possible to bypass all the defense mechanisms embedded in the Intel CSME security model.

These are the two elements on which the Intel CSME Root of Trust is based:

1. Security Fuses, which are unique to each crystal instance, whether it’s a chipset or a System-on-Chip (SoC). They are generated by a special entity called the Key Generation Facility (KGF), which ensures their uniqueness, confidentiality, and integrity until they are programmed into the crystal’s One-Time-Programmed (OTP) configuration. The KGF is likely to be a secure server connected to the factory programmer via a secure channel, operating at the final stages of the High-Volume Manufacturing (HVM) process.
2. The Fuse Encryption Key (FEK), which encrypts the Security Fuses using the symmetric encryption algorithm AES before they are written to the OTP configuration. This key is not unique and is shared among all instances of a particular microarchitecture. For example, all chipsets of the Tiger Point generation or all SoCs of the Goldmont microarchitecture share the same FEK.

Figure 1 illustrates the Security Fuses and the Fuse Encryption Key, as well as their place in the overall hierarchy of encryption keys that implement various mechanisms and ensure the security of Intel CSME. This figure is based on an Intel document [2], page 15, Figure 4, “Keys Derivation Conceptual Key”.

In the figure above, the Security Fuses are represented by a red rectangle on the right with labeled “Chipset Key Fuses (256 bit)”. However, the Chipset Key Fuses are only part of the Security Fuses, which also include fuses for the EPID Private Key, EPID Group ID, PTT Endorsement Key Counter, and Debug Enabled Chipset Key (see [2], Section 4.1.1.1, “The Fuse-Encryption Hardware Key, the Chipset Key and its Derivatives”).

It’s not hard to guess that these root encryption keys form the foundation of trust for the technologies implemented in Intel CSME, which Intel confidently presents in various presentations, without any doubt about the possibility of their compromise. In fact, the phrase “hardware root of trust” is intended to inspire confidence in the average user, who is not familiar with the details of the implementation and operation of hardware components, and to make the public believe that the reliability of hardware is always higher than that of software systems. But is this really the case?

Let’s look at the main points that make up the protection of the Security Fuses.

Figure 1 only shows that the Chipset Key Fuses are inputs for an AES decryption procedure with a 128-bit encryption key (blue circle with the number 4), but it omits all the details related to the storage and extraction of the binary data that make up the Security Fuses. It is precisely the implementation of these specific details that makes or breaks the security of both the Security Fuses and the entire platform.

The security of the Security Fuses is based on:

1. The use of One-Time-Programmed memory, based on E-FUSE technology, to program the Security Fuses into the crystal. At the photolithography stage, the E-FUSE schematics are presented in an initial (unprogrammed) state, allowing the writing of any binary data – both zeros and ones. At one of the final stages, which takes place during the fabrication of the processor or system logic chip on the factory conveyor, the OTP configuration is written using industrial programmers that are electrically connected to the contacts of the finished chip. This allows a unique configuration to be set for each crystal instance, which is exactly what is required to assign the generated Security Fuses to each chip.

Once the E-FUSE data is written, it cannot be rewritten because the programming process causes the internal conductors on the crystal to burn out due to the passage of high current generated by the E-FUSE controller. This controller, called the Fuse Controller, is responsible for both programming the Security Fuses and securely reading and transmitting them to the required hardware module, which is authorized to request them.

2. The encryption of the Security Fuses immediately after they are generated in the Key Generation Facility.

This level of protection keeps the data secure: first, during the transmission from the KGF to the HVM conveyor at the factory, and, second, in the event that the Security Fuses are extracted from a working chip instance using reverse engineering techniques. Attackers will not be able to use the root keys that make up the Security Fuses to decrypt the working data of the Intel CSME firmware (which was once executed on the chip that underwent such analysis), since this requires knowledge of the encryption key of the Security Fuses themselves.

This key, called the Fuse Encryption Key or simply the Hardware Key in Figure 1 (red rectangle on the left, marked with an arrow), is itself an important element of the Intel CSME security model, as mentioned above, and Intel uses special methods to protect it, which will be described separately below.

The previously mentioned reverse engineering techniques are based on the use of scanning electron microscopes (SEM) and layer-by-layer analysis of the CMOS elements that make up the logic of the silicon crystals, which can detect the programmed E-FUSE data because their burnt-out conductors change their structure in a way that is visible under an electron microscope (see Figure 2).

Although such analysis is more complex than reverse engineering of hardware logic or reading ROM data of integrated circuits, it is quite possible with the appropriate skills and high-resolution equipment.

It should be noted that such analysis is destructive in its nature and renders the microchip inoperable, but the extracted encryption keys (if they are stored in E-FUSE in plaintext) can be used to gain access to information created using this chip, as well as to impersonate it — that is, to emulate this chip in internet services based on remote authentication, in order to gain access to protected data intended exclusively for controlled use on genuine Intel equipment, in technologies such as DRM. These technologies do not deliver the protected data to users, but rather transmit it directly to hardware playback devices, allowing users to view the data, but not copy it.

3. A centralized mechanism, implemented in the Fuse Controller hardware logic, which processes read requests and transmits the Security Fuses to internal devices within the Intel CSME subsystem.
This platform device is located outside the Intel CSME domain, as it not only provides and protects the Security Fuses but also performs the function of storing configuration information for devices (hardware OTP configuration). Not only devices within the Intel CSME subsystem but also main platform devices, such as CPU cores, memory controllers, USB controllers, and others, have their own OTP configuration, which is programmed at the final stage of Intel chip production.

Furthermore, some devices, such as CPU cores and the power management microcontroller (PCU or P-UNIT), also use encryption and store their root keys in OTP memory, for example, to implement the Intel Software Guard Extensions (Intel SGX) technology.
Therefore, the Fuse Controller IP block is a common device that is accessible to all platform devices with specific configuration requirements.

This configuration information is transmitted over a special service bus called the IOSF Side Band.
IOSF, which stands for Intel On-chip System Fabric, is a proprietary specification for several data buses and protocols that devices use to interact with each other within Intel platforms. This set of IOSF buses (including IOSF Primary, IOSF Side Band, and IOSF DFX) has replaced the PCI Express bus for implementing internal interaction between IP blocks within a single crystal. Initially developed for ultra-mobile platforms (based on the Intel Atom SoC), the IOSF specification quickly became the primary communication mechanism for both system logic chipsets and processor crystals in desktop and server systems.

As a result, all Intel platforms released to date are based on IOSF, and the PCI Express bus is now used only to connect external devices to the platform.

Within the IOSF bus, each device is assigned a unique identifier, the SAI (Security Attribute of Initiator), which remains the same for the same device even across different platform types. For example, the ATT bridge from the Intel CSME domain to the main platform devices always has an SAI of 0x20 (in DFX Green/Locked mode) on both Atom and desktop/server platforms.

In addition to the SAI, each device connected to the IOSF Side Band has a unique Port ID, which is used for packet routing purposes.

However, the Port ID of devices on the IOSF SB does not match for different platforms and processor/chipset models. Thus, the SAI identifies the device for security and access control purposes, while the Port ID is used for addressing on the bus.

It should be noted that there are special bridges on the IOSF SB, for example, between the processor and the chipset, which convert the Port ID according to predefined tables, but the SAI of device requests remains unchanged during such conversion.

For instance, when accessing the P-UNIT on the Intel Rocket Lake platform, the Intel CSME firmware uses its Port ID of 0x90, but the SB_BRIDGE between the PCH and CPU converts this identifier to 0xe2, which is used locally within the CPU domain (North Complex), while the SAI of 0x20 remains unchanged. This allows devices to implement access control based on universal access masks (for read, write, and configuration rights) without worrying about the Port ID of a particular client device on a given platform.

The Fuse Controller device contains a special table called the Fuse Distribution Look-up Table (FDLT), which specifies the address and length of the data to be transmitted from the common E-FUSE array for a specific Security Attribute of Initiator (SAI) and Port ID when requesting Security Fuses or hardware configuration.

If a request is made with an SAI that, according to this table, should not come from the specified Port ID, or if it is not mentioned in the table at all, then the request is rejected (completed with a special error status). At the same time, the hardware configuration and Security Fuses are requested using special operation codes of the IOSF Side Band bus (0xb8 and 0xba for hardware configuration, 0xbb for Security Fuses). Additionally, the Fuse Controller analyzes the current value of the DFX Secure Policy, which indicates different platform debugging levels, such as Red and Orange Unlock (see [4], page 6), and transmits the Security Fuses only if the platform is operating in Green/Locked mode.

More specifically, the DFX Secure Policy value is also a key attribute of the FDLT table data, and in Unlocked modes, instead of the production Security Fuses, a special debug-enabled key is issued, which, although unique to the platform, does not allow it to be verified in Intel EPID remote attestation technologies and does not provide access to the firmware data operating in Locked mode.
This is how the protection of CSME Security Fuses is implemented by the Fuse Controller: they can only be obtained on request from the Intel CSME hardware domain (through the appropriate SAI) and only in DFX Secure Policy Green.

4. Limiting the scope of the executable code of the Intel CSME firmware that has access to the original Security Fuses.

When examining the part of the Intel CSME firmware that is stored in non-reprogrammable memory (ROM) and starts executing immediately after the CSME subsystem is started, it becomes clear that only a small part of this code is allowed to access the original Security Fuses, while all other firmware modules, stored on SPI Flash, can only access derived keys (from the Chipset Key and EPID Root Key) that are also protected in some way (see [2], page 15, paragraph – The ROM can create several keys from the Chipset Key, in particular Wrapping Key and Memory Guard Key).

Furthermore, the raw data representing the Security Fuses is stored in the CSME memory for a very limited time, and the CSE Fuse Puller (FP) device, located in the CSME hardware domain and inaccessible from the main CPU environment, is responsible for obtaining them from the Fuse Controller (described above).

The FP is designed to be in a working state immediately after the CSME subsystem is reset, allowing it to request the Security Fuses, which is done by the CSME ROM. After the Security Fuses are obtained from the Fuse Controller, the FP stores them in its internal memory and allows the CSME ROM to access them through the MMIO mechanism.

The CSME ROM reads the Security Fuses from the FP into local SRAM memory, decrypts them using the Fuse Encryption Key, and places the result directly into the SKS. This process is described in more detail in the next chapter, presenting a flaw in the OCS architecture that allows the extraction of the FEK.
Here, we emphasize that the CSME ROM, after generating the first-level key hierarchy (root keys of various modules/mechanisms implemented in CSME, such as Wrapping Key, IVB Root Key, or Intel/Non-Intel Root Keys, some of which do not even depend on the Secure Version Number (see [2], page 15, Note “Once the fuses have been locked…” and paragraph “The ROM can create several keys from the Chipset Key…”, and a paragraph below about the Provisioning Key)), performs a procedure to clear the FP, zeroing its internal memory with the Security Fuses, and then blocks the FP, preventing subsequent requests to the Fuse Controller.

Thus, all subsequent CSME firmware modules, even those that run in the kernel mode (zero privilege level x86), such as rbe and kernel, have physical access to the FP device and can no longer request the Security Fuses because the FP is blocked. Thus, any vulnerability in any of the firmware modules does not allow access to the FP and, therefore, to the Security Fuses, but only to the derived encryption keys, which are completely updated after the vulnerability is fixed and the Secure Version Number is incremented, since the SVN value is used as one of the components of the initial data involved in the process of generating these encryption keys. And only a hypothetical error in the CSME ROM, in a rather limited area of the code, allows access to the encrypted Security Fuses stored in the FP.
This approach to protection shows how critical a resource the Security Fuses are from a security perspective – the entire security model is based on them, and if they are extracted (and decrypted), then the subsequent generation of derived keys with a new SVN is no longer meaningful (an attacker can recalculate them for any SVN) and the security is compromised without the possibility to recover for the given platform.

In this context, it is worth noting the special module of the CSME firmware called the Intel Debug Launch Module (IDLM).

This module is an exception to the general rule described above: when it is run, the CSME ROM does not block or clear the FP memory, providing this module with access to the Security Fuses. At the same time, the IDLM module is not included in the stock, production firmware distributed by Intel among platform developers (OEM, ODM). We believe that IDLM is intended for platform debugging and is used exclusively by Intel engineers to find the causes of hardware failures. And although we have never encountered the actual IDLM module and have not studied all its capabilities, we can say without exaggeration that its inherent property, potential access to Security Fuses, turns IDLM into a real backdoor: Intel engineers can extract Security Fuses from any platform, having local and possibly even remote access (through Intel CSME firmware update mechanisms), and thus decrypt user data that uses the Intel firmware TPM (fTPM), implemented in the PTT (Platform Trust Technology) firmware module, as an encryption key storage.

Therefore, we believe that the presence of the IDLM mechanism in all Intel platforms released to date is a compelling argument against using Intel fTPM as an encryption key store for software products such as Microsoft BitLocker.

Vulnerabilities that allow access to Security Fuses

To date, there are two known vulnerabilities that allow extraction of Security Fuses in encrypted form. Each of these vulnerabilities is characterized by its own limited set of affected platforms, as well as the impossibility of fundamental correction – in essence, the fixes released by Intel for each of the vulnerabilities are a set of “patches” aimed at reducing the risk of their successful exploitation as much as possible. And only in newer platforms (based on new microarchitectures) have these vulnerabilities been completely fixed at the hardware level. Let’s take a quick look at each of them:

1. CVE-2019-0090. Hardware vulnerability of the CSME system agent’s IOMMU. Described in the Intel security bulletin INTEL-SA-00213 [5]. Intel published a separate whitepaper [6] detailing the technical aspects of this vulnerability: the essence of the problem, affected platforms, consequences of successful exploitation, and methods for preventing it. Since Intel does not usually disclose technical details of published vulnerabilities, the exception to this practice in this case shows the seriousness of CVE-2019-0090, namely: the possibility of accessing encrypted Security Fuses. However, although it is not obvious from [6], it is not possible to directly access the Fuse Encryption Key (FEK) when exploiting the described vulnerability – the FEK is generated and used inside the Offload and Crypto Subsystem hardware modules (which will be described in the next chapter) and CSME does not work with its binary data directly, but only operates with it via commands to the Secure Key Storage, where the FEK is stored. Thus, CVE-2019-0090 allows to overcome only the first level of the Intel CSME security model, which is described in the previous chapter. However, we later found a hardware flaw in the SKS module that allows the FEK to be extracted before the SKS is cleared. This flaw is described in detail in the next chapter. Using a chain of vulnerabilities, CVE-2019-0090 combined with the SKS key insecurity, it becomes possible to fully compromise CSME, that is, access the decrypted Chipset Key, EPID Root Key, and other keys (see the chapter “Intel CSME Security Root of Trust” above) on all affected platforms. It should be noted that exploiting this CSME System Agent IOMMU vulnerability is a non-trivial task. Although we successfully exploitated this vulnerability on the Cannon Lake platform and extracted the CSME ROM in this way, the creation of a working proof-of-concept (PoC) for accessing Security Fuses seemed difficult to us due to the unstable exploitation, which is due to the nature of the vulnerability — a race condition during equipment initialization (see [6], page 6, paragraph regarding CVE-2019-0090). A little later, we found a more “stable” vulnerability (described below) that allows accessing Security Fuses, and we focused our efforts on exploiting the new vulnerability. So, for now, the question of a PoC for CVE-2019-0090 remains open, although it no longer makes much sense, given the vulnerability that will be discussed next.
2. CVE-2021-0146. This vulnerability is described by Intel in the security bulletin INTEL-SA-00528 [7]. It allows you to extract Security Fuses from platforms based on the SoC Atom Apollo Lake generation (CPUID 506C9, 506CA, and 506F1). Although Intel also indicates that the newer SoC Gemini Lake and Gemini Lake Refresh are prone to this vulnerability, the initial proof-of-concept (PoC) does not work on Gemini Lake/Refresh. The essence of this vulnerability is a hardware attack of the Voltage Fault Injection type, which allows disrupting the logic of the internal DFX Aggregator device that controls the debug unlock levels of the platform (Red and Orange, see [4], page 6). The DFX Aggregator manages the DFX Secure Policy, which is transmitted over the DFX Debug Bus to each device on the platform that stores significant security data (Platform Assets). This data includes the CSME Security Fuses, which are stored in the Fuse Controller device (see the chapter “Intel CSME Security Root of Trust”). The DFX Aggregator is designed so that after debug unlock in Red or Orange mode, or after activating the Delayed Authentication Mode (DAM, see [4], page 6, paragraph “There are four main levels of DFX policy as indicated in the table below”), the DFX Secure Policy is fixed in such a way that it is no longer possible to return to the initial, locked state (Green) without completely powering down the platform. Otherwise, in debug mode, changes can be made to the hardware configuration of devices (for example, changes to SAI access masks) that would allow accessing Platform Assets after returning to the Green/Locked mode. However, using Voltage Fault Injection, it becomes possible to perform a hardware reset of the DFX Aggregator device and then, using some specifics of its internal mechanisms, create a situation in which the DFX Secure Policy is returned to Green/Locked, but the hardware changes made in debug mode (with the DFX Secure Policy equal to Red) are not reset.
   We plan to publish a separate white paper describing the details of this hardware attack based on Voltage Fault Injection, but for the purposes of this study, it is enough to say that this attack is carried out entirely using the platform’s internal means, without using external power sources, equipment, or physical modification of the system’s printed circuit board. In Red Unlock mode, the integrated voltage regulator LDO (implemented using a Low Drop Out electrical circuit) called VNNLDO is programmed by accessing the platform’s power management controller (PMC) microcontroller. This PMC microcontroller is fully controlled in Red Unlock mode through the JTAG debug interface connected to the Direct Control Interface (DCI). After resetting the DFX Secure Policy, the modified hardware environment allows accessing the Security Fuses, as the Fuse Controller continues to provide them in response to requests from CSME, without recognizing the compromise, since the system is again operating in Green/Locked mode. The initial PoC for CVE-2021-0146 used Intel’s VISA (Visualization of Internal Signals Architecture, see [8]) technology to capture the debug trace of the interaction between the Fuse Controller and the Fuse Puller from the CSME domain, which includes the transmission of Security Fuses over the IOSF SB bus. Since the set of internal hardware signals that can be analyzed using Intel VISA technology is platform-specific (for desktop platforms based on Intel Core processors, the VISA signal list does not include IOSF SB bus data signals), this PoC was initially limited to Atom-based platforms: Apollo Lake and Gemini Lake/Refresh. However, for Gemini Lake/Refresh, Intel has hardware-limited some of the Intel VISA functions starting from the very first product steppings, making it impossible to obtain IOSF SB bus data signals in Green/Locked modes in principle. Intel engineers have strictly blocked the use of a special mechanism called Secure Access Bit on all Gemini Lake/Refresh platforms, making the PoC non-functional. However, the main problem – the vulnerability to the Voltage Fault Injection attack for the DFX Aggregator – has not been fixed, as this would require a complete redesign of the power subsystem of this IP block, which is based on VNNAON, and this is not possible within the framework of a new crystal stepping, but only after redesigning the schematics in new platforms.
   Therefore, we created a new PoC that operates not using Intel VISA to capture the trace for the IOSF SB bus, but allows accessing the CSME Fuse Puller hardware registers before its clearance by the CSME ROM. This made it possible to obtain Security Fuses on Gemini Lake/Refresh platforms as well. However, accessing the encrypted Security Fuses did not immediately allow achieving full platform compromise, as the key used to encrypt them (Fuse Encryption Key) is stored not in CSME memory, but in a special device called Secure Key Storage, which works with encryption keys without direct access to their binary data and without transmitting them to CSME RAM. Thus, it may seem that the CSME security model actually works: Security Fuses are extracted, the first level of protection is bypassed, but the platform is not compromised because the actual encryption keys cannot be obtained.
   But unfortunately, there is a serious flaw in the implementation of SKS that allows extracting the binary data for the Fuse Encryption Key and thus decrypting the Security Fuses, which already means full platform compromise. Moreover, since the FEK is not unique to each crystal instance, but the same for all Apollo Lake systems, and in turn for all Gemini Lake/Refresh systems, the second level of the CSME security model needs to be bypassed only once, on just one representative of each microarchitecture, which is what we did in this study, in which we also publish the FEK for both Apollo Lake and Gemini Lake/Refresh. This is discussed in the next chapter.

A vulnerability in the Offload and Crypto Subsystem (OCS) module’s architecture allows the fuse encryption key to be extracted

The Intel CSME’s subsystem, in addition to its firmware, also includes a hardware component consisting of a set of devices (IP blocks) that implement certain functions necessary for CSME’s operation at the hardware level. The CSME’s hardware environment is isolated from other devices integrated into the platform (such as PCI-E, USB, and SPI controllers), and direct access to them is only possible from the address space (physical memory) of the microcontroller that runs the CSME firmware. Access to some CSME devices is also possible from the address space of the main processor (host), but only through a special bridge called ATT (Address Translation Tables), which represents these devices in the host’s PCI configuration space.

One of the devices in the Intel CSME subsystem is the Offload and Crypto Subsystem (OCS), which provides cryptographic functions and DMA (Direct Memory Access)-based memory copying mechanisms for CSME’s software components. The cryptography and DMA mechanisms in OCS are implemented in hardware, which greatly accelerates the execution of the firmware on a relatively weak microcontroller (Minute IA, an x86-compatible microprocessor with a Lakemont microarchitecture, roughly equivalent in computational power to an Intel 486 from the 1990s). The next picture from [2] (Page 12, Figure 2, Hardware Architecture Conceptual Diagram) shows the place of OCS in CSME domain.

The internal implementation of OCS is unusual, as it is not a monolithic IP block, but rather a set of IP blocks that interact with each other through a special bus called OCP (Open Core Protocol). The OCP bus is an open standard of OCP-IP (OCP International Partnership [9]) working group under the management of the Accellera Systems Initiative. The primary purpose of OCP is to provide a unified interface for IP blocks developed by independent companies. As it was mentioned earlier (see Chapter 1, describing CSME security architecture), instead of the PCI/PCI-Express bus, integrated devices in Intel processors and chipsets interact with each other through a proprietary (in terms of specification) bus called IOSF (Intel On-chip System Fabric). So, the choice of a non-monolithic design and an open OCP bus for OCS suggests that the cryptographic IP blocks in OCS are developed by a third-party company, possibly using commercial hardware libraries available to hardware logic developers. Alternatively, Intel may have designed OCS as a component available for use by third parties, which would explain the choice of a modular architecture and open interfaces.

In any case, as will be shown below, the non-monolithic design of OCS and the required interaction methods between IP blocks led to a serious architectural issue that was overlooked by Intel engineers during the implementation of OCS. This architectural flaw resulted in a vulnerability and allowed us to extract the Fuse Encryption Key and fully compromise the Intel CSME security model.

The OCS consists of the following devices:

1. AES_A and AES_P: two IP blocks that implement symmetric encryption using the AES algorithm, one for general CSME firmware tasks and the other for page encryption and decryption operations, perfromed as part of the page management (Paging) mechanism. AES_P has the additional feature of supporting code/data page integrity control values (ICV).
2. HCU (Hash Control Unit): a device that implements SHA256/348 hashing algorithms and the HMAC (Hash-based Message Authentication Code) algorithm based on SHA.
3. RC4: an implementation of the RC4 symmetric encryption protocol.
4. GPDMA: an IP block that performs DMA operations unrelated to encryption.
5. EAU: a module that implements the RSA-2048/3096 asymmetric encryption algorithm for digital signature implementation.
6. SKS: Secure Key Storage, a module that allows storing encryption keys in OCS without exchanging binary data through CSME memory, and operates on them using integer slot numbers that contain the corresponding keys.
7. Bridge: a special bridge that connects the internal OCP bus of OCS to the IOSF bus of the CSME hardware environment.

Each of these devices has a dedicated address range on the OCP bus for programming the hardware functions implemented by the device. For example, the hardware registers of the HCU IP block are accessible at addresses 0xB000-0xC000, while AES_A has reserved addresses 0x8000-0x9000, AES_P has addresses 0xA000-0xB000, and SKS is accessible at addresses 0xF000-0x10000, as shown in the following screenshot from the Wind River Simics software used to emulate Intel platforms.

The crypto blocks of OCS (that is, devices that perform encoding, decoding, and hashing functions according to specific algorithms, such as AES, HCU, and EAU), contain a set of registers in their address space that are used to set the initial encryption/authentication key. The Intel CSME firmware sets the initial key before performing encryption/decryption/hashing requests to implement mechanisms that ensure cryptography-based authentication and confidentiality.

The hardware registers of the OCS cryptographic modules, which are used to set the encryption key, are only accessible for writing. Therefore, even if malicious code compromises the CSME firmware and gains access to the OCS address space, the encryption keys used in the last cryptographic operations cannot be extracted. However, OCS does not impose any hardware-level restrictions on the order in which key data is written to the crypto blocks. Therefore, the CSME firmware can transmit key data in any order, operating on write operations to registers at the level of several bytes or even byte-by-byte. That is, each 4-byte register (or single-byte register for some crypto blocks) containing specific key bytes, depending on its address, retains data from the last write operation, and the CSME firmware forms the key by performing multiple writes to the hardware key registers until the complete key of 16 or 32 bytes is transmitted, depending on the algorithm used. It is possible to rewrite the same register address multiple times before its direct use in the device when performing a cryptographic operation request. This hardware feature of OCS crypto blocks (the ability to perform multiple writes to key registers) does not pose any security problems if the CSME firmware is the only entity that owns the original encryption key and, therefore, its code is entitled to form this key in any way it chooses. However, this feature, when used in the case where the encryption key is not set by the CSME firmware but is established by the OCS itself (this case will be considered below), leads to a critical security problem, as it allows the established key to be guessed by rewriting its individual bytes (and performing corresponding cryptographic operations with pre-known data). This type of attack on the cryptographic key can be considered a variant of a known-plaintext attack [10], where the attacker controls both the plaintext and the ciphertext, as well as most of the encryption key, and the complexity of directly brute-forcing the unknown part of the key depends on the granularity of the rewrite, that is, the minimum possible length of data that can be rewritten in the hardware registers that set the encryption key. For the AES_A and AES_P crypto devices, the granularity of key rewriting is one byte, and the complexity of finding the encryption key, if its size is 32 bytes, will be 256*32 comparisons of encrypted text. For the HCU crypto block, rewriting the key is only possible in 4-byte words, and the complexity of finding a 32-byte key will be (2^32) * 8 comparisons.

If we carefully examine the scheme for generating root encryption keys in Figure 1, it becomes clear that the CSME firmware does not have direct access to the Security Fuses encryption key (Fuse Encryption Key, or HW Key on the diagram), or to the Chipset Key decrypted by this key. To generate and store these keys in the OCS, there is a special device called Secure Key Storage (SKS). As can be seen from the diagram, SKS generates the FEK key based on two components: a 384-bit hardware vector and a 128-bit ROM vector. These two components undergo a procedure called HW Shuffle, resulting in a 128-bit FEK key. This key exists only within SKS, and the CSME firmware does not have access to its binary data: it can modify it by transmitting different ROM vectors, but it does not know the resulting key, since it does not have access to the hardware vector, which is embedded in the SKS hardware logic. At the same time, the SKS command interface operates with encryption keys using their numerical identifiers—addresses of cells or slots where the corresponding keys are stored. The FEK key is always stored in slot 1. Then, SKS can transmit the key from any slot to a specified crypto block (AES or HCU) using its identifier, and the result of the cryptographic operation can be extracted from the crypto device and placed in a specified slot. Thus, the CSME firmware, by requesting the necessary SKS operations and operating with slot identifiers, does not have access to the binary data of the keys stored in the corresponding slots. It should be noted that the CSME firmware can transmit the bytes of its own key, which it owns, directly to an SKS slot (there is a corresponding command for this), but it is precisely the ability of SKS to interact with the cryptographic devices of OCS, bypassing CSME, that allows building a secure scheme for generating root encryption keys, which is why SKS was created in the first place. However, as we mentioned at the beginning, although the security model does not raise any concerns, its implementation contains critical errors, and we would like to analyze the reasons for their occurrence in more detail.

To demonstrate the problem, let’s consider the interaction between SKS and the crypto blocks in more detail. So, to transmit a key to the cryptographic devices, as well as to extract data from them, SKS must have the ability to perform write and read operations on the hardware registers of the OCS crypto blocks in one way or another. With a monolithic OCS design, organizing such transactions can be done without excessive complexity at the level of internal RTL logic. However, in our case, since each OCS device is a separate hardware module with its own interface connected to a common bus, SKS is forced to use standard read/write memory transactions on the OCP bus to write and read the MMIO of the crypto devices. At the same time, it has access to the same interface of these devices (a set of registers) as the CSME firmware, and the only thing that distinguishes SKS from CSME is a unique device identifier provided according to the OCP bus protocol. It becomes clear that special support for SKS is required from the crypto devices, which would distinguish its transactions and provide it with higher privileges than CSME, otherwise, collisions are inevitable, which will undoubtedly affect the security of the interaction between SKS and the cryptographic devices. All this greatly complicates the hardware logic of the devices inside OCS, which must clearly delineate the priority and sequence of accesses to the registers through which the keys for cryptographic operations are set. Thus, we see that the rejection of the monolithic OCS design complicates the logic of the devices in the most critical area from a security perspective, namely in the transmission of secret data, such as encryption keys. As a result, to protect the SKS keys, the crypto blocks introduce a special operating mode, SKS mode.

Figure 7 shows a part of the internal signals of the HCU crypto device from OCS, which are available for analysis through the Intel VISA technology. We see the presence of a signal called sks_mode, which takes on a value of 1 when this mode is activated. Through runtime analysis of this signal, we established that it is activated when the first 4-byte word of data is written to the HCU registers containing the encryption key using a request from SKS. At the same time, if HCU is in SKS mode, any write to the key registers from the CSME side causes HCU to exit SKS mode and clear the current key that came from SKS. The non_secured_key_wr signal changes its value to 1 and remains active until it is explicitly reset through the HCU status registers. This means that the protection against overwriting secret keys is implemented and working correctly. However, as we can conclude from the signals shown in Figure 5, SKS mode implies not only key protection but also prevention of reading output data, which are the result of calculations during the execution of a cryptographic operation (in our case, hashing according to the SHA algorithm), by any OCP client except SKS. In the HCU hardware logic, this is handled by the read_chains_allowed signal, which takes on the value of 0 (reading is prohibited) in SKS mode. Thus, only SKS can read the resulting data of the crypto device using OCP bus read transactions if the read_chains_allowed signal is 0. Of course, SKS can also read output data in the case of inactive SKS mode for HCU (when the original HMAC key is set by the CSME firmware). In both cases, the resulting data is placed in a specified SKS slot and can be used in subsequent cryptographic operations as a key. And here we come to a serious architectural problem of OCS: the inability of CSME to obtain the results of cryptographic hashing operation that was performed using a key from SKS. Although such protection is necessary for some cases, for example, in key derivation procedures, when a new key is generated by processing additional data using a base key, the other cases of applying cryptographic operations, such as hashing runtime data of the CSME firmware to check its integrity, require abandoning SKS mode, since the resulting hash must be read into CSME memory for subsequent use in one way or another.

This leads to a big problem: what to do if the original key must be protected from access by CSME, but the data obtained during its use must be accessible? The answer is: SKS mode for HCU crypto block does not imply such application and it must be abandoned. But how to protect encryption keys in such cases? The Intel engineers found a solution: they added a mode for secure and non-secure keys in SKS, which actually solves nothing because SKS transactions transmitting non-secure keys do not activate SKS mode in HCU, which leads to the possibility of overwriting the established key from the CSME side (see above, CSME is entitled to overwrite the bytes of its keys). The correct solution would be to separate the protection against overwriting the encryption key and the optional possibility of reading the resulting data on the crypto device side within SKS mode, but HCU doesn’t implement such feature. It worth noting, that the AES_A/AES_P crypto devices do allow reading the resulting encoded/decoded data obtained using SKS keys, protecting them from overwriting, so, the lack of this highly required feature in HCU strongly implies non-Intel design of OCS.

Thus we have identified the main problem of SKS: part of its keys, that is, those stored in non-secure slots, although inaccessible to CSME from the point of view of the SKS command interface, can actually be easily extracted by applying a variant of a known-plaintext attack with the possibility of overwriting the key in the AES_A, AES_P, and HCU crypto devices. This is an architectural problem and it exists at the hardware level, that is, it cannot be fixed by making changes to the CSME firmware.

In Figure 1, for each key, on the left, its attributes are listed, and one of them is Secure Mode, which controls the SKS mode of the crypto device when using this key, as discussed above. These SKS slot attributes, including Privilege Level, Locked, and Secure Mode, are set each time a new key is added to the specified slot: when it is generated by SKS itself (the case of FEK), when data is transmitted directly from the CSME firmware, and when the resulting data of crypto operations is used to create a new key (for example, key derivation or key decryption).

However, Figure 1 clearly shows that both for FEK (HW Key, Slot #1) and for Chipset Key (Slot #12, the notation Slot #0 in Figure 1 is incorrect), the Secure Mode attribute is equal to 0 – and this is the second architectural error that undermines the entire CSME security model, as it allows the extraction of FEK. According to document [6] (Page 14, Paragraph – Usage of Secure Key Storage (SKS) Hardware), FEK cannot have a Secure Mode attribute, since it is used not only to decrypt the Chipset Key (the first 32 bytes of Security Fuses) but also to decrypt the EPID Private Key, which is also part of Security Fuses. At the same time, cryptographic operations using the EPID Private Key are not supported at the hardware level in OCS, since they are performed according to the elliptic curve digital signature algorithm (ECDSA, Elliptic Curve Digital Signature Algorithm, see [11]) and are implemented at the software level, that is, the EPID Private Key must be read into CSME memory. But this is highly incorrect argument proving the choice of insecure mode for FEK, because the resulting data of AES devices can be read back into CSME memory for secure keys! And here we can see the lack of coordination between Intel CSME firmware developers and the hardware engineers: insecure keys are intended only for use by HCU crypto operations, in the case of their results must be read to CSME memory, what is not the case for EPID Private Key obtained directly by AES decryption applied for its part of Security Fuses using FEK.

Intel simply states in documents [2] (Page 15, Note 1) and [6] (Page 11, Paragraph “Note the Fuse Encryption Hardware Key…”) that FEK is not intended to protect the Chipset Key and EPID Private Key from CSME ROM. Let this be the case, however, the most terrible consequence of an insecure FEK is the possibility of extracting it itself from SKS, which, together with the compromise of Security Fuses, as we already discussed in Chapter 2, completely destroys the Intel CSME security model. In our research, to extract FEK, we used the AES_A crypto device and successfully restored FEK on the Intel Apollo Lake and Gemini Lake platforms. Here’s the prof:

If we talk about the reasons for the emergence of such a fatal flaw in the implementation of a well-thought-out model, then we, understanding the speculative nature of our subsequent statements, will still try to answer this urgent question: how did it happen that a company like Intel, with all its experience in designing and developing reliable hardware, was unable to implement security for one of the most critical subsystems from this point of view in its platforms?

So, we see the following reasons for the insecure FEK and, as a result, the complete compromise of Intel CSME:

1. The group of engineers at Intel who developed the hardware environment for the CSME subsystem decided to use a third-party library to implement hardware support for cryptography, which did not fully meet the necessary functional criteria. Namely, it did not support the ECDSA elliptic curve encryption algorithm and had an inconvenient SKS mode for the HCU crypto device that was only suitable for key derivation procedures, but not for ordinary data hashing using integrity keys.
2. The decision was made to add a non-secure key mode to the SKS device to support cryptographic operations based on the SHA algorithm with ordinary data used by the CSME firmware, which (operations) do not use the SKS mode implemented for the library’s crypto devices.
3. The security architects overlooked or simply ignored the fact that the cryptographic modules of the library do not provide protection for the original keys without activating the SKS mode, so the non-secure key mode of SKS is very dangerous and should be used very carefully only for derived keys. In fact, it would be more correct not to have the non-secure key mode in SKS at all and to store the keys with such requirements in CSME memory directly, so as not to mislead firmware developers.
4. The CSME firmware developers erroneously chose the non-secure SKS mode for FEK. They mistakenly believed that AES crypto devices, analogous to HCU device, block reading the resulting data for secure keys into CSME memory. In fact, AES devices allow such use. The developers could have simply chosen the secure SKS mode for FEK without any functional limitations, thus preventing the disastrous effects described in this paper. Stating that FEK is not meant to protect the Chipset Key from CSME ROM, they missed the main point: they put the FEK itself at risk, which is not unique to each SoC/system logic chip, but is the same for all versions of the CSME firmware with the same ROM vector. This means that FEK is the same on all platforms belonging to one generation, and its compromise means a problem not only for a specific platform instance, but for all chips of that family.

In conclusion, it should be noted that Intel CSME is completely compromised on old platforms where arbitrary code execution and the compromise of Security Fuses is possible (see SA-00086, SA-00213, and SA-00528). However, newer systems are also prone to the architectural flaws of FEK described above. This may become critical if new vulnerabilities are discovered that allow code execution within CSME. It should also be noted that the use of compromised systems mentioned in the above bulletins should now be considered insecure, and all software patches are powerless against the compromise of Security Fuses and FEK. Although these platforms are no longer manufactured and are officially End-Of-Life, many of them are still actively used in embedded systems, affecting platforms from various vendors.

Resources

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