On Sat, Oct 28, 2017 at 5:39 AM, Arno Wagner <arno@xxxxxxxxxxx> wrote:
As always, the fact of thematter is that an attacker that has
access to the decrypted container can get everything, including
all data in there. But said attacker could also replace the
cryptsetup binary, the kernel, etc. so it is somthing to be
aware of, not something to fix.
In this case, that's only true to a point: if an attacker were able to interrupt the reboot process (e.g. by opening the BIOS) they would have a valid, unencrypted disk decryption key/passphrase in the initramfs, which would allow them access to the master key, etc.
There would be no need to replace anything, just to dd the first MB of the encrypted partition(s) and copy the custom initramfs with the key/passphrase which is, I think, what Robert meant here:
Anyone (or any bot) that had an opportunity to make a copy of the LUKS header while that key was installed can always use that header, together with that "temporary" key, to unlock the container.
I don't think that a detached header would help: we're talking about unattended reboots, so the detached header would have to be present when the user is not.
There's also a question on when is the initramfs generated: AFAIK the "most secure" time would be when the reboot command is [about to be] issued, which would minimize the time the LUKS header has two used slots. Recreating it before (even manually, when the computer is attended) would expose the passphrase on the unencrypted boot partition for all the time between generation and reboot.
That being said, the question was around any disadvantage on repeated changes, which shouldn't be a problem (per Robert).
If the probability of the key getting stolen is low enough (i.e. you're not worried about your header getting cloned/stolen) then you should be ok.
One small modification I would make, it to use n+2 slots: n are 'yours' (with the passphrase/passphrases you would use to decrypt normally), then one slot with your temporary key and one with a random passphrase that you can use for luksAddKey during the creation of the custom initramfs; I'm guessing you want to script the process to run at some point, possibly when you're not there, so having this extra slot allows you to not write your personal passphrase anywhere on disk and maybe (with some scripting) even rotate this passphrase every now and again.
Claudio
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
