☰

如果我使用 LUKS 和 TPM 加密磁盘而不指定 pcr_ids，是否存在漏洞？

tag-icon • tag-icon luks tpm
如果我使用 LUKS 和 TPM 加密磁盘而不指定 pcr_ids，是否存在漏洞？

根据网上很多教程，将TPM存储的密钥添加到LUKS的过程是运行clevis luks bind -d /dev/sda1 tpm2 '{"pcr_ids": "7"}'，但是我收到以下错误：

ERROR: pcr-input-file filesize does not match pcr set-list
ERROR: Could not build pcr policy
ERROR: Unable to run tpm2_createpolicy
Invalid input!

因此我删除了 pcr_ids，命令变为clevis luks bind -d /dev/sda1 tpm2 '{}'。这很有效。将“密码”添加到插槽并将磁盘添加到 /etc/crypttab（使用 tpm2-device=auto）可使磁盘在启动时自动解密。

我不确定它是否足够安全。这种做法是否存在漏洞？

PS 我在 MSI X570A-PRO 上使用 AMD 5950X（及其 ftpm）

答案1

将 TPM 密封1数据绑定到 PCR 用于对系统状态施加特定要求。如果策略中没有任何（有用的）PCR，则可以从任何操作系统和任何环境中解封数据（即 LUKS 密钥）。

因此，尽管数据仍然绑定到相同的机器，它无法防止有人在该机器上启动 Linux LiveCD 并通过 手动解封 LUKS 密钥tpm2_load；也无法防止有人快速编辑你的 /boot/initrd 以使其在屏幕上打印未密封的密钥；也无法防止有人添加init=/bin/sh到内核命令行并以此方式绕过操作系统登录密码。

通常建议使用 PCR7，因为它与安全启动状态绑定（例如，使用 BitLocker 时，它将密钥解封限制在加载 Microsoft 签名的 Windows 内核时，而不是使用第三方证书时），尽管我不确定这对于支持基于 Shim 的安全启动的 Linux 来说是否足够。其他选项要么过于具体和脆弱（例如 PCR4），要么不够具体（例如 PCR4）。

不过，“tpm2-device=auto” 看起来不像是用于 Clevis 的 – 它是用于 systemd-cryptsetup 提供的 tpm2 插件的，我认为它在存储 LUKS 元数据的方式上与 Clevis 不兼容。相应的命令是systemd-cryptenroll --tpm2-pcrs=7 /dev/sda1。

1非 TPM 存储，因为 TPM 将加密数据返回给操作系统进行存储。

相关内容