- 安全启动依赖于 UEFI、密钥层次结构（PK、KEK）和数据库（DB、DBX），以确保只执行受信任的固件和引导加载程序。
- 2011 年的证书将于 2026 年到期，因此需要更新密钥和数据库以维护 Windows 和 Linux 中的启动保护。
- 固件加固结合了安全启动、签名更新、硬件信任根、加密和持续监控。
- FirmGuard 等解决方案和专业的嵌入式系统合作伙伴有助于实现远程管理、向 UEFI 迁移以及安全启动链的实施。
在许多计算机和设备上，固件会在每次按下电源按钮时静默启动，但其他一切的可靠性——或者说其脆弱性——都取决于这一刻。什么是固件？它有什么用途？安全启动、UEFI 和强大的固件加固相结合，决定了系统是能够抵御严重攻击还是会被一个简单的恶意 U 盘攻破。
本文将直入主题，以冷静而直接的方式解释什么是安全启动，它与 UEFI 固件有何关联，证书将于 2026 年过期会带来哪些问题，以及所有这些如何融入 Windows、Linux 和嵌入式系统的安全体系。您还将看到一些高级解决方案，例如远程 BIOS 管理、完整性监控，以及在情况复杂时专家合作伙伴的作用。
什么是安全启动？它为什么如此重要？
安全启动是UEFI 固件中内置的一项安全功能，用于控制在初始启动阶段可以运行哪些软件。它的目标很简单，但有效执行起来却很困难：确保只有经过签名和信任的代码（引导加载程序、UEFI 驱动程序、EFI 应用程序）才能启动，并阻止任何不符合固件中定义策略的二进制文件。
实际上，UEFI 固件会将即将执行的代码的数字签名与内部存储的一系列证书和签名列表进行比较。如果签名与受信任数据库 (DB) 中允许的证书或哈希值匹配，则该组件执行；否则，它将被阻止。这样做是为了防止试图劫持启动过程的引导程序和恶意软件的执行。
安全启动随着 Windows 8 的发布而大规模普及，当时那些在操作系统启动前加载的威胁开始激增。该模型基于信任链：UEFI 固件首先验证其内部模块（例如 Option ROM），然后检查引导加载程序（例如 Windows 启动管理器或 Linux 中的 shim/GRUB），只有在所有验证通过后，才会将控制权交给引导加载程序，引导加载程序再对内核和其他二进制文件进行验证。
关键在于，安全启动的信任机制由出厂设置的固件策略定义。该策略通过密钥和数据库树来体现：平台密钥优先于所有其他密钥，密钥执行密钥扩展 (KEK) 用于授权更改，以及两个列表 DB 和 DBX，分别规定了允许和禁止的操作。妥善管理这一生态系统与在 Windows 11 菜单中启用安全启动选项同样重要。
关键结构：PK、KEK、DB 和 DBX
安全启动的核心是密钥和签名数据库的层次结构。理解它对于任何安全加固策略都至关重要，无论是在家庭环境中，尤其是在企业或关键任务基础设施中。
最顶层是平台密钥 (PK)，通常由硬件制造商生成和管理。该密钥拥有最终权限：拥有它的人可以更改安全启动的所有其他元素，因此泄露该密钥会危及整个信任链。一些组织会将默认的平台密钥替换为自己创建的密钥，从而获得对平台的控制权。
密钥交换密钥 (KEK)比安全启动密钥低一级，用于授权对数据库 (DB) 和数据库交换文件 (DBX) 进行更新。通常会有一个 Microsoft KEK，一个或多个来自硬件制造商的 KEK，以及在企业环境中，组织自身的 KEK。任何拥有有效 KEK 的实体都可以在安全启动列表中添加或撤销证书和哈希值。
允许的签名数据库 (DB)存储固件在启动阶段可以执行的二进制文件的证书和哈希值。这包括来自 Microsoft、OEM 以及（如果适用）设备管理公司的证书。当固件分析引导加载程序或选项 ROM 时，它会在数据库中查找匹配项，以决定是否加载它。
另一方面，还有已撤销签名数据库 (DBX)，其中包含不再被视为安全的二进制文件和证书。微软会定期更新 DBX，以使存在漏洞的引导加载程序（如 BootHole 攻击中出现的）或已被证明不安全的组件失效。保持 DBX 的更新是防止已签名但已过期的二进制文件继续成为攻击入口点的关键。
2026 年到期的安全启动证书
自安全启动引入以来，几乎所有兼容 Windows 的计算机都在密钥扩展库 (KEK) 和数据库 (DB) 中包含了一套通用的微软证书。问题在于，其中一些证书是在 2011 年颁发的，即将过期，这将直接影响数百万台设备的启动保护。
具体来说， Microsoft Corporation KEK CA 2011、Microsoft Windows Production PCA 2011或Microsoft UEFI CA 2011等证书的有效期介于 2026 年 6 月至 10 月之间。每个证书都发挥着不同的作用：对 DB 和 DBX 更新、Windows 加载程序、第三方引导加载程序或第三方制造商的 Option ROM 进行签名。
为了确保持续安全，微软在 2023 年发布了新的证书，取代了 2011 年的证书：例如，Microsoft Corporation KEK 2K CA 2023 取代了原来的 KEK，Windows UEFI CA 2023 用于系统引导加载程序，以及更新了 EFI 应用程序签名和第三方 Option ROM 的证书。
该公司集中管理着Windows生态系统中大部分设备的证书更新，其方式与分发其他安全补丁类似。OEM厂商也会在必要时发布固件更新，以集成新证书或调整安全启动设置。
如果设备在当前密钥过期之前没有收到新密钥，它将继续正常启动并接收 Windows 更新，但它将无法再对启动阶段应用特定的缓解措施：它将无法接收 Windows 启动管理器中的某些更改、DB/DBX 更新或针对新发现的底层漏洞的补丁。
证书到期的影响及必要措施
2011 年证书过期并不意味着您的计算机将无法启动，但会逐渐降低系统抵御影响启动时间的威胁的能力。这可能会对诸如 BitLocker 加固或使用依赖安全启动信任链的第三方引导加载程序等场景产生影响。
为了最大限度地降低风险，微软建议（并且在许多情况下会自动执行）将 KEK 和 DB 证书更新到 2023 年的过程。IT 管理员和安全人员应验证其设备是否已收到这些更新，尤其是在硬件或固件更新频率较低的异构集群中。
行动指南很明确：检查每种设备的“安全启动”状态，确定是否正在使用旧证书并制定升级计划，然后在更新 BIOS 后按照指南启用“安全启动”。在托管环境中，通常需要查阅制造商的特定文档或遵循“Windows 安全启动密钥创建和管理指南”，才能将新密钥正确集成到部署过程中。
在某些情况下，尤其是在使用组织自身的证书自定义了 PK、KEK 或 DB 密钥时，更新可能需要手动步骤和仔细测试，以避免禁用尚未用当前密钥重新签名的合法引导加载程序。此处的协调错误可能导致系统在应用安全补丁后无法启动。
安全启动和 Linux：信任链、Shim 和 GRUB2
在 Linux 系统中，这个过程类似，但也有其自身的特点。大多数现代发行版都依赖于一个名为 shim 的组件，这是一个由微软签名的引导加载程序，它使 UEFI 固件能够直接识别自身。Shim 充当桥梁：固件借助微软的签名加载它，然后 shim 使用特定于发行版的密钥验证 GRUB2 和内核。
在启用安全启动的 Linux 系统中，典型的流程如下：UEFI 验证 shim，shim 验证 GRUB2，GRUB2 验证内核。每个阶段都依赖于数字签名和密钥策略，这些密钥策略存在于 shim 本身以及安全启动数据库中。这确保了硬件制造商无需预先知道每个发行版的密钥，同时仍然能够控制哪个内核可以启动。
在这种情况下，我们之前看到的那些要素仍然至关重要：PK 控制谁可以更改固件中的全局安全启动配置，KEK 决定谁可以更新 DB 和 DBX，DB 收集受支持的密钥（包括 shim 所需的密钥），而 DBX 存储用于锁定易受攻击的二进制文件的撤销信息。
该模型在互操作性方面具有优势，但也增加了操作复杂性。例如，当 shim 或 GRUB2 中出现严重漏洞时，需要快速更新受影响的引导加载程序，同时发布一个 DBX 条目来撤销旧版本。如果顺序错误，即使 shim 的二进制文件已被撤销，系统最终可能仍然需要旧版本才能启动。
因此，正确管理 DBX 和 Linux 引导加载程序签名成为一项棘手的任务，尤其是在多个发行版、LTS 版本和参与引导的第三方软件（例如加密管理器或虚拟机管理程序）共存的环境中。
安全启动可以保护哪些内容……以及它不能保护哪些内容。
安全启动旨在阻止针对启动早期阶段的攻击。这些攻击包括修改引导加载程序以加载自身有效载荷的引导工具包、被恶意版本替换的内核、在操作系统之前运行的伪造选项 ROM，以及为获得持久性而引入的 EFI 二进制文件。
通过要求启动链中的每个组件都经过签名和验证，可以大幅减少任何试图“隐藏”在操作系统底层的攻击者的攻击面。被攻破的引导加载程序甚至可以在安全工具生效之前禁用遥测功能、绕过完整性检查或植入rootkit 。安全启动旨在堵住这条攻击途径。
这也在一定程度上限制了拥有物理访问权限的攻击者的选择：仅仅使用篡改过的充电器从U盘启动已经不够了，因为固件会拒绝未经支持证书签名的二进制文件。这并不意味着物理安全不再重要，但确实提高了那些企图利用安全漏洞入侵设备的人的门槛。
然而，安全启动存在明显的局限性。它无法防范操作系统本身的漏洞，也无法阻止拥有提升权限的用户滥用合法功能造成损害。此外，它也无法阻止网络攻击、服务漏洞利用或应用层配置错误。
此外，历史表明，启动链本身也可能存在漏洞。Shim和 GRUB2 都曾发生过严重故障，例如臭名昭著的 BootHole 事件。该事件中，GRUB2 配置分析中的一个缺陷允许攻击者在不使签名失效的情况下篡改启动过程。针对这些事件的应对措施是通过 DBX 更新二进制文件并撤销不安全的版本，这再次凸显了主动维护安全启动的重要性。
实施、强化和维护方面的挑战
大多数安全启动问题并非源于复杂的攻击，而是源于设备固件过时、DBX 列表失效，或者密钥自硬件出厂以来就未进行过检查。换句话说，就是长期操作疏忽造成的。
在许多情况下，改进的第一步非常简单，只需系统地应用制造商发布的UEFI/BIOS 更新即可。这些更新不仅可以修复错误，还可以包含新的安全功能、密钥管理改进以及固件本身漏洞的补丁。
另一个关键领域是密钥管理。完全依赖 OEM 和微软 PK/KEK 密钥的组织完全受制于这些供应商的密钥更新计划，而自行管理密钥的组织则需要一份清晰的密钥清单：每个密钥的签署人、密钥的到期时间以及轮换计划。失去对密钥清单的控制，无疑会在创业初期造成混乱。
数据库 (DB) 和数据库交换文件 (DBX) 需要特别监控。几个月未更新的 DBX 文件很可能包含已被声明为不安全的二进制资源。另一方面，未经充分测试的更新可能会破坏与旧版本 shim 或 GRUB2 的兼容性。因此，许多公司会将 DB/DBX 的变更整合到常规的变更管理流程中，并在预发布环境中进行预先测试。
在大型组织中，将安全启动与启动过程度量和TPM支持相结合的做法越来越普遍。这会将每个启动阶段的哈希值记录在TPM中，从而允许远程验证系统是否已使用已知且授权的固件、引导加载程序和内核组合启动。
超越启动：在所有阶段保护固件
安全启动固然强大，但仅靠它本身并不足以保障安全。固件安全是一个持续的过程，包括配置、更新、监控和事件响应。其理念是构建相互加强的多层保护。
安全固件更新至关重要。如果我们允许在任何环境下刷写固件，却不进行签名验证、不提供防降级攻击保护，也不提供故障恢复机制，那么依赖安全启动就毫无意义。更新必须经过数字签名，并遵循严格的流程，理想情况下，还应包含防止回滚到易受攻击版本的保护措施。
此外，建议充分利用现有的安全硬件：硬件信任根、安全密钥存储区、TPM、TrustZone、外部安全模块……这些组件可以隔离加密密钥，使拥有物理访问权限的攻击者更难在不被发现的情况下提取密钥或修改代码。
在数据方面，验证启动加上敏感信息加密的结合是一项重大进步。如果设备使用安全启动来确保只启动受信任的固件，就可以将数据解密与该验证状态关联起来。这样，即使有人复制了内存，除非他们能够重现相同的合法启动序列，否则也无法访问其中的内容。
循环的完成需要运行时保护机制：定期内存和固件完整性检查、看门狗、与启动失败或修改尝试相关的安全事件日志，当然还有阻止调试接口、保护程序存储器读取以及适当的硬件访问控制。
FirmGuard 和远程 BIOS/UEFI 管理
在企业环境和托管服务提供商中，单独管理每台设备的固件配置既浪费时间又容易出错。而像FirmGuard 这样的解决方案则能解决这个问题，它提供了一个集中式平台，可以远程保护、配置、监控和更新 BIOS/UEFI 固件。
其主要功能之一是能够远程配置关键的 BIOS/UEFI 选项（SecureConfig）。这使得管理员能够系统地启用安全启动、调整安全参数、禁用从未经授权的设备启动，或应用强化配置模板，而无需实际前往每台工作站。
此外，FirmGuard 还集成了持续固件完整性监控 (SecureCheck) 功能。该平台监控 BIOS/UEFI 的更改，检测异常修改，并在发现任何可能指向潜在恶意活动或未经授权的配置更改的迹象时发出警报。在固件日益成为攻击目标的环境中，这种可见性至关重要。
对于仍在传统 BIOS 模式下运行的系统，FirmGuard 新增了第三个组件SecureSense，该组件能够识别仍在使用传统 BIOS 的系统，并协助其迁移到 UEFI——这是使用安全启动和其他现代安全功能的关键步骤。从企业或 MSP 的角度来看，这意味着从异构且难以管理的系统迁移到更加同质化且更易于防御的系统。
综合来看，这些类型的解决方案不仅可以降低固件攻击的风险，还可以为托管服务提供商提供明显的附加价值，他们可以通过提供额外的底层保护来脱颖而出，并且通过自动化以前手动且成本高昂的任务来提高利润率。
嵌入式系统中的固件和安全启动
除了个人电脑和服务器之外，固件安全在嵌入式设备中也至关重要，例如工业控制器、医疗设备、消费电子产品、汽车等等。在这些设备中，固件故障不仅会导致数据丢失，而且往往还会造成物理安全风险和监管责任。
这些设备的最终用户通常并不知道其底层运行着存在漏洞的固件。然而，这些事件却是真实存在的：由于安全问题，医疗设备曾被大规模召回，例如众所周知的心脏起搏器就因存在远程攻击风险而不得不进行更新或更换。这些情况会影响消费者的信任、收入以及制造商的声誉。
当嵌入式设备的固件遭到破坏时，后果可能是毁灭性的：失去客户信任、代价高昂的召回、认证延迟（医疗保健、汽车、工业）、品牌形象受损，有时甚至会导致关键基础设施的运营中断。
在这些环境中，安全启动显得尤为重要。从执行的第一个字节开始建立信任链，确保只有经过制造商（或可信机构）签名的固件才能启动。之后，启动过程的每个阶段都可以验证下一个阶段：初始引导加载程序、辅助引导加载程序、应用程序固件、嵌入式操作系统内核等等。
然而，在嵌入式设备上部署安全启动并非易事。它需要硬件支持来安全地存储密钥，需要一段不可更改的代码段作为信任根，还需要一种制造工艺，能够在不泄露密钥和证书的情况下，为每个设备定制其密钥和证书。在一些功能非常有限的平台上，可能需要实现自定义的安全引导加载程序，这会带来性能、资源消耗和成本方面的挑战。
增加层数以实现真正强大的固件
为了实现强大的固件保护，需要多层防护。第一层是安全启动，但它必须辅以安全的更新机制、受保护的存储、运行时防御和完善的组织实践。
在更新方面，所有固件和底层软件镜像都应进行数字签名，并且最好能防止降级。空中下载 (OTA) 或本地更新应在接受更改前验证签名，并应遵循软件安全更新的最佳实践，制定应急预案（固件备份、安全恢复模式），以避免故障后系统无法使用。
安全存储扮演着至关重要的角色。现代微控制器 (MCU)、配备 TrustZone、TPM 或专用安全元件的片上系统 (SoC)能够保护密钥和敏感数据，即使有人拥有物理访问权限，也无法在不留下痕迹或付出巨大努力的情况下提取它们。将这些密钥的访问权限与安全启动的成功挂钩，进一步增强了安全性。
在执行过程中，必须结合定期完整性检查、看门狗、内存保护（MPU、MMU、锁步）、启动失败尝试或可疑固件更改的日志，以及在非常关键的产品中，甚至物理篡改传感器。
最后，如果组织不采用安全的开发和漏洞管理实践，所有这些措施都将无法有效发挥作用：威胁分析、面向安全的设计、代码审查、渗透测试、清晰的事件响应流程，以及安全与质量齐头并进的生命周期管理。固件不能被视为编写一次即可置之不理的东西。
拥有固件和安全方面的专家合作伙伴的价值
鉴于我们所看到的种种情况，不难理解为什么许多公司在需要加强安全启动和固件保护时会求助于专业的嵌入式系统和网络安全合作伙伴。仅仅掌握编程技能是不够的：你还需要精通硬件、密码学、工业流程、相关法规以及整个攻击和防御生态系统。
优秀的合作伙伴拥有开发引导加载程序、驱动程序、复杂嵌入式系统、加密机制和硬件控制器的实践经验，能够设计真正集成到产品中的安全解决方案，而不是只会增加维护复杂性的临时附加组件。
它们通常还包括操作手册和成熟的工具：可重用的安全启动模块、用于管理密钥和证书的脚本、固件加固指南、包含二进制签名和自动验证的持续集成 (CI) 流水线等等。这可以节省时间，并降低新手犯下代价高昂的错误的可能性。
网络安全同样至关重要。那些持续关注最新漏洞、侧信道攻击、常用物联网架构缺陷以及安全设计最佳实践的团队，有助于从架构阶段就融入安全措施，而不是在最后阶段才进行修补。他们通常秉持“安全设计”的理念，从需求阶段就开始进行威胁建模和风险评估。
如果合作伙伴还拥有相关的ISO认证（例如ISO 9001、ISO 13485、ISO 26262等），则能进一步确保其流程经过审核且结构规范。这不仅意味着他们知道需要做什么，还意味着他们拥有正式的程序和可追溯性，这在医疗保健或汽车等监管严格的行业中尤为重要。
最后还有一个因素，虽然不那么技术性，但同样重要：沟通和同理心。优秀的合作伙伴不会满口晦涩难懂的术语，也不会强加那些根本无法在您的时间或预算范围内实施的解决方案。他们会认真倾听您的限制，清晰地解释各种方案，并调整方法，在安全性、成本和上市时间之间找到平衡点。在固件和安全启动项目中，这种目标一致的感觉至关重要。
简而言之，实施安全启动和强化固件需要结合坚实的技术基础（UEFI、密钥层级结构、更新的证书、维护良好的数据库/数据库X文件）、规范的操作（固件更新、密钥管理、定时启动、监控），以及在必要时借助能够解决内部漏洞的专业解决方案和合作伙伴的支持。如果所有这些都正确执行，系统就能以可靠的启动过程启动，从而强化从内核到最高层应用程序的所有后续安全措施。
