Windows 安全启动证书过期和 CA 更新

什么是安全启动？

安全启动是统一可扩展固件接口中的一项安全功能， (基于 UEFI) 的固件，可帮助确保只有受信任的软件在设备的启动 (启动) 序列中运行。 它的工作原理是针对存储在设备固件中的一组受信任的数字证书 (（也称为证书颁发机构或 CA) ）验证预启动软件的数字签名。 作为行业标准，UEFI 安全启动定义了平台固件如何管理证书、对固件进行身份验证，以及作系统 (作系统) 如何与此过程交互。 有关 UEFI 和安全启动的更多详细信息，请参阅 安全启动。

Windows 8中首次引入了安全启动，以防止当时出现的预启动恶意软件 (也称为启动工具包) 威胁。 作为平台初始化的一部分，安全启动在执行前对固件模块进行身份验证。 这些模块包括 UEFI 固件驱动程序 (，例如选项 ROM) 、启动加载程序以及应用程序。 作为安全启动过程的最后一步，固件会验证安全启动是否信任启动加载程序。 然后，固件将控制权传递给启动加载程序，后者反过来会验证、加载到内存中并启动 Windows OS。

安全启动在制造过程中通过固件策略集定义受信任的代码。 对此策略的更改（例如添加或撤销证书）由密钥层次结构控制。 此层次结构从通常由硬件制造商拥有的平台密钥 (PK) 开始，然后是密钥注册密钥 (KEK) (也称为密钥交换密钥) ，其中可能包括Microsoft KEK 和其他 OEM KEK。 允许的签名数据库 (DB) 和不允许的签名数据库 (DBX) 确定哪些代码可以在 OS 启动之前在 UEFI 环境中运行。 DB 包括由 Microsoft 和 OEM 管理的证书，而 DBX 由Microsoft使用最新的吊销进行更新。 任何具有 KEK 的实体都可以更新 DB 和 DBX。

Windows 安全启动证书在 2026 年到期

由于 Windows 引入了安全启动支持，所有基于 Windows 的设备在 KEK 和 DB 中都携带了同一组Microsoft证书。 这些原始证书即将到期，如果设备具有任何列出的证书版本，设备将受到影响。 若要继续运行 Windows 并接收安全启动配置的定期更新，需要更新这些证书。

术语
KEK： 密钥注册密钥
CA： 证书颁发机构
分贝： 安全启动签名数据库
DBX： 安全启动吊销的签名数据库
可能需要采取措施来确保 Windows 设备在 2026 年证书过期时保持安全。 UEFI 安全启动 DB 和 KEK 都需要使用相应的新 2023 证书版本进行更新。 有关新证书的详细信息，请参阅 Windows 安全启动密钥创建和管理指南。
| Microsoft已颁发更新的证书，以确保 Windows 设备上的安全启动保护的连续性。 Microsoft将在大部分 Windows 设备上管理这些新证书的更新过程。 当 2011 CA 过期时，没有新 2023 证书的 Windows 设备无法再收到危害 Windows 启动安全性的预启动组件的安全修补程序。

1.、安全启动、Windows 和密钥管理

1.1、UEFI（统一可扩展固件接口）规范定义了称作“安全启动”的固件执行身份验证过程。 作为行业标准，安全启动定义了平台固件如何管理证书、对固件进行身份验证，以及操作系统如何与此过程交互。
1.2、安全启动基于公钥基础结构 (PKI) 过程，用于在允许模块执行之前对其进行身份验证。 这些模块包括固件驱动程序、选项 ROM、磁盘上的 UEFI 驱动程序、UEFI 应用程序或 UEFI 启动加载程序。 通过在执行前的映像身份验证，安全启动降低了启动前遭受恶意软件攻击（例如 rootkit）的风险。 Microsoft 依赖于 Windows 8 和更高版本中的 UEFI 安全启动（作为其受信任启动安全体系结构的一部分）来改善客户的平台安全性。 Windows 8 和更高版本的客户端电脑以及“Windows 硬件兼容性要求”中定义的 Windows Server 2016 需要安全启动。
1.3、安全启动过程的工作原理如下：
1.3.1、固件启动组件：固件验证操作系统加载程序是否受信任（Windows 或其他受信任操作系统。）
1.3.1.1、Windows 启动组件：BootMgr、WinLoad、Windows 内核启动。 Windows 启动组件验证每个组件上的签名。 不会加载任何不受信任的组件，存在这种组件会触发安全启动修正。
1.3.1.2、防病毒和反恶意软件初始化：将在此软件中检查 Microsoft 颁发的特殊签名，以验证它是否为受信任的启动关键型驱动程序。此软件将在启动过程的早期阶段启动。
1.3.1.3、启动关键型驱动程序初始化：在 WinLoad 中进行安全启动验证的过程中会检查所有启动关键型驱动程序上的签名。
1.3.1.4、其他操作系统初始化
1.3.1.5、Windows 登录屏幕

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

1.5、 公钥基础结构 (PKI) 和安全启动
1.5.1、PKI 在系统中建立真实性和信任。 安全启动将 PKI 用于两种高级目的：
1.5.2、在启动过程中确定早期启动模块是否受信任并允许其执行。
1.5.3、对服务请求的身份验证包括检查安全启动数据库是否已修改和平台固件是否已更新。
1.6、PKI 包括：
一个证书颁发机构 (CA)，它颁发数字证书。
一个注册机构，它验证向 CA 请求证书的用户的身份。
一个中心目录，用于存储密钥以及编制密钥的索引。
一个证书管理系统。
1.7、公钥加密
1.7.1、公钥加密使用一对数学上相关的加密密钥（分别称为公钥和私钥）。 如果你只知道其中一个密钥，无法轻松计算出另一个密钥。 如果一个密钥用于加密信息，则只有相应的密钥才能解密该信息。 对于安全启动，私钥用于对代码进行数字签名，而公钥用于验证该代码中的签名以证明其真实性。 如果私钥被泄露，则使用相应公钥的系统不再安全。 这可能会导致 bootkit 攻击，并会损害负责确保私钥安全性的实体的信誉。
1.7.2、安全启动公钥系统中包含以下各项：
1.7.2.1、RSA 2048 加密
RSA-2048 是一种非对称加密算法。 以原始格式存储 RSA-2048 模数所需的空间为 2048 位。

