Security is a broad topic that has components across all layers of the technology stack. Lately I’ve been investigating the concept of Secured-core computing, available with hardware from OEM providers running Windows 10 and now also Windows Server 2022 (preview). Why would you use a secured-core device and what additional security features does it have?
A known-secure foundation for mission-critical data
You might be familiar with Windows security features like Bitlocker device encryption or Microsoft Defender. If you’re handling or storing sensitive data on a device, Secured-core capabilities can provide further assurance that the hypervisor or the operating system has not been tampered with and access to data in memory is protected.
When you have financial details, medical records, personally identifiable information or commercially sensitive or secret data, the combination of hardware, firmware and software capabilities in a secured-core system help protect against sophisticated attacks.
Secured-core capabilities
Let’s explore some of the additional protection capabilities available with a secured-core Windows PC or Windows Server, with selected OEM hardware.
Hardware root of trust with TPM 2.0
Trusted Platform Modules (TPM) can be either hardware chips embedded in the motherboard or added on, or newer processors can come with firmware-based TPM. A TPM can create and store encryption keys and store other secrets like certificates. This chip storage is separate from traditional disk or memory storage used by the operating system and applications, so it’s isolated from software-based attacks. As you would expect, TPM 2.0 has more features than the previous 1.2 version, including supporting the SHA-2 256 hash algorithm.
This little piece of hardware can check the integrity of the BIOS and firmware of the device, comparing it to information that has been burned into the chip by the device manufacturer. This Secure Boot capability confirms that no unauthorized firmware or software has been loaded before the operating system, and lets the operating system proceed to load. This gives us a “hardware root of trust” – a hardware level verification that the rest of the operating system and applications can rely on.
For more information, visit Trusted Platform Module Technology Overview and How Windows 10 uses the TPM.
Dynamic Root of Trust for Measurement (DRTM)
Root of Trust for Measurement (RTM) doesn’t live solely inside the TPM chip, but it’s a software capability that the TPM helps out with. Here we want to measure that the environment that is booting is untampered and verified, similar to how you’d request someone to verify their identity with trusted documentation. Because I know that an Australian citizen has a certain drivers license, medical card and passport, I can ‘measure’ the ones you’ve shown me against what I know is accurate, and then I can trust you.
The challenge is that there are many different things that happen during boot (known as the boot chain) – these can change over time and change the order in which they load. Dynamic Root of Trust for Measurement solves this, allowing the components to load first and then be measured. Again, this root of trust is another security-check that system components (the boot chain) has not been tampered with.
For more information, visit Windows Defender System Guard: How a hardware-based root of trust helps protect Windows 10
Kernel Direct Memory Access (DMA) protection
PCI devices, like high performance graphics cards, used to be connected to the motherboard via PCI slots or soldered onto the motherboard. These device have direct access to read and write system memory, with using the system processor, hence why they are perfect for high performance tasks. With externally accessible PCIe ports, you can now plug in certain PCI devices like you would a USB key. Unfortunately, that means an unattended device could now have a malicious PCI device plugged into it, which could read the system memory or load malicious code into it, with no protection (known as a drive-by attack).
Kernel DMA protection uses the Input/Output Memory Management Unit (IOMMU) to block PCI devices unless the drivers for that device support memory isolation, like DMA remapping. DMA remapping restricts the device to a certain memory ‘location’ (a pre-assigned domain or physical memory region). That ensure that the device is allocated a clear space of memory to perform its functions, and doesn’t have access to any other information stored in system memory. If the device driver doesn’t support DMA re-mapping, it won’t be able to run on a secured-core device.
For more information, visit Kernel DMA Protection and detailed specifications at Kernel DMA Protection (Memory Access Protection) for OEMs
Virtualization-based security (VBS) and Hypervisor-based code integrity (HVCI)
Imagine if you ran a virtual machine on your computer that was completely isolated from your host operating system. Your computer has no idea that this other thing is actually running on the same hardware, using the same physical resources, and you can limit whether your computer can ping it or transfer files to or from it. Virtualization-based security uses hardware-based virtualization features to create and isolate a secure region of memory away from the operating system, similar to running a VM. Windows can now use this to protect authenticated user credentials and run other security features, away from the grips of any malware that gains access to the OS kernel.
Hypervisor-based code integrity (HVCI) uses VBS to check the integrity of kernel mode drivers and binaries before they are started and prevents unsigned drivers or system files from being loaded into system memory. User-mode configurable code integrity policy checks applications before they're loaded, and will only start executables that are signed by known, approved signers. While this may sound similar to a user account control prompt (do you trust this application?), the difference is that VBS is running these checks in an isolated environment. The code does not get access to the hypervisor or system memory until it has been checked and verified inside the VBS environment.
For more information, visit Virtualization-based Security (VBS) and Hypervisor-protected Code Integrity enablement
Conclusion:
Secured-core capabilities for Windows 10 and Windows Server 2022 were really interesting to wrap my head around. It’s indicative of just how much happens during the boot process and the potential for security attacks at the very bottom layers of the technology stack. I hope you found this article interesting too!