Re: [dm-crypt] Disadvantages of many temporary keys?

[Robert Nichols <rnicholsNOSPAM@comcast.net>]

On 10/27/2017 08:09 PM, L. Rose wrote:
> Hi everyone,
> 
> My setup runs off a dmcrypt/luks encrypted drive. I want to do daily
> unattended reboots, so I don't want to have to enter the password upon
> reboot. I thought of generating a random temporary key, inserting that
> into a secondary slot on my container using luksAddKey and preparing a
> custom initramfs containing that temporary key, so that the system can
> unlock the container once after the reboot. When the system is up and
> running again, I'll remove that random temporary key from both the
> container and the initramfs.
> 
> My question is: Do dmcrypt/luks containers suffer from frequent key
> adding/removal? Will the container degrade because of this usage, or
> maybe get errors? If so, is there a better way for unattended reboots?

It won't suffer. All that happens when you add or remove a key is that the portion of the LUKS header for that keyslot gets rewritten.

But, removal of that temporary key is not as secure as you might think. 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. "LUKS with detached header" would be the most straightforward way, but the master key could also be constructed from that header + key and used directly with cryptsetup to access the container's contents.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.