System Guard：基于硬件的信任根如何帮助保护 Windows

若要保护关键资源（例如Windows 身份验证堆栈、单一登录令牌、Windows Hello生物识别堆栈和虚拟受信任的平台模块），系统的固件和硬件必须可信。

System Guard将现有 Windows 系统完整性功能重新组织在一个屋脊下，并设置 Windows 安全性的下一组投资。 它旨在提供以下安全保障：

  • 在系统启动时保护和维护系统的完整性
  • 验证是否通过本地和远程证明真正维护了系统完整性

在系统启动时保持系统的完整性

用于度量的静态信任根 (SRTM)

使用 Windows 7，攻击者用来持久保存和逃避检测的方法之一是在系统上安装通常称为的引导工具包或 rootkit。 此恶意软件将在 Windows 启动之前或启动过程中启动，使它能够以最高级别的特权启动。

由于Windows 10在现代硬件上运行，基于硬件的信任根有助于确保未授权的固件或软件 (（如启动工具包) ）在 Windows 启动加载程序之前无法启动。 此基于硬件的信任根来自设备的安全启动功能，该功能是统一可扩展固件接口 (UEFI) 的一部分。 这种测量静态早期启动 UEFI 组件的技术称为测量 (SRTM) 的静态信任根。

由于有成千上万的电脑供应商生产具有不同 UEFI BIOS 版本的许多型号，因此在启动时，SRTM 测量数量非常多。 此处存在两种建立信任的方法：维护已知“不良”SRTM 度量的列表 (也称为阻止列表) ，或维护已知“良好”SRTM 度量的列表， (也称为允许列表) 。

每个选项都有一个缺点：

  • 已知“坏”SRTM 度量列表允许黑客仅更改组件中的 1 位，以创建需要列出的全新 SRTM 哈希。 这意味着 SRTM 流本质上是脆弱的 - 一个小更改可能会使整个信任链失效。
  • 已知“良好”SRTM 度量的列表要求仔细添加每个新的 BIOS/PC 组合测量，这很慢。 此外，UEFI 代码的 bug 修复可能需要很长时间才能设计、生成、重新测试、验证和重新部署。

安全启动 - 用于度量的动态信任根 (DRTM)

System Guard安全启动（在 Windows 10 版本 1809 中首次引入）旨在通过利用一种称为动态信任根的测量技术来缓解这些问题 (DRTM) 。 DRTM 最初允许系统自由启动到不受信任的代码中，但在启动系统后不久，通过控制所有 CPU 并强制系统进入已知且测量的代码路径。 这样做的好处是允许不受信任的早期 UEFI 代码启动系统，但随后能够安全地转换为受信任的度量状态。

System Guard安全启动。

安全启动简化了 SRTM 度量的管理，因为启动代码现在与特定的硬件配置无关。 这意味着有效代码度量的数量很小，并且将来的更新可以更广泛、更快速地部署。

系统管理模式 (SMM) 保护

系统管理模式 (SMM) 是 x86 微控制器中的一种特殊用途 CPU 模式，用于处理电源管理、硬件配置、热监视以及制造商认为有用的任何其他内容。 每当请求其中一个系统操作时，会在运行时调用不可屏蔽的中断 (SMI) ，这将执行 BIOS 安装的 SMM 代码。 SMM 代码以最高特权级别执行，并且对 OS 不可见，这使得它成为恶意活动的有吸引力的目标。 即使System Guard安全启动用于延迟启动，SMM 代码也可能访问虚拟机监控程序内存并更改虚拟机监控程序。

为了防范这种情况，使用了两种技术：

  • 分页保护，以防止对代码和数据进行不当访问
  • SMM 硬件监督和证明

可以实现分页保护，将某些代码表锁定为只读，以防止篡改。 这会阻止访问任何尚未分配的内存。

硬件强制实施的处理器功能（称为监督器 SMI 处理程序）可以监视 SMM 并确保它无法访问不应访问的地址空间的任何部分。

SMM 保护是基于安全启动技术构建的，需要它才能正常运行。 将来，Windows 10还会测量此 SMI 处理程序的行为，并证明没有操作系统拥有的内存被篡改。

在 Windows 运行时 (运行后验证平台完整性)

虽然System Guard提供了高级保护，有助于在启动期间和运行时保护和维护平台的完整性，但现实情况是，我们必须将“假设违规”心态应用于我们最复杂的安全技术。 我们可以相信，这些技术正在成功地完成其工作，但我们还需要能够验证它们是否成功实现了其目标。 对于平台完整性，我们不能只信任平台（可能遭到入侵）来自我证明其安全状态。 因此，System Guard包括一系列能够远程分析设备完整性的技术。

Windows 启动时，System Guard将使用设备的受信任平台模块 2.0 (TPM 2.0) 进行一系列完整性测量。 System Guard安全启动不支持早期 TPM 版本，例如 TPM 1.2。 此过程和数据在硬件上与 Windows 隔离，以帮助确保测量数据不受平台泄露时可能发生的篡改类型的影响。 在这里，度量值可用于确定设备固件的完整性、硬件配置状态和 Windows 启动相关组件等。

启动时间完整性。

系统启动后，System Guard使用 TPM 对这些度量进行签名和密封。 根据请求，Intune或Microsoft Configuration Manager等管理系统可以获取它们以供远程分析。 如果System Guard指示设备缺乏完整性，则管理系统可以采取一系列操作，例如拒绝设备访问资源。

Windows 版本和许可要求

下表列出了支持System Guard的 Windows 版本：

Windows 专业版 Windows 企业版 Windows 专业教育版/SE Windows 教育版
是 是 是 是

System Guard许可证权利由以下许可证授予：

Windows 专业版/专业教育版/SE Windows 企业版 E3 Windows 企业版 E5 Windows 教育版 A3 Windows 教育版 A5
是 是 是 是 是

有关 Windows 许可的详细信息，请参阅 Windows 许可概述。

System Guard的系统要求

此功能适用于以下处理器：

  • 从 Intel® Coffeelake、Whiskeylake 或更高版本芯片开始的 Intel® vPro™ 处理器
  • 从 Zen2 或更高版本芯片开始的 AMD® 处理器
  • 具有 SD850 或更高版本芯片集的 Qualcomm® 处理器

从 Intel® Coffeelake、Whiskeylake 或更高版本芯片开始的 Intel® vPro™ 处理器的要求

名称 描述
64 位 CPU 虚拟机监控程序和基于虚拟化的安全 (VBS) 需要至少具有 4 个内核的 64 位计算机 (逻辑处理器) 。 有关 Hyper-V 的详细信息，请参阅 Windows Server 2016 上的 Hyper-V 或 Windows 10 上的 Hyper-V 简介。 有关虚拟机监控程序的详细信息，请参阅 虚拟机监控程序规范。
受信任的平台模块 (TPM) 2.0 平台必须支持离散 TPM 2.0。 不支持集成/固件 TPM，但支持平台信任技术的 Intel 芯片 (PTT) 除外，PTT 是一种符合 TPM 2.0 规范的集成硬件 TPM。
Windows DMA 保护 平台必须符合 Windows DMA 保护规范 (所有外部 DMA 端口在 OS 显式) 之前必须关闭。
SMM 通信缓冲区 必须在 EfiRuntimeServicesData、EfiRuntimeServicesCode、EfiACPIMemoryNVS 或 EfiReservedMemoryType 内存类型中实现所有 SMM 通信缓冲区。
SMM 页表 不得包含到 EfiConventionalMemory (的任何映射，例如，没有 OS/VMM 拥有的内存) 。
不得包含到 EfiRuntimeServicesCode 中代码节的任何映射。
不得对同一页具有执行和写入权限
必须仅允许 TSEG 页可以标记为可执行，并且内存映射必须报告 TSEG EfiReservedMemoryType。
必须实现 BIOS SMI 处理程序，以便在每个 SMM 条目上锁定 SMM 页表。
新式/连接待机 平台必须支持新式/连接待机。
TPM AUX 索引 平台必须使用索引、属性和策略设置 AUX 索引，该索引、属性和策略与 SHA256 AUX 数据) 的数据大小正好为 104 字节 (的 TXT DG 中指定的 AUX 索引相对应。 (NameAlg = SHA256)
平台必须使用以下项设置 PS (平台供应商) 索引：
  • 正是创建时“TXT PS2”样式的属性，如下所示：
    • AuthWrite
    • PolicyDelete
    • WriteLocked
    • WriteDefine
    • AuthRead
    • WriteDefine
    • 野田
    • 写
    • PlatformCreate
  • policyCommandCode (CC = TPM2_CC_UndefineSpaceSpecial) (SHA256 NameAlg 和 Policy)
  • 大小正好为 70 个字节
  • NameAlg = SHA256
  • 此外，在操作系统启动时，它必须已初始化并锁定 (TPMA_NV_WRITTEN = 1，TPMA_NV_WRITELOCKED = 1) 。
PS 索引数据 DataRevocationCounters、SINITMinVersion 和 PolicyControl 必须全部0x00
AUX 策略 所需的 AUX 策略必须如下所示：
  • A = TPM2_PolicyLocality (Locality 3 & Locality 4)
  • B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpecial)
  • authPolicy = {A} 或 {{A} AND {B}}
  • authPolicy 摘要 = 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 索引 平台固件必须设置一个 TPM NV 索引，供 OS 使用以下项：
  • 句柄：0x01C101C0
  • 属性：
    • 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 = TPM2_PolicyAuthorize (MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} 或 {{A} AND {B}}
    • 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
