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

[Daniel P. Berrange]

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.

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