[Qemu-devel] QCOW2 cryptography and secure key handling

[Qemu-devel] QCOW2 cryptography and secure key handling

[Benoît Canet]

Hi,

I have some budget to improve QCOW2's cryptography.

My main concern is that the QCOW2 image crypto key is passed in clear text.

Do you (the block maintainers) have an idea on how the code could be improved
to securely pass the crypto key to the QCOW2 code ?

Best regards

Benoît

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

[Daniel P. Berrange]

On Tue, Jul 23, 2013 at 02:47:06PM +0200, Benoît Canet wrote:
> 
> Hi,
> 
> I have some budget to improve QCOW2's cryptography.
> 
> My main concern is that the QCOW2 image crypto key is passed in clear text.

That is only a problem if someone can sniff the communications channel
used by the monitor socket between QEMU & the management application.
IOW, this is only a problem if someone has configured QEMU to listen on
a TCP / UDP socket for monitor traffic. If they had done this, it would
be considered an insecure configuration regardless of whether qcow2
encryption is used or not. So I don't think there's any problem which
needs solving from the POV of clear text keys over the monitor, besides
to document that you should configure QEMU such that its monitor is
only accessible to the app managing it. eg use a UNIX domain socket
for configuration.

> Do you (the block maintainers) have an idea on how the code could be improved
> to securely pass the crypto key to the QCOW2 code ?

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.


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

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

[Benoît Canet]

> > Do you (the block maintainers) have an idea on how the code could be improved
> > to securely pass the crypto key to the QCOW2 code ?
> 
> 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.

Thanks I will read the LUKS specification.

Best regards

Benoît

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

[Benoît Canet]

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

Best regards

Benoît

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

[Stefan Hajnoczi]

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 haven't
looked at qcow2 encryption in the past because fairly few people
actually use it.

One use-case I have heard about is qcow2 files over NFS.  The network
and the storage system should not see guest data.  Only the host and the
VM should see the data.

A big win with LUKS is that you can change the passphrase without
re-encrypting the data.

Stefan

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

[Kevin Wolf]

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.

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

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 guess if you want to plausibly claim that some new code does better,
some questions like these have to be answered.

Kevin

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

[Daniel P. Berrange]

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

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

[Benoît Canet]

> 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

I already tried the generic block driver approach on other project. (Quorum)
The problem is that it result in complex issues to make the driver works with
all QEMU features (think snapshots) and that no one has the funding to tackle
the infrastructure work required to solve this: writing BlockBackend and block
filters.

Best regards

Benoît

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

[Paolo Bonzini]

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

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

[Daniel P. Berrange]

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

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

[Paolo Bonzini]

Il 24/07/2013 17:33, Daniel P. Berrange ha scritto:
>>> 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.

Note that this is independent of LUKS vs. anything else.  LUKS only
provides the key, you then have to implement encryption yourself.  And
full implementation of all the cyphers and modes that LUKS supports
would be a lot of work.

