Microsoft UEFI CA 签名策略更新

本博文介绍了 UEFI 签名策略变更。这些变更非常重要，它们有助于确保安全引导实现其安全目标，以及保持对 UEFI 提交申请进行签名的合理周转时间。本博文还重申了现有的 UEFI 签名策略许可条款的一些重要内容。

UEFI 签名是由 Windows 开发人员中心硬件仪表板提供的一项服务，其允许您提交针对 x86 或 x64 系统的计算机的 UEFI 固件二进制文件，并由 Microsoft 进行签名，以便它们可以更轻松地安装在使用安全引导的运行 Windows 的计算机上，并执行已进行 UEFI CA 签名的代码。

在 Microsoft 保留是否对提交申请进行签名的自由裁量权的同时，这些要求应始终予以遵循。这不仅可以帮助您在更短的周转时间内使提交申请获签，还有助于避免出现吊销的情况。在签名之前，Microsoft 可能会进行后续审查，包括（但不仅限于）调查表、包测试以及针对这些要求的其他安全测试。

1.自2014年3月15日起，UEFI 提交将需要一个 EV 证书。

            a. 从2014年3月15日开始，SysDev 将开始接受由 DigiCert 或 VeriSign 颁发的 EV 证书来进行新的提交和续订。

            b. 在 2014 年 8 月 15 日之前，现有提交者必须从现有的非 EV 代码签名证书移至 EV 代码签名证书。这一扩展旨在为无障碍迁移提供便利。

2.仅向客户（无内部专用代码或工具）发布而产生的高质量代码（例如，“交付厂商版”代码，而不是测试或调试模块）才有资格获得 UEFI 签名。对于内部专用代码，我们建议您关闭安全引导，或者在开发和测试期间向 SecureBoot 数据库中添加您自有的密钥。

3.要进行 UEFI 签名的提交代码不得受到 GPLv3 或任何旨在授予某人要求授权密钥的权利以使其能够在设备上安装修改后的代码的许可证的影响。受此类已签名的许可证的影响的代码可能会被吊销签名。例如，根据 GPLv3 许可的 GRUB 2 将不会被签名。

4.如果存在与使用某些技巧的代码相关联的已知恶意软件矢量，该代码将不会被签名，而且可能会被吊销签名。例如，使用未采用 SecureBoot 的 GRUB 版本将不会被签名。

5.所有代码模块都必须在执行之前进行身份验证。若情况并非如此，申请将不会被签名，而如果已签名，则将被吊销。

a. 如果您的提交申请加载 GRUB 或其他加载器，其必须采用 SecureBoot。

例如，带 SecureBoot 补丁的最新的 GRUB 2。

b. 当初始引导完成时，开发人员可能会认为安全引导的安全要求已满足。但是，在执行未经过身份验证的代码之后，如果安全引导系统允许启动其他操作系统实例，则安全引导的安全保证将会受到威胁。如果这一漏洞被利用，提交申请可能将被吊销。

6.如果您的提交申请是填充码（将执行递交给其他引导加载器）：

a. 代码签名密钥只能由受信任的人员，在物理安全的环境中，至少使用双因素身份验证进行备份、存储和恢复。

• 私钥必须受到硬件加密模块的保护。这包括但不限于 HSM、智能卡（例如 USB 令牌和 TPM）。
• 操作环境必须至少获得等同于 FIPS 140-2 第 2 级的安全级别。

如果嵌入的证书是 EV 证书，您满足上述所有要求。我们建议您使用 EV 证书，因为这样将缩短 UEFI CA 签名周转时间。

b. 提交者必须针对填充码加载的所有内容设计强大的吊销机制，随后直接实施该机制。

c. 如果您的密钥丢失或被滥用，或者您的密钥泄露，所有依赖于该密钥的提交申请都将被吊销。

d. 众所周知，一些填充码在 SecureBoot 系统中暴露出了缺陷。为了缩短签名周转时间，我们建议您使用 填充码 - GitHub 分支中的 0.7 或更高版本的源代码。

7.在提交以进行签名之前，您需要根据预提交测试文档（用于 UEFI 提交申请）测试您的产品。

8.如果您的提交代码存在已知的安全漏洞，提交申请将不会被签名，即使您的功能不公开该代码。例如，最新的已知安全版本的 OpenSSL 是 0.9.8za 和 1.0.1h，因此如果您的提交申请包含带有已知漏洞的早期版本，其将不会被签名。