LUKS 是否保护文件系统的完整性?

信息安全 正直 卢克斯
2021-08-31 05:24:21

我已阅读:

http://css.csail.mit.edu/6.858/2013/readings/bitlocker.pdf

Bitlocker 不提供数据完整性,因为它在磁盘中占用更多空间。PDF 还说驱动器加密系统不提供存储数据的完整性,实施所谓的穷人身份验证:

“最好的解决方案是使用穷人的身份验证:加密数据并相信密文的变化不会转化为明文的语义变化。例如,攻击者可以更改可执行文件的密文,但是如果新的明文实际上是随机的,我们可以希望这些更改更有可能使机器或应用程序崩溃,而不是做攻击者想要的事情。”

LUKS 是否对用户数据提供任何完整性检查?

截至 Arch 的 wiki ( https://wiki.archlinux.org/index.php/Dm-crypt/Specialties ):

“mkinitcpio-chkcryptoboot 是一个 mkinitcpio 挂钩,它在早期用户空间期间执行完整性检查,并建议用户在系统似乎已受到威胁时不要输入其根分区密码。安全性通过加密的 /boot 分区实现,该分区使用解锁GRUB 的 cryptodisk.mod 模块,以及一个根文件系统分区,它使用不同于前者的密码进行加密。这样可以保护 initramfs 和内核免受脱机篡改,即使 /boot 分区密码也可以保持根分区的安全在受感染的机器上输入(前提是 chkcryptoboot 挂钩检测到了泄露,并且在运行时本身没有受到泄露)。”

亲切的问候

2个回答

使用选项格式化的 LUKS--integrity <algorithm>将为加密卷提供完整性保护。

为此,--type luks2必须在格式化设备时使用(打开使用 LUKS2 格式化的设备和完整性保护的工作方式与“正常”加密设备完全相同)。

缺点是完整性目标需要将数据写入两次以保持写入的原子性。禁用此功能 ( --integrity-no-journal) 可能会导致数据丢失 - 校验和之间的不匹配将被报告为读取时的 I/O 错误。第二个缺点是校验和丢失了一些空间,介于 0.1%(对于 crc32)和 0.78%(对于 SHA-256)之间。

对于高级格式化驱动器(4K 扇区),最好同时提供--sector-size 4096,因为这将确保虚拟块与磁盘物理块的块对齐。

请参阅FOSDEM 演示文稿

不,LUKS1 不进行任何完整性检查。认证加密相对于明文扩展了密文,而 LUKS1 没有任何功能来处理这个问题。LUKS1 使用dm-crypt,通常在 CBC 或 XTS 模式下。

2021 年 3 月更新:正如其他人所指出的,LUKS2 增加了对经过身份验证的加密的支持(默认情况下禁用)。目前,手册页警告说这仍然是一个实验性扩展。