Trusted boot
The hardware root of trust
In this article I like to explain the basic functionalities about the concept of computer architectural mechanisms to ensure a trusted boot. Initially, I’ll explain the basic concept of a standard boot process, then the magic of root of trust will be added to accomplish a trusted boot. This article focused on standard Intel Architecture (IA), described in [1] and [2].
Motivation
The motivation of a trusted boot is the danger of malicious malware, which is a harmful piece of software. It secretly installs itself on the computer and stays hidden by working silently in the background. In particular, rootkits infiltrate systems in an early state during the boot process, so malicious code can run at the highest software privilege level. For this reason, the power of trusted boot could avoid an attack of rootkits.
Basic boot process
To illustrate the basic behavior of a computer architecture’s standard boot process it is important to understand the routines the boot process does. Most computers follows the boot process, which could be summarized as following:
The boot process is initialized after powering up the computer (CPU reset). The boot process is also known as bootstrapping process and abbreviated as booting. The boot process is a sequence of steps that collectively initialize all the computer’s hardware components and load the system into DRAM. [2]
The BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface) is a firmware component stored in nonvolatile memory, usually a flash chip/EEPROM on the motherboard. UEFI is the successor of BIOS and expands the functionalities by adding a couple of features, for example: an graphical user interface (GUI), controllable with mouse input; native 64-Bit support for modern operating systems; ability to load hardware specific driver for peripherals like network interface cards and so on. The BIOS/UEFI loads the boot loader, which is typically the first user-related software component loaded during the boot process. The boot loader is usually stored in the hard drive, together with the operating system and applications.
An Intel Architecture typically starts with the PCH (Platform Controller Hub), containing the Intel Management Engine (ME), which is similar to an dedicated embedded computer system and starts before the CPU. After configuring the basics of the machines hardware, the PCH allows the CPU to come out of reset [4]. The bootstrap processor (BSP) fetches the first address and executes it at physical address 0xFFFFFFF0, also known as the reset vector. This accesses the ROM / Flash device at the top of the ROM. The CPU then loads the BIOS (or UEFI) from the boot firmware SPI (Serial Peripheral Interface) flash [4]. In this state, the basic functionalities for input and output, such as keyboard and monitor, are initially working and further peripherals could be loaded.
Meanwhile, the preparation for memory initialization is executed from the ROM, since DRAM is not available yet. There are three steps necessary to get the system ready prior to initialize the memory:
- Processor Microcode Update
- Processor Initialization
- Chipset Initialization
Initialization means an announcement of devices, which need to be accessible for further operations in run-level. Every piece of hardware is announced with an unique device-ID and its purpose. Details about these steps are described in BIOS/firmware specific writer’s guides. In general, all Base Address Registers (BARs) should be initialized and watchdog timer needs to be disabled prior to memory initialization, otherwise a random error could occur [1].
After preparation, initialization of the memory is the next step. The functionalities differs wide from chipset to chipset and is described in the Memory initialization Reference Code (MRC) distributed by Intel [1]. The operating environment requirements may include (but may not be limited to):
- Processor Operating Mode
- Cache Configuration
- Memory Geometry Information
The memory initialization covers the total size of DRAM and executes some routines to test the memory, validate the integrity and setup the stack. Because of the necessary hardware access, the boot process is actually executed with system privileges (Kernel-mode) to announce the machines hardware for applications through operating system calls (SYSCALLS). Then, the DRAM is ready for operation and the boot loader is fetched from MBR (Master Boot Record), usually on the hard drive and stored in DRAM and then executed there.
So the execution control is passed to the boot loader, which initializes the DRAM for translating physical addresses to virtual addresses. It loads necessary driver and the initial operating system image from storage into system memory and passes execution control to the kernel of the operating system [4].
Finally, the operating system (OS) is up and has different modes of operations, i.e. User-mode and Kernel-mode. The purpose of User-mode is to avoid the user for destructive system calls, so it needs the operation system to communicate with other hardware components. The Kernel-Mode is the ability of the system to finally access the hardware. Because of that, the OS acts like an API (Application Programming Interface) for the applications executed in User-mode.
Overall, the system privileges during a basic boot process came from low-level (core hardware initialization), to mid-level (operating system) and finally to high-level (applications) states.
Trusted boot process
As you can see, the basic boot process assumed the sequential loading of different boot stages runs as expected. But how can you verify that each step in the boot sequence is running the software that you know is secure? If our hardware or software has been compromised at any point in the boot sequence then the attacker has the most privilege on our system and likely can do anything they want [4].
The magic to prevent such attacks is achieved by the root of trust. The goal of a hardware root of trust is to verify that the software installed in every component of the hardware is the software that was intended. This way we are able to verify and know without a doubt whether a machine’s hardware or software has been hacked or overwritten by an attacker [4].
The successor of BIOS, named UEFI implements a function called Secure Boot which is designed to ensure that the firmware that is executed during boot is verified through a valid signature, backed by a locally trusted certificate.
Trusted Boot is the measurement (hashing) of system firmware boot components and the creation of secure cryptographic artifacts that clearly demonstrate that particular firmware has been executed by the system. Intel SGX relies on software attestation, means the proof is a cryptographic signature that certifies the hash of the secured artifact. Trusted Boot artifacts can be used to verify system integrity or to seal secrets to that they are only available after certain firmware has executed. Secure Boot is the cryptographic signing and verification of firmware boot components. Secure Boot prevents the system from executing either accidentally or maliciously modified firmware. After powering up the computer with an activated Secure Boot option set in UEFI, the Platform Initialization (PI) process in the UEFI firmware validates, that each binary loaded for execution has a valid signature.The block called Security (SEC) implementation is responsible for building a temporary memory store and loading sequentially the subsequent firmware into it [2]. For this reason, the system is the root of trust, because it performs the first steps towards establishing the system’s desired security properties.
The trusted boot is also known as a measured boot, because all the software involved in the boot process is measured, that means, cryptographically hashed. The SEC implementation takes the first steps in establishing the system’s measurement, namely resetting the special register that stores the measurement result, hashes the PEI implementation, and storing the measurement in the special register [2]. One of the first tasks performed by the Pre-EFI Initialization (PEI) implementation is enabling DRAM, which requires discovering and initializing the DRAM chips connected to the motherboard. Then, PEI copies itself from the temporary memory store into DRAM and flushes the temporary memory. The PEI throws up the control to the Driver eXecution Environment phase (DXE), which locates and starts firmware drivers for various components in the computer. After that, the Bood Device Selection phase (BDS) and Transient system load phase (TSL) succeed, where an EFI application loads the OS selected as boot device. Finally, the OS loader passes control to the operating system’s kernel, entering the Run Time phase (RT) [2].
A hardware root of trust is the idea on which all secure operations of a computing system depend. It contains the keys used for cryptographic functions and enables a secure boot process. The root of trust is a source that can always be trusted within a cryptographic system, so its secure by design. The most secure implementation of a root of trust is in hardware, making it immune from malware attacks, as long as no bugs or a weak implementation faults exist. Because cryptographic security is dependent on keys to encrypt and decrypt data and perform functions such as generating digital signatures and verifying signatures, the system implements a hardened hardware module. Because this module is for all intents and purposes inaccessible outside the computer ecosystem, that ecosystem can trust the keys and other cryptographic information it receives from the root of trust module to be authentic and authorized. This is important, because to avoid being hacked, components of computing ecosystems need a way to determine information they receive is authentic. It enables the computer to secure the data and applications and helps to build trust in the overall computer system.
References
[1] Intel Corporation, Minimal Intel Architecture Boot Loader Bare Bones Functionality Required for Booting an Intel Architecture Platform, Jan 2010.
[2] Victor Costan and Srinivas Devadas, Intel SGX Explained
[3] Ruan X. (2014) Boot with Integrity, or Don’t Boot. In: Platform Embedded Security Technology Revealed. Apress, Berkeley, CA
[4] Jessie Frazelle. 2020. Securing the Boot Process. Queue 17, 6, Pages 60 (November-December 2019), 17 pages. DOI:https://doi.org/10.1145/3380774.3382016