1.7.2.2、自签名证书
由与证书公钥匹配的私钥签名的证书称为自签名证书。 根证书颁发机构 (CA) 证书属于这种类别的证书。
1.7.2.3、 证书颁发机构
证书颁发机构 (CA) 颁发签名证书，用于确认证书使用者的身份并将该身份绑定到证书中包含的公钥。 CA 使用其私钥为证书签名。 它向自签名根 CA 证书中的所有相关方颁发相应的公钥。
1.7.2.4、在安全启动中，证书颁发机构 (CA) 包括 OEM（或其代理人）和 Microsoft。 CA 生成构成信任根的密钥对，然后使用私钥为合法操作（例如允许的早期启动 EFI 模块和固件服务请求）签名。 交付的相应公钥将嵌入到支持安全启动的电脑上的 UEFI 固件中，并用于验证这些操作。
1.7.3、公钥。公共平台密钥在电脑上交付，可供用户访问，或者是“公开的”。 在本文档中，我们将使用后缀“pub”来表示公钥。 例如，PKpub 表示 PK 的公钥部分。
1.7.4、私钥。要使 PKI 正常工作，需要安全地管理私钥。 私钥应该仅供组织中少数高度可信的人员访问，并放置在实施了严格访问策略限制的物理安全位置。 在本文档中，我们将使用后缀“priv”来表示私钥。 例如，PKpriv 表示 PK 的私钥部分。
1.7.5、 证书。数字证书的主要用途是验证已签名数据的来源，例如二进制文件等。证书的常见用途是使用传输层安全性 (TLS) 或安全套接字层 (SSL) 确保 Internet 消息安全性。 使用证书验证已签名数据可让接收方知道数据的来源，以及数据在传输过程中是否被更改。从较高层面讲，数字证书一般包含可分辨名称 (DN)、公钥和签名。 DN 标识某个实体 - 例如某家公司，该实体持有与证书公钥匹配的私钥。 使用私钥为证书签名并将签名放在证书中可将私钥与公钥相关联。证书可以包含某些其他类型的数据。 例如，一个 X.509 证书包括该证书的格式、该证书的序列号、用于对该证书进行签名的算法、颁发该证书的 CA 的名称、请求该证书的实体的名称和公钥以及 CA 的签名。
1.7.6、链接证书
根 CA 是自签名证书，其他证书由根 CA 签名。
1.7.6.1、用户证书通常由不同的私钥签名，例如 CA 的私钥。 这就构成了一个双证书链。 验证用户证书是否真实涉及到验证证书中的签名，这需要使用 CA 的公钥。 但在可以使用 CA 的公钥之前，需要验证随附的 CA 证书。 1.7.6.2、由于 CA 证书是自签名证书，因此 CA 公钥用于验证证书。
用户证书不需要由根 CA 的私钥签名。 它可以由中间方的私钥签名，该中间方的证书由 CA 的私钥签名。 这是三证书链的一个实例：用户证书、中间证书和 CA 证书。 但是，链可以包含多个中间方，因此证书链可为任意长度。
1.7.7、安全启动 PKI 要求。UEFI 定义的信任根由平台密钥以及 OEM 或 ODM 在固件核心中包含的任何密钥组成。 UEFI 安全启动过程不涉及预 UEFI 安全性和信任根，不过，本文中所参考的美国国家标准技术研究所 (NIST) 和受信任计算小组 (TCG) 出版物介绍了这些技术。
1.8、安全启动要求
实现安全启动时需要考虑以下参数：
客户要求
Windows 硬件兼容性要求
密钥生成和管理要求。
需要为安全启动密钥管理选择硬件（例如硬件安全模块 (HSM)），考虑交付给政府和其他机构的电脑的特殊要求，最后考虑创建、填充和管理各种安全启动密钥的生命周期的过程。

