LUKS and dm-crypt distinction responsibilities

Question

Reading through the documentation of both dm-crypt and LUKS, I understand that LUKS is a format specification to allow FDE, and that dm-crypt is a dm target which allows encryption / decryption of writes / reads to the block device.

However, I'm unsure about what each of these now exactly provides (ie what are the responsibilities). In the slides that the author (Milan Broz) made, it mentions that LUKS2 can also provide integrity protection (hence making the encryption authenticated). From this, and also reading the LUKS1 specification I think this is not possible in LUKS1. However, later in the slides it talks how dm-crypt allows for authenticated encryption. This is where I'm confused; do we assume we use LUKS2?

I feel like I'm not really grasping the main function and responsibilities of both LUKS and dm-crypt.

Thanks!

Answer 1

Lets start from the kernel part:

• Device mapper is a kernel driver that allows creating new block devices from existing ones. It provides multiple additional features like RAID, caching or encryption through so called targets.
• dm-crypt is a device mapper target that provides transparent encryption. This means you can create a block device on top of your disk or partition and everything you write to this new device mapper device will be encrypted before the data is actually written to the disk. And vice versa for reading: if you read from the device, the data is read from the disk and decrypted before returning to you.
• dm-integrity is also a device mapper target, this one has a special metadata area for each block which are used to store checksum of the data block. This allows detection of data corruption.

Now the userspace level:

You can use device mapper directly, but it's not user friendly. Say you want to use dm-crypt directly -- to access the data you need to know the encryption algorithm, used IV and of course the key (which isn't short and easy to remember). It wouldn't be very practical to ask for these during boot.

That's where LUKS comes in. It provides two things: header and way to store (and manage) keys. Header allows system to identify the device as LUKS and contains all the metadata needed to work with the device. And key management allows you to safely store the encryption key on the disk, protected by easy to remember passphrase (or key file, TPM, FIDO token, etc.).

So the LUKS format only gives system all the information needed to correctly set the device mapper device up. You'll most likely use cryptsetup for that -- tool and library that can read the LUKS metadata, decrypt the key stored in there and correctly create the DM device.

The difference between LUKSv1 and LUKSv2 is in the format of the metadata. LUKSv2 adds some features, one of them is the authenticated encryption, which is combination of dm-crypt and dm-integrity -- integrity provides the checksums and crypt makes sure the checksums are also encrypted so it isn't possible to simply change both data and the cheksum hiding the change (plain integrity doesn't protect against this, it can be used only to protect about random data changes like bit rot). So authenticated encryption is provided by combining two technologies with LUKSv2 -- the metadata in the LUKSv2 header tell how the two device mapper targets needs to be configured and combined to get the data.