[dm-crypt] in-place Re-Encrypt with different encryption key / Key Escrow / Header Recovery.

[dm-crypt] in-place Re-Encrypt with different encryption key / Key Escrow / Header Recovery.

[Robert.Heinzmann]

[-- Attachment #1: Type: text/plain, Size: 2695 bytes --]

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 
 
 

[-- Attachment #2: Type: text/html, Size: 5635 bytes --]

Re: [dm-crypt] in-place Re-Encrypt with different encryption key / Key Escrow / Header Recovery.

[Milan Broz]

On 03/11/2011 09:54 AM, Robert.Heinzmann@deutschepost.de 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

Re: [dm-crypt] in-place Re-Encrypt with different encryption key / Key Escrow / Header Recovery.

[Arno Wagner]

On Fri, Mar 11, 2011 at 09:54:21AM +0100, Robert.Heinzmann@deutschepost.de 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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
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