On Fri, Mar 11, 2011 at 09:54:21AM +0100, Robert.Heinzmann@xxxxxxxxxxxxxxx wrote: > 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. "encryption key escalation"? What does that mean? > 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. Indeed. > 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) ? Not that I know. > 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 ? If your imaging systems allows is, then just create a new encrypted partition before putting that partition image in there. If we are talking LUKS here, then you do not even need customization. Just putting a complete binary disk image on a machine is not a good idea, also for other reasons. For example, make sure not to image any randomness seed files for the kernel, openssl, ssh, gnupg, Java, key files for ssh, UUIDS in disks and RAIDed partitions, etc... The way to do this for Linux, is actually to automatize the installation. Then all these problems go away. Imagimg a machine is a crutch developed in the Windows world. For automated Linux installation, I can highly recommend FAI (Fully Automated Installation). Takes about a day until you get how it works though. I used it to install a cluster. Allows you things like reinstallting 20 machines in a few minutes without data loss and with individual adaptions. Also usable for larger installations. > 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) No special problem. This incidentally can also be done easier by just storing a header backup while a recovery passphrase is set. However, if your user knows what he/she does, they can change the master key with just a bit more effort. I would say your protection goal here is to prevent accidental deletion of the recovery passhprase, not intentional deletion. Arno > Regards, > Robert > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
