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 discuss another feature that ensures the platform’s 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, the 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 the Kernel Mode Code Signing check for integrity.
Is this a full-proof security mechanism?
Security is a subjective matter. If I talk about myself as an admin, what I consider secure, the end-user may feel the same as for restrictive, hampering his daily work. As such, a balance needs to be struck between security and usability.
Why am I saying such?
By default, KeKernelxecutes, the drivers that return ELAM classification Good, Bad but Critical for Boot and Unknown. This is best for usability.
But as an admin, you can modify this behavior to let only drivers who return a Good classification from ELAM get executed. However, this is most secure but can lead to an unstable system failing to boot.
Also, the ELAM driver only gets to check the driver’s signature as provided to it via RPC call from the KeKernelgainst, the fixed AV signature database stored in the ELAM registry hive. It has its limitation when detecting heuristic or polymorphing malware in the disguise of drivers.
In the case of Kernel Mode Code Signing check, you, as an admin, have the Configurable Code Integrity at your disposal, which lets you lock down a system to run trusted apps only. This is pretty restrictive. In its default state, though, the Code Integrity service is also susceptible to attacks.
Since the fully functional Anti-Malware service starts post keKernelnitialization, it cacan’tuarantee a completely reliable and secure OS platform.
This is where Microsoft introduced Windows Measured Boot. (This was introduced with Windows 8)
Windows Measured Boot
Windows Measured Boot is an approach similar to Secure Boot – it starts with a Root of Trust. It then extends the chain as it verifies the cryptographic signature of each component before execution.
But unlike Secure Boot, Measured Boot has a hardware dependency – Trusted Platform Module (TPM)
Before executing the next component, the currently-running component “m “assures” “r computes the hash of the next element (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 detail herein in another blog post.
Thus even if 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 record 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 attestation purposes for compliance.
Secure Boot, Trusted Boot, and Measured Boot can vouch for a reliable OS platform suitable for modern enterprise scenarios when clubbed together.
However, Windows Measured Boot also aids in one more thing.
An operating system can enforce its security policies only while itit’sctive.
But how can it protect the data 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 seal the Bitlocker key to TPM using the boot measurements. If the boot parameters get changed, it will be a different measurement.
TPM only unseals a key if the measurements match the measurement values with which the key was sealed. This ensures that even if the system is compromised physically, the malicious user wowon’te able to easily access the data residing in the storage drive.
This was all for today. Thanks for reading