TPM 应该解决“先有鸡还是先有蛋”的问题，即在哪里存储未加密的磁盘加密密钥，这样人们就不能简单地在机器中弹出另一个硬盘驱动器、启动不同的操作系统并直接从磁盘/闪存/BIOS/读取密钥...
据我所知，TPM 基本上是通过检查启动的软件来实现这一点的，如果该软件与预设的哈希值不匹配，它将保持锁定状态并拒绝给出磁盘加密密钥。
我读过很多文章，指出 systemd 可以帮助将我的 LUKS 密钥嵌入到 TPM 中systemd-cryptenroll。但这些仅涉及将密钥嵌入到 TPM 中，并没有阻止攻击者读取这些密钥。
我陷入困境的是弄清楚如何确保从 BIOS 固件到登录存在可靠的信任链，确保如果操作系统被篡改，它将无法启动，或者 TPM 将拒绝移交加密密钥。
E例如，如果终端上的某人只需按 grub 提示符并启动 linux 即可init=/bin/bash为自己提供 root 登录而无需密码，那么加密我的硬盘驱动器就没有多大用处。在这种情况下，加密就完全没有意义了。
我坚持两个相当具体的点：
- 典型的基于 systemd 的发行版（Debian 或 Ubuntu）首先如何锁定 TPM。这可以保护哪些文件不被篡改？
- 我必须加强启动顺序中的哪些其他内容以防止被篡改？
- 例如：grub EFI 二进制文件、EFI 中的 grub.cfg、编辑启动项的 grub 密码、initramfs、...
答案1
我陷入困境的是弄清楚如何确保从 BIOS 固件到登录存在可靠的信任链，确保如果操作系统被篡改，它将无法启动，或者 TPM 将拒绝移交加密密钥。
这是构建在流程中的；这是--tpm-pcrs=您提供给 systemd-cryptenroll 的选项。
TPM 在内存中保存由系统固件、引导加载程序以及偶尔由操作系统提供的各种事件的“事件日志”。每个事件都会“测量”系统的某些部分 - 例如，固件将在加载 grubx64.efi 可执行文件时记录其哈希值； GRUB 将记录每个命令并（可能？）记录正在执行的内核映像的哈希值；内核将记录 initrd 的哈希值和命令行的哈希值 - 每个事件都会“扩展”也存储在 TPM 内存中的哈希链。
所有这些测量的目标是一组 PCR（“平台配置寄存器”），每个寄存器都保存一个 SHA 哈希值。每个事件使用以下公式扩展其中一个 PCR：
new_value = H(old_value || event_data_hash)
以便 PCR 中的最终哈希验证该 PCR 的整个事件链，就像单个 Git 提交哈希验证导致其的整个提交历史记录一样。 （虽然只有一个事件日志，但每个事件只更新一个PCR，因此每个PCR充当一个独立的哈希链。）
就其本身而言，PCR 绝对不执行任何操作，但“密封”操作可用于指定政策可能需要特定的 PCR 才能具有特定的值；如果不满足该策略，TPM 将拒绝解封数据。
因此，每当systemd-cryptenroll要求 TPM 密封（加密）LUKS 卷密钥时，它都会包含基于--tpm-pcrs=您指定的内容的策略。具体保护什么内容取决于您选择的 PCR。
例如，PCR[4] 将包含固件生成的事件，用于测量正在运行的每个 .efi 可执行文件。 （如果 Linux 内核作为带有自己的嵌入式引导加载程序的“EFI 存根”运行，则可能包括 Linux 内核。）这可能会很烦人，因为每次升级时哈希值都会发生变化，因此带有 BitLocker 的 Windows 通常将篡改保护与安全启动联系起来 –它绑定到 PCR[7]，而 PCR[7] 包含事件证书用于签署可执行文件；任何由 Microsoft 的“官方 Windows 第一方证书”签名的内容都会通过。
然后，如果您还想测量 initramfs，使用现代（5.17+）Linux 内核，您可以在策略中包含 PCR[9]。对于内核命令行，systemd-boot 将更新 PCR[8]。 （我不确定 GRUB 使用什么或何时使用。）最近 systemd 开发人员更加重视“统一内核映像”，其中包含内核和 initramfs 以及捆绑在一起的命令行；整个包将被验证为单个 .efi 二进制文件。
（我有一个旧项目除了常规功能之外，它还能够以文本格式转储事件日志。）
特别针对 Linux，有一个非权威指南介绍了 PCR 索引的用途这里。
在 Ubuntu 上，该包tpm2-工具tpm2_eventlog包括可用于通过内核读取 TPM 事件日志的命令：
tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements
这可以帮助准确确定哪些内容用于生成 PCR 值，从而有效地防止哪些文件和设置被篡改。