首先是乐子一则，来自猫老师的频道。请务必阅读 原始报告，过于好笑。

正好写点想写的。暴论：不依赖 HSM (安全芯片) 的设备加密都是无效的。

Limitations #

借用 forensics 的提法，设备解密状态分为 BFU 和 AFU 模式。
一般地，后者具有更广的攻击面，从简单的 锁屏 或 认证 绕过到 warm reboot 及 DMA 攻击，需要复杂、全面且系统性的加固。Windows 11 Security Book 中介绍了常见缓解措施，其中不乏因导致显著性能降级而为用户所诟病的特性。

本文仅讨论前者。

为什么需要 HSM？ #

Brute-Force Protection #

dm-crypt/LUKS 通过提高合法解锁的代价（迭代次数、memory-hard KDF）设计上提供了良好的抗 BFA 性能，但对于简单 passphrase、社工字典或是 $5 扳手的物理攻击下未必有较为理想的保护效果。

HSM 通常能够设定最大失败次数，或随尝试次数增加而指数级延长重试等待时间。

Integrity Measurements #

HSM 对系统组件进行完整性测量，如结果与受签名保护的哈希记录（digest）不符，证明 bootchain 里高低被塞了点东西。后文将以 systemd 的 TPM2 集成为例，展开该过程。

Inline Encryption #

一般地，对于 BitLocker/LUKS 等全盘加密实现，AFU 状态下可以在 RAM dump 中查找并提取密钥。安卓和水果设备要好很多，均有实现¹ inline encryption，保证原始存储密钥仅在专用硬件中使用。

Besides HSM #

群友提及微软对 BitLocker 禁用了“硬件加密”，原因见 CVE-2018-12037 及 SSP '19 论文。KB4516071 中描述了这一行为变更：

Changes the default setting for BitLocker when encrypting a self-encrypting hard drive. Now, the default is to use software encryption for newly encrypted drives. For existing drives, the type of encryption will not change.

常见 SED 符合 TCG Opal 2.0 标准，加解密均于盘上主控进行，DEK 不出盘，但相较于前述 inline encryption 仍有本质区别：SED 对主机透明，无法验证加解密的正确性，可能因固件缺陷导致安全问题，并不能替代 HSM；iirc² 同 AES 256bit 下性能不如软件加密，在部分设备上也有兼容性问题³。

除了作为 BitLocker/LUKS 后端，商用场景里 SED 一般采用 pre-boot 认证，开机从 shadow MBR 中加载 PBA 镜像，解密后重启进入正常引导流程，对系统完全透明。此外，无论 SED 激活与否，使用 psid revert 可以立即销毁盘上 DEK，即加密擦除内容。

TCG 另有 Pyrite 规范，仅用作认证而不加密数据，因此不在讨论范围。

TPM？ #

和安全启动类似，微软的 TPM 大普及有一定的正面价值。尽管不能提供接近 HSM 的保护，但既然已经被设备制造商内置，合理利用可以起到 §2.1、§2.2 所述的效果。

按 firmware / discrete TPM 分类，前者包括 Intel PTT、AMD fTPM⁴ 等，跑在 CPU 内置的协处理器（如 Intel ME on Quark，AMD PSP on Cortex-A5）上，处于更高的特权级，也更易受到攻击。 Intel 的 fTPM 实现将资料存在 ME 里，看起来是无法 LPC bus sniffing，但仍存在 TPM-FAIL 等侧信道利用手段，也受 TCG 参考实现和 ME/CSME/TXE 固件缺陷影响，需要及时更新软件。

此外，应当留意 swap hibernation，虽然设置交换区有助于休眠，更大的交换页面也能平衡内存利用率，但理论上存在泄露的可能性。 cold-boot attack 作为可能的攻击手段，如硬件支持，最好是打开内存加密⁵功能。退而求其次，不使用计算机时将其关闭，并启用内核的 init_on_free 特性，确保密钥及时从内存中擦除。

本打算简单带过，结果又成了想到哪写到哪，码了长篇累牍的废话。那么「基础实践」部分就留到之后了，咕咕咕