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

["Daniel P. Berrange" <berrange@redhat.com>]

On Wed, Jul 24, 2013 at 05:30:22PM +0200, Paolo Bonzini wrote:
> 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?

Yep, that is another particularly good reason to deprecate qcow2's
existing aes encryption and adopt an existing format that has got
a proven good design like LUKS.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|