[dm-crypt] pashphrase management question

Sven Eschenberg sven at whgl.uni-frankfurt.de
Thu Oct 27 12:24:02 CEST 2016

Am 27.10.2016 um 09:55 schrieb Arno Wagner:
> On Thu, Oct 27, 2016 at 01:17:42 CEST, Robert Nichols wrote:
>> On 10/26/2016 11:43 AM, ClEmFoster wrote:
>>> hello,
>>> The setup:
>>> I work in an environment that has a whole disk encryption requirement for
>>> VMs.  If the VM is restarted an admin has to hit the console and type in
>>> the passphrase to boot.  This is OK, we don't reboot much, and security
>>> guys are happy.  The problem is they are going to start requiring that
>>> these machines also receive a passphrase change every 3 or 6 months.  That
>>> brings me to the question.
>> Are "they" aware that anyone who has had read access to the device
>> with the LUKS container has had an opportunity to copy the LUKS
>> header, and can always use that LUKS header with the old passphrase
>> to unlock the container (perhaps after spending however much time
>> and processing power is needed to crack that passphrase offline).
>> For that matter, anyone with root access to the VM while the LUKS
>> container is unlocked can easily obtain the master key
>> (dmsetup table --showkeys /dev/{whatever}) and can always access
>> the LUKS container with that.
>> Changing the passphrase doesn't protect against any of that.
> This is probably just the usual "cargo-cult" security, i.e.
> follow the ritual (a.k.a. "Process") without question,
> because that would require understanding.
> Regular passphrase changes on storage-encryption make
> absolutely no sense and gives you absolutely no
> protection benefit (unless you have told somebody
> that should not know, in which case you need to change
> them immediately).

I might be wrong, but changing the passphrase could make sense if (and 
only if) you switch the actual encryption key along with it by 
reencrypting the whole device. Aside from that changing passphrases 
seems a little pointless.
> I would try to give "them" a definition of the LUKS
> passphrase that does not make it a "password" or
> "login credential", and with a bit of luck you can
> negate thereby prevent the usuall "password" process
> and its requirements from applying.
> One approach would be to make this a "technical secret"
> or the like. After all, they probably to not require,
> say,  passphrases protecting certificates to be changed
> regularly, because that would be relatively difficult.
> Regards,
> Arno



More information about the dm-crypt mailing list