硬件安全可测试性规范

项目
06/20/2023

简介

HSTI 可防止 Windows 设备上的安全功能配置错误。对于客户而言，HSTI 尽最大努力确保他们购买的计算机在默认情况下是安全的。对于 IHV 和 IBV，HSTI 可确保遵守安全承诺。对于 OEM 和 ODM，它可以轻松确保交付的系统配置了开箱即用的安全性，并且将保持安全，而无需开发专有解决方案。

HSTI 测试的结果将由 Windows 兼容性测试使用，并且该结果可用于验证设备是否已正确配置为启用支持的安全功能。这些测试可用于识别现场不安全的工程设备，例如，可能包含不安全测试密钥的工程设备。 Windows 操作系统可能会使用这些测试的结果在不安全的设备上显示水印（或类似标记）。

注意

需要使用平台来实现硬件接口，并共用本主题中指定的文档和工具。

背景

读者需要了解 UEFI 的基础知识，并了解安全启动技术，包括 UEFI 规范和 NIST SP 800-147 的第 27 部分“安全性”。

此要求包含三个方面：

用于查询硬件和固件安全状态的独立于平台的接口
上述接口实现的设计和可选代码评审
共享文档和工具

基础实现

位域

IHV 定义了代表平台的可测试安全功能的位域。此位域完全涵盖了所有 IHV、IBV 或 OEM HSTI 测试返回的 HSTI 对象的所有可定义位。 IHV 实现器必须设计位域的定义，并提供适当的文档，以便 IBV 正确返回 HSTI 测试的结果。

SecurityFeaturesRequired

SecurityFeaturesRequired 字段仅用于处理 IHV HSTI 对象中的字段，并且是 IHV 定义所需安全功能的位域的方法。

SecurityFeaturesImplemented

这是由返回 HSTI 对象的测试实现的安全功能的位域。

SecurityFeaturesVerified

这是由返回 HSTI 对象的测试验证的安全功能的位域。

实现指南

IHV 将为符合 Windows 兼容性要求的平台开发参考安全设计。此外，IHV 和 IBV 还将实现以编程方式进行的测试，验证是否正确启用了参考安全实现，并通过硬件安全测试接口报告结果。这些测试将作为编译模块（而不是源）传递到 OEM 和 ODM，并且应该无需修改即可正常运行。如果 OEM/ODM 偏离了参考安全设计，则这些测试模块可能会报告故障，OEM/ODM 将需要联系 Microsoft 来评审修改并实现报告这些异常的其他 HSTI 实例。根据参考设计和文档，OEM 应能够利用这些安全模块，而无需进行修改。要添加其他安全模块或修改任何安全模块行为的 OEM 必须与 Microsoft 进行设计评审。

作为测试实现的一部分，模块实现者将包含一个结构。下文的“原型”部分中包含了此结构的原型。 IHV 将在安全参考清单中定义每个位的含义。 IHV 会进一步定义位域中每个位的含义。最后，IHV 将在 OEM 结构中包含“必需”位域，并且对于能够以编程方式进行测试的所有要求，都将在“已实现”位域中设置一个位。

IBV 和 OEM 能够在“已实现”字段中设置位，前提是他们向 Microsoft 提交了设计，并且该设计中可以通过编程方式检查这些位所代表的安全功能是否存在。如果这些测试通过，它们可以在各自的结构中设置“已验证”字段。

如果存在，则应运行适用于 IHV、IBV 和 OEM 的测试模块。在 SecurityFeaturesEnabled 字段中的某个位上设置的 true 值表示测试结果通过。如果测试未运行或未通过，则应为代表位设置值 0。

结果处理逻辑示例

此示例代表将由结果处理使用的逻辑。实现的位域必须遵循以下格式：1 表示已实现，0 表示未实现。如果实现了某些内容，则需要它。结果位域必须遵循以下格式：0 表示失败或测试不存在，1 仅表示确认通过。

计算完所有结果后，IHV 结果位域将与其必需位域一起进行 NXORd。所有非 IHV 结果位域都与其各自实现的位域进行 ANDed。生成的位域都 ORd 在一起，以获取总体结果。此操作的传递结果将是一个完全由 1 组成的位域。

可交付结果和所有权

独立硬件供应商 (IHV) 和独立 BIOS 供应商 (IBV)

支持连接待机系统的芯片供应商和 IBV 必须实现独立于平台的接口，以便查询其参考平台各自的硬件和固件安全状态。这些实现必须作为编译的模块提供。建议对这些模块进行签名，并在运行它们时执行签名检查。这样做的目的是查询硬件和固件设计以及状态，以报告平台的正确安全预配。

OEM 和 ODM

OEM 和 ODM 不能修改或篡改供应商向其提供的 HSTI 测试。需要 OEM 和 ODM 确保其系统将 HSTI 测试作为 Windows 认证要求的组成部分进行传递：

Windows 硬件认证要求 - Windows 8.1 WHCR

System.Fundamentals.Firmware.UEFISecureBoot
System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby

如果 OEM 要求一种方法提供替代方法来实现相同或更好的安全性，而不是进行修改，则 OEM 可以提供额外的安全检查。 OEM 安全检查必须至少完全涵盖一个 IHV 或 IBV 安全测试。使用之前，OEM 必须提交给 Microsoft 进行设计评审，并且遵守与其他 HSTI 测试提供商相同的文档和工具披露要求。获得 Microsoft 的批准后，OEM 可以纳入对 IHV 和 IBV 测试进行延伸的安全测试。

请注意，HSTI 设计中不需要 OEM 证明。 HSTI 不是 OEM 的要求列表，它是一个用于保证固件、硬件和配置参数的有效编程安全测试的接口。

安全状态接口

接口基于 UEFI 版本 2.4 中定义的 EFI 适配器信息协议生成。

平台安全状态接口

摘要

平台安全信息 - 返回有关平台与 Windows 硬件认证要求相关的符合性 System.Fundamentals.Firmware.CS.UEFISecureBoot、System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby 和 System.Fundamentals.Firmware.CS.UEFISecureBoot.Provisioning。

原型

InformationType

#define ADAPTER_INFO_PLATFORM_SECURITY_GUID \
     {0x6be272c7, 0x1320, 0x4ccd, { 0x90, 0x17, 0xd4, 0x61, 0x2c, 0x01, 0x2b, 0x25 }}

#define PLATFORM_SECURITY_VERSION_VNEXTCS   0x00000003

#define PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE   0x00000001  // IHV
#define PLATFORM_SECURITY_ROLE_PLATFORM_IBV 0x00000002
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_OEM 0x00000003 
#define PLATFORM_SECURITY_ROLE_IMPLEMENTOR_ODM  0x00000004

对应的 InformationBlock：

typedef struct { 
    UINT32  Version,
    UINT32  Role,
    CHAR16  ImplementationID[256],
    UINT32  SecurityFeaturesSize,
    UINT8   SecurityFeaturesRequired[],     //Ignored for non-IHV
    UINT8   SecurityFeaturesImplemented[],
    UINT8   SecurityFeaturesVerified[],
    // CHAR16   ErrorString[];
} ADAPTER_INFO_PLATFORM_SECURITY;

术语	说明
版本	返回 PLATFORM_SECURITY_VERSION_VNEXTCS
角色	此接口的发行者的角色。参考平台设计器（例如 IHV 和 IBV）应分别返回 PLATFORM_SECURITY_ROLE_PLATFORM_REFERENCE 和 PLATFORM_SECURITY_ROLE_PLATFORM_IBV。如果设计器中的测试模块无法完全验证所有安全功能，则平台实现者（OEM 和 ODM）将需要使用实施者角色发布此接口。
ImplementationID	此实现的人工可读供应商、型号和版本。例如“SiliconVendorX Chip1234 v1”和“BIOSvendorY BIOSz v2”。
SecurityFeaturesSize	SecurityFeaturesRequired and SecurityFeaturesEnabled 数组的大小（以字节为单位）。数组必须具有相同的大小。
SecurityFeaturesRequired	IHV 定义的位域，对应于必须实现以满足 PLATFORM_SECURITY_VERSION 版本定义的安全要求的所有安全功能。例如，可能需要实现 7 个功能才能满足版本要求，并且可能会报告值 0b01111111。
SecurityFeaturesImplemented	发行者定义的位域，与已在此模块中实现编程测试的所有安全功能相对应。
SecurityFeaturesVerified	发行者定义的位域，与此实现验证的所有安全功能相对应。
ErrorString	以 Null 结尾的字符串，每行一个故障（以 CR/LF 终止），带有唯一标识符，OEM/ODM 可以使用该标识符定位文档，该文档将描述修正故障的步骤 - 建议使用文档的 URL。例如，应用于对象的 0x4827 JTAG not disabled http://somewhere.net/docs/remediate4827.html \r\n0x2744 Platform Secure Boot key not provisioned http://somewhere.net/docs/remediate2744.html

内存管理注意事项

为了在 HSTI 模块之间实现兼容性，实现者应使用 AllocatePool() 而不是 AllocatePages()。

HSTI 实现的设计评审

Microsoft 应对所有测试接口实现进行初步的设计评审。 “HSTI 设计注意事项”部分提供了设计评审中可能询问的问题示例。

可选代码评审

HSTI 实现者可以请求由 Microsoft 执行代码评审。可以根据资源的优先级和可用性（但不能保证）来提供代码评审。代码评审将在遵守保密协议的前提下进行。

芯片和固件供应商应该向 Microsoft 提供它们向 OEM 提供的所有所需的与安全相关的参考文档和工具。这些文档和工具应在提供给 Windows OEM 之前提供。这些内容应该包括但不限于与融合、安装和更新固件、固件和启动恢复、硬件诊断、固件诊断和启动诊断相关的所有文档和工具。提供的文档和工具应该完全足以在实验室环境中执行 HSTI 检查。

HSTI 设计注意事项