1.9、安全启动相关的密钥
1.9.1、用于安全启动的密钥如下：
pk、kek、db、dbx 和固件密钥、winrt 密钥
1.9.2、通过 OEM 在制造期间安装在固件中的平台密钥保护的。 安全引导使用其他密钥来保护对存储密钥的数据库的访问，以允许或禁止执行固件。
1.9.3、已获授权的数据库 (db) 包含代表受信任固件组件和操作系统加载程序的公钥与证书。 禁止的签名数据库 (dbx) 包含恶意和有漏洞组件的哈希以及已泄露的密钥和证书，并阻止执行这些恶意组件。 这些策略的强度基于使用验证码和公钥基础结构 (PKI) 对固件进行签名。 PKI 是在信息交换期间创建、管理和吊销用于建立信任的证书的完善过程。 PKI 是安全启动的安全模型的核心。
1.10、平台密钥 (PK)
1.10.1、根据 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.10.2、若要更改平台所有权，必须将固件置于 UEFI 定义的设置模式，该模式会禁用安全启动。 请仅在制造过程中需要使用设置模式时，才还原到设置模式。
1.10.3、对于桌面和服务器设备，OEM 可以管理 PK 和与之关联的必要 PKI，或选择使用适用于 OEM 的 Microsoft 托管 PK。 Microsoft 托管 PK 受 Microsoft HSM 保护，并作为 PKI 最佳实践的一部分进行管理。 它是 Windows 生态系统的首选 PK。
1.11、注册或更新用于注册平台密钥的密钥交换密钥 (KEK)
1.11.1、平台所有者通过根据 UEFI 规范 2.3.1 勘误表 C 第 7.2.1 部分中的规定调用 UEFI 启动服务 SetVariable() 并重置平台，来注册平台密钥的公钥部分 (PKpub)。 如果平台处于设置模式，则新的 PKpub 应通过其对应的 PKpriv 签名。 如果平台处于用户模式，则必须使用当前的 PKpriv 为新的 PKpub 签名。 如果 PK 的类型为 EFI_CERT_X509_GUID，则此公钥必须通过中间 PKpriv 签名，而不是通过 PK 颁发的任何证书的私钥签名。
1.11.2 清除平台密钥
平台所有者通过使用变量大小 0 调用 UEFI 启动服务 SetVariable() 并重置平台，来清除平台密钥的公钥部分 (PKpub)。 如果平台处于设置模式，则不需要对空变量进行身份验证。 如果平台处于用户模式，则必须使用当前 PKpriv 为空变量签名；有关详细信息，请参阅 UEFI 规范 2.3.1 勘误表 C 中的第 7.2 部分（变量服务）。 强烈建议不要通过使用生产 PKpriv 为包签名来重置平台，因为这会允许以编程方式禁用安全启动。 这种做法主要用在生产前测试方案中。也可以使用安全平台特定的方法清除平台密钥。 在这种情况下，全局变量设置模式也必须更新为 1。
1.12、PK 生成
1.12.1、根据 UEFI 的建议，公钥必须存储在非易失性存储中，该存储在电脑上具有防篡改和防删除功能。 私钥安全保存在合作伙伴场所或 OEM 的保安室中，只会将公钥加载到平台上。 第 2.2.1 和 2.3 部分提供了更多详细信息。
1.12.2、Microsoft 提供适用于 OEM 的 PK，以消除维护和保护 PK 证书的责任。 PK 受 Microsoft HSM 保护，并作为 Microsoft PKI 操作的一部分进行管理。
1.12.3、生成的 PK 数量由平台所有者 (OEM) 自行决定。 这些密钥可以：
在每台电脑上生成一个密钥。 每台设备有一个唯一的密钥。 政府机构、金融机构或其他安全需求较高的服务器客户可能需要这样做。 这可能需要提供额外的存储和加密处理能力来为大量电脑生成私钥和公钥。 这会增大将来向设备推送固件更新时将设备映射到其相应 PK 的复杂性。 可以根据 HSM 供应商使用几种不同的 HSM 解决方案来管理大量的密钥。
1.12.4、为每个型号生成一个密钥。 每个电脑型号有一个密钥。 此处的弊端是，如果密钥泄露，同一型号的所有计算机都易受攻击。 Microsoft 建议将此方法用于桌面型电脑。
1.12.5、为每个产品系列生成一个密钥。 如果密钥泄露，则整个产品系列都易受攻击。
1.12.6、为每个 OEM 生成一个密钥。 虽然这可能是最简单的设置方法，但如果密钥泄露，生产的每台电脑都易受攻击。 为了加速工厂车间的操作，可以预先生成 PK（也许还包括其他密钥），并将其存储在安全位置。 以后可以在装配线中检索和使用这些密钥。
1.13、重新生成 PK 密钥
1.13.1、如果 PK 泄露或客户出于安全要求决定注册自己的 PK，则可能需要这样做。可以根据选择用于创建 PK 的方法针对某个型号或电脑重新生成密钥。 所有较新的电脑将通过新建的 PK 签名。
1.13.2、若要在生产电脑上更新 PK，需要使用一个通过现有 PK 签名的变量更新来替换该 PK，或需要一个固件更新包。 OEM 还可以创建一个 SetVariable() 包，并使用一个只更改 PK 的简单应用程序（例如 PowerShell）分发该包。 固件更新包将由安全固件更新密钥签名并由固件验证。 如果执行固件更新来更新 PK，应确保保留 KEK、db 和 dbx。
1.13.3、在所有电脑上，建议不要将 PK 用作安全固件更新密钥。 如果 PKpriv 泄露，安全固件更新密钥也会泄露（因为它们是相同的）。 在这种情况下，可能无法进行更新以注册新的 PKpub，因为更新过程也会泄密。
1.13.4、在 SOC 电脑上，还有另一个原因解释了为何不应使用 PK 作为安全固件更新密钥。 此原因是安全固件更新密钥永久烧刻在符合 Windows 硬件认证要求的电脑上的熔断器中。

