Re: Disadvantages of many temporary keys?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt



[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux