为了防御恶意软件攻击，目前市面上所有电脑设备启动时默认开启安全启动(Secure Boot)模式。安全启动(Secure Boot)是UEFI扩展协议定义的安全标准，可以确保设备只使用OEM厂商信任的软件启动。UEFI签名认证就是对运行在 UEFI 系统下的 efi 驱动和通过 UEFI 启动的 shim（垫片）进行测试审查后，获得微软 UEFI 签名。UEFI签名认证能够解决固件在启动时加载不了，无法正常工作等问题。

什么是BIOS、EFI和UEFI

BIOS是固化在电脑主板上一个程序，主要用于开机系统自检和引导加载操作系统。而现在的新型电脑用的基本都是UEFI启动，从EFI启动过渡而来，基本功能上都和BIOS差不多，都是完成系统自检、完成硬件初始化、加载操作系统。

EFI，是Extensible Firmware Interface的词头缩写，直译过来就是可扩展固件接口，它是用模块化、高级语言（主要是C语言）构建的一个小型化系统，它和BIOS一样，主要在启动过程中完成硬件初始化，但它是直接利用加载EFI驱动的方式，识别系统硬件并完成硬件初始化，彻底摒弃读各种中断执行。当EFI发展到1.1的时候，英特尔决定把EFI公之于众，EFI在2.0后也遂改称为UEFI。

UEFI 即统一可扩展固件接口，UEFI 用于替代较旧的 BIOS 固件接口和可扩展固件接口 (EFI) 1.10 规范。目前的计算机硬件基本上都集成了 UEFI 的固件，并逐步形成和推广成统一可扩展接口，负责加电自检（POST）、联系操作系统以及提供连接操作系统与硬件的接口。

UEFI具有一个独特的功能——安全启动(secure boot)，而EFI是没有安全启动的。安全启动是UEFI扩展协议定义的安全标准，旨在帮助确保设备仅使用原始设备制造商 (OEM) 信任的软件启动，通俗的解释是叫做固件验证，开启UEFI的安全启动后，主板会根据TPM芯片（或者CPU内置的TPM）记录的硬件签名对各硬件判断，只有符合认证的硬件驱动才会被加载。而Win8以后的Windows则是在操作系统加载的过程中对硬件驱动继续查签名，符合Windows记录的硬件才能被Windows加载。

如何进行UEFI签名认证

开发者需要通过“Windows合作伙伴中心硬件仪表板”对UEFI 固件二进制文件进行数字签名，使其能够安装在 Windows 设备上。“Windows合作伙伴中心硬件仪表板”注册以及UEFI 固件签名都需要使用扩展验证（EV）代码签名证书。

UEFI 签名是 Windows 硬件开发人员中心仪表板提供的一项服务，开发人员通过该服务提交面向 x86、x86-64 或 ARM 计算机的 UEFI 固件二进制文件，通过手动审查批准这些二进制文件后，即可在启用安全启动且允许微软第三方UEFI CA的电脑上安装。

沃通CA提供微软指定证书颁发机构DigiCert、Sectigo等品牌EV代码签名证书，支持为驱动程序、UEFI固件、LSA插件进行签名，支持用于Windows合作伙伴中心硬件仪表板门户帐号注册。

微软最新UEFI签名要求

以下为微软对UEFI 签名认证的最新要求（2021年1月发布）：

(1)UEFI 提交需要 EV 代码签名证书和 Azure Active Directory （AAD） 帐户。

(2)只有将发布给客户的生产质量代码（例如，“发布到制造”代码，而不是测试或调试模块）（没有仅限内部的代码或工具）才有资格进行 UEFI 签名。对于内部使用的代码，应将自己的密钥添加到安全启动数据库 UEFI 变量，或在开发和测试期间关闭安全启动。

(3)Microsoft UEFI CA 仅对那些供公众使用的产品进行签名，并且是跨所有 UEFI 安全启动支持的设备实现互操作性所必需的产品。如果产品特定于特定 OEM 或组织，并且外部不可用，则应使用私钥对其进行签名，并将证书添加到安全启动数据库。

(4)提交用于 UEFI 签名的代码不得受 GPLv3 或任何旨在赋予某人要求授权密钥的权利以便能够在设备上安装修改后形式的代码的许可证的约束。受已签名的此类许可证约束的代码可能会吊销该签名。例如，GRUB 2 在 GPLv3 下获得许可，不会被签名。

(5)如果存在与使用某些技术的代码相关的已知恶意软件向量，则该代码将不会签名，并且可能会被吊销。例如，使用未启用安全启动的 GRUB 版本将不会进行签名。

(6)如果提交代码中存在已知的安全漏洞，则不会对提交进行签名，即使你的功能未公开该代码也是如此。例如，OpenSSL 的最新已知安全版本是 0.9.8za 和 1.0.1h，因此，如果提交包含包含已知漏洞的早期版本，则不会对提交进行签名。

(7)在提交签名之前，您必须按照提交预测试文档（对于 UEFI 提交）测试您的产品。

(8)微软不会签署使用 EFI_IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER 的 EFI 提交。相反，建议过渡到EFI_IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER。这可以防止不必要地使用运行时 EFI 驱动程序。

(9)使用 EFI 字节码 （EBC）：Microsoft 不会签署基于 EBC 的提交的 EFI 提交。

(10)如果你的提交是 DISK 加密或基于文件/卷的加密，则必须确保不加密 EFI 系统分区，或者如果加密，请确保对其进行解密，并在 Windows 准备好启动时使其可用。

(11)如果你的提交由许多不同的 EFI 模块、多个 DXE 驱动程序和多个启动应用程序组成，Microsoft 可能会要求你将 EFI 文件合并为最小格式。例如，每个体系结构可能只有一个启动应用程序，并将 DXE 驱动程序合并到一个二进制文件中。

(12)如果你的提交是 SHIM（将执行移交给另一个引导加载程序），那么您必须首先提交给 SHIM 审查委员会并获得批准，然后才能签署提交。该审查委员会将检查以确保以下内容：

代码签名密钥必须仅由具有受信任角色的人员备份、存储和恢复，并在物理安全环境中至少使用双因素授权。

私钥必须使用硬件加密模块进行保护。这包括但不限于 HSM、智能卡、类似智能卡的 USB 令牌和 TPM。

操作环境必须达到至少等于 FIPS 140-2 级别 2 的安全级别。

如果嵌入式证书是 EV 证书，则应满足上述所有要求。我们建议您使用 EV 证书，因为这将加快 UEFI CA 签名周转速度。

提交者必须为填充程序加载的所有内容设计和实现强大的吊销机制，无论是直接的还是随后的。

如果您丢失密钥或滥用密钥，或者密钥泄露，则任何依赖该密钥的提交都将被撤销。

已知某些填充程序会给安全启动系统带来弱点。为了更快地完成签名，建议使用 shim – GitHub 分支中的 0.8 或更高版本的源代码。

(13)如果提交包含 iPXE 功能，则需要执行其他安全步骤。此前，微软已经完成了对2Pint的iPXE分支的深入安全审查。