1.14、密钥交换密钥 (KEK)：密钥交换密钥在操作系统与平台固件之间建立信任关系。 每个操作系统（可能还包括每个需要与平台固件通信的第三方应用程序）会将一个公钥 (KEKpub) 注册到平台固件中。
1.14.1 注册密钥交换密钥
平台所有者通过以下两种方式之一注册密钥交换密钥：根据 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() 写入数据库。
1.14.2、如果平台处于设置模式，则不需要对签名数据库变量进行签名，但仍应根据第 7.2.1 部分中有关已经过身份验证的变量的规定来准备 SetVariable() 调用参数。 如果平台处于用户模式，则必须使用当前的 PKpriv 为签名数据库签名
1.14.3、清除 KEK。可以“清除”（删除）KEK。 注意，如果平台上未安装 PK，则不需要为“清除”请求签名。 如果已签名，则清除 KEK 时需要 PK 签名的包，而清除 db 或 dbx 时需要由 KEK 中存在的任何实体签名的包。
1.14.4、Microsoft KEK。需要以下 Microsoft KEK 证书以启用对不良映像的吊销，通过更新 dbx，并且可能更新数据库以准备较新的 Windows 签名映像。
Microsoft Corporation KEK 2K CA 2023
SHA-1 证书哈希：459AB6FB5E284D272D5E3E6ABC8ED663829D632B。
SignatureOwner GUID：{77fa9abd-0359-4d32-bd60-28f4e78f784b}。
Microsoft 会向合作伙伴提供证书，可将该证书添加为 EFI_CERT_X509_GUID 或 EFI_CERT_RSA2048_GUID 类型的签名。
可从以下位置下载 Microsoft KEK 证书：https://go.microsoft.com/fwlink/?linkid=2239775。
KEKDefault 平台供应商必须在 KEKDefault 变量中提供一组默认的密钥交换密钥。 有关详细信息，请参考 UEFI 规范的第 27.3.3 部分。
1.14.5、OEM/第三方 KEK - 添加多个 KEK
客户和平台所有者不需要有自己的 KEK。 在非 Windows RT 电脑上，OEM 可以使用额外的 KEK，以允许其他 OEM 或受信任的第三方控制 db 和 dbx。
1.14.6、安全启动固件更新密钥：安全固件更新密钥用于在需要更新固件时为固件签名。 此密钥的最低密钥强度必须达到 RSA-2048。 所有固件更新必须由 OEM、其受信任的委托人（例如 ODM 或 IBV（独立 BIOS 供应商））或安全签名服务以安全方式签名。
1.14.7、根据 NIST 出版物 800-147，现场固件更新必须支持准则中所述的所有要素：
对固件闪存存储所做的任何更新必须由创建者签名。
固件必须检查更新的签名。
1.15、为安全固件更新创建密钥
1.15.1、将使用同一密钥为所有固件更新签名，因为公钥部分驻留在电脑上。 还可以使用链接到安全固件更新密钥的密钥来为固件更新签名。
1.15.2、每台电脑可能有一个密钥（例如 PK），或者每个型号或每个产品系列有一个密钥。 如果每台电脑有一个密钥，则意味着需要生成数百万个唯一的更新包。 请根据资源可用性考虑哪种方法适合你。 为每个型号或产品系列提供一个密钥是合理的折衷方案。
1.15.3、安全固件更新公钥（或其哈希，使用哈希可以节省空间）将存储在平台上的某种受保护的存储中 - 通常是受保护的闪存（在电脑上）或一次性可编程熔断器（在 SOC 上）。如果仅存储此密钥的哈希（以节省空间），则固件更新将包含该密钥，更新过程的第一阶段将验证更新中的公钥是否与存储在平台上的哈希匹配。
1.15.4、胶囊 (Capsule) 是每次重启后操作系统将数据传递到 UEFI 环境的一种方式。 Windows 调用 UEFI UpdateCapsule() 来传送系统和电脑固件更新。 在调用 ExitBootServices() 之前启动时，Windows 会将在 Windows 驱动程序存储中找到的任何新固件更新传入 UpdateCapsule()。 UEFI 系统固件可以使用此过程来更新系统和电脑固件。 利用此项 Windows 固件支持，OEM 可以依赖相同的通用格式和过程来更新系统的固件和电脑固件。 固件必须实现 ACPI ESRT 表才能支持 Windows 的 UEFI UpdateCapsule()。
1.15.5、有关实现 Windows UEFI 固件更新平台支持的详细信息，请参阅以下文档：Windows UEFI 固件更新平台。
更新胶囊可以存储在内存或磁盘中。 Windows 支持内存中更新。
1.15.6、胶囊（内存中胶囊）
下面是用于运行内存中更新胶囊的事件流：
胶囊由操作系统中的应用程序放入内存中
设置邮箱事件以告知 BIOS 有等待的更新
电脑重启并验证胶囊映像，然后 BIOS 执行更新
1.15.7、典型固件更新的工作流：
下载并安装固件驱动程序。
重新启动。
操作系统加载程序检测并验证固件。
操作系统加载程序将二进制 Blob 传递给 UEFI。
UEFI 执行固件更新（此过程由芯片供应商负责）。
操作系统加载程序检测成功完成。
操作系统完成启动。

