安全技术篇 – Secure Boot（下）

一、简介

UEFI固件在启动的过程中，可能会遭受到各种各样的攻击，从而会造成重大的威胁。UEFI的启动流程是由多个部分组成的，每个部分实施的保护技术都会有所不同。

下图展示Intel CPU对UEFI启动的验证流程：

Secure Boot（安全启动）是验证启动过程中使用的每个二进制文件（如驱动程序、内核等），验证的方式主要有两种：对于有签名的程序，通过公钥来检查签名是否合法。而对于没有签名的程序，则可以检查其哈希值是否合法。

如何判断合法呢？UEFI固件中有一个数据库，存放着经过认证的公钥或哈希值列表，在校验二进制文件是否合法的时候，公钥或哈希值便是从数据库中获取的。

UEFI规范中，对于安全启动主要定义三大部分，信任链密钥、操作模式和信任关系的建立。

二、信任链密钥

安全启动建立了在平台所有者、平台固件和操作系统之间的的信任关系，通过两对密钥来进行逐级验证。

Platform Key (PK)

平台密钥（PK）是指在系统中处于最高层级的主密钥证书，也是安全启动的根证书，在平台所有者和平台固件之间建立了可信链。PK采用 RSA-2048 加密算法，以公钥证书的形式存在。在最安全的使用情况下，每个端点设备都应拥有唯一的 PK，通常由所有者或基础结构运营商负责维护。PK 私钥可以签署 UEFI 环境变量或 KEK、DB 和 DBX 的变更，这些变更可以通过 PK 证书进行验证。PK 不能用于签署在启动时检查的可执行二进制文件。

需要注意的是，必须先安装 PK 证书，Secure Boot 才能开始执行安全检查。一些厂商会在设备出厂时预装随机生成的 PK 或通用/共享 PK。终端所有者也可以在定制过程中安装自己的 PK，每个端点使用唯一的 PK 可以更好地防范 UEFI 攻击。

Key Exchange Keys (KEK)

密钥交换密钥（KEK）在操作系统和平台固件之间建立了信任关系。一个系统中通常存在一个或多个 KEK，它们是 RSA-2048 公钥证书。不同的端点设备可以共享相同的 KEK，并非特定于某个端点。KEK 可以用于更新 DB 和 DBX ，也可以用于对可启动程序的签名。然而，替换 KEK 比较困难，因为需要 PK 的参与。因此，KEK 应仅用于更新DB 和 DBX 。

Allow Database (DB)

允许列表数据库（DB）用于存储允许在启动时执行的二进制文件的哈希值或证书。存储内容有两种类型，SHA-256 哈希值和RSA 2048 公钥证书。如果二进制文件的签名可以通过证书验证，则允许在启动时执行。同样，即使没有签名，计算出的 SHA-256 哈希值与受信任的哈希值匹配的二进制文件也将被允许启动。通俗的讲，它便是一个存储白名单程序信息的数据库。

Disallow Database (DBX)

与DB相反，禁止列表数据库（DBX）是一个存储黑名单程序信息的数据库。DBX 在启动时具有最终否决权，任何与 DBX 哈希值匹配或具有由 DBX 证书验证的签名的二进制文件都将被禁止在启动时执行。DBX 通常用于针对错误签名的二进制文件，例如恶意软件或调试引导加载程序。通常会首先检查 DBX，除非存在MOKX。

Machine Owner Key (MOK)

机器所有者密钥（MOK）并非 UEFI Secure Boot 标准的一部分，而是由 Linux 实现使用。MOK 的功能与 DB（允许列表数据库）相同，由预引导加载程序 Shim 进行初始化。Linux 发行版使用 MOK 密钥来签署自己的二进制文件，而不是采用由 Microsoft 或原始设备制造商（OEM）签署每个更新或变体的流程。有装过ubuntu系统的，你会发现，引导分区除了EFI\Boot\BootX64.efi，还存在一个\EFI\ubuntu\shimx64.efi。Shim 由 Microsoft 签署，因此可在大多数支持 Secure Boot 标准模式的计算机上运行。MOK 可以存储 SHA-256 哈希值和 RSA 公钥证书。一些 Linux 内核使用 MOK 进行驱动程序签名检查，以替代或补充 DB、DBX 和 KEK。

Machine Owner Key Deny list (MOKX)

机器所有者密钥禁止列表（MOKX）也不是 UEFI Secure Boot 标准的一部分，而是存在于 Linux 实现中，其功能类似于 DBX（禁止列表数据库）。引导加载程序 Shim 负责初始化 MOKX。一些 Linux 内核使用 MOKX 进行驱动程序签名检查，以替代或补充 DBX。如果存在 MOKX，通常会在检查 DBX 之前先检查 MOKX。

平台固件会对启动过程中的代码进行签名检查，一直检查到 Bootloader。参与启动过程的软件组件，例如引导加载程序、内核、初始文件系统、驱动程序、内核模块、策略等，必须在软件层面继续执行签名检查机制。在不同的操作系统中，签名检查的具体实现方式有所不同：

• Microsoft Windows： 签名检查由 Windows Boot Manager 和 Windows 内核执行。
• Red Hat Enterprise Linux (RHEL)： 签名检查由 Shim、GRUB 和 Linux 内核执行。Red Hat 使用存储在 Microsoft 签名的 Shim 版本中的 MOK（Machine Owner Key，机器所有者密钥）来验证 GRUB、内核、驱动程序和其他二进制文件。

三、操作模式

User Mode

User Mode 即用户模式，是指在注册 PK 后生效的 Secure Boot 操作模式，Secure Boot 策略会被强制执行。用户模式是 Secure Boot 的默认模式，通常用于生产环境中。在用户模式下，通常无法修改 Secure Boot 策略。如果需要更改策略，需要进入设置模式或审核模式。

Setup Mode

Setup Mode 即设置模式，在尚未安装 PK 时将处于此模式，此模式允许操作 PK、 KEK、DB 和 DBX，系统所有者可以添加、删除或修改这些值，以控制允许在启动时执行的文件。一旦建立 PK，系统会在下次启动时自动退出设置模式并进入用户模式。

Audit Mode

Audit Mode 即审核模式，其目的是收集有关 Secure Boot 检查结果的调试信息。进入审核模式后，仍然执行签名检查，但不会被禁止未授权的程序启动。管理员可以使用此模式来查看哪些启动过程部分被验证了、验证结果如何、是否存在与启动组件和策略相关的问题。

Deployed Mode

Deployed Mode即部署模式，是最安全的模式，它强制执行当前的 Secure Boot 配置，验证所有程序的合法性，且限制模式的切换。

四、建立信任关系

注册PK

平台所有者可以通过调用 UEFI 引导服务 SetVariable() 来注册 PK 的公钥部分（PKpub），注册过程的具体要求取决于系统所处的模式：

• 设置模式：新的 PKpub 可以使用其对应的私钥 PKpriv 进行签名。
• 用户模式：新的 PKpub 必须使用当前的 PKpriv 进行签名。

当平台处于设置模式时，PK 注册成功后将立即进入用户模式。

已认证的 PK 变量始终可以读取，但只能在以下情况下写入：

• 平台处于设置模式
• 平台处于用户模式，并且提供的 PKpub 已使用当前的 PKpriv 进行签名

清除PK

密钥交换密钥（KEKs）存储在一个签名数据库中，该数据库作为一个经过认证的 UEFI 变量进行存储。

平台所有者可以通过以下两种方式注册 KEK：

1. 调用 SetVariable() 函数： 调用 SetVariable() 函数并将 EFI_VARIABLE_APPEND_WRITE 属性设置为真，同时将新密钥(s)包含在 Data 参数中。
2. 读取、追加和写入数据库： 使用 GetVariable() 函数读取数据库，将新的 KEK 追加到现有的密钥中，然后使用 SetVariable() 函数写入数据库，但不设置 EFI_VARIABLE_APPEND_WRITE 属性。

在注册与清除密钥的操作中，涉及了几种模式的切换，如下图：

五、总结

在平台固件中，通过注册 PK、KEK 和 DB 建立信任关系，其中固件只能包含一个PK，而 KEK 和 DB 则可以包含多个。平台固件可以通过调用SetVariable()函数来注册和清除密钥，在此过程中，涉及了Setup Mode, User Mode, Audit Mode和Deployed Mode的切换。

通过建立信任链，Secure Boot 可以确保系统只运行经过认证的软件，保护系统免受恶意代码攻击。

六、引用

• https://learn.microsoft.com/zh-cn/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11
• https://tianocore-docs.github.io/Understanding_UEFI_Secure_Boot_Chain/draft/secure_boot_chain_in_uefi/uefi_secure_boot.html#2-1-uefi-secure-boot
• https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.html#secure-boot