In my previous articles related to Secure Boot and Trusted Boot, I have explained how Microsoft has worked to secure the boot phase of Windows 10 to provide a secure and reliable OS platform for the enterprise scenario.
Today in this article, I will be talking about another such feature which ensures the platform integrity – Windows Measured Boot.
Secure Boot helps secure the EFI boot phase of Windows by allowing only trusted EFI components to get executed. This includes the EFI Boot Manager (bootmgfw.efi) and the OS Boot Loader (winload.efi)
As the OS Boot Loader gets executed, it verifies the OS Kernel (ntoskrnl.exe) signature before loading it to memory. It also scans the SYSTEM registry hive to load the SERVICE_BOOT_START drivers to memory.
As Kernel initialization begins, ELAM driver gets executed as the first driver among the SERVICE_BOOT_START drivers loaded to memory by the OS Boot Loader, which then scans the other SERVICE_BOOT_START and SERVICE_SYSTEM_START drivers for AV check and sends the classification (Good, Bad, Bad but Critical, Unknown) to Kernel based on which it will decide the execution.
During the kernel initialization phase, the OS components are also subjected to Kernel Mode Code Signing check for integrity check.
Is this a full proof security mechanism?
Security is a subjective matter. If I talk about me as an admin, what I consider to be secure, the end user may consider the same as restrictive, hampering his daily work. As such, a balance needs to be struck between security and usability.
Why am I saying such?
By default, Kernel executes the drivers that returns ELAM classification Good, Bad but Critical for boot and/or Unknown. This is best for usability.
But as an admin, you can modify this behavior to let only drivers which returns Good classification from ELAM to get executed. Though this is most secure but can lead to an unstable system failing to boot.
Also the ELAM driver only gets to check the signature of the driver as provided to it via RPC call from the Kernel against the fixed the AV signature database stored in ELAM registry hive. As such it has its limitation when it comes to detecting heuristic or polymorphing malwares in disguise of drivers.
In case of Kernel Mode Code Signing check, you as an admin, have the Configurable Code Integrity at your disposal which lets you to lock down a system to run trusted apps only. This is pretty restrictive. In its default state though, Code Integrity service is also susceptible to attacks.
Since the fully functional Anti-Malware service starts post kernel initialization, it can’t guarantee a complete reliable and secure OS platform.
This is where Microsoft introduced Windows Measured Boot. (This was actually introduced with Windows 8)
Windows Measured Boot
Windows Measured Boot is an approach similar to Secure Boot – starts with a Root of Trust and then extends the chain as it verifies the cryptographic signature of each component prior to execution.
But unlike Secure Boot, Measured Boot has a hardware dependency – Trusted Platform Module (TPM)
Prior to executing the next component, the currently-running component “measures” or computes the hash of the next component(s) in the chain and this measurement is stored in the TPM PCR banks which can be retrieved later to verify the boot components later on.
The process of storing the measurement at each step to TPM is a one-way hash – irreversible.
PCR new value = SHA Digest of (PCR old value || data to extend)
I have this explained in details here in another blog post.
Thus even if a malware manages to evade the ELAM and Kernel Mode Code Signing check and gets executed during the system boot, with Measured Boot, it will still have its trace captured.
This is Windows Measured Boot – in itself, it does nothing but records the hash of each component to the device TPM that gets executed as the system boots. This measurement can later be retrieved for reporting to AM service for remediation, or for attestation purpose for compliance.
When clubbed together, Secure Boot, Trusted Boot and Measured Boot can vouch for a reliable OS platform suitable for modern enterprise scenarios.
However, Windows Measured Boot also aids in one more thing.
An operating system can enforce its security policies only while it’s active.
But how can it protect the data that resides in the storage drive when it is offline or a malicious user has physical access to the system internals?
This is where Bitlocker Drive Encryption steps in. Windows Measured Boot helps to seal the Bitlocker key to TPM using the boot measurements. If the boot parameters get changed, it will result in a different measurement. TPM only unseals a key if the measurments matches the measurment values with which the key was sealed. This ensures that even if the system is compromised physically, the malicious user wont be able to get access to the data residing in the storage drive easily.
This was all for today. Thanks for reading…