MicroOS 使用 TPM 和 Keylime 进行远程证明

介绍

在2021年，我们开始更加关注 MicroOS 的安全性。默认情况下，MicroOS 是一个相当安全的发行版：在开发过程中，所有更改都会公开审查，修复（包括 CVE）会首先（或同时）集成到 Tumbleweed 中，我们拥有只读根文件系统和恢复旧快照的工具，并且安全团队会定期审计一些新组件。此外，从 AppArmor 迁移到 SELinux 应该有助于标准化安全管理。

但我们真的希望尽可能地提高标准。例如，我们开始考虑如何在发行版中正确启用 IMA/EVM，或者我们有哪些替代方案用于 由 TPM 支持的完整磁盘加密。在新的 Transactional Image Update 安装程序中，对 dm-verity 进行了评估。

MicroOS 中我们取得进展的另一个领域是如何衡量系统的健康状况，远程检测未经授权的更改（远程认证），并尽可能快地全局执行操作。

TPM 作为信任根

如今，我们所有的设备（笔记本电脑、台式机、服务器、手机或平板电脑）都包含一个称为 TPM（Trusted Platform Module 首字母缩写）的加密协处理器。有时它位于 CPU 内部，但也可以焊接在主板上或作为固件中的软件实现。这些协处理器非常便宜（而且不幸的是速度慢），但在我们想要设计需要基于硬件信任根的软件时非常有用。

例如，假设我们想要加密磁盘，但我们不想在启动时被要求输入密码。我们需要一个可信组件，能够在启动过程的早期提供密码，并且系统可以 - 以某种方式 - 验证它是否是真实的，而不是其他代理试图冒充它。TPM 提供了执行此验证的机制，如果一切顺利，则将密码解封给内核，以便它可以解密磁盘。

许多其他操作也需要相同的角色，例如访问需要验证机器/用户组合的 VPN。由于 TPM 的设计方式，它们可以生成我们可以检查的密钥，以验证它们是否来自特定的 TPM 而不是其他 TPM。例如，这对于开放对内部网络的访问非常有用。

在我们需要验证系统健康状况时，另一个需要信任根的活动是可测量启动。

可测量启动和远程认证

一般机制如下：在启动过程中，固件的早期部分负责初始化一些硬件组件并设置一些时钟，完成后，在将执行委托给下一阶段（可能是 UEFI 固件的早期阶段）之前，它会将下一阶段加载到内存中，并计算其哈希值（例如 SHA256），并将此信息传达给我们信任的硬件组件（在本例中为 TPM）。该组件现在可以将启动过程委托给该第二阶段，该第二阶段将在需要移动到第三阶段时执行相同的操作（加载、测量并向 TPM 传达测量结果），以此类推，直到 Grub2 进入操作并加载内核。

如果这样做，我们实际上可以测量启动程序链中的每个步骤，从固件深处的早期阶段到（包括）内核。此过程称为“可测量启动”。TPM 记录了所有这些测量结果！

实际上我是在撒谎（好吧，有点，我们稍后会看到）。

TPM 便宜且内部空间有限，因此 TPM 本身无法拥有完整的测量记录。在 TPM 内部，我们有一些称为平台配置寄存器 (PCR) 的寄存器，它们具有一个特性：我们可以读取它们，但不能直接写入它们。要更改寄存器的值，我们有一个称为扩展的操作，可以将其视为获取寄存器的当前值，在末尾附加我们想要扩展的哈希值（在本例中为测量的结果），并计算完整字符串的哈希值（再次，例如 SHA256）。计算出的新值将存储在 PCR 中。

此扩展操作使得 PCR 的当前值取决于其所有先前的值以及之前使用的值（测量结果）。因此，为了复制一个值，我们需要知道启动链中每个阶段的正确测量结果（包括 PCR 在复位后的初始值，通常为 0x00..0）。

