It’s important to secure the boot process to prevent the installation of malicious software. In this video, you’ll learn about hardware root of trust, secure boot, trusted boot, and measured boot.
One consistent aspect of IT security is that the attackers are constantly going after our systems. They’re trying to find new ways to gain access to our operating systems, and the data that we’re keeping on those operating systems.
Once they compromise the device, they want to get embedded within that operating system, and they don’t want to be thrown out or lose contact with that particular system. It’s very difficult to find a way to exploit an operating system. It’s even more difficult to try to get in the second time.
That’s why the boot process would be a perfect place to try to get into an operating system and stay there. Something like a rootkit has traditionally been able to work at the kernel level, which means it has full control of the operating system, and you’re able to infect the system before the OS can even start.
Once that malicious software is operating at the kernel level, it effectively has full control of the operating system. This is why protecting every part of the boot process becomes so important.
In this video, we’re going to look at secure boot, trusted boot, and measured boot, which are all different parts of the boot process. This is something called the chain of trust. And it’s incredibly important that these are in place to be able to protect our operating systems.
Anything we do with IT security is based on a level of trust that we have with the operating systems that we’re using, and the software that we’re loading on that operating system. We’re concerned about our data, and we want to be sure that our data is safely encrypted on that system. We want to be sure when we visit a website, that we can trust that that website is going to be the legitimate one. And if we’re using an operating system, we’re trusting that that operating system has not been infected.
But of course, this isn’t a blind trust. We put specific security controls in place to make sure that we can rely on, and trust, that these systems are safe. For example, if you’re working on an individual system, you probably have a Trusted Platform Module, or TPM. We’ll learn more about TPM’s in this video.
And in a future video, we’ll look at hardware security modules, or HSM’s.
It’s this hardware root of trust that gives us the ability to trust that the system is going to be safe and secure. One significant security advantage of this hardware root of trust is that it’s hardware. It’s not something that you can easily change by running malicious software, or changing something about an application configuration. You have to physically change this if you have any hopes of modifying what’s on the hardware of that system.
This also means the hardware has to be installed for the trust to be put into the system. So if you’re running an operating system, there should be a Trusted Platform Module on your computer that gives you that hardware root of trust.
The computing device you’re using may have a piece of hardware called a Trusted Platform Module, or TPM. This is an image of a TPM module that can be installed onto this particular motherboard, or it may be something that is integrated into the motherboard itself.
The TPM is designed to help with cryptographic functions that are used by applications within the operating system. This can include a cryptographic processor, which is commonly used as a random number generator, or a key generator.
You might also have memory on this Trusted Platform Module that’s able to store keys, especially keys that can be burned in and not changed. This means that we can reference the Trusted Platform Module to be able to obtain a unique value that’s not on any other computer that you might have.
This might also store information in the memory, such as encryption keys, or configuration information about the hardware that this TPM is installed on.
And all of this information within the TPM is password protected. And before you think of using a brute force attack to gain access to this system, it is already built with an anti-brute force technology, so that you’re not able to constantly try to find the password that’s used for a particular TPM.
With the Trusted Platform Module providing the hardware security, our BIOS provides the software security. And our UEFI BIOS has a function within it called secure boot.
This is part of the UEFI BIOS specification, so any device that has a UEFI BIOS is going to be able to use secure boot. There are also protections built into the UEFI BIOS itself to protect the BIOS.
For example, the BIOS has the manufacturer’s public key as part of the BIOS software, and if there is a BIOS update, then there’s a digital signature check to make sure that the BIOS update is really coming from the manufacturer.
This means that someone can’t provide a fake version of a BIOS, or one that is malicious, and somehow get around the update process. Once secure boot is enabled inside of that BIOS, we can now check the bootloader of the operating system to make sure that no malicious software has changed any part of that bootloader.
We’ll make sure that the bootloader’s digital signature verifies with the digital signature from the operating system manufacturer. There is a trusted certificate that the bootloader must be signed by, and that trusted certificate is compared to the digital signature that is in the bootloader.
The operating system’s bootloader must be signed by a certificate that is trusted, or it has to be a manually approved digital signature, so that we know when we’re starting the operating system, that no part of that bootloader has been changed by any malicious software.
Once the secure boot process is complete, we move to the trusted boot process. During this process the bootloader, which we now know has not been changed, is going to verify the digital signature of the operating system kernel.
This ensures that the operating system kernel has not been modified by any malware, and if there has been any change, the boot process will stop. The kernel of the operating system will then verify other parts of the OS, such as boot drivers and start up files, and make sure that those components remain safe.
And just before the operating system starts loading any hardware drivers, it starts a process called ELAM. This is the early launch anti-malware. The operating system will check every driver that it’s loading to make sure that it is trusted. There’s a digital signature associated with these drivers, and it will check every single one of those digital signatures.
If the driver fails that digital signature verification, or the digital signature is untrusted, then that driver will not be loaded by the operating system.
Once the drivers are loaded, we can move to the measured boot process. This is the process that allows us to measure if any changes have occurred with the operating system.
If this was just your computer, then you may have a number of checks that you perform to make sure that your system is running normally. But if you have thousands of computers, there needs to be an automated way to ensure that all of these operating systems have not been infected by any type of malware.
Fortunately, there are some measurements that are taken that can help put this automation. That UEFI BIOS is going to store a hash of the firmware, boot drivers, and anything else that’s loaded during the secure boot and the trusted boot process. And the hash created by that information is stored within the TPM of the system.
Now that all of this information is gathered, we can begin a process called remote attestation, which means that our device is going to provide a central management server with a verification report showing all of the information that’s been gathered.
That report is going to be encrypted and digitally signed with the keys that are part of the TPM. And that is sent to the attestation server. That server is then going to receive the boot report, and compare the information in that report with the information that it knows to be trusted on that system.
If that report shows that the software or hardware in that system has been modified, then the system administrators can choose to turn that system off, or have that system disabled until it can be looked at by a technician.