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

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

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

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

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

度量 (SRTM) 的静态信任根

使用 Windows 7 时,攻击者用来持久保存和逃避检测的方法之一是在系统上安装通常称为 bootkit 或 rootkit 的设备。 此恶意软件将在 Windows 启动之前启动,或者在启动过程本身期间启动,使其能够以最高级别的特权开始。

Windows 10在经过Windows 8认证或更高版本的新式硬件 (上运行,) 基于硬件的信任根,有助于确保未经授权的固件或软件 ((例如 bootkit) )可以在 Windows 启动加载程序之前启动。 这种基于硬件的信任根源来自设备的安全启动功能,它是统一可扩展固件接口 (UEFI) 的一部分。 这种测量静态早期启动 UEFI 组件的方法称为静态信任根,用于度量 (SRTM) 。

由于有成千上万的电脑供应商生产许多具有不同 UEFI BIOS 版本的模型,因此启动时会出现大量 SRTM 度量。 此处存在两种建立信任的方法-要么维护已知的“坏”SRTM 度量列表 (也称为阻止列表) ,要么保留已知的“好”SRTM 度量列表 (也称为允许列表) 。

每个选项都有一个缺点:

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

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

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

System Guard 安全启动。

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

系统管理模式 (SMM) 保护

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

若要防御此问题,请使用两种技术:

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

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

称为主管 SMI 处理程序的硬件强制处理器功能可以监视 SMM,并确保它不访问它不应访问的地址空间的任何部分。

SMM 保护基于安全启动技术构建,需要其正常运行。 将来,Windows 10还将衡量此 SMI 处理程序的行为,并证明未篡改任何 OS 拥有的内存。

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

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

Windows 10启动时,Windows Defender System Guard使用设备的受信任平台模块 2.0 (TPM 2.0) 执行一系列完整性度量。 System Guard 安全启动不支持早期的 TPM 版本,例如 TPM 1.2。 此过程和数据在硬件上与 Windows 隔离,以帮助确保度量数据不受平台遭到入侵时可能发生的篡改类型。 在此处,度量可用于确定设备固件、硬件配置状态和 Windows 启动相关组件的完整性,仅举几例。

启动时间完整性。

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

System Guard 的系统要求

对于以 Intel® Coffeelake、威士忌湖或更高版本硅开头的 Intel® vPro™ 处理器 描述
64 位 CPU 虚拟机监控程序和基于虚拟化的安全 (VBS) 需要一台 64 位计算机,其中至少有四个内核 (逻辑处理器) 。 有关 Hyper-V 的详细信息,请参阅 Windows Server 2016 上的 Hyper-VWindows 10 上的 Hyper-V 简介。 有关虚拟机监控程序的详细信息,请参阅 虚拟机监控程序规范
受信任的平台模块 (TPM) 2.0 平台必须支持离散 TPM 2.0。 除了支持平台信任技术的 Intel 芯片 (PTT) (一种符合 TPM 2.0 规范的集成硬件 TPM)外,不支持集成/固件 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 索引,其索引、属性和策略与 TXT DG 中指定的 AUX 索引完全对应,而 SHA256 AUX 数据) 的数据大小正好为 104 字节 (。 (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) 在 OS 启动时。
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) 需要一台 64 位计算机,其中至少有四个内核 (逻辑处理器) 。 有关 Hyper-V 的详细信息,请参阅 Windows Server 2016 上的 Hyper-VWindows 10 上的 Hyper-V 简介。 有关虚拟机监控程序的详细信息,请参阅 虚拟机监控程序规范
受信任的平台模块 (TPM) 2.0 平台必须支持离散 TPM 2.0 或 Microsoft 冥王星 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 更新系统固件。