Windows Defender System Guard: How a hardware-based root of trust helps protect Windows 10

To protect critical resources such as the Windows authentication stack, single sign-on tokens, the Windows Hello biometric stack, and the Virtual Trusted Platform Module, a system's firmware and hardware must be trustworthy.

Windows Defender System Guard reorganizes the existing Windows 10 system integrity features under one roof and sets up the next set of investments in Windows security. It's designed to make these security guarantees:

  • Protect and maintain the integrity of the system as it starts up
  • Validate that system integrity has truly been maintained through local and remote attestation

Maintaining the integrity of the system as it starts

Static Root of Trust for Measurement (SRTM)

With Windows 7, one of the means attackers would use to persist and evade detection was to install what is often referred to as a bootkit or rootkit on the system. This malicious software would start before Windows started, or during the boot process itself, enabling it to start with the highest level of privilege.

With Windows 10 running on modern hardware (that is, Windows 8-certified or greater) a hardware-based root of trust helps ensure that no unauthorized firmware or software (such as a bootkit) can start before the Windows bootloader. This hardware-based root of trust comes from the device’s Secure Boot feature, which is part of the Unified Extensible Firmware Interface (UEFI). This technique of measuring the static early boot UEFI components is called the Static Root of Trust for Measurement (SRTM).

As there are thousands of PC vendors that produce many models with different UEFI BIOS versions, there becomes an incredibly large number of SRTM measurements upon bootup. Two techniques exist to establish trust here—either maintain a list of known 'bad' SRTM measurements (also known as a blocklist), or a list of known 'good' SRTM measurements (also known as an allowlist).

Each option has a drawback:

  • A list of known 'bad' SRTM measurements allows a hacker to change just 1 bit in a component to create an entirely new SRTM hash that needs to be listed. This means that the SRTM flow is inherently brittle - a minor change can invalidate the entire chain of trust.
  • A list of known 'good' SRTM measurements requires each new BIOS/PC combination measurement to be carefully added, which is slow. Also, a bug fix for UEFI code can take a long time to design, build, retest, validate, and redeploy.

Secure Launch—the Dynamic Root of Trust for Measurement (DRTM)

Windows Defender System Guard Secure Launch, first introduced in Windows 10 version 1809, aims to alleviate these issues by leveraging a technology known as the Dynamic Root of Trust for Measurement (DRTM). DRTM lets the system freely boot into untrusted code initially, but shortly after launches the system into a trusted state by taking control of all CPUs and forcing them down a well-known and measured code path. This has the benefit of allowing untrusted early UEFI code to boot the system, but then being able to securely transition into a trusted and measured state.

System Guard Secure Launch.

Secure Launch simplifies management of SRTM measurements because the launch code is now unrelated to a specific hardware configuration. This means the number of valid code measurements is small, and future updates can be deployed more widely and quickly.

System Management Mode (SMM) protection

System Management Mode (SMM) is a special-purpose CPU mode in x86 microcontrollers that handles power management, hardware configuration, thermal monitoring, and anything else the manufacturer deems useful. Whenever one of these system operations is requested, a non-maskable interrupt (SMI) is invoked at runtime, which executes SMM code installed by the BIOS. SMM code executes in the highest privilege level and is invisible to the OS, which makes it an attractive target for malicious activity. Even if System Guard Secure Launch is used to late launch, SMM code can potentially access hypervisor memory and change the hypervisor.

To defend against this, two techniques are used:

  • Paging protection to prevent inappropriate access to code and data
  • SMM hardware supervision and attestation

Paging protection can be implemented to lock certain code tables to be read-only to prevent tampering. This prevents access to any memory that hasn't been assigned.

A hardware-enforced processor feature known as a supervisor SMI handler can monitor the SMM and make sure it doesn't access any part of the address space that it isn't supposed to.

SMM protection is built on top of the Secure Launch technology and requires it to function. In the future, Windows 10 will also measure this SMI Handler’s behavior and attest that no OS-owned memory has been tampered with.

Validating platform integrity after Windows is running (run time)

While Windows Defender System Guard provides advanced protection that will help protect and maintain the integrity of the platform during boot and at run time, the reality is that we must apply an "assume breach" mentality to even our most sophisticated security technologies. We can trust that the technologies are successfully doing their jobs, but we also need the ability to verify that they were successful in achieving their goals. For platform integrity, we can’t just trust the platform, which potentially could be compromised, to self-attest to its security state. So Windows Defender System Guard includes a series of technologies that enable remote analysis of the device’s integrity.

As Windows 10 boots, a series of integrity measurements are taken by Windows Defender System Guard using the device’s Trusted Platform Module 2.0 (TPM 2.0). System Guard Secure Launch won't support earlier TPM versions, such as TPM 1.2. This process and data are hardware-isolated away from Windows to help ensure that the measurement data isn't subject to the type of tampering that could happen if the platform was compromised. From here, the measurements can be used to determine the integrity of the device’s firmware, hardware configuration state, and Windows boot-related components, just to name a few.

Boot time integrity.

After the system boots, Windows Defender System Guard signs and seals these measurements using the TPM. Upon request, a management system like Intune or Microsoft Configuration Manager can acquire them for remote analysis. If Windows Defender System Guard indicates that the device lacks integrity, the management system can take a series of actions, such as denying the device access to resources.

System requirements for System Guard

For Intel® vPro™ processors starting with Intel® Coffeelake, Whiskeylake, or later silicon Description
64-bit CPU A 64-bit computer with minimum four cores (logical processors) is required for hypervisor and virtualization-based security (VBS). For more information about Hyper-V, see Hyper-V on Windows Server 2016 or Introduction to Hyper-V on Windows 10. For more information about hypervisor, see Hypervisor Specifications.
Trusted Platform Module (TPM) 2.0 Platforms must support a discrete TPM 2.0. Integrated/firmware TPMs aren't supported, except Intel chips that support Platform Trust Technology (PTT), which is a type of integrated hardware TPM that meets the TPM 2.0 spec.
Windows DMA Protection Platforms must meet the Windows DMA Protection Specification (all external DMA ports must be off by default until the OS explicitly powers them).
SMM communication buffers All SMM communication buffers must be implemented in EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS, or EfiReservedMemoryType memory types.
SMM Page Tables Must NOT contain any mappings to EfiConventionalMemory (for example no OS/VMM owned memory).
Must NOT contain any mappings to code sections within EfiRuntimeServicesCode.
Must NOT have execute and write permissions for the same page
Must allow ONLY that TSEG pages can be marked executable and the memory map must report TSEG EfiReservedMemoryType.
BIOS SMI handler must be implemented such that SMM page tables are locked on every SMM entry.
Modern/Connected Standby Platforms must support Modern/Connected Standby.
TPM AUX Index Platform must set up a AUX index with index, attributes, and policy that exactly corresponds to the AUX index specified in the TXT DG with a data size of exactly 104 bytes (for SHA256 AUX data). (NameAlg = SHA256)
Platforms must set up a PS (Platform Supplier) index with:
  • Exactly the "TXT PS2" style Attributes on creation as follows:
    • AuthWrite
    • PolicyDelete
    • WriteLocked
    • WriteDefine
    • AuthRead
    • WriteDefine
    • NoDa
    • Written
    • PlatformCreate
  • A policy of exactly PolicyCommandCode(CC = TPM2_CC_UndefineSpaceSpecial) (SHA256 NameAlg and Policy)
  • Size of exactly 70 bytes
  • NameAlg = SHA256
  • Also, it must have been initialized and locked (TPMA_NV_WRITTEN = 1, TPMA_NV_WRITELOCKED = 1) at time of OS launch.
PS index data DataRevocationCounters, SINITMinVersion, and PolicyControl must all be 0x00
AUX Policy The required AUX policy must be as follows:
  • A = TPM2_PolicyLocality (Locality 3 & Locality 4)
  • B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpecial)
  • authPolicy = {A} OR {{A} AND {B}}
  • authPolicy digest = 0xef, 0x9a, 0x26, 0xfc, 0x22, 0xd1, 0xae, 0x8c, 0xec, 0xff, 0x59, 0xe9, 0x48, 0x1a, 0xc1, 0xec, 0x53, 0x3d, 0xbe, 0x22, 0x8b, 0xec, 0x6d, 0x17, 0x93, 0x0f, 0x4c, 0xb2, 0xcc, 0x5b, 0x97, 0x24
