玻尔百科从计算机通电的那一刻起，一系列复杂的软件便开始执行，将系统唤醒。但是，我们如何能信任这一过程？我们如何能确定初始代码没有被恶意行为者替换，从而在系统启动之前就危及整个系统？这个根本性的挑战——从不受信任的状态建立信任——正是启动安全旨在解决的核心问题。没有一个安全的基础，所有更高级别的安全措施，从杀毒软件到防火墙，都建立在不稳固的地基之上。
本文将深入探讨为保障启动过程安全而开发的精妙解决方案。通过两个主要章节，您将对这一关键安全领域有深刻的理解。首先，在“原则与机制”中，我们将剖析信任链的基础概念，探索安全启动如何强制执行真实性，以及可信启动如何提供系统状态的无可辩驳的证据。之后，“应用与跨学科联系”将展示这些原则在现实世界中的应用——从保护您的个人笔记本电脑和云虚拟机，到它们在远超计算机科学的领域中出人意料的关联性。
想象一下您正在建造一座堡垒。您不会只建造一堵坚固的外墙，而是会设计一系列由守卫把守的门，每个守卫只为由前一个守卫担保的人开门。整个堡垒的安全依赖于这条不间断的信任链。启动计算机的过程也是如此。从您按下电源按钮的那一刻起，一连串的软件组件相继唤醒，每个组件都将控制权交给下一个。我们如何能确定这种交接是安全的，没有恶意的冒名顶替者混入其中？这就是启动安全的根本问题。
保障启动过程安全最简单、最精妙的理念被称为信任链。可以把它想象成一系列的数字握手。最先运行的软件——固件，是最初的守卫。在加载下一个组件——引导加载程序之前，它会检查其数字签名。
数字签名是现代密码学的一大奇迹。通过使用一对密钥（一个公钥和一个私钥），软件供应商可以用他们的秘密私钥来“签署”他们的代码。任何拥有公钥的人——公钥安全地存储在计算机的固件中——都可以验证该签名。一个有效的签名以数学上的确定性证明了两件事：
如果引导加载程序的签名有效，固件便交出控制权。然后，引导加载程序成为新的守卫。在它加载操作系统内核之前，它会执行完全相同的检查，验证内核的签名。这个过程一环扣一环，形成一条链。这种每个阶段都拒绝加载未经验证的后继者的强制执行机制，就是安全启动（Secure Boot）的精髓。
但是这条链从何开始？你不可能有无限多的守卫。这链条的第一环必须是无条件信任的。这就是信任根（Root of Trust）。在大多数现代计算机中，这种信任根植于处理器本身及其从只读存储器（ROM）芯片运行的初始、不可变的代码——这些代码在工厂中固化，无法更改。这个不可更改的代码就是我们的第一个守卫，一个我们无需验证就信任的守卫，整个信任链都建立在它之上。
这条信任链听起来异常简单和安全。但就像任何完美的理想一样，它会遭遇严酷的现实：链中的组件只是软件，由人类编写，而人总会犯错。数字签名保证了一段代码是真实的，但它并不能保证代码没有缺陷或漏洞。一个签了名的驱动程序仍然可能有缓冲区溢出；一个签了名的引导加载程序仍然可能包含逻辑缺陷。
这就引出了一个至关重要的概念：可信计算基（Trusted Computing Base, TCB）。TCB 是我们为了维持系统安全而被迫信任的所有硬件和软件组件的集合。它不仅包括被验证的代码，还包括进行验证的代码。如果引导加载程序的签名检查例程存在缺陷，它可能会被欺骗，从而接受一个恶意的内核，即使密码学基础完美无瑕。
因此，安全设计的一个核心原则是保持 TCB 尽可能小和简单。TCB 中每增加一行代码，就多了一个可能隐藏缺陷的地方，就像我们堡垒墙上的又一道裂缝。考虑两种设计：一个执行所有操作的庞大、单体的引导加载程序，与一系列更小、专门的“链式”加载程序。虽然链式方法可能有更多独立的部件，但其 TCB 代码总大小可能要小得多，从而减少了代码级漏洞的攻击面。然而，这引入了一个权衡：更多的阶段可能意味着更多的配置选项，可能会增加简单配置错误的风险。安全工程的艺术就在于管理这些权衡。
如果我们无法保证我们信任的代码是完美的，我们至少能否获得一份关于启动过程中发生了什么的无可辩驳的记录？如果我们的计算机有一个防篡改的飞行数据记录仪会怎样？这就是可信启动（Measured Boot）及其重要硬件伙伴可信平台模块（TPM）背后的理念。
TPM 是计算机主板上的一个小型、专用的安全芯片。可以把它想象成一个带有一种非常特殊笔记本的数字公证人。这个笔记本由一组称为平台配置寄存器（Platform Configuration Registers, PCRs）的寄存器组成。在可信启动期间，一个组件在执行之前，会计算其加密哈希——一个独特的数字指纹。然后，这个指纹被“度量”到一个 PCR 中。
度量过程不是简单的写入，而是一种称为 extend 的特殊操作。PCR 的新值变为 ，其中 是一个哈希函数， 表示串联。这个操作是单向的。你无法撤销一个 extend 操作或篡改其序列。PCR 中的最终值是扩展到其中的整个测量历史的加密摘要。只要启动链中的任何一个组件发生改变，最终的 PCR 值就会完全不同。
这让我们能够解决安全启动无法解决的一个难题。想象一个攻击者巧妙地修改了内核的配置——例如，一个禁用了关键安全功能的命令行参数——而不是内核代码本身。因为这个配置文件不是可执行文件，只检查代码签名的安全启动会让它通过。系统启动了，但处于一个被削弱的状态。然而，可信启动会看到一切。引导加载程序被设计为不仅度量内核代码，还度量其配置。当攻击者修改命令行时，度量值会改变，最终的 PCR 值也会改变，这种偏差被不可磨灭地记录下来。
如果记录被锁在机器内部，那它就毫无用处。TPM 的神来之笔是远程证明（remote attestation）。TPM 可以使用一个在工厂中烧录的、独特的、不可伪造的私钥来签署其 PCR 值。它会生成一份“引用”（quote）——一份关于其当前状态的签名声明——并可以将其呈现给远程服务器。服务器随后可以检查这份引用。如果 PCR 值与一个已知良好启动的“黄金”值相匹配，服务器就信任该机器并授予其访问敏感数据的权限。如果不匹配，服务器就知道出了问题，并可以隔离该设备，而攻击者没有任何办法伪造这份报告 [@problem_id:3679563, 3688014]。
安全启动是门口执行宾客名单的保镖。可信启动是记录每个进入者的安全摄像头。你需要两者兼备才能拥有一个真正安全的系统。
即使有这种双管齐下的防御，聪明的对手仍然能找到攻击系统的办法。最阴险的攻击不是破解密码学，而是利用操作过程中的接缝。
最经典的攻击之一是检查时-使用时（Time-of-Check to Time-of-Use, TOCTOU）漏洞。想象一下引导加载程序的安全检查就像一场“调包计”：
在检查和使用之间的微小间隙里会发生什么？现代计算机一个强大的功能叫做直接内存访问（Direct Memory Access, DMA），它允许像网卡和存储驱动器等外围设备直接向系统内存写入数据，从而绕过主处理器以提高效率。一个恶意的设备，或者一个控制该设备但被攻破的可信驱动程序，可能会利用 DMA，在内核经过检查之后、运行之前，用恶意版本覆盖内存中已验证的内核。
这种攻击巧妙地绕过了我们的防御。安全启动感到满意，因为原始内核是有效的。可信启动也感到满意，因为它度量的是原始内核。但实际运行的代码却是攻击者的。这给了我们一个深刻的教训：TCB 不仅必须包括执行检查的软件，还必须包括任何有能力颠覆这些检查的组件，比如存储驱动程序。为了防御这种情况，现代系统采用了一个输入输出内存管理单元（Input-Output Memory Management Unit, IOMMU），这是一个充当看门人的硬件组件，它限制了一个设备的 DMA 允许访问哪些内存区域。一个安全的启动过程必须在尽可能早的阶段配置这个 IOMMU，以便在外围设备有机会造成危害之前将它们置于数字沙箱中。
另一个微妙的攻击向量是攻击安全启动策略本身。关于允许什么（ 数据库）和禁止什么（ 数据库）的规则存储在可配置的固件变量中。一个能够在早期启动环境中执行恶意代码的攻击者可能会试图进入一个特殊的 SetupMode，以非法地将自己的密钥添加到允许列表中。这凸显了围绕策略本身建立防御的必要性，例如要求物理在场才能授权对这些关键变量的更改。再一次，我们可信启动的“全视之眼”提供了一张安全网：对这些策略变量的任何更改本身都会被度量到一个 PCR 中（具体来说是 ），确保即使攻击者成功了，他们也无法向远程证明服务器隐藏证据。
计算机不是一个静态的产物；它是一个需要更新的生命系统。这对可信启动构成了一个有趣的挑战。如果你安装了一个合法的操作系统更新，你的内核就变了。下次启动时，度量值会不同，PCR 值也会不同，任何绑定到旧 PCR 值的秘密——比如全盘加密密钥——都将拒绝解锁。你的系统是完美的安全的，但也是完美的不可用的！。
这不是设计缺陷，而是一个迫使我们明确并安全地处理更新的特性。现代 TPM 支持可以解决这个问题的复杂策略。例如，系统可以配置为不仅为一组 PCR 值解封密钥，而是为任何经过操作系统供应商授权和签名的值集解封。当安装更新时，一个由供应商签名的特殊令牌被用来“祝福”新的预期 PCR 值，允许系统在更新后无缝启动，同时仍然受到保护，免受未经授权的更改 [@problem-id:3686042]。
这个谜题的最后一块是管理不可避免的情况：当一个可信软件供应商的私有签名密钥被盗时会发生什么？突然之间，攻击者持有了一把“金钥匙”，可以签署任何他们想要的恶意软件，而安全启动会乐于接受它。唯一的解决方案是撤销。UEFI 安全启动标准中包含一个禁止签名数据库（），正是为此目的。当一个密钥已知被泄露时，它的签名或证书可以被添加到这个黑名单中。固件将拒绝任何用它签名的代码，即使它也在允许列表中。这使得一个迅速而稳健的撤销机制成为安全生态系统中绝对关键的一部分。这也为最小化信任提供了一个强有力的论据：你的信任存储中的第三方密钥越少，其中之一被泄露的概率就越低，从而缩小了系统的整体攻击面。
启动安全的旅程是一个由美丽、层层叠加的理念构成的过程。它始于一个加密链的简单优雅，然后面对不完美软件和强大硬件的混乱现实，最终演变成一个能够报告其状态、管理变化并从妥协中恢复的动态、有弹性的系统。这是对保护现代计算根基的深思熟虑的证明。
在探索了启动安全的原则之后，我们现在来到了我们探索中最激动人心的部分。就像一位物理学家，在掌握了运动定律后，抬头看到它们在天空中描绘出行星的轨道，我们现在将看到安全启动和可信启动这些抽象原则是如何活跃起来的。它们不仅仅是尘封的规范；它们是我们数字世界中信任的积极、常常是无形的构建者。从您可能正在阅读本文的笔记本电脑，到为云提供动力的庞大数据中心，甚至到远超计算机科学的领域，事实证明，“信任链”的概念是一个惊人地普遍而优美的理念。
让我们从离我们最近的机器开始：我们自己的个人电脑。在这里，挑战不仅仅是建造一座坚不可摧的堡垒，而是要建造一座能为其合法主人毫不费力地打开大门的堡垒。这是安全与可用性之间的一场微妙舞蹈。
想象一下设置一台新的工作站。攻击者可能会试图从一个恶意的 USB 盘启动，或者他们可能会物理偷走电脑，取出硬盘，并试图读取你的数据。我们如何防御这种情况，而又不必强迫你每次开机都输入三个不同的密码？解决方案是我们核心概念的优雅交响。首先，我们启用 UEFI 安全启动。这确保了机器只会运行经过加密“已知”和信任的操作系统，从而挫败了从未经授权的介质启动的企图。其次，我们用管理员密码保护固件设置本身。这个简单的步骤可以防止攻击者直接进入设置菜单并关闭安全启动。最后，我们启用全盘加密（FDE），但有一个巧妙的转折：我们将解密密钥绑定到可信平台模块（TPM）。
TPM 就像一个沉默而警惕的守卫。它监视着启动过程，而安全启动保证了该过程的完整性。只有当启动过程完全符合预期——没有篡改，没有恶意代码——TPM 才会将磁盘加密密钥释放给操作系统。结果如何？磁盘完全加密以防被盗，启动过程受到保护以防被颠覆，而您，作为用户，通过操作系统熟悉单一的登录提示来体验这一切。所有的加密握手和完整性检查都在您看到登录屏幕之前自动完成。这种设置以最小的摩擦实现了强大的安全性，是以用户为中心的设计的杰作。
但如果您是一名开发者、科学家，或者只是一个好奇的修补者呢？如果您想运行一个自定义编译的 Linux 内核或加载特殊的驱动程序呢？这是否意味着您必须拆掉堡垒的围墙？完全不是。安全启动的设计者预见到了这种需求，提供了一种机制，不是为了打破信任链，而是为了有意识地扩展它。一种常见的方法是注册一个“机器所有者密钥”（Machine Owner Key, MOK）。这是一个由您创建和控制的密钥。通过一个一次性的、需要物理在场的过程，您指示引导加载程序信任用您的 MOK 签名的模块。您实际上是在告诉系统，“我，作为所有者，为这个代码担保。”另一种方法是将您的公钥直接编译到您构建的内核中。在这两种情况下，原则是相同的：您将平台的一部分信任委托给自己，允许自定义代码运行，同时仍然确保只有您明确授权的软件才能这样做。
在像双启动 Windows 和 Linux 这样的复杂设置中，这种灵活性变得至关重要。在这里，信任链可能变得更加错综复杂。当 GRUB 引导加载程序（Linux 使用）链式加载 Windows 启动管理器时，它本身并不对其进行验证。相反，它明智地将控制权交还给 UEFI 固件，后者再使用其内置密钥验证微软签名的引导加载程序，开始一条全新的、安全的链。然而，Linux 端的配置错误——例如，禁用了对 Linux 内核本身的签名检查——可能会打破这条链。即使引导加载程序（GRUB）是经过验证的，如果它随后加载了一个未经证的内核，信任就丧失了。这是安全启动和可信启动之间差异的一个完美例证。一次可信启动可能仍然会记录恶意内核的哈希值，从而在事后提供篡改的证据。但安全启动从一开始就阻止它运行。
当我们从一台个人电脑转向企业或云数据中心中的数千台机器时，原则保持不变，但规模放大了挑战。
考虑一家公司需要允许现场技术人员从特殊的 USB 维护驱动器启动笔记本电脑。他们如何才能在允许这样做的同时，又不向任何恶意的 USB 盘敞开大门？答案在于管理信任数据库。企业管理员可以定制签名数据库（），使其只包含公司自己的公钥，而不是使用可能信任各种第三方密钥的默认 UEFI 设置。现在，只有由企业签名的维护工具才被信任。所有其他的都会被拒绝。这是将最小权限原则直接应用于系统基础的体现。
这个想法可以扩展到更复杂的场景，比如数据中心中使用预启动执行环境（Preboot eXecution Environment, PXE）通过网络启动的无盘计算机。传统的 PXE 协议，DHCP 和 TFTP，是出了名的不安全；它们就像明信片，无法保证是谁发送的，也无法保证在传输过程中是否被读取。本地网络上的攻击者可以轻易地拦截这些请求，并提供一个恶意的操作系统。为了保障其安全，我们构建了多层信任。首先，UEFI 安全启动确保初始的网络引导程序是经过签名且真实的。然后，这个程序可以丢弃不安全的 TFTP，转而通过像传输层安全（TLS）这样的安全、加密的通道来获取操作系统的其余部分，并钉住服务器证书以确保它正在与正确的机器通信。与此同时，可信启动记录每个组件的哈希值，为整个网络启动过程创建一条可审计的轨迹。
这种理念的最终演进是在云端。当您启动一个虚拟机（VM）时，“硬件”只是在主机上运行的软件。信任根在哪里？在这里，VMM 或 hypervisor 充当了基础。它加载 VM 的虚拟固件，从而在 VM 内部开启信任链。为了提供一个硬件锚点，主机上的物理 TPM 可以支持数千个虚拟 TPM（vTPMs），每个 VM 一个。客户 VM 的启动过程——从虚拟固件到引导加载程序再到内核——都被度量到其自己的私有 vTPM 中。
这使得可信启动最强大的应用之一成为可能：远程证明。想象一下，您想在云中运行一个敏感的工作负载，但在发送任何秘密信息之前，您需要证明该 VM 正在运行正确、未被篡改的软件。通过远程证明，您可以向 VM 发起挑战。您的验证器向 VM 发送一个随机数，一个“nonce”。VM 的 vTPM 将此 nonce 整合到一个“引用”（quote）中——一份关于其 PCR 度量值的签名声明。这份引用，连同一个证明 vTPM 身份与物理主机绑定的证书链，被发送回来。通过验证这个加密包，您可以确定——无需盲目信任云提供商的基础设施——该 VM 处于一个已知良好的状态。这个 nonce 和 quote 的舞蹈是现代机密计算的基石。
安全是一个动态的领域，是攻防之间永恒的棋局。了解一项技术的局限性与其优势同样重要。一个典型的例子是冷启动攻击。如果攻击者获得对正在运行的机器的物理访问权限，他们可以冻结 DRAM 模块，切断电源，并提取其内容——包括驻留在内存中的敏感数据，如磁盘加密密钥。这种攻击并不颠覆启动过程；它完全绕过了它。安全启动和可信启动保护的是系统启动时的完整性，但它们并非旨在保护正在使用中的数据的机密性。随后的远程证明会显示一次完全干净的启动，因为物理内存盗窃在 TPM 的日志中没有留下任何痕迹。这给了我们一个至关重要的教训：安全机制有其明确的范围，物理安全始终至关重要。
一个更微妙、更深层次的威胁针对的是软件的源头：供应链。想象一下，一个攻击者攻破了某个软件供应商使用的编译器。被攻破的编译器秘密地向其构建的操作系统内核中注入了一个后门。该供应商在不知情的情况下，用他们的官方密钥签署了这个恶意内核。由此产生的系统是一个悖论：安全启动会验证它，因为签名是真实的。可信启动会证明其完整性，因为它的哈希值与（在不知情的情况下被篡改的）官方清单相匹配。整个信任链都成立，但系统却从内部腐烂了。
我们如何防御这种深层次的攻击？我们必须将我们的信任链进一步向“左”延伸到开发过程本身。这引出了一些前沿的理念：
这些技术使我们不仅能验证正在运行的是什么，还能验证它是如何产生的。这是信任的前沿，将验证从运行时环境推回到创造的那一刻。
我们的旅程始于计算机内部，但其核心思想——一条锚定在无可指摘根源上的信任链——是一条具有非凡普适性的原则。让我们以一个来自完全不同领域的例子来结束：一家环境化学实验室。
一位科学家正在测量一种污染物的浓度。最终的数字由一台连接到气相色谱仪的计算机生成。计算机本身通过安全启动和可信启动得到保护，为软件和仪器设置创建了可验证的日志。但这足以信任最终结果吗？
如果用来称量初始化学标准的分析天平校准不准怎么办？如果用来配制溶液的容量瓶没有按照正确的规格制造怎么办？这些基础性的、物理工具中的任何错误都会使得标准的“已知”浓度变为未知。整个数百万美元仪器的校准将建立在一个谎言之上。所有后续的测量都将毫无意义。
这项科学实验真正的可信计算基（TCB）不仅仅是计算机的启动固件和其 TPM。它还包括经过认证的分析天平、A 级容量玻璃器皿以及提供时间戳的同步时间源。这些是物理和时间的信任根。最终科学结果的完整性是一条由数字和物理环节共同锻造的链条。计算机的可信启动日志可以证明设备驱动程序的完整性，但前提是与之进行比较的化学标准本身是可信的。
在这里，我们看到了这个概念深层次的统一性。UEFI 固件验证引导加载程序，在原则上，与科学家信任其分析天平的校准证书并无不同。两者都是在建立一个信任根，所有后续对真实性和完整性的声明都源于此。从 TPM 的硅芯片核心到玻璃吸管上精确蚀刻的标记，对可验证真理的追求都依赖于这条不间断的链条。这就是启动安全经久不衰而又优美的教诲。