Intel-based computers implement various hardware, firmware, and cryptographic algorithms to preserve the integrity of the platform. Protecting the supply chain incorporates the protection of the keys used in the integrity-checking process. A few recent events have highlighted the risks associated with keys critical to the platform integrity, such as:
- Intel confirms leaked Alder Lake BIOS Source Code is authentic (October 2022)
- The MSI Incident covered in Part 1 and Part 2 on our website (April 2022)
- That one time Microsoft leaked golden keys that were used in Secure Boot (August 2016)
- The “leaky” FTP server that left some of AMI’s keys exposed (April 2013)
It is difficult to navigate through the numerous processes and locations of the keys. Below is a guide that helps you understand where many of the keys are stored and how they are used so that you can be better prepared and informed for the next leak:
- CPU microcode – Before applying microcode updates, the system validates the integrity and authenticity of the update package to ensure it has not been tampered with or maliciously modified. Intel uses a digital signature to sign microcode update packages. The update package contains a digital signature generated using a private key known only to Intel. The public key is embedded in the CPU. Also, note there are other firmware instances within the CPU for various components (such as the Gen Graphics uController or GuC).
- Intel Boot Guard – Intel’s Boot Guard contains several different mechanisms for providing system integrity in the early stages of the boot process:
- The first stage of the boot process is the Initial Boot Block (IBB), which contains the firmware code responsible for initializing the system. The IBB is digitally signed by the OEM and a key manifest containing signature information is added to the firmware and used by hardware at startup to verify IBB integrity before running it.
- The Boot Guard ACM (signed by an Intel key fused into the CPU) residing in SPI flash is verified by CPU microcode and then runs with special privileges to verify the IBB using the keys in the Boot Guard manifest.
- Once the IBB is executed, it initializes the system and starts a chain of trust that needs to verify additional firmware prior to execution.
- Steve Orrin from Intel provided Below The Surface podcast listeners a great description in episode #11.
- Intel ME/CSME – Intel’s CSME also establishes a root of trust, serving as the foundation of its security infrastructure, independently from the host CPU. The root of trust is implemented within the hardware and is responsible for verifying the integrity of the firmware and other critical components.
- CSME employs digital signatures generated using cryptographic keys to sign firmware and other system components (the chipset has its own Intel public key burned into its fuses to verify the ME/CSME firmware). These signatures are used to verify the authenticity and integrity of the code during the boot process. If a component fails the signature check, CSME prevents its execution to protect against potential tampering or unauthorized modifications (including the CSME code itself)
- For a deeper understanding of Intel ME/CSME please refer to Firmware Security Realizations – Part 2 – Start Your Management Engine
- BMC – BMCs and their key usage can vary by manufacturer. Some implement a verification system that uses cryptographic keys in hardware to verify the authenticity of the firmware. BMCs may have additional security features, such as Secure Boot or trusted platform modules (TPMs) that introduce and guard access to cryptographic keys. Manufacturers may fall into one of the following categories:
- Do not perform any cryptographic verification
- Only verify when an update is being applied, not when booting
- Check BMC and/or BIOS firmware at boot time without using keys provisioned into hardware (fuses) but instead read keys from non-immutable SPI flash storage
- Implement a full hardware-based root of trust where the BMC will not boot at all if the SPI flash has been compromised and it can’t recover the system
- UEFI Secure Boot – UEFI secure boot is a feature that ensures the integrity and authenticity of the operating system and firmware by verifying their digital signatures before they are loaded during the boot process. It incorporates the following components:
- Platform Key (PK) – The root cryptographic key securely stored within the firmware to verify all other cryptographic keys in the system (such as the KEK). This is usually owned by the OEM that made the device.
- Key Exchange Keys (KEKs) – This key (or set of keys) allows the firmware to trust other manufacturers or third parties. The primary job of a KEK is to verify DB and DBX entries. This is usually owned by Microsoft for machines with a Windows logo.
- Authorized Database (db) – The db contains a list of X509 certificates or SHA1/SHA256 hashes of allowed images.
- Forbidden Database (dbx) – The dbx contains X509 certificates or SHA1/SHA256 hashes of revoked images.
- UEFI Secure Boot may also be configured using a SHIM or with user-generated keys referred to as MOKs (Machine Owner Keys)
- For a deeper understanding of Secure Boot please refer to Firmware Security Realizations – Part 1 – Secure Boot and DBX
- TPM – A TPM has several key slots or registers, each serving a specific purpose. The exact number and purpose of these slots can vary depending on the TPM version and implementation. At the root of trust within the TPM, there’s at least one key that the manufacturer should provision:
- Endorsement Key (EK) – The EK is a unique key embedded in the TPM during manufacturing. It is used to establish the identity and authenticity of the TPM. The EK certificate, signed by the TPM manufacturer, can be used for remote attestation and verification of the TPM’s integrity.
- Initial Device Identity Key/Initial Attestation Key (IDevID/IAK) – This pair of keys is created and provisioned by the OEM and intended to securely identify the overall device, as opposed to just the TPM. This is a newer addition to the TPM 2.0 specification and not all devices will include these keys.
In addition to keys provisioned by the manufacturer, several other keys are generated and used within the TPM throughout its operation:
- Storage Root Key (SRK) – The SRK is the parent key for all other keys generated or imported into the TPM. It is created during the TPM initialization process and remains within the TPM throughout its lifecycle until a new owner “takes ownership” of the TPM. The SRK is used to encrypt and protect other keys stored in the TPM.
- Attestation Identity Key (AIK) – The AIK is a key pair generated within the TPM for remote attestation. It allows a trusted third party to verify the system’s integrity by providing evidence that the system’s software and configuration have not been tampered with.
- Local Device Identity Key/Local Attestation Key (LDevID/LAK) – This pair of keys is created and provisioned by the owner/administrator of the system and intended to securely identify the overall device, as opposed to just the TPM.
- Storage Keys – TPMs can generate or import symmetric or asymmetric keys that are securely stored within the TPM. These keys can be used to protect sensitive data stored on the system, such as disk encryption keys, credentials, or digital certificates. The storage keys are securely wrapped using the SRK and can only be accessed through the TPM’s cryptographic operations.
- Sealing Keys – Sealing keys are used to encrypt data and bind it to a specific TPM or system state. The sealed data can only be decrypted and accessed when the TPM is in a specific state, ensuring the integrity and confidentiality of the data.
- Attestation Keys – Attestation keys are used for generating cryptographic evidence that can be provided to a remote party to verify the system’s integrity. These keys are used in remote attestation processes to demonstrate that the system’s software and configuration are in a trusted state.
- Platform Configuration Registers (PCR) – Although not keys themselves, a key part of how TPMs work is through the use of Platform Configuration Registers which are used to record a series of measurements of the state of the system as its booting. These are intended to be cryptographically hard to falsify due to the mechanism that’s used to update them. The state of the PCR registers is used as an integral part of sealing and unsealing keys stored within the TPM as well as attesting to the state of the system to a remote party.
- UEFI Firmware Updates – UEFI Firmware update images should be signed to prevent malicious actors from inserting code that can compromise the system before the operating system is loaded (aka a “bootkit”). UEFI-based firmware uses “capsules” for signed UEFI updates upon reboot or sleep. Capsules contain firmware volumes to be updated and firmware executables that perform the update. During the firmware update process at boot-time, the firmware checks the capsule signature before flashing. The UEFI firmware includes a pre-installed root certificate which serves as the foundation of the PKI used for firmware updates. The firmware capsule is signed using the private key of the entity responsible for creating the update (typically the manufacturer or OEM). The signature is generated using a cryptographic algorithm (e.g., RSA) and appended to the firmware capsule. The UEFI firmware uses the pre-installed root certificate to validate the digital signature on the firmware capsule.
- Components – One of the later stages of the boot process is to initialize the connected devices. Component firmware is stored on a wide variety of devices (and potentially other locations within the platform, such as SPI flash) including Cameras, USB hubs, Network Interface Cards (NICs), storage devices, Wireless adapters, graphics cards, and more. Inside your computer, there are also many other components the user does not typically interface with, but are present nonetheless, such as Embedded Controllers (e.g. on laptops this is the component and firmware that controls the keyboard and allows the user to change the volume or adjust the screen brightness). The signing and verification methods across all of the manufacturers differ greatly, if present at all.
References:
