Windows 安全启动密钥创建和管理指南

本文档指导 OEM 和 ODM 在制造环境中创建和管理安全启动密钥与证书。 其中涉及了与平台密钥 (PK)、安全固件更新密钥和第三方密钥交换密钥 (KEK) 的创建、存储和检索相关的问题。

注意

这些步骤并非特定于电脑 OEM。 企业和客户也可以使用这些步骤来配置其服务器以支持安全启动。

有关 UEFI 和安全启动的 Windows 要求可在 Windows 硬件认证要求中找到。 本文不介绍新的要求，也不代表官方 Windows 计划。 它旨在作为认证要求以外的指南，以帮助构建高效且安全的过程来创建和管理安全启动密钥。 这一点非常重要，因为 UEFI 安全启动在允许执行代码之前基于公钥基础结构对代码进行身份验证。

读者应具备 UEFI 的基础知识，并对安全启动（UEFI 规范第 27 章）和 PKI 安全模型有基本的了解。

现在可以通过 Windows 硬件认证工具包 (HCK) 了解在 Windows 上验证安全启动所要满足的要求并获取相关测试和工具。 但是，这些 HCK 资源不涉及 Windows 部署密钥的创建和管理。 本文将密钥管理视为一种资源，以帮助指导合作伙伴部署固件使用的密钥。 它并非规范性指导，也不包括任何新要求。

本页内容：

本文档可充当制定客户开箱即用的电脑、工厂部署工具和密钥安全性最佳做法的起点。

UEFI（统一可扩展固件接口）规范定义了称作“安全启动”的固件执行身份验证过程。 作为行业标准，安全启动定义了平台固件如何管理证书、对固件进行身份验证，以及操作系统如何与此过程交互。

安全启动基于公钥基础结构 (PKI) 过程，用于在允许模块执行之前对其进行身份验证。 这些模块包括固件驱动程序、选项 ROM、磁盘上的 UEFI 驱动程序、UEFI 应用程序或 UEFI 启动加载程序。 通过在执行前的映像身份验证，安全启动降低了启动前遭受恶意软件攻击（例如 rootkit）的风险。 Microsoft 依赖于 Windows 8 和更高版本中的 UEFI 安全启动（作为其受信任启动安全体系结构的一部分）来改善客户的平台安全性。 Windows 8 和更高版本的客户端电脑以及“Windows 硬件兼容性要求”中定义的 Windows Server 2016 需要安全启动。

安全启动过程的工作原理如下图 1 所示：

图 1：Windows 受信任启动体系结构

UEFI 安全启动的实现是 Microsoft 受信任启动体系结构的一部分，已在 Windows 8.1 中引入。 越来越高明的恶意软件漏洞利用演进趋势开始将启动路径作为首选攻击媒介。 此类攻击很难防范，因为反恶意软件产品可能会被恶意软件禁用，导致它们无法完全加载。 借助 Windows 受信任启动体系结构及其通过安全启动建立的信任根，可以确保只有经过签名、通过认证的“已知正常”代码和启动加载程序能够在操作系统本身加载之前执行，从而防止客户在启动路径中执行恶意代码。

PKI 在系统中建立真实性和信任。 安全启动将 PKI 用于两种高级目的：

PKI 包括：

公钥加密使用一对数学上相关的加密密钥（分别称为公钥和私钥）。 如果你只知道其中一个密钥，无法轻松计算出另一个密钥。 如果一个密钥用于加密信息，则只有相应的密钥才能解密该信息。 对于安全启动，私钥用于对代码进行数字签名，而公钥用于验证该代码中的签名以证明其真实性。 如果私钥被泄露，则使用相应公钥的系统不再安全。 这可能会导致 bootkit 攻击，并会损害负责确保私钥安全性的实体的信誉。

安全启动公钥系统中包含以下各项：

1.2.1 RSA 2048 加密

RSA-2048 是一种非对称加密算法。 以原始格式存储 RSA-2048 模数所需的空间为 2048 位。

1.2.2 自签名证书

由与证书公钥匹配的私钥签名的证书称为自签名证书。 根证书颁发机构 (CA) 证书属于这种类别的证书。

1.2.3 证书颁发机构

证书颁发机构 (CA) 颁发签名证书，用于确认证书使用者的身份并将该身份绑定到证书中包含的公钥。 CA 使用其私钥为证书签名。 它向自签名根 CA 证书中的所有相关方颁发相应的公钥。

在安全启动中，证书颁发机构 (CA) 包括 OEM（或其代理人）和 Microsoft。 CA 生成构成信任根的密钥对，然后使用私钥为合法操作（例如允许的早期启动 EFI 模块和固件服务请求）签名。 交付的相应公钥将嵌入到支持安全启动的电脑上的 UEFI 固件中，并用于验证这些操作。

（在与安全启动模型相关的 Internet 资源中可以轻松获得有关 CA 用法和密钥交换的详细信息。）

1.2.4 公钥

公共平台密钥在电脑上交付，可供用户访问，或者是“公开的”。 在本文档中，我们将使用后缀“pub”来表示公钥。 例如，PKpub 表示 PK 的公钥部分。

1.2.5 私钥

要使 PKI 正常工作，需要安全地管理私钥。 私钥应该仅供组织中少数高度可信的人员访问，并放置在实施了严格访问策略限制的物理安全位置。 在本文档中，我们将使用后缀“priv”来表示私钥。 例如，PKpriv 表示 PK 的私钥部分。

1.2.6 证书

数字证书的主要用途是验证已签名数据的来源，例如二进制文件等。证书的常见用途是使用传输层安全性 (TLS) 或安全套接字层 (SSL) 确保 Internet 消息安全性。 使用证书验证已签名数据可让接收方知道数据的来源，以及数据在传输过程中是否被更改。

从较高层面讲，数字证书一般包含可分辨名称 (DN)、公钥和签名。 DN 标识某个实体 - 例如某家公司，该实体持有与证书公钥匹配的私钥。 使用私钥为证书签名并将签名放在证书中可将私钥与公钥相关联。

证书可以包含某些其他类型的数据。 例如，一个 X.509 证书包括该证书的格式、该证书的序列号、用于对该证书进行签名的算法、颁发该证书的 CA 的名称、请求该证书的实体的名称和公钥以及 CA 的签名。

1.2.7 链接证书

来源：证书链：

图 2：三证书链

用户证书通常由不同的私钥签名，例如 CA 的私钥。 这就构成了一个双证书链。 验证用户证书是否真实涉及到验证证书中的签名，这需要使用 CA 的公钥。 但在可以使用 CA 的公钥之前，需要验证随附的 CA 证书。 由于 CA 证书是自签名证书，因此 CA 公钥用于验证证书。

用户证书不需要由根 CA 的私钥签名。 它可以由中间方的私钥签名，该中间方的证书由 CA 的私钥签名。 这是三证书链的一个实例：用户证书、中间证书和 CA 证书。 但是，链可以包含多个中间方，因此证书链可为任意长度。

UEFI 定义的信任根由平台密钥以及 OEM 或 ODM 在固件核心中包含的任何密钥组成。 UEFI 安全启动过程不涉及预 UEFI 安全性和信任根，不过，本文中所参考的美国国家标准技术研究所 (NIST) 和受信任计算小组 (TCG) 出版物介绍了这些技术。

1.3.1 安全启动要求

实现安全启动时需要考虑以下参数：

需要为安全启动密钥管理选择硬件（例如硬件安全模块 (HSM)），考虑交付给政府和其他机构的电脑的特殊要求，最后考虑创建、填充和管理各种安全启动密钥的生命周期的过程。

1.3.2 安全启动相关的密钥

用于安全启动的密钥如下：

图 3：与安全启动相关的密钥

上图 3 显示了具有安全启动的电脑中的签名和密钥。 该平台是通过 OEM 在制造期间安装在固件中的平台密钥保护的。 安全引导使用其他密钥来保护对存储密钥的数据库的访问，以允许或禁止执行固件。

已获授权的数据库 (db) 包含代表受信任固件组件和操作系统加载程序的公钥与证书。 禁止的签名数据库 (dbx) 包含恶意和有漏洞组件的哈希以及已泄露的密钥和证书，并阻止执行这些恶意组件。 这些策略的强度基于使用验证码和公钥基础结构 (PKI) 对固件进行签名。 PKI 是在信息交换期间创建、管理和吊销用于建立信任的证书的完善过程。 PKI 是安全启动的安全模型的核心。

下面提供了有关这些密钥的更多详细信息。

1.3.3 平台密钥 (PK)

根据 UEFI 2.3.1 勘误表 C 的第 27.5.1 部分，平台密钥在平台所有者与平台固件之间建立信任关系。 平台所有者根据 UEFI 2.3.1 勘误表 C 第 7.2.1 部分中的规定，将密钥的公钥部分 (PKpub) 注册到平台固件中。此步骤将平台从设置模式转为用户模式。 Microsoft 建议平台密钥的类型为 EFI_CERT_X509_GUID，公钥算法为 RSA，公钥长度为 2048 位，签名算法为 sha256RSA。 如果存储空间是一个考虑因素，平台所有者可以使用类型 EFI_CERT_RSA2048_GUID。 如本文档前面所述，公钥用于检查签名。 平台所有者以后可以使用密钥的私钥部分 (PKpriv)：

1.3.3.1 注册或更新用于注册平台密钥的密钥交换密钥 (KEK)

平台所有者通过根据 UEFI 规范 2.3.1 勘误表 C 第 7.2.1 部分中的规定调用 UEFI 启动服务 SetVariable() 并重置平台，来注册平台密钥的公钥部分 (PKpub)。 如果平台处于设置模式，则新的 PKpub 应通过其对应的 PKpriv 签名。 如果平台处于用户模式，则必须使用当前的 PKpriv 为新的 PKpub 签名。 如果 PK 的类型 EFI_CERT_X509_GUID为 ，则必须由直接 PKpriv 签名，而不是 PK 下颁发的任何证书的私钥。

1.3.3.2 清除平台密钥

平台所有者通过使用变量大小 0 调用 UEFI 启动服务 SetVariable() 并重置平台，来清除平台密钥的公钥部分 (PKpub)。 如果平台处于设置模式，则不需要对空变量进行身份验证。 如果平台处于用户模式，则必须使用当前 PKpriv 为空变量签名；有关详细信息，请参阅 UEFI 规范 2.3.1 勘误表 C 中的第 7.2 部分（变量服务）。 强烈建议不要通过使用生产 PKpriv 为包签名来重置平台，因为这会允许以编程方式禁用安全启动。 这种做法主要用在生产前测试方案中。

也可以使用安全平台特定的方法清除平台密钥。 在这种情况下，全局变量设置模式也必须更新为 1。

图 4：平台密钥状态示意图

1.3.3.3 PK 生成

根据 UEFI 的建议，公钥必须存储在非易失性存储中，该存储在电脑上具有防篡改和防删除功能。 私钥安全保存在合作伙伴场所或 OEM 的保安室中，只会将公钥加载到平台上。 第 2.2.1 和 2.3 部分提供了更多详细信息。

生成的 PK 数量由平台所有者 (OEM) 自行决定。 这些密钥可以：

在每台电脑上生成一个密钥。 每台设备有一个唯一的密钥。 政府机构、金融机构或其他安全需求较高的服务器客户可能需要这样做。 这可能需要提供额外的存储和加密处理能力来为大量电脑生成私钥和公钥。 这会增大将来向设备推送固件更新时将设备映射到其相应 PK 的复杂性。 可以根据 HSM 供应商使用几种不同的 HSM 解决方案来管理大量的密钥。 有关详细信息，请参阅使用 HSM 生成安全启动密钥。

为每个型号生成一个密钥。 每个电脑型号有一个密钥。 此处的弊端是，如果密钥泄露，同一型号的所有计算机都易受攻击。 Microsoft 建议将此方法用于桌面型电脑。

为每个产品系列生成一个密钥。 如果密钥泄露，则整个产品系列都易受攻击。

为每个 OEM 生成一个密钥。 虽然这可能是最简单的设置方法，但如果密钥泄露，生产的每台电脑都易受攻击。 为了加速工厂车间的操作，可以预先生成 PK（也许还包括其他密钥），并将其存储在安全位置。 以后可以在装配线中检索和使用这些密钥。 第 2 和第 3 章提供了更多详细信息。

1.3.3.4 重新生成 PK 密钥

如果 PK 泄露或客户出于安全要求决定注册自己的 PK，则可能需要这样做。

可以根据选择用于创建 PK 的方法针对某个型号或电脑重新生成密钥。 所有较新的电脑将通过新建的 PK 签名。

若要在生产电脑上更新 PK，需要使用一个通过现有 PK 签名的变量更新来替换该 PK，或需要一个固件更新包。 OEM 还可以创建一个 SetVariable() 包，并使用一个只更改 PK 的简单应用程序（例如 PowerShell）分发该包。 固件更新包将由安全固件更新密钥签名并由固件验证。 如果执行固件更新来更新 PK，应确保保留 KEK、db 和 dbx。

在所有电脑上，建议不要将 PK 用作安全固件更新密钥。 如果 PKpriv 泄露，安全固件更新密钥也会泄露（因为它们是相同的）。 在这种情况下，可能无法进行更新以注册新的 PKpub，因为更新过程也会泄密。

在 SOC 电脑上，还有另一个原因解释了为何不应使用 PK 作为安全固件更新密钥。 此原因是安全固件更新密钥永久烧刻在符合 Windows 硬件认证要求的电脑上的熔断器中。

1.3.4 密钥交换密钥 (KEK)：密钥交换密钥在操作系统与平台固件之间建立信任关系。 每个操作系统（可能还包括每个需要与平台固件通信的第三方应用程序）会将一个公钥 (KEKpub) 注册到平台固件中。

1.3.4.1 注册密钥交换密钥

如 1.4 签名数据库（Db 和 Dbx）中所述，密钥交换密钥存储在签名数据库中。 签名数据库是作为经过身份验证的 UEFI 变量存储的。

平台所有者通过以下两种方式之一注册密钥交换密钥：根据 UEFI 规范 2.3.1 勘误表 C 中第 7.2 部分（变量服务）中的规定，在设置 EFI_VARIABLE_APPEND_WRITE 属性并在 Data 参数中包含新密钥的情况下调用 SetVariable()；或者使用 GetVariable() 读取数据库，并将新的密钥交换密钥追加到现有密钥，然后根据根据 UEFI 规范 2.3.1 勘误表 C 中第 7.2 部分（变量服务）中的规定，在不设置 EFI_VARIABLE_APPEND_WRITE 属性的情况下使用 SetVariable() 写入数据库。

如果平台处于设置模式，则不需要对签名数据库变量进行签名，但仍应根据第 7.2.1 部分中有关已经过身份验证的变量的规定来准备 SetVariable() 调用参数。 如果平台处于用户模式，则必须使用当前的 PKpriv 为签名数据库签名

1.3.4.2 清除 KEK

可以“清除”（删除）KEK。 注意，如果平台上未安装 PK，则不需要为“清除”请求签名。 如果已签名，则清除 KEK 时需要 PK 签名的包，而清除 db 或 dbx 时需要由 KEK 中存在的任何实体签名的包。

1.3.4.3 Microsoft KEK

需要以下 2 个 Microsoft KEK 证书，才能通过更新 dbx 来吊销不良映像，并可能更新数据库以准备较新的 Windows 签名映像。

Microsoft Corporation KEK CA 2011

Microsoft Corporation KEK 2K CA 2023

1.3.4.4 KEKDefault 平台供应商必须在 KEKDefault 变量中提供一组默认的密钥交换密钥。 有关详细信息，请参考 UEFI 规范的第 27.3.3 部分。

1.3.4.5 OEM/第三方 KEK - 添加多个 KEK

客户和平台所有者不需要有自己的 KEK。 在非 Windows RT 电脑上，OEM 可以使用额外的 KEK，以允许其他 OEM 或受信任的第三方控制 db 和 dbx。

1.3.5 安全启动固件更新密钥：安全固件更新密钥用于在需要更新固件时为固件签名。 此密钥的最低密钥强度必须达到 RSA-2048。 所有固件更新必须由 OEM、其受信任的委托人（例如 ODM 或 IBV（独立 BIOS 供应商））或安全签名服务以安全方式签名。

根据 NIST 出版物 800-147，现场固件更新必须支持准则中所述的所有要素：

对固件闪存存储所做的任何更新必须由创建者签名。

固件必须检查更新的签名。

1.3.6 为安全固件更新创建密钥

将使用同一密钥为所有固件更新签名，因为公钥部分驻留在电脑上。 还可以使用链接到安全固件更新密钥的密钥来为固件更新签名。

每台电脑可能有一个密钥（例如 PK），或者每个型号或每个产品系列有一个密钥。 如果每台电脑有一个密钥，则意味着需要生成数百万个唯一的更新包。 请根据资源可用性考虑哪种方法适合你。 为每个型号或产品系列提供一个密钥是合理的折衷方案。

安全固件更新公钥（或其哈希，使用哈希可以节省空间）将存储在平台上的某种受保护的存储中 - 通常是受保护的闪存（在电脑上）或一次性可编程熔断器（在 SOC 上）。

如果仅存储此密钥的哈希（以节省空间），则固件更新将包含该密钥，更新过程的第一阶段将验证更新中的公钥是否与存储在平台上的哈希匹配。

胶囊 (Capsule) 是每次重启后操作系统将数据传递到 UEFI 环境的一种方式。 Windows 调用 UEFI UpdateCapsule() 来传送系统和电脑固件更新。 在调用 ExitBootServices() 之前启动时，Windows 会将在 Windows 驱动程序存储中找到的任何新固件更新传入 UpdateCapsule()。 UEFI 系统固件可以使用此过程来更新系统和电脑固件。 利用此项 Windows 固件支持，OEM 可以依赖相同的通用格式和过程来更新系统的固件和电脑固件。 固件必须实现 ACPI ESRT 表才能支持 Windows 的 UEFI UpdateCapsule()。

有关实现 Windows UEFI 固件更新平台支持的详细信息，请参阅以下文档：Windows UEFI 固件更新平台。

更新胶囊可以存储在内存或磁盘中。 Windows 支持内存中更新。

1.3.6.1 胶囊（内存中胶囊）

下面是用于运行内存中更新胶囊的事件流。

1.3.7 典型固件更新的工作流

1.4.1 允许的签名数据库 (db)

EFI _IMAGE_SECURITY_DATABASE db 的内容控制在验证加载的映像时信任哪些映像。 数据库可以包含多个证书、密钥和哈希，以识别允许的映像。

以下 2 个证书必须包含在 db 中，才能允许 Windows OS 加载程序加载：

Microsoft Windows 生产 PCA 2011

Windows UEFI CA 2023

除了锁定为仅启动 Windows 的系统外，OEM 应考虑包括 Microsoft 第三方 UEFI CA，以允许第三方 UEFI 驱动程序和应用程序在电脑上运行，而无需为用户执行其他步骤。

Microsoft Corporation UEFI CA 2011

Microsoft UEFI CA 2023

1.4.2 DbDefault：平台供应商必须在 dbDefault 变量中为签名数据库提供一组默认条目。 有关详细信息，请参阅 UEFI 规范中的第 27.5.3 部分。

1.4.3 禁止的签名数据库 (dbx)

在检查 db 之前验证映像时，必须检查 EFI_IMAGE_SIGNATURE_DATABASE1 dbx 的内容，一旦存在任何匹配项，就必须阻止映像的执行。 数据库可以包含多个证书、密钥和哈希，以识别禁止的映像。 Windows 硬件认证要求规定必须存在一个 dbx，因此在 Microsoft 开始提供 dbx 更新或发生类似事件之前，任何虚拟值（例如 SHA-256 哈希 0）都可用作安全占位符。 单击此处 从 Microsoft 下载最新的 UEFI 吊销列表。

1.4.4 DbxDefault：平台供应商可以在 dbxDefault 变量中为签名数据库提供一组默认条目。 有关详细信息，请参阅 UEFI 规范中的第 27.5.3 部分。

PKpub

PK

OEM

PK – 仅 1 个。 必须是 RSA 2048 或更强。

Microsoft Corporation KEK CA 2011

Microsoft Corporation KEK 2K CA 2023

KEK

Microsoft

允许对 db 和 dbx 进行更新：

https://go.microsoft.com/fwlink/p/?linkid=321185

https://go.microsoft.com/fwlink/p/?linkid=2239775.

Microsoft Windows Production CA 2011

Windows UEFI CA 2023

db

Microsoft

签名数据库 (数据库) 中的此 CA 允许 Windows 启动： https://go.microsoft.com/fwlink/?LinkId=321192

https://go.microsoft.com/fwlink/p/?linkid=2239776.

禁止的签名数据库

dbx

Microsoft

来自 Microsoft 的已知错误密钥、CA 或映像列表

安全固件更新密钥

OEM

对于此密钥，建议使用与 PK 不同的密钥

表 1：安全启动所需的密钥/db

下面提供了用于比较的一些指标。

以下指标可帮助你根据 UEFI 规范 2.3.1 勘误表 C 的要求和自己的需求选择 HSM 电脑。

它是否允许密钥备份？

备份既可以存储在现场的安全位置（该位置与 CA 计算机和 HSM 所在的物理位置不同），也可以存储在非现场位置。

它是否可实现灾难恢复的高可用性？

2.2.1 硬件安全模块 (HSM)

根据上述准则，HSM 可能是最合适且最安全的解决方案。 大多数 HSM 具有 FIPS 140-2 第 3 级别的合规性。 FIPS 140-2 第 3 级别的合规性对身份验证的要求很严格，并规定不得从 HSM 导出或导入密钥。

HSM 支持多种密钥存储方式。 可将密钥本地存储在 HSM 本身中，也可将其存储在附加到 HSM 的服务器上。 在服务器上，密钥将在加密后存储，这非常有利于需要存储大量密钥的解决方案。

加密模块安全策略应指定物理安全策略，包括在加密模块中实施物理安全机制，例如防篡改密封、锁定、篡改响应和归零开关以及警报。 它还允许指定操作员所要采取的措施，以确保维持物理安全机制，例如定期检查防篡改密封，或测试篡改响应和归零开关。

2.2.1.1 网络 HSM

此解决方案在安全性、标准遵从性、密钥生成、存储和检索方面是同类最佳的。 其中的大多数电脑都支持高可用性并具有备份密钥的能力。

这些产品的价格可能高达数万美元，具体取决于它们提供的额外服务。

2.2.1.2 独立 HSM

这些产品非常适合用于独立服务器。 用户可以使用 Microsoft CAPI 和 CNG，或 HSM 支持的任何其他安全 API。 这些 HSM 采用不同的外形规格，支持 USB、PCIe 和 PCMCIA 总线。

它们可以选择性地支持密钥备份和高可用性。

2.2.2 自定义解决方案提供商

公钥加密可能具有挑战性，有时需要理解全新的加密概念。 某些自定义解决方案提供商可以帮助客户在制造环境中正常运行安全启动。

BIOS 供应商、HSM 公司和 PKI 咨询公司提供多种自定义解决方案，使安全启动 PKI 能够在制造环境中正常运行。

下面列出了其中一些提供商：

2.2.2.1 BIOS 供应商

某些 BIOS 供应商能够提供自定义解决方案。

2.2.2.2 HSM 供应商

某些 HSM 供应商能够提供自定义咨询服务。 有关详细信息，请参阅使用 HSM 生成安全启动密钥并为其签名（示例）。

2.2.3 受信任的平台模块 (TPM)

受信任的平台模块 (TPM) 是主板上的一个硬件芯片，其中存储了用于加密的加密密钥。 许多计算机都包含 TPM，但如果不包含，添加 TPM 是没有作用的。 启用后，受信任的平台模块可以帮助保护全盘加密产品，例如 Microsoft BitLocker 功能。 它使硬盘驱动器一直保持锁定或密封，直到电脑完成系统验证或身份验证过程。

TPM 可以生成、存储和保护在加密和解密过程中使用的密钥。

TPM 的缺点是，其中可能不包含快速加密处理器用于加速制造环境中的处理。 此外，它们不适合存储大量密钥。 可能无法实现备份和高可用性，以及 FIPS 140-2 第 3 级别的标准合规性。

2.2.4 智能卡

智能卡可以生成和存储密钥。 它们确实与 HSM 有一些共同的功能，例如身份验证和防篡改，但包含的密钥存储或备份空间不是很大。 它们需要人工干预，性能可能较低，因此可能不适合在自动化和生产环境中使用。

智能卡的缺点类似于 TPM。 其中可能不包含快速加密处理器用于加速制造环境中的处理。 此外，它们不适合存储大量密钥。 可能无法实现备份和高可用性，以及 FIPS 140-2 第 3 级别的标准合规性。

2.2.5 扩展的验证证书

EV 证书是提供较高保证的证书，其私钥存储在硬件令牌中。 这有助于制定更有效的密钥管理做法。 EV 证书的缺点与智能卡相同。

2.2.6 以软件为中心的方法（不建议）

