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

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

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.

The ability to change the passphrase is also a pretty big deal. If
your passphrase is compromised for whatever reason, you want to have
a fast / efficient mechanism to change it in all affeted disk images
while the VMs are still in use. The LUKS format allows for that, since
it separates user passphrase from encryption keys. The LUKS format
is design with anti-forensic measures so that when you invalidate
a passphrase it is hard to get it back.

With qcow2 you'd have to offline all VMs & re-create the images with
new keys, then secure erase all the data stored with the old key.
This is an awfully bad way to deal with passphrase compromises.

> So what can we take from LUKS, how would it be integrated in qcow2 and
> what will the final result be like then?

IMHO the key thing we want to preserve here, is the ability to take an
existing LUKS block device and convert it into a qcow2 image, without
needing to know the passphrase or re-encrypt. Similarly take a qcow2
image with LUKS encryption and turn that back into a block device,
again without knowing the passphrase

There are two ways I could see it happening. Either integrate directly
into the qcow2 file format, by mapping LUKS headers & key material
blocks into the qcow2 header region in some manner.

Alternatively do it in a completely generic block driver, that qcow2
(or any other qemu bdrv) calls into instead of the file bdrv. That
way the entire LUKS format becomes the image file data payload. A
separate block driver, could also allow LUKS to be layered ontop,
so that metadata is encrypted too.  eg so you could end up with
either layering

   QCow2 bdrv -> LUKS bdrv -> file bdrv
   LUKS bdrv -> QCow2 bdrv -> file bdrv

> For example, currently qcow2 doesn't encrypt metadata. Is this a
> problem? If metadata is encrypted, you have some blocks whose content is
> pretty predictable. Does this hurt?

I don't think it is neccessary to encrypt the image file header metadata
as a general rule, since there arguably isn't any sensitive data in there.
If you did LUKS as a standalone generic bdrv though, you could have the
option of layering it above the qcow2 driver, for the minority who
really need it.

> I guess if you want to plausibly claim that some new code does better,
> some questions like these have to be answered.

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