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

[Benoît Canet]

Le Monday 29 Jul 2013 à 12:32:35 (+0100), Daniel P. Berrange a écrit :
> On Mon, Jul 29, 2013 at 01:25:24PM +0200, Kevin Wolf wrote:
> > Am 29.07.2013 um 13:21 hat Markus Armbruster geschrieben:
> > > Paolo Bonzini <address@hidden> writes:
> > > 
> > > > 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
> > > 
> > > Fine example of why the "we use a standard, strong cypher (AES),
> > > therefore our crypto must be good" argument is about as convincing as "I
> > > built this sandcastle from the finest quartz sand, so it must be
> > > strong".
> > > 
> > > Crypto should be done by trained professionals[*].
> > > 
> > > [...]
> > > 
> > > 
> > > [*] I studied crypto deeply enough to know I'm not.
> > 
> > The point is, how do you know that you end up with good crypto when you
> > add LUKS-like features? You still use them in a different context, and
> > that may or may not break it. I can't really say.
> 
> If we're not sufficiently confident in what we're doing, then we ought to
> find suitable people to advise us / review what we'd propose. I know Red
> Hat has people on its security team who we might be able to get to review
> any proposals in this area, if we wanted further crypto advise. If we went
> with an approach of incorporating LUKS, then we should also connect with
> the dm-crypt maintainers  / LUKS designers to ask them to review what we're
> proposing to do.

http://www.spinics.net/lists/dm-crypt/msg05277.html

Best regards

Benoît

> 
> 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 :|
>