本文演示瞭如何使用可信平台模塊 2 芯片配置 clevis 和 systemd-cryptenroll，以在啟動時自動解密您的 LUKS 加密分區。
如果你只是想獲得自動解密，你可以直接跳到先決條件部分。
動機
磁盤加密通過直接訪問您的硬件來保護您的數據（私鑰和重要文檔）。 考慮出售您的筆記本電腦/智能手機或被邪惡的機會主義演員偷走。 所有數據，即使“已刪除”，也是可以恢復的，因此可能會落入未知的第三方手中。
磁盤加密它不是保護您的數據不被正在運行的系統訪問。 例如，磁盤加密不能保護您的數據免受以您的用戶身份或在內核空間中運行的惡意軟件的訪問。 那個時候就已經破解了。
在啟動時輸入密碼短語來解密驅動器可能會非常乏味。 在現代系統中，稱為“TPM”（可信平台模塊）的安全硬件芯片可以存儲秘密並自動解密您的驅動器。 這是一個選擇因素，不是第二因素。 記住這一點。 如果做得好，這是一種具有類似於密碼短語的安全級別的替代方案。
背景
TPM2 芯片是設備內部的一個小型硬件模塊，基本上為只寫或只讀信息提供 API。 這樣，您可以向其中寫入一個秘密，但您以後永遠無法讀取它（但 TPM 稍後可以在內部使用它）。 或者在您稍後閱讀的地方寫下信息。 TPM2 提供了一種稱為 PCR（平台配置記錄）的東西。 這些記錄採用 SHA1 或 SHA256 哈希值，並包含用於斷言 UEFI 配置等完整性的測量值。
在系統 UEFI 中啟用或禁用安全引導。 除其他事項外，Secure Boot 計算啟動鏈中每個組件（UEFI 及其配置、引導加載程序等）的哈希值，並以這樣一種方式將它們鏈接起來，即對其中一個組件的更改會改變所有後續組件中計算和存儲的哈希值聚合酶鏈反應。 通過這種方式，您可以在您所處的環境中建立信任。 衡量您的環境的可信度很有用，例如，在破解您的驅動器時。 他UEFI 安全啟動規範定義從 0 到 7 的 PCR。其他一切對操作系統和應用程序都是免費的。
根據規範在哪個 PCR 中測量的內容的摘要
- 心肺復蘇術 0: EFI 固件信息，例如它的版本
- 心肺復蘇術 1– 與 EFI 固件相關的其他配置和信息
- 心肺復蘇術 2：硬件組件 EFI 驅動器（如 RAID 控制器）
- 心肺復蘇術 3：存儲在 2 中的驅動程序的附加設置和信息
- 心肺復蘇術 4- 預操作系統診斷和 EFI 操作系統加載程序
- 心肺復蘇術 5: EFI OS Loader配置和GPT表
- 心肺復蘇術 6: 為主機平台製造商變量保留，不被 EFI 使用
- 心肺復蘇術 7：存儲安全啟動策略設置
在哪個 PCR 中測量什麼的一些例子
- initramfs 的更改在 PCR 9 和 10 中測量。因此，如果您使用 dracut -f 重新生成 initramfs，則必須重新綁定。 這將在每次內核更新時發生。
- Grub 配置更改，例如添加內核參數、內核等，在 PCR 8、9 和 10 中進行測量。
- 存儲設備在 PCR 8 和 10 上進行測量。但是，集線器和 YubiKeys 似乎沒有在任何一個 PCR 上進行測量。
- 其他操作系統在 PCR 1 處測量。例如，在使用 Fedora Linux Live Image 啟動之前連接 USB 記憶棒時會發生這種情況。
- 引導至實時映像會更改 PCR 1、4、5、8、9 和 10。
一個名為 clevis 的工具為 LUKS 加密磁盤生成一個新的解密秘密，將其存儲在 TPM2 芯片中，並配置 TPM2 僅當 PCR 狀態與配置時匹配時才返回秘密。 只有在狀態符合預期時，Clevis 才會嘗試檢索秘密並在啟動時自動解密磁盤。
安全隱患
當您僅使用平台的內置硬件建立替代解鎖方法時，您必須相信您的平台製造商會做好他們的工作。 這是一個敏感的問題。 人們對安全的硬件和固件設計充滿信心。 然後就是有信心UEFI、bootloader、kernel、initramfs等。 他們沒有被修改。 結合起來，您期望一個可以自動解密驅動器的可信環境。
話雖這麼說，您必須相信（或者更好的是，驗證）供應商在平台的整體設計中沒有搞砸任何事情，它才會被認為是一種相當安全的解密替代方案。 在許多情況下，事情並沒有按計劃進行。 例如，當安全調查表明，聯想筆記本電腦上的 BitLocker 會使用未加密的 SPI 通信TPM2 將 LUKS 密碼短語洩露為純文本，甚至沒有篡改系統，或者 BitLocker 使用了 SSD 驅動器的本機加密功能，可以通過恢復出廠設置繞過.
這些示例都是關於 BitLocker 的，但它們應該清楚地表明，如果一般設計被破壞，那麼秘密是可訪問的，並且這種解決方法不如僅存在於您腦海中的密碼短語安全（並且作為密碼管理器在某個安全的地方). 另一方面，請記住，在大多數情況下，為訪問驅動器數據而進行的詳盡研究和攻擊對於投機取巧的壞人來說是不值得的。 此外，不必在每次啟動時都輸入密碼應該有助於採用這項技術，因為它是透明的，但為不需要的訪問增加了額外的障礙。
以前的要求
首先檢查：
- 安全啟動已啟用並正常工作
- TPM2 芯片可用
- 安裝了 fork 包
U 形夾是魔法發生的地方。 它是您在運行的操作系統中用於將 TPM2 綁定為選擇解密方法並在 initramfs 中使用它從 TPM2 讀取解密秘密。
確認安全啟動已啟用。 dmesg 輸出應如下所示：
$ dmesg | grep Secure
[ 0.000000] secureboot: Secure boot enabled
[ 0.000000] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7
[ 0.005537] secureboot: Secure boot enabled
[ 1.582598] integrity: Loaded X.509 cert 'Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42'
[ 35.382910] Bluetooth: hci0: Secure boot is enabled
檢查 TPM2 芯片的 dmesg：
$ dmesg | grep TPM
[ 0.005598] ACPI: TPM2 0x000000005D757000 00004C (v04 DELL Dell Inc 00000002 01000013)
安裝 clevis 依賴項並使用 dracut 重新生成 initramfs。
sudo dnf install clevis clevis-luks clevis-dracut clevis-udisks2 clevis-systemd
sudo dracut -fv --regenerate-all
sudo systemctl reboot
他重新開始是重要的得到正確的PCR 基於用於下一步的新 initramfs 映像的測量。
設置叉子
將 LUKS 加密分區與 TPM2 芯片鏈接。 將 fork 指向您的 LUKS 分區（root）並指定要使用的 PCR。
出現提示時輸入您當前的 LUKS 密碼。 該過程使用它來生成一個新的獨立秘密，它將其 LUKS 分區綁定到 TPM2 以用作選擇解密方法。 因此，如果它不起作用，您仍然可以選擇直接輸入解密密碼。
sudo clevis luks bind -d /dev/nvme... tpm2 '{"pcr_ids":"1,4,5,7,9"}'
如上所述，當引導到另一個系統（例如實時磁盤）時，PCR 1、4 和 5 會發生變化。 PCR 7 跟踪當前的 UEFI 安全引導策略，如果通過 EFI 加載 initramfs，則 PCR 9 會發生變化。
注意：如果你只想保護 LUKS 密碼免受實時圖像的影響，但不介意更“精心設計”的攻擊，例如篡改未加密的引導分區上的未簽名的 initramfs，那麼你可以跳過 PCR 9 並省去麻煩重新鏈接更新。
自動解密附加分區
對於二級加密分區，使用 /etc/crypttab。
使用 systemd-cryptenroll 註冊磁盤以供 systemd 解鎖：
sudo systemd-cryptenroll /dev/nvme0n1... --tpm2-device=auto --tpm2-pcrs=1,4,5,7,9
然後通過添加選項 tpm2-device=auto,tpm2-pcrs=1,4,5,7,9 在 /etc/crypttab 中反映該設置。
取消鏈接、重新鏈接和編輯
列出設備的所有當前綁定:
$ sudo clevis luks list -d /dev/nvme0n1... tpm2
1: tpm2 '{"hash":"sha256","key":"ecc","pcr_bank":"sha256","pcr_ids":"0,1,2,3,4,5,7,9"}'
取消配對設備:
sudo clevis luks unbind -d /dev/nvme0n1... -s 1 tpm2
他-s該參數指定存儲在 TPM 中的此磁盤的備用秘密槽。 如果您總是在重新綁定之前解除綁定，則應該為 1。
重新生成鏈接，以防 PCR 發生變化:
sudo clevis luks regen -d /dev/nvme0n1... -s 1 tpm2
編輯設備設置:
sudo clevis luks edit -d /dev/nvme0n1... -s 1 -c '{"pcr_ids":"0,1,2,3,4,5,7,9"}'
故障排除
磁盤解密密碼消息在啟動時顯示，但在一段時間後消失:
使用 systemctl edit 將掛起命令添加到 systemd-ask-password-playmouth.service 文件，以防止在加載內核模塊之前向 TPM 發出請求：
[Service]
ExecStartPre=/bin/sleep 10
將以下內容添加到 /etc/dracut.conf.d/systemd-ask-password-plymouth.conf 配置文件中：
install_items+=" /etc/systemd/system/systemd-ask-password-plymouth.service.d/override.conf "
然後通過 sudo dracut -fv –regenerate-all 重新生成 dracut。
重啟然後重新生成鏈接：
sudo systemctl reboot
...
sudo clevis luks regen -d /dev/nvme0n1... -s 1