In fact, LUKS supports a cypher mode as weak as the current qcow2 mode
("cbc-plain") and it even supports ECB.  And dually, adding a more
robust cypher mode to the current qcow2 encryption would be trivial and
would protect against the watermarking attack (it would not fix the
problems with keys, of course, so I'm not suggesting to do it).

Paolo

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

[Daniel P. Berrange]

On Wed, Jul 24, 2013 at 05:40:14PM +0200, Paolo Bonzini wrote:
> Il 24/07/2013 17:33, Daniel P. Berrange ha scritto:
> >>> 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.
> 
> Note that this is independent of LUKS vs. anything else.  LUKS only
> provides the key, you then have to implement encryption yourself.  And
> full implementation of all the cyphers and modes that LUKS supports
> would be a lot of work.
> 
> In fact, LUKS supports a cypher mode as weak as the current qcow2 mode
> ("cbc-plain") and it even supports ECB.  And dually, adding a more
> robust cypher mode to the current qcow2 encryption would be trivial and
> would protect against the watermarking attack (it would not fix the
> problems with keys, of course, so I'm not suggesting to do it).

True, implementing all the algorithms that the kernel supports for
LUKS would be alot of work, and mostly a waste of time for the weak
modes. So we'd probably want to be pragmatic about what we targetted,
and pick a handful of common ciphers which are considered strong
and commonly used by high quality disk encryption software.

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

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

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> 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.

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

[Kevin Wolf]

Am 29.07.2013 um 13:21 hat Markus Armbruster geschrieben:
> Paolo Bonzini <pbonzini@redhat.com> 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.

Kevin

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 <pbonzini@redhat.com> 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 :|

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 <pbonzini@redhat.com> 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 :|
> 

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

[Benoît Canet]

> Crypto should be done by trained professionals[*].

I agree I feel uneasy to write cryptographic code.

Best regards

Benoît

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

[Benoît Canet]

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

void qcow2_encrypt_sectors(BDRVQcowState *s, int64_t sector_num,
                           uint8_t *out_buf, const uint8_t *in_buf,
                           int nb_sectors, int enc,
                           const AES_KEY *key)
{
    union {
        uint64_t ll[2];
        uint8_t b[16];
    } ivec;
    int i;

    for(i = 0; i < nb_sectors; i++) {
        ivec.ll[0] = cpu_to_le64(sector_num);
        ivec.ll[1] = 0;
        AES_cbc_encrypt(in_buf, out_buf, 512, key,
                        ivec.b, enc);
        sector_num++;
        in_buf += 512;
        out_buf += 512;
    }
}

CBC mode would imply that each sector would be crypted by combining the
plaintext with the previous sector.
It's does not look to be the case as the IV is reset to sector_num for each
sector.
It look like CTR mode.

Best regards

Benoît

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

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

[Laszlo Ersek]

On 07/31/13 17:27, Benoît Canet wrote:
>> For example, current qcow2 encryption is vulnerable to a watermarking
>> attack.
>> http://en.wikipedia.org/wiki/Disk_encryption_theory#Cipher-block_chaining_.28CBC.29
> 
> void qcow2_encrypt_sectors(BDRVQcowState *s, int64_t sector_num,
>                            uint8_t *out_buf, const uint8_t *in_buf,
>                            int nb_sectors, int enc,
>                            const AES_KEY *key)
> {
>     union {
>         uint64_t ll[2];
>         uint8_t b[16];
>     } ivec;
>     int i;
> 
>     for(i = 0; i < nb_sectors; i++) {
>         ivec.ll[0] = cpu_to_le64(sector_num);
>         ivec.ll[1] = 0;
>         AES_cbc_encrypt(in_buf, out_buf, 512, key,
>                         ivec.b, enc);
>         sector_num++;
>         in_buf += 512;
>         out_buf += 512;
>     }
> }
> 
> CBC mode would imply that each sector would be crypted by combining the
> plaintext with the previous sector.
> It's does not look to be the case as the IV is reset to sector_num for each
> sector.
> It look like CTR mode.

No, it's CBC.

Each individual sector is encrypted with CBC. For each sector, the IV is
selected with a scheme that "resembles" CTR, but (a) IV selection is a
different concept from chaining mode, (b) the IV generation used above
is *not* CTR either.

http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher-block_chaining_.28CBC.29

http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_.28CTR.29

The watermarking attack Paolo linked does work here:

    If the IVs are predictable an adversary can manage to store a file
    specially created to zero out the IV, it is possible to leave a
    "watermark" on the disk, proving that the specially created file is,
    indeed, stored on disk. The exact method of constructing the
    watermark depends on the exact function providing the IVs; but the
    general recipe is to create two encrypted sectors which have
    identical first blocks b1 and b2;  these two are then related to
    each other by

      b1 xor IV1 == b2 xor IV2

    Thus, when these two blocks are encrypted, they both encrypt to the
    same thing, leaving a watermark on the disk.

We can "xor IV2" both sides of the above equation:

  b1 xor IV1 xor IV2 == b2

Suppose that you as the attacker can have a good guess at the
"sector_num" parameter of the qcow2_encrypt_sectors() function. Then you
create two (consecutive) sectors:

sector X:
- Let's denote the first 16 bytes with B1. The contents of these bytes
doesn't matter, you can fill them from /dev/urandom eg. for good
selectivity. (16 bytes because that's the block size of AES.)

- Let's denote the remaining 512-16 = 496 bytes with S. The same idea
covers the contents of S.

Then, sector Y:
- Let's denote the first 16 bytes with B2. Prepare their contents as
follows:

  B2 := B1 ^ sector_num ^ (sector_num + 1)

- The remaining 496 bytes should be filled with the same S.


When qcow2_encrypt_sectors() is called with the "sector_num" you
predicted, with "in_buf" pointing at X directly followed by Y, the
following happens:

In the first sector (X),
- The first 16 bytes are encrypted using "sector_num" as IV:

  cipher1 := encrypt(sector_num ^ B1, secret_key)

- The remaining 496 bytes (considered one big message) use "cipher1" as IV.

In the next sector (Y),
- The first 16 bytes are encrypted using "sector_num+1" as IV:

  cipher2 := encrypt((sector_num+1) ^ B2, secret_key)

However,

  (sector_num+1) ^ B2 ==
  (sector_num+1) ^ (B1 ^ sector_num ^ (sector_num + 1)) ==
  (sector_num+1) ^ (sector_num + 1) ^ B1 ^ sector_num ==
  sector_num ^ B1

Therefore,

  cipher2 == encrypt(sector_num ^ B1, secret_key) ==
  cipher1

Which means that the first 16 bytes of these two sectors will look the
same in the encrypted image.

- The remaining 496 bytes in the second block are encrypted using
cipher2==cipher1 as IV. However, since the plaintext contents ("S") is
shared between the trailing 496 bytes of both sectors, and secret_key is
the same, and the cipher2==cipher1 IVs are the same too, these encrypt
to the same data as well.

You'll end up with two identical sectors in the encrypted image.

    To protect against the watermarking attack, a cipher or a hash
    function is used to generate the IVs from the key and the current
    sector number, so that an adversary cannot predict them. In
    particular, the ESSIV approach uses a block cipher in CTR mode to
    generate the IVs.

Laszlo

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

[Laszlo Ersek]

On 07/31/13 19:52, Laszlo Ersek wrote:

> You'll end up with two identical sectors in the encrypted image.

Apologies for following up on my own message...

If you want to store an arbitrary N bit long bit-string (a watermark)
that is visible in the encrypted image, then you need:
- a good guess at "sector_num" (like before),
- B1 (like before),
- to compute B_n from B(n-1), like before,
- two different trailing plaintext portions (each containing 496 bytes),
let's call them S0 and S1,
- (N+1) consecutive sectors in total.

You'd write the subject bitstring like this:

void compute_next_B(uint64_t B[2], uint64_t *sector_num)
{
    B[0] ^= (*sector_num ^ (*sector_num + 1));
    ++*sector_num;
}

void write_string(const char unsigned *subject_string, size_t N,
                  uint64_t sector_num)
{
    const char unsigned S[2][496] = {
        /* constant originally drawn from a good pseudo-random source */
    };
    uint64_t B[2] = { /* ditto */ };
    int i = 0;
    size_t n;

    write_sector(sector_num, B, S[i]);
    for (n = 0; n < N; ++n) {
        i ^= is_bit_set(subject_string, n);
        compute_next_B(B, &sector_num);
        write_sector(sector_num, B, S[i]);
    }
}

Just speculating...
Laszlo

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

[Daniel P. Berrange]

On Tue, Jul 23, 2013 at 05:22:47PM +0200, Stefan Hajnoczi wrote:
> 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 haven't
> looked at qcow2 encryption in the past because fairly few people
> actually use it.
> 
> One use-case I have heard about is qcow2 files over NFS.  The network
> and the storage system should not see guest data.  Only the host and the
> VM should see the data.

Yep, that is the core usecase. You are securing the system such that
only the VM host administrator/processes can compromise the data. It
is protected against malicious storage and/or network administrators.

> A big win with LUKS is that you can change the passphrase without
> re-encrypting the data.

Other benefits of LUKs are

 - Strong encryption key, even if the passphrase itself is weak
 - Support for multiple passphrases
 - Support for arbitrary different encryption algorithms / settings
 - Ability to detect whether the passphrase is correct or not rather
   than just decrypting to produce garbage

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