Hello List,
re-encrypting with
different encryption key
--------------------------------------------------------------
when using dm_crypt
in image based deployment strategy setups, where a pre-encrypted image is used
as golden master image, the problem of encryption key escalation is a issue.
In those setups,
where a machine is provisioned from a pre-configured master (e.g. VMWare, EC2
etc), all Images share the same encryption key. Altough it is easy to change the
wrapping key (aka the passphrases or keyfiles) for a volumes, changing the
encryption key is not possible.
This leads to a
situation, where if one machine is compromized and the attacker was able to gain
access to the master key (which is a trivial command, dmsetup table --showkeys),
the attacker can decrypt all data created from this master image - aka all
machines, wheather online or offline. This practially eliminates a whole lot of
security.
Now to the question:
- Are the
development plans or is there already a way to easily, in-place and online
change the encryption key (of course reencrypting all data on the device)
?
My way of doing it
currently would be vgextend with new encrypted device + pvmove for a setup where
the whole PV of a LVM volume is encrpyted, however this means I need twice the
space. Any other ways to do it ?
Key escrow / header
recovery
-----------------------------------------
Another question is:
In larger environments key escrow is wanted feature. It practially reduces
security, but allows companies to ensure regulatory requirements. I
know that RedHat works on this for FC16 and RHEL6 includes basic support,
however I guess a lot of people are practially bound to RHEL5 for at least
another 1-2 years.
While LUKS provides
multi-key functionality and thus allows key escrow with master key, this does
not protect from users WANTING to destroy the data. If some admin does bezerk,
he can just remove tha last key slot from a LUKS volume and all data is
unrecoverable lost (until you have a header backup). So one might argue that you
should always have a backup and thus you always have a header backup (in case
you do block level backup), the encrpytion key itself seems to be a good
candidate for key escrow because it currently does not change over
time.
Now the question:
- Do you
see any security impact if instead of using a passphrase on the LUKS header for
key escrow, someone is using the encryption key itself dmsetup table --showkeys
for key escrow ? (assuming of course properly protected key escrow process and
unique encryption keys for each disk)
Regards,
Robert
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
