You can, but it breaks security, because the cloned container has the same header and hence the same master key. You cannot change the master key on a LUKS container, even if you change the passphrase(s), the master key stays the same. That means whoever has access to one of the clones can decrypt them all, completely bypassing the passphrases.

If we set a new secret user key, the encrypted master key stored on disk changes but the master key does not. Hence, users can change password frequently without re-encrypting all the data.

My questions:

1. If we can have up to 8 slots for decryption does that mean we have 8 corresponding Master Keys split in anti-forensic stripes or is it still ONE MK ?
2. If it is ONE MK how the passphrase from slot 2 decrypt it when it is already encrypted with the passphrase from slot 1 (yes I know it is not the passphrase itself, but I keep it like that for simplicity).

3. Regarding the second quotation. So per my understanding while changing the LUKS passphrase we first provide the current passphrase, we then provide a new one and that changes the encrypted representation of the MK but after decryption it is still the same that was randomly generated during first initialization, correct?

4. Then regarding the first quotation. I simply don't get it, at least notthe last sentence

That means whoever has access to one of the clones can decrypt them all, completely bypassing the passphrases

Does that mean that if a have server A with LUKS encryption protected by a high-entrophy passphrase and clone that drive I would be able to decrypt that drive without even knowing or having to provide that passphrase ? If yes how would I do that ? Dump the MK from memory on server A, or how ?

Data is encrypted with Data Encryption Key. Each slot encrypts the DEK using a Key Encryption Key derived from a passphrase. Access to the DEK gets you the data. Access to any of the KEKs will give you access to the DEK. Clearing a passphrase slot, changing the passphrase, etc. does not change the DEK.

Whoever had access to the volume and a working passphrase could have extracted and saved the DEK, and that means they can use the DEK to decrypt the data in the future, when the slot with the passphrase they knew has been deleted. It also means they can decrypt any of the clones of the volume, even those for which the passphrase they knew was never valid.

If you really need to give different people access to a copy of the volume and be able to revoke access from other copies or from data added to the volume after their access was revoked, you have to change the DEK - reencrypt the volume or create a new encrypted volume (with possibly same passphrases protecting the new DEK) and copy all the data.

• Whoever had access to the volume and a working passphrase could have extracted and saved the DEK Extracted exactly from where ? Once decrypted where is the key stored ? RAM ? May 26, 2019 at 18:48
• You can from RAM, but you can just process the LUKS header as a file without really mounting the volume.
– Z.T.
May 26, 2019 at 18:50
• You can use the following command line "cryptsetup luksDump --dump-master-key /dev/encrypted_device" in order to get the master key. May 26, 2019 at 19:29
• hmm okay but in the LUKS header I have only an encrypted representation of the MK, isn't it ? I can see MK bits, digest, salt ... Once the MK gets decrypted by the secret key generated from PBKDF2 it remains in decrypted form in the slot or is it still encrypted there but the decrypted MK is stored in RAM ? May 27, 2019 at 7:52
• The master key is stored encrypted, yes. If you know one of the 8 possible passwords you can decrypt it and store it on a post it note and then you can use that master key you have to decrypt any other volume that shares it - was cloned from same volume. I really don't understand your confusion.
– Z.T.
May 27, 2019 at 8:01