4、Secure Boot的启用与配置：如何在主流主板和操作系统中启用Secure Boot，以及配置自定义密钥
Secure Boot（安全启动）是UEFI固件与操作系统之间建立信任链的关键机制。它的核心目标并非阻止恶意软件“安装”到磁盘，而是阻止未经签名的代码在系统启动的最早期阶段（固件→引导加载程序→内核）被执行。理解其启用与配置，不仅涉及BIOS菜单中的几个开关，更涉及密钥体系（PK、KEK、db、dbx）的完整生命周期管理。本章将围绕主流主板（以华硕、微星、戴尔为例）和操作系统（Windows 11、Ubuntu 22.04+、RHEL 9）的启用流程，深入讲解自定义密钥的生成、签名与部署方法，并剖析常见配置陷阱。
上图展示了Secure Boot的信任链模型。平台密钥（PK）是整个体系的根，它控制着密钥交换密钥（KEK）的更新；KEK又控制着签名数据库（db）和吊销数据库（dbx）的更新。系统启动时，UEFI固件使用db中的公钥验证引导加载程序的签名，引导加载程序再使用内核签名验证内核。理解这个层级关系，是进行自定义密钥配置的前提。
4.1 核心原理：从固件到内核的信任链传递
Secure Boot并非一个单一的安全功能，而是一套基于非对称加密的启动验证协议。其核心逻辑是：每一级启动组件在加载下一级组件之前，必须验证后者的数字签名是否有效。这个验证过程依赖于存储在主板NVRAM中的四个密钥/数据库变量：
- PK（Platform Key，平台密钥）：最高级别的密钥，通常由主板厂商预置，但用户可以替换为自己的密钥。PK的私钥用于签署KEK的更新。
- KEK（Key Exchange Key，密钥交换密钥）：用于签署db和dbx的更新。微软的KEK通常预装在主板上，以允许Windows更新签名数据库。
- db（Signature Database，签名数据库）：包含被允许执行的引导程序、驱动和内核的签名或哈希值。
- dbx（Revoked Signature Database，吊销签名数据库）：包含已知恶意或不信任的签名或哈希值，一旦匹配，启动将被阻止。
当用户按下电源键，UEFI固件首先执行自身代码，然后读取db中的签名列表，验证引导加载程序（如Windows Boot Manager或shim.efi）的签名。验证通过后，引导加载程序接管，继续验证操作系统内核。整个过程形成一个链式信任，任何一环断裂（签名无效、被吊销或缺失），系统都会拒绝启动并提示安全违规。
4.2 判断方法与操作流程：主流主板与操作系统的启用步骤
不同厂商的主板在BIOS菜单布局上差异较大，但核心选项名称和逻辑基本一致。以下分别介绍华硕（ASUS）、微星（MSI）和戴尔（Dell）的典型操作路径，以及Windows和Linux下的验证方法。
4.2.1 主板固件中的启用流程
| 主板/品牌 | 进入BIOS方式 | 典型菜单路径 | 关键设置项 |
|---|---|---|---|
| 华硕 (ASUS) | 开机按 Del 或 F2 | Boot → Secure Boot | OS Type: Windows UEFI mode；Key Management: 可导入自定义PK |
| 微星 (MSI) | 开机按 Del | Settings → Security → Secure Boot | Secure Boot: Enabled；GOP/CSM 需设为 UEFI only |
| 戴尔 (Dell) | 开机按 F2 | Secure Boot → Secure Boot Enable | Secure Boot Mode: Audit Mode / Deployed Mode；需先切换至 Audit Mode 才能自定义密钥 |
以华硕主板为例，启用Secure Boot的完整流程如下：
- 开机按
Del进入BIOS设置界面。 - 按
F7切换到高级模式（Advanced Mode）。 - 进入
Boot选项卡，确认CSM (Compatibility Support Module)已设置为Disabled（必须关闭CSM，否则无法启用Secure Boot）。 - 将
OS Type设置为Windows UEFI mode（部分主板显示为“Other OS”或“Custom”）。 - 进入
Secure Boot子菜单，将Secure Boot Control设置为Enabled。 - 保存并退出（F10），系统重启后即生效。
Win+R 输入 msinfo32 查看“BIOS模式”是否为“UEFI”。
4.2.2 操作系统中的验证与配置
在Windows 11/10中，可以通过以下命令验证Secure Boot状态：
# 以管理员身份运行 PowerShell
Confirm-SecureBootUEFI
# 如果返回 True，则表示已启用；如果返回 False，则表示未启用
# 或者使用 msinfo32 查看“安全启动状态”在Linux（Ubuntu/RHEL）中，可以使用 mokutil 工具：
# 查看Secure Boot状态
mokutil --sb-state
# 输出 "SecureBoot enabled" 表示已启用
# 查看当前已注册的密钥
mokutil --list-enrolled对于Ubuntu 22.04+，如果系统检测到Secure Boot处于启用状态，安装NVIDIA驱动或第三方内核模块时，会提示配置MOK（Machine Owner Key）。此时需要设置一个一次性密码，重启后在蓝色MOK管理界面中录入密码并确认注册密钥。
4.3 配置自定义密钥：从生成到部署的完整闭环
对于企业用户或安全要求较高的场景，使用主板出厂预置的微软密钥可能不够可控。自定义密钥允许组织完全掌控启动信任链，确保只有经过组织签名的引导程序才能运行。以下是一个基于OpenSSL和efitools的完整操作案例。
4.3.1 案例背景与目标
某金融机构要求所有终端工作站仅能启动经过IT部门签名的Linux内核和引导加载程序，防止员工自行安装双系统或使用未授权的Live USB启动。初始状态为主板默认的“Setup Mode”（即PK未设置，可自由写入密钥）。目标是将PK、KEK、db全部替换为组织自有的密钥，并签名一个自定义的GRUB引导加载程序。
4.3.2 生成密钥与证书
# 1. 创建密钥目录
mkdir -p /root/secureboot-keys && cd /root/secureboot-keys
# 2. 生成平台密钥 PK（包含私钥和自签名证书）
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My Platform Key/" -keyout PK.key -out PK.crt -days 3650 -nodes
# 3. 生成密钥交换密钥 KEK
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My KEK/" -keyout KEK.key -out KEK.crt -days 3650 -nodes
# 4. 生成签名数据库密钥 db
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=My db Key/" -keyout db.key -out db.crt -days 3650 -nodes
# 5. 将证书转换为EFI签名列表格式（使用 efitools 包）
cert-to-efi-sig-list -g "$(uuidgen)" PK.crt PK.esl
cert-to-efi-sig-list -g "$(uuidgen)" KEK.crt KEK.esl
cert-to-efi-sig-list -g "$(uuidgen)" db.crt db.esl
# 6. 生成带时间戳的更新文件（用于固件验证）
sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth
sign-efi-sig-list -k KEK.key -c KEK.crt KEK KEK.esl KEK.auth
sign-efi-sig-list -k db.key -c db.crt db db.esl db.auth4.3.3 在固件中部署密钥
将生成的 PK.auth、KEK.auth、db.auth 文件复制到FAT32格式的U盘中。重启进入BIOS，找到“Secure Boot”或“Key Management”选项，执行以下操作：
- 首先清除原有的PK（如果处于User Mode），或直接进入“Setup Mode”（部分主板需通过跳线或BIOS选项重置）。
- 依次加载
db.auth、KEK.auth、PK.auth（顺序不可颠倒，因为PK的写入需要KEK签名，而KEK的写入需要db签名？实际上，在Setup Mode下，固件允许直接加载PK，但加载KEK和db时，固件会验证其签名是否由当前PK或KEK签署。因此，正确顺序是：先加载db，再加载KEK，最后加载PK）。 - 保存并退出，系统将自动切换到User Mode。
4.3.4 签名引导加载程序与内核
部署自定义密钥后，现有的GRUB和内核将无法启动，因为它们的签名不在db中。需要重新签名：
# 使用 sbsigntool 签名 GRUB
sbsign --key db.key --cert db.crt --output /boot/efi/EFI/ubuntu/grubx64.efi.signed /boot/efi/EFI/ubuntu/grubx64.efi
# 签名 Linux 内核
sbsign --key db.key --cert db.crt --output /boot/vmlinuz-$(uname -r).signed /boot/vmlinuz-$(uname -r)
# 更新 GRUB 配置，指向签名后的文件
update-grub对于Ubuntu系统，更推荐使用 shim-signed 机制，即保留微软签名的shim作为第一级引导加载程序，然后通过MOK（Machine Owner Key）机制注册自定义密钥。这样无需替换shim，只需将db.crt注册到MOK列表中。
4.3.5 结果验证与风险复盘
完成上述操作后，重启系统。如果一切正常，系统将顺利进入Linux桌面。此时再次运行 mokutil --list-enrolled，可以看到自定义的db证书已列出。若尝试使用一个未签名的引导程序（如从U盘启动一个未签名的GRUB），固件将拒绝加载并显示“Security Violation”错误。
风险与代价：此操作的最大风险是密钥丢失。如果PK私钥丢失，且需要更新固件或添加新硬件驱动，将无法修改db，导致系统无法引导新内核。因此，建议将私钥离线存储在硬件安全模块（HSM）或加密的离线存储中。此外，每次内核更新后，都需要重新签名，否则系统无法启动。这可以通过配置DKMS或自定义脚本来简化。
4.4 常见误区与总结复盘
在配置Secure Boot的过程中，以下误区经常导致启动失败或安全失效：
- 误区一：启用Secure Boot后，Legacy启动设备（如光驱、U盘）完全无法使用。实际上，Secure Boot只影响UEFI启动路径。如果主板支持UEFI，且U盘使用FAT32格式并包含EFI引导文件，仍然可以启动。但传统的MBR引导的U盘（非UEFI）会被拒绝。
- 误区二：自定义密钥后，Windows无法启动。如果之前使用的是Windows，且未将微软的KEK和db证书加入自定义数据库，Windows Boot Manager将无法通过验证。解决方案是在生成db时，将微软的证书（可从微软官网下载）一并加入db.esl。
- 误区三：在BIOS中关闭CSM后，独立显卡无法输出。部分老款显卡的Option ROM仅支持Legacy模式，关闭CSM后可能导致无显示输出。此时需要更新显卡固件（GPU UEFI Option ROM）或更换显卡。
- 误区四：认为Secure Boot可以防止Rootkit。Secure Boot只验证启动链，一旦内核加载完成，它就不再起作用。内核漏洞或驱动漏洞仍可能被利用。
总结复盘：启用Secure Boot是提升系统启动安全性的基础步骤，但真正的安全需要结合TPM（可信平台模块）、BitLocker或LUKS磁盘加密、以及定期的固件更新。对于企业环境，建议采用集中管理的方式，通过Microsoft Intune或Red Hat IdM统一推送自定义密钥策略，避免在每台机器上手动操作。对于个人用户，如果不需要高度定制，保留主板默认的微软密钥即可，但务必确保固件和操作系统均为最新版本，以修补已知的Secure Boot绕过漏洞（如CVE-2023-40547）。