I was just curious if someone had a high level overview of how a system like LUKS worked for full disk encryption, aka. how it stores keys and how those keys are verified, and if data is de-crypted by a wrapper for all standard i/o. I found a brief description of how LUKS hooks into the init process here Full System encryption with LUKS on headless server - unlock with dropbear and busybox. How?


Solution 1:

Luks is an encryption layer on a block device, so it operates on a particular block device, and exposes a new block device which is the decrypted version. Access to this device will trigger transparent encryption/decryption while it's in use.

It's typically used on either a disk partition, or a LVM physical volume which would allow multiple partitions in the same encrypted container.

LUKs stores a bunch of metadata at the start of the device. It has slots for multiple passphrases. Each slot has a 256 bit salt that is shown in the clear along with an encrypted message. When entering a passphrase LUKS combines it with each of the salts in turn, hashing the result and tries to use the result as keys to decrypt an encrypted message in each slot. This message consists of some known text, and a copy of the master key. If it works for any one of the slots, because the known text matches, the master key is now known and you can decrypt the entire container. The master key must remain unencrypted in RAM while the container is in use.

Knowing the master key allows you access to all the data in the container, but doesn't reveal the passwords in the password slots, so one user cannot see the passwords of other users.

The system is not designed for users to need to know or interact with the master key, and this key can't be changed without re-encrypting. The use of password slots means that passwords can be independent of the encryption key: they be changed without re-encrypting the entire container, and there can be multiple password slots.