/Intel x86 Root of Trust: loss of trust

Intel x86 Root of Trust: loss of trust


https://www.shutterstock.com/image-photo/fire-burning-blazing-computer-motherboard-cpugpu-1617430696

The scenario that
Intel system architects, engineers, and security specialists perhaps feared
most is now a reality. A vulnerability has been found in the ROM of the Intel
Converged Security and Management Engine (CSME). This vulnerability jeopardizes
everything Intel has done to build the root of trust and lay a solid security
foundation on the company’s platforms. The problem is not only that it is
impossible to fix firmware errors that are hard-coded in the Mask ROM of
microprocessors and chipsets. The larger worry is that, because this
vulnerability allows a compromise at the hardware level, it destroys the chain
of trust for the platform as a whole.


Positive Technologies
specialists have discovered an error in Intel hardware, as well as an error in
Intel CSME firmware at the very early stages of the subsystem’s operation, in
its boot ROM. Intel CSME is responsible for initial authentication of Intel-based
systems by loading and verifying all other firmware for modern platforms. For
instance, Intel CSME interacts with CPU microcode to authenticate UEFI BIOS
firmware using BootGuard. Intel CSME also loads and verifies the firmware of
the Power Management Controller responsible for supplying power to Intel chipset
components.


Even more
importantly, Intel CSME is the cryptographic basis for hardware security technologies
developed by Intel and used everywhere, such as DRM, fTPM, and Intel Identity
Protection. In its firmware, Intel CSME implements EPID (Enhanced Privacy ID).
EPID is a procedure for remote attestation of trusted systems that allows
identifying individual computers unambiguously and anonymously, which has a
number of uses: these include protecting digital content, securing financial
transactions, and performing IoT attestation. Intel CSME firmware also implements
the TPM software module, which allows storing encryption keys without needing an
additional TPM chip—and many computers do not have such chips.


Intel tried to
make this root of trust as secure as possible. Intel’s security is designed so that
even arbitrary code execution in any Intel CSME firmware module would not jeopardize
the root cryptographic key (Chipset Key), but only the specific functions of
that particular module. Plus, as the thinking went, any risks could be easily
mitigated by changing encryption keys via the security version number (SVN)
mechanism. This was demonstrated in 2017, when an arbitrary code execution vulnerability
was found in the BringUP (bup) firmware module, as described in Intel SA-00086.
At that time, Intel simply generated new keys by incrementing the SVN, easily
preventing any compromise of EPID-based technologies.


Unfortunately, no
security system is perfect. Like all security architectures, Intel’s had a
weakness: the boot ROM, in this case. An early-stage vulnerability in ROM enables
control over reading of the Chipset Key and generation of all other encryption
keys. One of these keys is for the Integrity Control Value Blob (ICVB). With
this key, attackers can forge the code of any Intel CSME firmware module in a
way that authenticity checks cannot detect. This is functionally equivalent to a
breach of the private key for the Intel CSME firmware digital signature, but
limited to a specific platform.


The EPID issue is
not too bad for the time being because the Chipset Key is stored inside the
platform in the One-Time Programmable (OTP) Memory, and is encrypted. To fully
compromise EPID, hackers would need to extract the hardware key used to encrypt
the Chipset Key, which resides in Secure Key Storage (SKS). However, this key
is not platform-specific. A single key is used for an entire generation of
Intel chipsets. And since the ROM vulnerability allows seizing control of code
execution before the hardware key generation mechanism in the SKS is locked,
and the ROM vulnerability cannot be fixed, we believe that extracting this key
is only a matter of time. When this happens, utter chaos will reign. Hardware IDs
will be forged, digital content will be extracted, and data from encrypted hard
disks will be decrypted.


The vulnerability
discovered by Positive Technologies affects the Intel CSME boot ROM on all
Intel chipsets and SoCs available today other than Ice Point (Generation 10).
The vulnerability allows extracting the Chipset Key and manipulating part of
the hardware key and the process of its generation. However, currently it is
not possible to obtain that key’s hardware component (which is hard-coded in
the SKS) directly. The vulnerability also sets the stage for arbitrary code
execution with zero-level privileges in Intel CSME.


We will provide
more technical details in a full-length white paper to be published soon. We
should point out that when our specialists contacted Intel PSIRT to report the vulnerability,
Intel said the company was already aware of it (CVE-2019-0090). Intel
understands they cannot fix the vulnerability in the ROM of existing hardware. So
they are trying to block all possible exploitation vectors. The patch for
CVE-2019-0090 addresses only one potential attack vector, involving the
Integrated Sensors Hub (ISH). We think there might be many ways to exploit this
vulnerability in ROM. Some of them might require local access; others need
physical access.

As a sneak peek,
here are a few words about the vulnerability itself:


1.     The vulnerability is present in both hardware
and the firmware of the boot ROM. Most of the IOMMU mechanisms of MISA (Minute
IA System Agent) providing access to SRAM (static memory) of Intel CSME for
external DMA agents are disabled by
default
. We discovered this mistake by simply reading the documentation, as
unimpressive as that may sound.

2.     Intel CSME firmware in the boot ROM first
initializes the page directory and starts page translation. IOMMU activates
only later. Therefore, there is a period when SRAM is susceptible to external
DMA writes (from DMA to CSME, not to the processor main memory), and
initialized page tables for Intel CSME are already in the SRAM.

3.     MISA IOMMU parameters are reset when Intel
CSME is reset. After Intel CSME is reset, it again starts execution with the boot
ROM.


Therefore, any platform device capable of performing DMA to Intel CSME static memory and resetting Intel CSME (or simply waiting for Intel CSME to come out of sleep mode) can modify system tables for Intel CSME pages, thereby seizing execution flow.


Author: Mark Ermolov, Positive Technologies

Original Source