On 03/11/2011 09:54 AM, Robert.Heinzmann@xxxxxxxxxxxxxxx wrote: > Hello List, Hi, I am sure other will address security aspect better than me, so I'll just respond to technical things.... > 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. If anyone provides pre-encrypted appliances which share one master key, it is wrong design. Better is to have plaintext golden image, create new encrypted device and copy plaintext data there. This way you are sure that master key differs. > 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) ? Yes, plans are there through integration with LVM If you are Red Hat customer, please ask through support for this feature. https://bugzilla.redhat.com/show_bug.cgi?id=488718 dmcrypt mailing request will not help me to increase priority of these requests, I need my management to see that people really want to use that. > 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 ? Using dd to another device, change key, dd back is usually quicker. (But not online.) > 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. The same question as above - backporting changes to RHEL5 is incredibly problematic (mainly for kernel, but library compatibility is also not easy sometimes). No plans or request to rebase it there for now. Again, please use Red Hat support if it is request for feature backport. I would suggest you here plan to use RHEL6, most of changes are already there, and development will continue there. Anyway, new cryptsetup works on RHEL5, AFAIK volume_key is available for RHEL5 as well. (You can always recompile packages yourself, usually static version work nice here - just one binary. LUKS is backward compatible for default settings.) > 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, There is no system which is resistant to attack if attacker has full admin rights. Period. Use backups:-) > the encrpytion key itself seems to > be a good candidate for key escrow because it currently does not > change over time. volume_key - https://fedorahosted.org/volume_key/ cryptsetup luksDump --dump-master-key cryptsetup luksHeaderBackup - all is here already in recent versions. Of course you need to store it on safe place. > - 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) volume_key is designed as key escrow mechanism for master key, it uses libcrypsetup as backend, so it is directly supporting LUKS. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
