How does LUKS work?

Question

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

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.

Comments

[thomasrutter]

Are you able to give some more detail about why you need to know this, ie what are you trying to achieve?

[fritz]

I'm wondering for purely academic reasons. I have no plans to modify/achieve anything.

[DJCrashdummy]

maybe asking this on security.stackexchange.com would be a good idea. -- for now this may answer your question partly: security.stackexchange.com/questions/39306/…

[Andrea Lazzarotto]

Welcome to Ask Ubuntu! I agree that security.SE would probably give you better answers that AU, nevertheless the question is on topic here as well and it's also an interesting one. +1 :)

[joonas.fi]

Awesome, accurate summary! I've been researching LUKS and it turns out there's not great technical overviews about it. Am trying to write a blog post right now..

[Ciprian Tomoiagă]

@joonas.fi have you finished your blog post? :) I'd appreciate a good overview

[joonas.fi]

@CiprianTomoiagă unfortunately no, it's still a draft. I can show you the draft but bear in mind that it's unfinished. It might contain errors and not be understandable enough :) Here: gist.github.com/joonas-fi/b6bfc564a1a7f3d6b120728db5d48b61

[user1847]

Fantastic writeup, @joonas.fi. Thank you :)

[thomasrutter]

The ability to change passwords without re-encrypting is a convenience feature. It means you're not stuck with the same password forever, and that you can change it without decrypting and re-encrypting everything. If your master key was compromised at any time, you're screwed no matter what. If your old password was compromised but the attacker never gained access to the encrypted data at the time, then they won't be able to gain access after either, unless they come across an old version of the encrypted data.

[thomasrutter]

@bobcat regarding your previous comment, yes the unencrypted master key exists in RAM while it's mounted so it is possible for an authorised user to read it. What was meant by the quoted sentence is it's not intended that the end user needs to know or interact with the master key at all in normal operation, it's intended that they use their password instead. The assumption is, you don't give access to anyone who you wouldn't want to be able to get the master key, because anyone with access can do so, and add new authorised users, remove existing ones, etc. Everything except read passwords.

[MWB]

@thomasrutter Thanks for the clarifications. I hope you'll work them into the answer. +1 in advance.