有一天，当 Alice 从 Bobs 服务器下载一些照片时，警报响了。特鲁迪来窃取所有数据。
幸运的是，服务器设置为在服务器机房警报时关闭并且具有全磁盘加密。不幸的是，由于服务器正忙于 Alice，因此关闭的速度相当缓慢。更糟糕的是，特鲁迪带来了一些液氮。
现在，Trudy 回到实验室并从被盗的服务器 RAM 中提取加密密钥。很快，Trudy 就会知道 Alice 和 Bobs 的秘密活动。
问：Cryptsetup 并不是要关闭包含系统根目录的设备。是否有其他解决方案比echo b > /proc/sysrq-trigger增加 Linux 系统上的取证工作成本更快？
编辑：是的，这个问题故意限于假设通过 cryptsetup 管理 LUKS 容器所涉及的有限准备时间和实现细节 - 存在其他更一般的问题。
擦除 LUKS 标头将使数据完全无法恢复，即使后来发现密码/加密密钥也是如此，因为 LUKS 使用的密码/密钥仅加密存储在标头中的主密钥，而该主密钥实际上加密了数据。
因此，首先，删除 LUKS 卷所在设备的前 2MB 应该使得即使稍后获得密码（例如通过橡胶软管密码分析）也无法进一步解密。确保同步覆盖标头，以免写入最终被缓冲和丢弃，因为您随后重新启动计算机而无需等待缓冲区被刷新。
然后，必须擦除 RAM。关闭计算机是一种可能性，但数据可能会在 RAM 中保留足够长的时间，以便有人将其浸泡在液氮中并进一步延长数据的剩余期限。Tails 使用的另一种方法是通过kexec覆盖 RAM 的特殊内核从软件中擦除 RAM。那应该可以击败冷启动攻击。
有两种方法可以解决这个问题，具体取决于您想让数据变得难以访问。
如果您只是想要求了解 LUKS 密码以重新获得对数据的访问权（或多或少是正常情况，但加快了），那么您可以cryptsetup luksSuspend在 dm-crypt 设备名称上使用。根据手册页，这是：
挂起一个活动设备（所有 IO 操作将被阻止并且对设备的访问将无限期地等待）并从内核内存中擦除加密密钥。
要从 luksSuspend 中恢复，请执行 luksResume。
注意：以下假设为 LUKS 1 格式。较新的 LUKS 2 格式不同。
如果您想确保 Trudy无法访问数据，那么您需要更激进的方法。在简单的情况下，我们假设 Trudy 没有 LUKS 标头备份，在这种情况下覆盖 LUKS 标头就足够了。您可以完全覆盖标头而不覆盖其他任何内容（标头的大小是“有效负载偏移量”（由 cryptsetup luksDump 报告）乘以 512 字节，并且它从设备的开头开始），或者您可以放心使用并覆盖更多。覆盖旋转硬盘的前 100 MB 大约需要 1-3 秒，主要取决于驱动器的旋转速度（7200 rpm 驱动器往往能够达到 100-120 MB/s，较慢的驱动器显然更慢):
dd if=/dev/urandom of=/dev/sdb1 bs=1M count=100 conv=sync
覆盖头部后，确保从内核内存中擦除密钥，以确保无法解密剩余数据。这就像cryptsetup luksSuspend dm-nameor一样简单cryptsetup remove dm-name。完成此操作后，容器仅包含无法解密的随机数据（没有破坏所使用的加密算法）。任何好的加密算法的输出，在没有解密密钥的情况下，在统计上都无法与随机噪声区分开来。
在后一种情况下，如果您真的想让 Trudy 的生活变得困难，那么您可以向底层存储设备发出 ATA 安全擦除。假设安全擦除在驱动器上正确实施，一旦完成（在非自加密旋转 HDD 上可能需要几个小时，但通常一旦启动就不能中断），之前存储的数据将无法访问。然而，对于大多数威胁模型来说，这可能是矫枉过正。覆盖 LUKS 标头并清除 RAM 中的密钥几乎肯定足以防止任何合理的对手访问数据。然而，由于磨损均衡，可能需要安全擦除以确保 SSD 上没有密钥材料残留.