[dm-crypt] Disadvantages of many temporary keys?

Claudio Moretti flyingstar16 at gmail.com
Sat Oct 28 12:14:04 CEST 2017


On Sat, Oct 28, 2017 at 5:39 AM, Arno Wagner <arno at wagner.name> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20171028/7f14bbbd/attachment.html>


More information about the dm-crypt mailing list