TPM NV Index Platform firmware must set up a TPM NV index for use by the OS with:
  • Handle: 0x01C101C0
  • Attributes:
    • TPMA_NV_POLICYWRITE
    • TPMA_NV_PPREAD
    • TPMA_NV_OWNERREAD
    • TPMA_NV_AUTHREAD
    • TPMA_NV_POLICYREAD
    • TPMA_NV_NO_DA
    • TPMA_NV_PLATFORMCREATE
    • TPMA_NV_POLICY_DELETE
  • A policy of:
    • A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} OR {{A} AND {B}}
    • Digest value of 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
Platform firmware Platform firmware must carry all code required to execute an Intel® Trusted Execution Technology secure launch:
  • Intel® SINIT ACM must be carried in the OEM BIOS
  • Platforms must ship with a production ACM signed by the correct production Intel® ACM signer for the platform
Platform firmware update System firmware is recommended to be updated via UpdateCapsule in Windows Update.
For AMD® processors starting with Zen2 or later silicon Description
64-bit CPU A 64-bit computer with minimum four cores (logical processors) is required for hypervisor and virtualization-based security (VBS). For more information about Hyper-V, see Hyper-V on Windows Server 2016 or Introduction to Hyper-V on Windows 10. For more information about hypervisor, see Hypervisor Specifications.
Trusted Platform Module (TPM) 2.0 Platforms must support a discrete TPM 2.0 OR Microsoft Pluton TPM.
Windows DMA Protection Platforms must meet the Windows DMA Protection Specification (all external DMA ports must be off by default until the OS explicitly powers them).
SMM communication buffers All SMM communication buffers must be implemented in EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS, or EfiReservedMemoryType memory types.
SMM Page Tables Must NOT contain any mappings to EfiConventionalMemory (for example no OS/VMM owned memory).
Must NOT contain any mappings to code sections within EfiRuntimeServicesCode.
Must NOT have execute and write permissions for the same page
BIOS SMI handler must be implemented such that SMM page tables are locked on every SMM entry.
Modern/Connected Standby Platforms must support Modern/Connected Standby.
TPM NV Index Platform firmware must set up a TPM NV index for use by the OS with:
  • Handle: 0x01C101C0
  • Attributes:
    • TPMA_NV_POLICYWRITE
    • TPMA_NV_PPREAD
    • TPMA_NV_OWNERREAD
    • TPMA_NV_AUTHREAD
    • TPMA_NV_POLICYREAD
    • TPMA_NV_NO_DA
    • TPMA_NV_PLATFORMCREATE
    • TPMA_NV_POLICY_DELETE
  • A policy of:
    • A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} OR {{A} AND {B}}
    • Digest value of 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
Platform firmware Platform firmware must carry all code required to execute Secure Launch:
  • AMD® Secure Launch platforms must ship with AMD® DRTM driver devnode exposed and the AMD® DRTM driver installed

Platform must have AMD® Secure Processor Firmware Anti-Rollback protection enabled
Platform must have AMD® Memory Guard enabled.
Platform firmware update System firmware is recommended to be updated via UpdateCapsule in Windows Update.
For Qualcomm® processors with SD850 or later chipsets Description
Monitor Mode Communication All Monitor Mode communication buffers must be implemented in either EfiRuntimeServicesData (recommended), data sections of EfiRuntimeServicesCode as described by the Memory Attributes Table, EfiACPIMemoryNVS, or EfiReservedMemoryType memory types
Monitor Mode Page Tables All Monitor Mode page tables must:
  • NOT contain any mappings to EfiConventionalMemory (for example no OS/VMM owned memory)
  • They must NOT have execute and write permissions for the same page
  • Platforms must only allow Monitor Mode pages marked as executable
  • The memory map must report Monitor Mode as EfiReservedMemoryType
  • Platforms must provide mechanism to protect the Monitor Mode page tables from modification
Modern/Connected Standby Platforms must support Modern/Connected Standby.
Platform firmware Platform firmware must carry all code required to launch.
Platform firmware update System firmware is recommended to be updated via UpdateCapsule in Windows Update.