2、允许的签名数据库 (db)

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

若要允许 Windows OS 加载程序加载，必须将以下证书包含在 db 中：
Windows UEFI CA 2023
SHA-1 证书哈希：45A0FA32604773C82433C3B7D59E7466B3AC0C67。
SignatureOwner GUID：{77fa9abd-0359-4d32-bd60-28f4e78f784b}。
Microsoft 会向合作伙伴提供证书，可将该证书添加为 EFI_CERT_X509_GUID 或 EFI_CERT_RSA2048_GUID 类型的签名。
可从以下位置下载 Windows UEFI CA 2023：https://go.microsoft.com/fwlink/?linkid=2239776。
除了锁定为仅启动 Windows 的系统，OEM 应考虑包括 Microsoft 第三方 UEFI CA 和 Microsoft Option ROM CA，以允许来自第三方的 UEFI 驱动程序和应用程序在电脑上运行，而无需用户执行其他步骤。

Microsoft Corporation UEFI CA 2011
SHA-1 证书哈希：46DEF63B5CE61CF8BA0DE2E6639C1019D0ED14F3。
SignatureOwner GUID：{77fa9abd-0359-4d32-bd60-28f4e78f784b}。
Microsoft 会向合作伙伴提供证书，可将该证书添加为 EFI_CERT_X509_GUID 或 EFI_CERT_RSA2048_GUID 类型的签名。
可从以下位置下载 Microsoft Corporation UEFI CA 2011：https://go.microsoft.com/fwlink/p/?linkid=321194。

Microsoft UEFI CA 2023
SHA-1 证书哈希：B5EEB4A6706048073F0ED296E7F580A790B59EAA。
SignatureOwner GUID：{77fa9abd-0359-4d32-bd60-28f4e78f784b}。
Microsoft 会向合作伙伴提供证书，可将该证书添加为 EFI_CERT_X509_GUID 或 EFI_CERT_RSA2048_GUID 类型的签名。
可从以下位置下载 Microsoft UEFI CA 2023：https://go.microsoft.com/fwlink/?linkid=2239872。

Microsoft Option ROM UEFI CA 2023
SHA-1 证书哈希：3FB39E2B8BD183BF9E4594E72183CA60AFCD4277。
SignatureOwner GUID：{77fa9abd-0359-4d32-bd60-28f4e78f784b}。
Microsoft 会向合作伙伴提供证书，可将该证书添加为 EFI_CERT_X509_GUID 或 EFI_CERT_RSA2048_GUID 类型的签名。
可从以下位置下载 Microsoft Option ROM UEFI CA 2023：https://go.microsoft.com/fwlink/?linkid=2284009。

3、关于UEFI规范

请参考：https://uefi.org/specifications