这里的目标是，一旦一切启动完成，用户就可以通过称为引用的操作向 TPM 请求这些 PCR 值。此操作返回由 TPM 唯一知道的密钥签名的报告，我可以验证该报告以查看它是否确实来自我的 TPM。然后，我可以将 PCR 值与我期望的 UEFI、Grub2 和内核的当前版本进行比较。如果它们匹配，我就确信启动链没有被篡改，如果不匹配……好吧……我们被黑了（或者我们在某个地方有未经授权的更新，我们需要检查）。

诚实地说，比较原始 PCR 值很困难。如果我们不知道启动链的所有测量结果，它们是无法预测的。

这就是为什么对于从 UEFI 到内核的每个测量，除了在 TPM 中扩展 PCR 寄存器之外，我们还在内存中存储一个包含所有这些测量结果的日志。我们在常规内存中注册一些用于测量的额外信息，例如 PCR 号码和用于扩展的值。我们还可以在日志中看到找到的签名（如果我们使用安全启动，则预期签名）、文本数据（例如 Grub2 中使用的内核命令行）等。

此日志将在各个阶段之间传递，直到到达内核，内核将通过安全文件系统将其提供给用户空间。此日志称为事件日志。

另一个要点是，我们现在可以从不同的机器远程请求 PCR 的当前值通过 TPM 的引用，以及事件日志的完整内容。有了这些信息，我们可以远程证明系统在启动过程中没有受到损害。当然，这被称为远程认证。

Keylime

如果我们有一个带有 TPM 的设备，我们可以转到 BIOS / UEFI 启动菜单并激活它。之后，此系统的每次启动都将按照此处描述的方式进行测量，我们可以通过向 TPM 请求引用（通过 MicroOS 中的 tpm2.0-tool 包）并将值与事件日志进行比较来执行认证。

但这无法正确扩展，我们需要一个工具来帮助我们自动执行此操作。

Keylime 是一个开源项目，旨在执行我们需要的操作：使用 TPM 作为所有测量结果的信任根来远程认证我们的设备。

在 Keylime 中，我们有一些可用的服务。agent 是需要安装在所有我们要监视的节点中的服务。该服务负责在需要时收集一些数据（TPM 引用、事件日志、IMA 日志等）。

此信息由另一个称为verifier 的服务请求，该服务将根据用户提供的信息验证此数据。

例如，它将检查 PCR 值是否是预期的值。它还可以使用用户提供的策略（例如 Python 代码）检查事件日志，以查找一些签名，查看 Grub 菜单用于启动，并比较一些已知测量结果（例如内核）。

此外，如果远程节点启用了 IMA，它可以验证我们正在运行的所有程序和服务的哈希值！

使用 Keylime，我们可以将密钥（例如证书或密钥）部署到我们的节点，并且可以在检测到我们的节点中未经授权的更改时执行用户定义的动作。

例如，如果 Keylime 检测到执行程序与预期的 IMA 哈希值不同，我们可以执行一个程序，该程序将尝试将此节点与其对等节点隔离，并撤销对网络中共享资源的任何访问权限，例如数据库。

好消息是，Keylime 已通过 YaST 中的两个新系统角色集成到 MicroOS 中。在安装过程中，我们现在可以看到两个新角色，一个应该用于我们要监视的节点（agent 角色），另一个用于将负责收集代理信息、执行验证并在需要时触发撤销操作的节点（verifier 角色）。

这些角色使我们今天开始在 MicroOS 中进行远程认证非常容易，并且该过程已完全记录。

更多信息！

我们已在 MicroOS 门户 中记录所有这些信息（以及更多信息）。在那里，您可以找到更详细的描述，包括如何配置agent 服务以便它们可以找到verifier，如何启用节点中的 IMA 并准备哈希白名单，以及如何编写可以在检测到入侵时采取行动的程序。

还有一些关于 TPM 的更多细节，以及如何检查它们是否存在于系统中并被 MicroOS 识别。

此外，我们最近举办了 SUSE Labs 2021 会议，并且所有视频都已 发布，包括一个关于 Keylime 和 TPM 在 MicroOS 环境中的应用 的演讲，您可以查看。 在本次会议的论文集中，还有一个 论文 可以用来补充这个主题！