使用加密 API 进行密钥管理。 这可能涉及到将密钥存储在已加密硬盘驱动器上的密钥容器中，并可能需要使用虚拟机建立额外的沙盒和安全措施。

这些解决方案不如使用 HSM 那样安全，并且会暴露出更明显的攻击途径。

2.2.6.1 Makecert（不建议）

Makecert 是一个 Microsoft 工具，可按如下所述用于生成密钥。 为确保尽量缩小受攻击面，可能需要在电脑中留出“气隙”。 存储了 PKpriv 的电脑不应连接到网络。 PKpriv 应存储在安全的位置，理想情况下，至少应使用智能卡来存储 PKpriv，甚至可以使用真正的 HSM。

有关详细信息，请参阅证书创建工具 (Makecert.exe)。

不建议使用此解决方案。

2.3.1 存储私钥

每个 RSA-2048 密钥的空间要求是 2048 位。 实际的密钥存储位置取决于所选的解决方案。 HSM 非常适合用于存储密钥。

工厂车间电脑的物理位置需是一个限制用户访问的受保护区域，例如安全笼。

也可以根据要求，将这些密钥存储在不同的地理位置或备份到不同的位置。

这些密钥的重新生成要求因不同的客户而异（请参阅附录 A 了解 Federal Bridge 证书颁发机构密钥重新生成准则）。

可以每年重新生成密钥一次。 你可能需要访问这些密钥长达 30 年之久（取决于密钥重新生成要求等因素）。

2.3.2 检索私钥

可能出于多种原因而需要检索密钥。

2.3.3 身份验证

根据 FIPS 140-2，身份验证基于访问级别。

级别 2

安全级别 2 至少需要基于角色的身份验证，使用此方法时，加密模块将对操作员的授权进行身份验证，确定其是否承担特定的角色并可执行一组相应的服务。

级别 3

安全级别 3 需要基于标识的身份验证机制，从而增强为安全级别 2 指定的基于角色的身份验证机制提供的安全性。 加密模块验证操作员的身份，并验证所识别的操作员是否有权承担特定的角色并执行相应的一组服务。

HSM 之类的电脑支持安全级别 3，这需要基于标识的“k of m 身份验证”。 也就是说，k 个实体可以使用令牌访问 HSM，但在给定的时间点，至少需要 m 个令牌中的 k 个才能正常完成身份验证，从而从 HSM 访问私钥。

例如，你可能需要有 5 个令牌中的 3 个才能完成身份验证，以访问 HSM。 这些成员可以是安全监管员、交易授权人和/或行政管理层的成员。

HSM 令牌

可以针对 HSM 制定策略，以要求出示令牌：

本地

远程

配置为自动化

良好的做法是使用令牌和令牌密码的组合。

2.4.1 UEFI 驱动程序签名

UEFI 驱动程序必须由 db 中的 CA 或密钥签名（如本文档中的其他部分所述），或者使用 db 中包含的驱动程序映像的哈希。 Microsoft 将使用 Microsoft Corporation UEFI CA 2011 提供类似于 WHQL 驱动程序签名服务的 UEFI 驱动程序签名服务。 由此服务签名的任何驱动程序将在包含 Microsoft UEFI CA 的任何电脑上无缝运行。 OEM 也可以为受信任的驱动程序签名，并将 OEM CA 包含在 db 中，或者将驱动程序的哈希包含在 db 中。 在所有情况下，如果 UEFI 驱动程序（选项 ROM）在 db 中不受信任，则不会执行它。

系统固件映像中包含的任何驱动程序不需要重新验证。 作为整个系统的一部分，映像可以充分保证该驱动程序在电脑上受信任。

Microsoft 已将此证书提供给任何想要为 UEFI 驱动程序签名的用户。 此证书是 Windows HCK 安全启动测试的一部分。 请遵循 [此博客文章]((https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates/) 详细了解 UEFI CA 签名策略和更新。

2.4.2 启动加载程序

Microsoft UEFI 驱动程序签名证书可用于为其他操作系统签名。 例如，Fedora 的 Linux 启动加载程序就是由它签名的。

此解决方案不要求将其他证书添加到密钥数据库。 除了经济高效的特性外，它还可以用于任何 Linux 发行版。 此解决方案适用于任何支持 Windows 的硬件，因此可在各种硬件上使用。

可从以下网页下载 UEFI-CA：https://go.microsoft.com/fwlink/p/?LinkID=321194。 以下链接提供了有关 Windows HCK UEFI 签名和提交的详细信息：

本部分旨在总结上述各部分的内容并逐步介绍操作方法：

建立安全 CA 或确定合作伙伴以安全生成和存储密钥

如果不使用第三方解决方案：

在 HSM 服务器上安装并配置 HSM 软件。 查看 HSM 参考手册以获取安装说明。 服务器将连接到独立 HSM 或网络 HSM。

有关 HSM 配置的信息，请参阅第 2.2.1、2.3 部分和附录 C。

大多数 HSM 提供 FIPS 140-2 第 2 和 3 级别的合规性。 配置 HSM 以达到第 2 或 3 级别的合规性。 第 3 级别的合规性对身份验证和密钥访问有更严格的要求，因此更安全。 建议达到第 3 级别的合规性。

配置 HSM 以实现高可用性、备份和身份验证。 查看 HSM 参考手册。

遵循有关设置 HSM 以实现高可用性和备份的 HSM 提供商准则。

此外，网络 HSM 通常提供多个网络端口来隔离流量；允许服务器在不同于普通生产网络的网络上与网络 HSM 通信。

确定安全团队的成员后，为其分配令牌。 需要为 k-of-m 身份验证设置 HSM 硬件。

安全启动密钥和证书预生成。 请参阅第 1.3 至 1.5 部分

使用 HSM API 预生成（提前生成）PK 和固件更新密钥与证书。

必需 - PK（建议为每个型号生成 1 个）、固件更新密钥（建议为每个型号生成 1 个）、Microsoft KEK、Db、Dbx。注意：OEM 不必生成 Microsoft KEK、db 和 dbx，此处提到这些密钥是为了保持文档完整性。可选 - OEM/第三方 KEK db、dbx 和任何其他要存储在 OEM 数据库中的密钥。

将 Windows 映像应用到电脑。

安装 Microsoft db 和 dbx。 请参阅第 1.3.6 部分和附录 B -安全启动 API。

将 Microsoft Windows Production PCA 2011 安装到 db 中。

安装一个空的 dbx（如果 Microsoft 未提供）。 在首次重启时，Windows 会通过 Windows 更新自动将 DBX 更新到最新版本。

注意

使用作为 Windows HCK 测试的一部分的 PowerShell cmdlet，或使用 BIOS 供应商提供的方法。

安装 Microsoft KEK。 请参阅第 1.3.3 部分。

将 Microsoft KEK 安装到 UEFI KEK 数据库中

注意

使用作为 Windows HCK 测试的一部分的 PowerShell cmdlet，或使用 BIOS 供应商提供的方法。

可选步骤 - OEM/第三方安全启动组件。 请参阅第 1.3.4 和 1.4 部分。

确定是否需要创建 OEM/第三方 KEK、db 和 dbx。

通过 HSM API 使用 OEM/第三方 KEK（前面已生成）为 OEM/第三方 db 和 dbx 签名。

安装 OEM/第三方 KEK、db 和 dbx。

UEFI 驱动程序签名 – 请参阅第 2.4 部分。

如果支持附加卡或其他 UEFI 驱动程序/应用/启动加载程序，请将 Microsoft Corporation UEFI CA 2011 安装到 UEFI db 中。

安全启动固件更新密钥 - 请参阅第 1.3.5 部分。

仅适用于非 Windows RT 电脑：安装安全固件更新公钥，或安装其哈希以节省空间。

（仅适用于在 SoC 上）可能需要执行不同的操作，例如，烧刻安全固件更新密钥：公钥或其哈希。

启用安全启动。 请参阅附录 B - 安全启动 API。

将 OEM/ODM PKpub（最好是证书，但密钥也没有问题）安装到 UEFI PK 中。

使用安全启动 API 注册 PK。 现在应为电脑启用安全启动。

注意

如果最后安装 PK，则不需要为 MS KEK、db、dbx 签名 - 不必提供 SignerInfo。 这是一条捷径。

测试安全启动：按照说明执行任何专有测试和 Windows HCK 测试。 请参阅附录 B - 安全启动 API。

交付平台：有可能永远不会再用到 PKpriv，但请妥善保管。

维护：将来的固件更新将通过签名服务使用安全固件更新“私钥”安全地进行签名。

安全策略白皮书 - https://go.microsoft.com/fwlink/p/?linkid=321288

Windows HCK 提交 -https://go.microsoft.com/fwlink/p/?linkid=321287

下面是一份概要性的核对列表，其中汇总了在非 Windows RT 电脑上启用安全启动所要执行的步骤。

根据白皮书第 4 部分所述定义安全策略（识别威胁、定义主动和被动策略）。

根据白皮书第 4 部分所述确定安全团队。

建立安全 CA 或确定合作伙伴（建议的解决方案）以安全生成和存储密钥。

确定有关密钥重新生成频率的策略。 此策略可能取决于是否有任何特殊客户要求，例如政府或其他机构的要求。

制定应急计划，以防安全启动密钥泄露。

根据第 1.3.3 和 1.5 部分确定要生成多少个 PK 和其他密钥。

这取决于客户群、密钥存储解决方案和电脑安全性。

如果你正在使用建议的解决方案通过第三方产品进行密钥管理，则可以跳过步骤 7-8。

采购用于密钥管理的服务器和硬件。 – 根据第 2.2.1 部分所述采购网络 HSM 或独立 HSM。 考虑是否需要使用一个或多个 HSM 来实现高可用性和密钥备份策略。

确定至少 3-4 名团队成员，他们拥有用于在 HSM 上进行身份验证的身份验证令牌。

使用 HSM 或第三方产品预生成与安全启动相关的密钥和证书。 密钥取决于电脑类型：SoC、Windows RT 或非 Windows RT。 有关详细信息，请参阅第 1.3 至 1.5 部分。

在固件中填充适当的密钥。

注册安全启动平台密钥以启用安全启动。 有关详细信息，请参阅附录 B。

按照说明执行任何专有测试和 HCK 安全启动测试。 有关详细信息，请参阅附录 B。

交付电脑。 有可能永远不会再用到 PKpriv，但请妥善保管。

你可能出于多种原因（例如更新 UEFI 组件、修复安全启动密钥泄露问题或定期重新生成安全启动密钥）而需要更新固件。

有关详细信息，请参阅第 1.3.5 和第 1.3.6 部分。

安全启动 API

以下 API 与 UEFI/安全启动相关：

GetFirmwareEnvironmentVariableEx：检索指定的固件环境变量的值。

SetFirmwareEnvironmentVariableEx：设置指定的固件环境变量的值。

GetFirmwareType：检索固件类型。

设置 PK

使用 Set-SecureBootUEFI cmdlet 启用安全启动。 在代码设置 PK 后，在下次重启之前，系统强制执行的安全启动不会生效。 在重启之前，代码可以调用 GetFirmwareEnvironmentVariableEx() 或 PowerShell cmdlet Get-SecureBootUEFI 来确认安全启动数据库的内容。

验证

可以使用 Msinfo32.exe 或 PowerShell cmdlet 来检查安全启动变量状态。 没有 WMI 接口。 还可以通过以下方式进行测试：让某人插入不当签名的可启动 U 盘（例如，在 Windows HCK 安全启动手动徽标测试中），然后验证该 U 盘是否无法启动。

安全启动 Powershell Cmdlet

Confirm-SecureBootUEFI：UEFI 安全启动是否已“打开”，值是 True 还是 False？

SetupMode == 0，SecureBoot == 1

Set-SecureBootUEFI：设置或追加已经过身份验证的 SecureBoot UEFI 变量

Get-SecureBootUEFI：获取已经过身份验证的 SecureBoot UEFI 变量值

Format-SecureBootUEFI：创建EFI_SIGNATURE_LISTs & EFI_VARIABLE_AUTHENTICATION_2序列化

Windows HCK 和安全启动说明

以下步骤适用于系统测试和非类驱动程序电脑测试。

禁用安全启动保护。

进入 BIOS 配置并禁用安全启动。

安装 HCK 客户端软件。

运行除以下测试之外的其他所有 Windows HCK 测试：

进入 BIOS 配置，启用安全启动，并将安全启动还原为默认配置。

运行以下 BitLocker 和安全启动测试：

进入 BIOS 配置并清除安全启动配置。 这会通过删除 PK 和其他密钥将电脑还原为设置模式。

注意

x86/x64 电脑必须支持清除。

运行安全启动手动徽标测试。

注意

安全启动要求在非 Windows RT 电脑上安装 Windows HCK 签名的驱动程序或 VeriSign 驱动程序

Windows HCK 安全启动徽标测试（自动）

此项测试将检查现成的安全启动配置是否正确。 这包括：

Windows HCK 安全启动手动测试文件夹布局

下面介绍 Windows HCK 安全启动手动徽标测试文件夹布局：

"\Test" 文件夹包含以下内容：

"\Generate" 文件夹包含用于显示以下信息的脚本：

测试证书的创建方式

包括测试证书和私钥

所有测试的创建方式

将证书和哈希转换为已签名的包

你可以自己运行此测试（需替换为自己的证书）

"\certs" 文件夹包含用于启动 Windows 的所有证书：

注意

请不要使用 "ManualTests\generate\TestCerts" 中所用的方法来生成密钥和证书。 此方法仅用于 Windows HCK 测试目的。 它使用磁盘上存储的密钥，这非常不安全，因此不建议采用。 此方法不适合在生产环境中使用。

"ManualTests\example\OutOfBox" 文件夹包含可用于在生产电脑上安装安全启动的脚本。

"ManualTests\generate\tests\subcreate_outofbox_example.ps1" 演示了这些示例的生成方式，当合作伙伴可以替换其 PK 和其他元数据时，这些示例中会显示“TODO”部分。

Windows HCK UEFI 签名和提交

以下链接提供了详细信息：

初级

此级别提供有关个人身份的最低保证程度。 此级别的主要功能之一是为要签名的信息提供数据完整性。 此级别与其中恶意活动风险被认为较低的环境相关。 它不适用于需要身份验证的交易；对于需要保密的交易，此级别通常不够高。但对于后一种情况，如果没有可提供较高保证程度的证书，则可以使用此级别。

基本

此级别提供与下述环境相关的基本保证级别：存在数据泄露风险和后果，但不认为这些问题很严重。 这可能包括访问私人信息，但恶意访问的可能性不高。 处于此安全级别时，用户被认为不太可能有恶意企图。

中等

此级别与存在中等数据泄露风险和后果的环境相关。 这可能包括交易涉及大量货币价值或存在欺诈风险，或涉及到访问私人信息，而恶意访问的可能性很大。

高

当数据受到的威胁很大，或安全服务故障造成的后果很严重时，适合使用此级别。 这可能包括价值极高的交易或较高的欺诈风险级别。

使用 HSM 生成安全启动密钥并为其签名（示例）

UEFI 验证选项 ROM 验证指南

安全启动概述