Re: [Qemu-devel] QCOW2 cryptography and secure key handling

[Paolo Bonzini <pbonzini@redhat.com>]

Il 23/07/2013 17:57, Daniel P. Berrange ha scritto:
> On Tue, Jul 23, 2013 at 05:38:00PM +0200, Kevin Wolf wrote:
>> Am 23.07.2013 um 17:22 hat Stefan Hajnoczi geschrieben:
>>> On Tue, Jul 23, 2013 at 04:40:34PM +0200, Benoît Canet wrote:
>>>>> More generally, QCow2's current encryption support is woefully inadequate
>>>>> from a design POV. If we wanted better encryption built-in to QEMU it is
>>>>> best to just deprecate the current encryption support and define a new
>>>>> qcow2 extension based around something like the LUKS data format. Using
>>>>> the LUKS data format precisely would be good from a data portability
>>>>> POV, since then you can easily switch your images between LUKS encrypted
>>>>> block device & qcow2-with-luks image file, without needing to re-encrypt
>>>>> the data.
>>>>
>>>> I read the LUKS specification and undestood enough part of it to understand the
>>>> potentials benefits (stronger encryption key, multiple user keys, possibility to
>>>> change users keys).
>>>>
>>>> Kevin & Stefan: What do you think about implementing LUKS in QCOW2 ?
>>>
>>> Using standard or proven approachs in crypto is a good thing.
>>
>> I think the question is how much of a standard approach you take and
>> what sense it makes in the context where it's used. The actual
>> encryption algorithm is standard, as far as I can tell, but some people
>> have repeatedly been arguing that it still results in bad crypto. Are
>> they right? I don't know, I know too little of this stuff.
> 
> One reason that QCow2 is bad, despite using a standard algorithm, is
> that the user passphrase is directly used encrypt/decrypt the data.
> Thus a weak passphrase leads to weak data encryption. With the LUKS
> format, the passphrase is only used to unlock the master key, which
> is cryptographically strong. LUKS applies multiple rounds of hashing
> to the user passphrase based on the speed of the machine CPUs, to
> make it less practical to brute force weak user passphrases and thus
> recover the master key.

Another reason that QCow2 is bad is that disk encryption is Complicated.
 Even if you do not do any horrible mistakes such as using ECB
encryption, a disk encrypted sector-by-sector has a lot of small
separate cyphertexts in it and is susceptible to a special range of attacks.

For example, current qcow2 encryption is vulnerable to a watermarking
attack.
http://en.wikipedia.org/wiki/Disk_encryption_theory#Cipher-block_chaining_.28CBC.29

dm-crypt or other disk encryption programs use more complicated schemes,
do we need to go there?

Paolo