Intel Boot Guard keys leak analysis

The Binarly security research team conducts an analysis of the recent Intel and Lenovo source code leaks to model the potential impact.

Over the past two years, attacks on multiple targets in the semiconductor industry have consistently led to leaks of firmware source code. A compromised developer device could potentially give an attacker access to the source code repository, adding a major gap in the security of the software supply chain.

A few weeks ago, news emerged about a firmware code leak from Lenovo that includes Intel Alder Lake reference code from the most recent devices. There was a lot of unfounded speculation on the internet about the impact of the leak, including discussions on the Intel Boot Guard private key leak and whether it makes the security technology no longer effective.

In this blog, the Binarly REsearch team will provide a deep-dive to explain how Intel Boot Guard works, what exactly was leaked, and to provide an assessment of the leak’s real impact.

Our analysis of all publicly available firmware images from Lenovo devices resulted in the following key discoveries:

• There have been 72 unique keys generated for BootGuard Key Manifest (KEYM) since 2015.
• Since 2015, a total of 74 unique keys have been generated for Boot Policy Manifest (BPM).
• Lenovo uses the exact same key for KEYM and BPM for different devices in the ThinkCentre and IdeaCentre product series. That leads to a general misunderstanding of the Intel Boot Guard technology and the misleading the purpose of those keys. It's no separation of Boot Guard’s trusted chain into two consecutive parts, which allows to reduce the impact of a compromised chain of trust in case the leaked keys.
• Another interesting observation: sometimes Lenovo changes both keys to new ones and then after a few updates later, roll back the old keys. The goal of these actions could only be assumed.

Let’s dive into Intel Boot Guard internals to better understand this technology and the impact of these kinds of firmware supply chain compromises. The Boot Guard is unfortunately not documented by Intel but some of the information was recovered by Binarly REsearchers in the past -- see this Black Hat 2017 presentation.

First, Intel Boot Guard is a hardware-based technology intended to protect PCs against executing non-genuine UEFI Firmware, which could happen in case a possible attacker has bypassed protection against modification of BIOS.

If Intel Boot Guard is enabled on the platform, upon powering on the platform and prior to execution of BIOS, the BootStrap Processor (BSP) wakes up to locate Firmware Interface Table (FIT) using a pointer stored at a fixed address 0xFFFFFFC0.

LABScon_2022_Binarly_Discloses_High_Impact_Firmware_Vulnerabilities_In_Insyde_Based_Devices

This table contains pointers to firmware objects related to startup and security procedures, including Boot Guard specific files:

• Boot Guard Authentication Code Module (ACM);
• Boot Guard Key Manifest (KEYM);
• Boot Guard Boot Policy Manifest (BPM).

The UEFITool automatically parses this data and display it in human readable format:

Intel Boot Guard (BG) Authentication Code Module (ACM) is a core of the technology that implements firmware validation. Like other types of Intel ACMs, this one is developed and signed by Intel via their RSA private key. The hash of the RSA public key is hardcoded into the other object pointed by FIT - Microcode Update (MCU). This is the reason Intel Boot Guard fails if no MCUs are present in the firmware.

In turn, the MCU capsule’s RSA public key hash is programmed into CPU Field Programmable Fuses (FPFs) and there is no way to replace it from hardware.

The scheme of ACM validation looks like this:

As a result, the trusted ACM is loaded into a secure memory inside the CPU called Authenticated Code RAM, which is basically L3 Cache. The ACM key modulus and signature sizes are 2048 bit, however starting from Boot Guard 2.0 version they moved to 3072 bits wide keys.

We can see its structure parsed by UEFITool here:

The Authentication Code Module (ACM) header information look like the following code structure:

 struct {
  UINT16 ModuleType;            // 2
  UINT16 ModuleSubType;         // 1
  UINT32 HeaderLen;             // 0xE0 (in DWORDs)
  UINT32 HeaderVersion;         // 03.00 (BCD format)
  UINT16 ChipsetId;             // 0xB00C
  UINT16 Flags;                 // 0x8000 (debug flag set)
  UINT32 ModuleVendor;          // 0x8086 (who else could it be?)
  UINT32 Date;                  // 2021-11-11 (BCD format)
  UINT32 Size;                  // 0x9400 (total size of ACM in DWORDs)
  UINT16 AcmSvn;                // 0
  UINT16 SeAcmSvn;              // 0
  UINT32 CodeControl;           // 0
  UINT32 ErrorEntryPoint;       // 0
  UINT32 GdtLimit;              // 0x20
  UINT32 GdtBasePtr;            // 0x3ED0
  UINT32 SegSel;                // 8
  UINT32 EntryPoint;            // 0xDAF4
  UINT8  Rsvd2[64];
  UINT32 KeySize;               // 0x60 (in DWORDs)
  UINT32 ScratchSize;           // 0xD0 (in DWORDs)
  UINT8  Rsa3072PubKey[384];    // 0x61 0x23 0xAD 0x70 ... (LSB format)
  UINT8  Rsa3072Sig[384];       // 0xBD 0xFC 0xB3 0x67 ... (LSB format)
  UINT8  Scratch[832];          // 0x00 0x00 0x00 0x00 ... (LSB format)
} ACM_HEADER;

Let’s look into the firmware dump how this data will be represented in actual ACM binary:

When executed, the BG ACM locates (via FIT) and verifies the BG manifests: KEYM and BPM. The hash of KEYM RSA public key is programmed into Intel ME FPFs during the manufacturing line without a capability of being replaced. ACM acquires this hash from Intel ME. The main purpose of KEYM is to store the hash of an RSA public key of the BPM which in turn contains the information on the Boot Policy, Initial Boot Block (IBB) description and its hash. IBB is also verified by the ACM.

As Initial Boot Blocks (IBB), vendors usually specify SEC and Pre-EFI (PEI) volumes, while the rest of the UEFI firmware (DXE and SMM) should be protected by Vendor-specific structure inside IBB (trusted boundaries of which are guaranteed by Intel Boot Guard trusted boot chain).

Let’s take a look on the example of extracted KEYM data structure from the firmware image:

Let’s take a look on the example of extracted Boot Policy Manifest data:

Intel’s intention to make KEYM as a proxy between hardware and BPM lets vendors be flexible in configuring their build process for different product lines.

For example, the KEYM’s key could be used for the series of products, when different BPM’s keys could be used for different models in a product series. This also allows SOCs to react to key leakage incidents in case a BPM key is compromised. The following part of the trusted boot chain can not be trusted then, but this situation could be fixed only via issuing a firmware update with the nex BPM key (with its hash recalculated in KEYM).

Unfortunately both KEYM and BPM private keys were leaked for four different product lines (8 keys in total).

Since the Key Manifest (KM) hash in FPFs cannot be rewritten, for those 4 products the KEYM (hence Intel Boot Guard) is compromised forever, meaning in turn that Boot Guard can be easily bypassed on those devices: these systems should be considered as Boot Guard disabled systems.

Binarly’s FwHunt can be used to determine the impact industry wide, thanks to our first community contributed rule. Since the KEYM’s and BPM’s RSA public keys are stored in the firmware image strictly without any compression - the rule is simple enough just to search for the public key’s byte pattern (in Little Endian order, which Intel prefers to use inside their blobs).

Overall, our analysis revealed that no impacted firmwares or devices were discovered in the wild. Downloading firmware for impacted devices from the website of official support also shows no evidence that those keys ever existed in Lenovo devices.

If we take a closer look at the ACM’s header in the above mentioned example, we can see that the flags field is equal to 0x8000, meaning that Debug flag is set for this module.

Though not all Authentication Code Modules (ACMs) have this flag set, this makes us feel that the leaked Boot Guard keys are intended for debug building lines and most likely we will never see such devices in the wild. Nevertheless we’ll keep monitoring the firmware assets and let the industry know if this incident affects any production device..