Intel x86 Root of Trust: loss of trust

So there came a moment that Intel’s system architects, engineers, and security experts were perhaps most afraid of: an error was found in the write-once memory area (ROM) of the Intel Converged Security and Management Engine, and this error casts doubt on all of the company’s efforts to create the root of confidence and the foundation of security on its platforms.

And the point here is not even that the errors of the firmware (firmware), which are “wired” in the on-board memory of the Mask ROM of microprocessors and chipsets, cannot be fixed, but rather that the error found destroys the trust chain of the entire platform as a whole, allowing compromise its hardware base.

Positive Technologies experts found a hardware error in the Intel hardware, as well as an error in the Intel CSME firmware, which manifests itself at a very early stage in the operation of this subsystem, in its boot ROM (boot ROM). It is known that it is Intel CSME that provides initial authentication of a system based on Intel chips, downloading and checking all the rest of the firmware of modern platforms. For example, Intel CSME, interacting with the CPU microcode, ensures the authenticity of the UEFI BIOS firmware using BootGuard technology. In addition, Intel CSME downloads and verifies the firmware of the Power Management Controller, which controls the voltage supply to each hardware unit in Intel chips.

But more importantly, it is Intel CSME that is responsible for the cryptographic base of such hardware protection technologies developed by Intel and used universally, such as DRM, fTPM and Intel Identity Protection. The Intel CSME firmware implements a remote certification system for trusted systems called EPID (Enhanced Privacy ID), which allows you to uniquely and anonymously identify each specific instance of a computing system (computer), finding many useful applications, such as protecting digital content, ensuring the security of financial transactions, certification of the Internet of things. In addition, Intel CSME firmware has a TPM software module that allows you to use it to store encryption keys without an additional TPM chip, which is not on every computer.

And Intel has tried to make this root of trust as secure as possible. The security system of Intel platforms is designed in such a way that even an arbitrary code execution error in any of the Intel CSME firmware modules does not carry the risk of losing the security root key (aka Chipset Key), but only jeopardizes the specific functions for which the vulnerable module is responsible, when This allows you to easily mitigate the risk by changing the encryption keys using the secure version number mechanism of SVN. This was clearly demonstrated in 2017, when an error of arbitrary code execution was found in the BringUP (bup) firmware module, described in Intel SA-00086. At that time, Intel simply performed key regeneration by increasing SVN, and thus easily avoided the risk of compromising EPID-based technologies.

But unfortunately, there are no perfect security systems, and, like any other, Intel’s security architecture has its Achilles heel – bootable ROM. An error in ROM in the early stages of execution really allows you to control the reading of the Chipset Key and the generation of all other encryption keys. One of these keys is used to encrypt an Integrity Control Value Blob (ICVB) data array. Having this key, you can fake the code of any of the Intel CSME firmware modules – and the authentication system will not be able to recognize the fake. This is tantamount to leaking the Intel CSME firmware digital signature private key, but for this particular platform.

At the moment, the situation with EPID is mitigated by the fact that the Chipset Key is stored inside the platform (in special OTP memory, One-Time Programmable Memory) in an encrypted form and to completely compromise the EPID, it is also necessary to extract the hardware key on which the Chipset Key is stored, which is encrypted in special SKS storage (Secure Key Storage). But this key is not unique to the platform, but one for the entire generation of Intel chipsets. And since the error found in the ROM allows you to intercept code execution until locking the hardware key generation mechanism in SKS, and the ROM error itself cannot be fixed, we believe that this is only a matter of time – when this key will be extracted. And then complete chaos will come: hardware identification will be faked, digital content will be extracted, encrypted information from permanent media will be decrypted.
So, Positive Technologies experts found an error in the Intel CSME boot ROM in all currently released Intel chipsets and SoC except Ice Point (10th generation of processors). This error allows you to extract the Chipset Key, as well as to manipulate part of the hardware key and the process of its generation, not allowing, however, at the moment to directly obtain its hardware component (wired in SKS). Moreover, this error in ROM allows you to organize arbitrary code execution at the zero privilege level of Intel CSME.

In more detail we will describe the technical details in a full white paper devoted to this error, which we plan to publish a little later. It should be noted that after our specialists contacted Intel PSIRT with a report on this error, Intel reported that the error was already known (CVE-2019-0090) Intel understands that it is impossible to fix an error in ROM in already released equipment, and therefore they simply block all possible ways of its operation. The patch for CVE-2019-0090 corrects only one of the possible attack vectors – through the integrated sensor hub (Integrated Sensors Hub, ISH). We think that there are potentially many ways to exploit this vulnerability in ROM. Some of them may require local access, some physical. To slightly open the veil of secrecy, let’s say a few words about the vulnerability itself:

The vulnerability is present both in hardware and in boot ROM firmware: the main part of the IOMMU mechanisms of the MISA system agent (Minute IA System Agent), which provides access to Intel CSME SRAM (static memory) for external DMA agents, disabled by default. This error, no matter how trite it sounds, we found just by reading the documentation.
The Intel CSME firmware in boot ROM initially initializes the page directory, enables page conversion, and only after a while activates IOMMU. Thus, there is a moment when static SRAM is available for external DMA write impact (DMA towards the CSME, and not to the main processor memory), and the initialized Intel CSME page tables are already stored in this SRAM.
The MISA IOMMU parameters are reset when reset is performed for Intel CSME, which after reset starts execution again from boot ROM.

Thus, any platform device that can perform DMA transactions in Intel CSME static memory and at the same time reboot Intel CSME (or just wait for the Intel CSME to wake up) can modify the system tables of Intel CSME pages and thus intercept execution.

Posted by Mark Ermolov, Leading Specialist, OS Technologies and Hardware Solutions Research Division, Positive Technologies.