平台固件 平台固件必须携带执行 Intel® 受信任执行技术安全启动所需的所有代码：
  • 必须在 OEM BIOS 中携带 Intel® SINIT ACM
  • 平台必须随附由平台的正确生产 Intel® ACM 签名者签名的生产 ACM
平台固件更新 建议通过 Windows 更新 中的 UpdateCapsule 更新系统固件。

从 Zen2 或更高版本芯片开始的 AMD® 处理器的要求

名称 描述
64 位 CPU 虚拟机监控程序和基于虚拟化的安全 (VBS) 需要至少具有 4 个内核的 64 位计算机 (逻辑处理器) 。 有关 Hyper-V 的详细信息，请参阅 Windows Server 2016 上的 Hyper-V 或 Windows 10 上的 Hyper-V 简介。 有关虚拟机监控程序的详细信息，请参阅 虚拟机监控程序规范。
受信任的平台模块 (TPM) 2.0 平台必须支持离散 TPM 2.0 或 Microsoft Pluton TPM。
Windows DMA 保护 平台必须符合 Windows DMA 保护规范 (所有外部 DMA 端口在 OS 显式) 之前必须关闭。
SMM 通信缓冲区 必须在 EfiRuntimeServicesData、EfiRuntimeServicesCode、EfiACPIMemoryNVS 或 EfiReservedMemoryType 内存类型中实现所有 SMM 通信缓冲区。
SMM 页表 不得包含到 EfiConventionalMemory (的任何映射，例如，没有 OS/VMM 拥有的内存) 。
不得包含到 EfiRuntimeServicesCode 中代码节的任何映射。
不得对同一页具有执行和写入权限
必须实现 BIOS SMI 处理程序，以便在每个 SMM 条目上锁定 SMM 页表。
新式/连接待机 平台必须支持新式/连接待机。
TPM NV 索引 平台固件必须设置一个 TPM NV 索引，供 OS 使用以下项：
  • 句柄：0x01C101C0
  • 属性：
    • 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 = TPM2_PolicyAuthorize (MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} 或 {{A} AND {B}}
    • 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
平台固件 平台固件必须携带执行安全启动所需的所有代码：
  • AMD® 安全启动平台必须附带公开的 AMD® DRTM 驱动程序开发节点和已安装的 AMD® DRTM 驱动程序

平台必须启用 AMD® 安全处理器固件反回滚保护
平台必须启用 AMD® 内存防护。
平台固件更新 建议通过 Windows 更新 中的 UpdateCapsule 更新系统固件。

使用 SD850 或更高版本芯片集的 Qualcomm® 处理器的要求

名称 描述
监视模式通信 必须在 EfiRuntimeServicesData (推荐) 、EfiRuntimeServicesCode 的数据部分（如内存属性表、EfiACPIMemoryNVS 或 EfiReservedMemoryType 内存类型所述）中实现所有监视器模式通信缓冲区
监视模式页表 所有监视器模式页表必须：
  • 不包含到 EfiConventionalMemory (的任何映射，例如，没有 OS/VMM 拥有的内存)
  • 他们不得对同一页具有执行和写入权限
  • 平台必须仅允许标记为可执行文件的监视模式页面
  • 内存映射必须将监视模式报告为 EfiReservedMemoryType
  • 平台必须提供机制来保护监视模式页表不受修改
新式/连接待机 平台必须支持新式/连接待机。
平台固件 平台固件必须携带启动所需的所有代码。
平台固件更新 建议通过 Windows 更新 中的 UpdateCapsule 更新系统固件。