Linux 中测量启动和可信启动的含义

当执行可信启动过程时，该过程不仅测量每个值，而且同时针对已知的（和预期的！）良好值执行检查。

图片来源：

opensource.com

有时我在寻找写作主题，并意识到有一个主题我以为我已经写过了，但在搜索后发现我还没有写过。其中一个主题是测量启动和可信启动——有时被误导性地称为“安全启动”。有一些特定的程序使用这些术语，并带有大写字母（例如，Secure Boot），我将尽量避免在本文中讨论。我更感兴趣的是通用过程——以及一个主要的潜在缺陷——而不是试图深入探讨具体细节。以下是我即将出版的关于计算和云信任的书籍（由 Wiley 出版）中的一段（经过大量编辑的）摘录。

为了理解测量启动和可信启动旨在实现什么，请查看 Linux 虚拟化堆栈：如果您想在 Linux 机器上使用虚拟机 (VM)，您需要运行的组件。这种描述可以说是过于简化了，但是（正如我上面提到的）我不是对具体细节感兴趣，而是对我试图实现的目标感兴趣。我将专注于底部的四个层（在一个相当简单的抽象级别）：CPU/管理引擎；BIOS/EFI；固件；和 hypervisor，但我也会考虑一个恰好在 CPU/管理引擎之上的层，它介入可信平台模块 (TPM) 和一些关于如何执行两个过程之一的指令（测量启动和可信启动）。一旦系统开始启动，TPM 就会被触发并开始其工作。也可以使用其他信任根，例如硬件安全模块 (HSM)，但我将在我的示例中使用 TPM，这是此上下文中最常见的示例。

在这两种情况（可信启动和测量启动）中，基本流程都从 TPM 对 BIOS/EFI 层执行测量开始。此测量涉及检查此层要执行的二进制指令，并创建二进制映像的加密哈希。生成的哈希然后存储在 TPM 中多个平台配置寄存器 (PCR)“槽”之一中。这些可以被认为是稍后可以读取的内存片段——既可以由 TPM 用于其目的，也可以由 TPM 外部的实体读取——但一旦写入就无法更改。这些内存片段从最初写入时起就受到完整性保护。这提供了保证，即一旦 TPM 将值写入 PCR，就可以认为该值在系统生命周期内保持不变，直到断电或重启。

在测量 BIOS/EFI 层之后，测量下一层（固件）。在这种情况下，生成的哈希与先前的哈希（存储在 PCR 槽中）组合，然后也存储在 PCR 槽中。该过程一直持续到过程中涉及的所有层都已被测量并且哈希结果已存储。有一些（有时非常复杂的）过程来设置原始 TPM 值（为了简单起见，我跳过了一些更低级别的步骤）并允许（希望是授权的）对层进行更改，例如用于升级或安全补丁。这种“测量启动”过程允许实体在过程完成后查询 TPM，并检查 PCR 槽中的值是否与使用各种层的“已知良好”版本预先计算的预期值相对应——也就是说，预先检查过的版本，其来源和完整性已经建立。

存在各种协议允许系统外部的各方检查 TPM 证明是正确的值（例如，通过网络连接）：从外部系统接收和检查此类值的过程称为“远程证明”。

这个过程——测量启动——使您能够 выяснить 您的系统的基础——最底层——是否是您认为的那样。但是如果它们不是呢？测量启动（顾名思义，不足为奇）会进行测量，但不会执行任何其他操作。

另一种选择是“可信启动”，它更进一步。当执行可信启动过程时，该过程不仅测量每个值，而且同时针对已知的（和预期的！）良好值执行检查。如果检查失败，则该过程将停止，并且系统的启动将失败。这听起来可能像是对系统采取的一种相当极端的方法，但有时这绝对是正确的方法。当所考虑的系统可能已被入侵时——这是您可以从可信启动过程失败中得出的一个可能的推论——最好是根本不可用，而不是基于有缺陷的期望运行。

如果我是被测系统的所有者，已经检查了所有被测量的各种组件（和测量结果），并且确信正在启动的是我想要的东西，那么这一切都很好。¹ 但是，如果我正在使用云上的系统，或者任何由其他人拥有和管理的系统呢？在这种情况下，我信任云提供商（或所有者/管理者）两件事

正确地完成所有测量并向我报告正确的结果
构建一些我应该首先信任的东西

这就是术语“可信启动”以及更糟糕的“安全启动”的问题所在。两者都暗示系统的绝对、客观属性已经建立——它是“可信的”或“安全的”——但这显然不是事实。显然，期望此类过程的设计者以失败状态命名它们——“不可信启动”或“不安全启动”——是不公平的，但是，除非我可以非常确定我信任系统的所有者完全正确地执行步骤二（并且为了我作为系统用户的最佳利益，而不是他们作为所有者的最佳利益），否则我无法做出更强的断言。

存在巨大的诱惑，将经过可信启动过程的系统标记为“可信系统”，而您可以做出的最好的断言是，在测量和/或可信启动过程中测量的特定层已被断言为该过程期望存在的层。这样的过程完全没有说明这些层是否适合提供行为保证，也没有说明在这些层之上的任何后续层的正确性（或适合提供行为保证的程度）。

重要的是要注意，TPM 的设计者非常清楚正在断言什么，并且关于信任的断言应该谨慎而节制地做出。然而不幸的是，系统的复杂性、对信任的普遍低理解以及上下文和传递信任的复杂性使得系统设计者和实施者很容易做错事，并假设任何成功执行了可信启动过程的系统都可以被认为是“可信的”。同样非常重要的是要记住，TPM 作为硬件信任根，为在您可能正在设计或实施的系统中建立信任链提供了可用的最佳机制之一，我计划很快写一篇关于它们的文章。