下面是 HSTI 实现者必须为其 HSTI 实现考虑的设计注意事项的直观列表。这并不是要求的严格列表，也不是注意事项的详尽列表。作为 HSTI 实现者，你将编写测试来验证拥有的安全功能，并努力实现尽可能全面的覆盖。与 Microsoft 进行设计评审之前，建议查看此列表以获取灵感，并考虑到 Microsoft 可能希望在实现这些功能时，尽可能地进行测试。

芯片供应商 (IHV) HSTI 检查

是否仅使用 RSA 2048 和 SHA256（或类似的加密强度）
固件代码必须位于受保护的存储中
1. 是否保护 spiflash？
2. 是否为 eMMC 分区实现只读，直到重置
3. 是否支持签名固件检查 - 由 OEM 安装的固件为只读，或者受安全固件更新过程保护。
安全固件更新过程
1. 默认情况下，是否使用测试密钥进行安全固件更新过程？（推荐）
2. 是否检查在生产环境中使用了测试密钥？
3. 是否允许回退到不安全的固件版本？如果是，则保护机制是什么？发生回退时是否清除了 TPM？
是否拥有用于替代 SecureBoot 的后门
1. 系统是否支持绕过 Secureboot 的内联提示？如果是，则是否在启用 SecureBoot 后禁用它？
2. 是否有制造后门？是否在启用 SecureBoot 后禁用它们，并始终在生产系统中禁用这些后门？
[CS] 启动完整性支持
1. 是否支持启动完整性？默认情况下是否启用了启动完整性？
2. 平台使用片载 ROM 或一次性可编程 (OTP) 内存来存储初始启动代码，并提供开机重置逻辑，以便从片载 ROM 或安全的片载 SRAM 上执行。
[CS] 内部和外部 DMA 保护
1. 是否只对启动过程中所需的组件保留内部 DMA？并且对所有其他组件都禁用了它？
2. 是否只对启动过程中所需的组件保留外部 DMA？并且对所有其他组件都禁用了它？
3. 如果固件具有启用和禁用 DMA 保护的选项，则在默认情况下，交付配置必须启用 DMA 保护
4. 哪些总线/设备（熔丝、安全引擎、TZ、视频、缓存、IMEM、内核内存）能够 DMA 访问不同的 NV 和可变存储区域，以及如何保护它们？
5. 是否支持 MOR 位实现
针对外部硬件调试器的防护
1. 是否支持 JTAG？开启 SecureBoot 时，JTAG 是否处于关闭状态
2. 是否提供制造后门来禁用 JTAG 保护？是否检查生产系统中不存在此后门？
3. 启用 JTAG 时，是否清除了 TPM？
4. 是否支持任何其他硬件调试器？并对其执行相同的检查。
是否正确预配了每台设备的唯一机密？
有哪些安全熔丝（供应商特定）
1. SOC SecureBoot 熔丝
2. 每台设备的唯一机密，如认可或加密熔丝
3. JTAG 熔丝
4. SOC 应用处理器 SecureBoot 熔丝
5. SOC MBA 处理器 SecureBoot 熔丝
6. SOC 新式处理器 SecureBoot 熔丝
7. 适用于平台的任何其他 SOC 特定熔丝

IBV HSTI 检查

是否仅使用 RSA 2048 和 SHA256（或更高版本，但不低于此）
兼容性支持模块 (CSM)
1. 是否提供启用 CSM 的选项
2. 启用 SecureBoot 后，是否检查加载 CSM 的阻塞情况
3. [CS] 是否检查 CSM 不会永久存在于 CS 系统中
固件代码必须位于受保护的存储中
1. 是否保护 spiflash？
2. 是否为 eMMC 分区实现只读，直到重置
3. 是否支持签名固件检查 - 由 OEM 安装的固件为只读，或者受安全固件更新过程保护。
安全固件更新过程
1. 默认情况下，是否使用测试密钥进行安全固件更新过程？
2. 是否检查在生产环境中使用了测试密钥？
3. 是否允许回退到不安全的固件版本？如果是，则保护机制是什么？发生回退时是否清除了 TPM？
4. 是否使用了测试密钥？
是否拥有用于替代 SecureBoot 的后门
1. 系统是否支持绕过 Secureboot 的内联提示？如果是，则是否在启用 SecureBoot 后禁用它？
2. 是否有制造后门？是否在启用 SecureBoot 后禁用它们，并始终在生产系统中禁用这些后门？
[CS] 内部和外部 DMA 保护
1. 是否只对启动过程中所需的组件保留内部 DMA？并且对所有其他组件都禁用了它？
2. 是否只对启动过程中所需的组件保留外部 DMA？并且对所有其他组件都禁用了它？
3. 如果固件具有启用和禁用 DMA 保护的选项，则在默认情况下，交付配置必须启用 DMA 保护
4. 哪些总线/设备（熔丝、安全引擎、TZ、视频、缓存、IMEM、内核内存）能够 DMA 访问不同的 NV 和可变存储区域，以及如何保护它们？
5. 是否支持 MOR 位实现