Does LUKS protect the filesystem integrity?

Question

I have read in:

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

that Bitlocker does not provide data integrity since it takes more space in the disk. The PDF says also that drive encryption systems do not offer integrity of the stored data, implementing the so-called poor man authentication:

"The best solution is to use poor-man’s authentication: encrypt the data and trust to the fact that changes in the ciphertext do not translate to semantically sensible changes to the plaintext. For example, an attacker can change the ciphertext of an executable, but if the new plaintext is effectively random we can hope that there is a far higher chance that the changes will crash the machine or application rather than doing something the attacker wants."

Does LUKS offer any integrity checks on users data?

As of Arch's wiki (https://wiki.archlinux.org/index.php/Dm-crypt/Specialties):

"mkinitcpio-chkcryptoboot is a mkinitcpio hook that performs integrity checks during early-userspace and advises the user not to enter his root partition password if the system appears to have been compromised. Security is achieved through an encrypted /boot partition, which is unlocked using GRUB's cryptodisk.mod module, and a root filesystem partition, which is encrypted with a password different from the former. This way, the initramfs and kernel are secured against offline tampering, and the root partition can remain secure even if the /boot partition password is entered on a compromised machine (provided that the chkcryptoboot hook detects the compromise, and is not itself compromised at run-time)."

Kind regards

Answer 1

No, LUKS1 does not do any integrity checking. Authenticated encryption expands the ciphertext with respect to the plaintext, and LUKS1 does not have any functionality in place to deal with this. LUKS1 uses dm-crypt, usually in CBC or XTS mode.

Update March 2021: As noted by others, LUKS2 adds support for authenticated encryption (disabled by default). Currently, the man page warns that this remains an experimental extension.

Answer 2

LUKS formatted with --integrity <algorithm> option will provide integrity protection for the encrypted volume.

For that to work, --type luks2 must be used when formatting the device (opening of the device formatted with LUKS2 and integrity protection works exactly as for "normal" encrypted devices).

The downside is that the integrity target requires data to be written twice to preserve atomicity of the writes. It is possible to disable this feature (--integrity-no-journal) with the possible risk of data being lost – mismatches between checksums will be reported as I/O errors on reads. Second downside is that some space is lost to checksums, between 0.1% (for crc32) and 0.78% (for SHA-256).

With Advanced Format drives (4K sectors), it's good idea to also provide --sector-size 4096 as that will ensure block-alignment of virtual blocks to disk-physical blocks.

See FOSDEM presentation.