An Introduction to secure booting

In this post, I will present my recent findings on secure booting. When the OS boot, some programs run in sequence. Each program runs its next program’s code. If there is no security feature during boot, an attacker can inject his malicious code into one of the booting programs. Therefore, he can get complete control of the compromised system. The complete threat modeling for the boot process is described in this link. The secure boot mechanism is the defense of such an attack. The checksum of each booting program is calculated and verified during the boot process. In other words, each program proves the integrity of the following running program. Therefore, an attacker can not inject his malicious code. I quote the following text from this link to describe the exact secure boot vs. measured boot process.

• In a Secure Boot chain, each step in the process checks a cryptographic signature on the executable of the next step before it’s launched. Thus, the BIOS will check a signature on the loader, and the loader will check signatures on all the kernel objects that it loads. The objects in the chain are usually signed by the software manufacturer, using private keys that match up with public keys already in the BIOS. If any of the software modules in the boot chain have been hacked, then the signatures won’t match, and the device won’t boot the image. Because the images must be signed by the manufacturer, it’s generally impractical to sign any files generated by the platform user (such as config files).
• In a Measured Boot chain, we still depend on a Root of Trust as the starting point for a chain of trust. But in this case, prior to launching the next object, the currently-running object “measures” or computes the hash of, the next object(s) in the chain, and stores the hashes in a way that they can be securely retrieved later to find out what objects were encountered. Measured Boot doesn’t make an implicit value judgement as to good or bad, and it doesn’t stop the platform from running, so Measured Boot can be much more liberal about what it checks. This can include all kinds of platform configuration information such as which was the boot device, what was in the loader config file, or anything else that might be of interest.

Two different approaches can do this process. The first approach entirely relies on the firmware software, which starts the booting process. For example, for the Debian-based OSes, we can use the method that describes in this link and this link. In the second approach, we can get help from the TPM module. In other words, we use the hardware facility e.g. TPM, and the process relies on firmware software (for example, UEFI). Trusted Computing Group (TCG) designed the TPM module (for learning more about TPM module, you can see this link). The TPM is a hardware module for saving secrets and cryptographic algorithms for calculating them in a secure place. In this approach, the checksum of booting programs are calculated and saved in TPM. TCG releases a software stack (TSS) to connect to the TPM and modify it. But it isn’t straightforward to implement the secure boot method by TSS and UEFI. SafeBoot is a suitable replacement. SafeBoot is a library module for implementing secure boot with TPM.

It is worth mentioning that the root of trust is essential and should be placed somewhere. Intel processor has Bootgurad as the static answer for this issue (see this link for the static vs dynamic root of trust). If the Bootguard policy is in the enforced mode, the checksum of the UEFI is stored in the One Time Program (OTP) fuse in the processor. Each time the UEFI is going to run, its integrity is verified. If it is not confirmed, the device is shut down.

Another issue is that the UEFI software is closed source. Therefore, we can not completely trust it. Coreboot is an alternative open-source firmware software. We could manage the secure boot, including TPM, with the help of Coreboot. We should keep in mind that we can install Coreboot when complete access to Bootguard configurations is possible.

In summary, we conclude that it is a four-phase path for enforcing secure boot:

1. Implementing Software Approach (UEFI Secure Boot)
2. Implementing Software and Hardware Approach with the help of TPM (Closed source UEFI + SafeBoot)
3. Enabaling the Static root of trust (Bootguard policy + Closed source UEFI + Safeboot)
4. Installing open-source Coreboot firmware with enabled Bootguard policy (Bootguard + Coreboot + TPM)