[Qemu-devel] Volume key in qcow3?

[Qemu-devel] Volume key in qcow3?

[Frediano Ziglio]

Hi,
  I noted that AES encryption using qcow2 just use the password given
as as key (and also truncating it to 16 bytes == 128 bits).
This is prone to brute force attacks and is not also easy to change
password (you have to decrypt and encrypt again the entire image).
LUKS and EncFS use another way. They generate a random key (the
"volume key") then use the password you give to encrypt N times (where
N is decided by security level or automatically based on time to
decrypt the volume key. To change the password just give the old one,
get the volume key and encrypt again using the new one. LUKS support
also multiple "slots" to allow multiple password and even using an
external key file.
Obviously this require an additional extension to qcow2 so I think it
require a new qcow3 format.

Frediano

Re: [Qemu-devel] Volume key in qcow3?

[Kevin Wolf]

Am 28.07.2011 10:05, schrieb Frediano Ziglio:
> Hi,
>   I noted that AES encryption using qcow2 just use the password given
> as as key (and also truncating it to 16 bytes == 128 bits).
> This is prone to brute force attacks and is not also easy to change
> password (you have to decrypt and encrypt again the entire image).
> LUKS and EncFS use another way. They generate a random key (the
> "volume key") then use the password you give to encrypt N times (where
> N is decided by security level or automatically based on time to
> decrypt the volume key. To change the password just give the old one,
> get the volume key and encrypt again using the new one. LUKS support
> also multiple "slots" to allow multiple password and even using an
> external key file.
> Obviously this require an additional extension to qcow2 so I think it
> require a new qcow3 format.

Yes, once we have qcow3, adding things like this should be easy enough.
I think the idea makes sense.

Another thing to consider with encryption is that we don't encrypt
metadata currently. I'm not entirely sure if this is a good or a bad
thing. Metadata is relatively predictable and I think that might hurt
the encryption? Though I'm really not an expert in this area.

Kevin

Re: [Qemu-devel] Volume key in qcow3?

[Frediano Ziglio]

2011/7/28 Kevin Wolf <kwolf@redhat.com>:
> Am 28.07.2011 10:05, schrieb Frediano Ziglio:
>> Hi,
>>   I noted that AES encryption using qcow2 just use the password given
>> as as key (and also truncating it to 16 bytes == 128 bits).
>> This is prone to brute force attacks and is not also easy to change
>> password (you have to decrypt and encrypt again the entire image).
>> LUKS and EncFS use another way. They generate a random key (the
>> "volume key") then use the password you give to encrypt N times (where
>> N is decided by security level or automatically based on time to
>> decrypt the volume key. To change the password just give the old one,
>> get the volume key and encrypt again using the new one. LUKS support
>> also multiple "slots" to allow multiple password and even using an
>> external key file.
>> Obviously this require an additional extension to qcow2 so I think it
>> require a new qcow3 format.
>
> Yes, once we have qcow3, adding things like this should be easy enough.
> I think the idea makes sense.
>
> Another thing to consider with encryption is that we don't encrypt
> metadata currently. I'm not entirely sure if this is a good or a bad
> thing. Metadata is relatively predictable and I think that might hurt
> the encryption? Though I'm really not an expert in this area.
>
> Kevin
>

I don't think this is a big issue, usually sensitive data is not in
knowing which clusters are allocated or in which sequence (perhaps
looking at allocation strategy you can detect operating system and
filesystem type), snapshot ids and descriptions are IMO more sensible.

Do anybody though that qcow2 can support data-deduplication using
refcounts? Well, in this case this is not possible with encrypted
data.

Frediano

Re: [Qemu-devel] Volume key in qcow3?

[Kevin Wolf]

Am 29.07.2011 10:47, schrieb Frediano Ziglio:
> 2011/7/28 Kevin Wolf <kwolf@redhat.com>:
>> Am 28.07.2011 10:05, schrieb Frediano Ziglio:
>>> Hi,
>>>   I noted that AES encryption using qcow2 just use the password given
>>> as as key (and also truncating it to 16 bytes == 128 bits).
>>> This is prone to brute force attacks and is not also easy to change
>>> password (you have to decrypt and encrypt again the entire image).
>>> LUKS and EncFS use another way. They generate a random key (the
>>> "volume key") then use the password you give to encrypt N times (where
>>> N is decided by security level or automatically based on time to
>>> decrypt the volume key. To change the password just give the old one,
>>> get the volume key and encrypt again using the new one. LUKS support
>>> also multiple "slots" to allow multiple password and even using an
>>> external key file.
>>> Obviously this require an additional extension to qcow2 so I think it
>>> require a new qcow3 format.
>>
>> Yes, once we have qcow3, adding things like this should be easy enough.
>> I think the idea makes sense.
>>
>> Another thing to consider with encryption is that we don't encrypt
>> metadata currently. I'm not entirely sure if this is a good or a bad
>> thing. Metadata is relatively predictable and I think that might hurt
>> the encryption? Though I'm really not an expert in this area.
>>
>> Kevin
>>
> 
> I don't think this is a big issue, usually sensitive data is not in
> knowing which clusters are allocated or in which sequence (perhaps
> looking at allocation strategy you can detect operating system and
> filesystem type), snapshot ids and descriptions are IMO more sensible.
> 
> Do anybody though that qcow2 can support data-deduplication using
> refcounts? Well, in this case this is not possible with encrypted
> data.

No, you can't have two clusters in the active L1 table that are mapped
to the same cluster in the image file. The reason for this is that you
can't update the QCOW_OFLAG_COPIED flag when doing COW (you would have
to scan all L2 tables, which just doesn't work performance-wise)

If we were to do this, we would have to have a flag that turns off the
usage of QCOW_OFLAG_COPIED (it is only a performance optimisation, so
doing this would be possible). Not sure if it's worth it.

Kevin