Re: [Qemu-devel] QCOW2 cryptography and secure key handling
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
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, §or_num);
write_sector(sector_num, B, S[i]);
}
}
Just speculating...
Laszlo
Re: [Qemu-devel] QCOW2 cryptography and secure key handling
> 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
> 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
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 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
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 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
Am 29.07.2013 um 13:21 hat Markus Armbruster geschrieben: > Paolo Bonzini 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
Paolo Bonzini 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
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
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
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
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
> 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
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 :|
Re: [Qemu-devel] QCOW2 cryptography and secure key handling
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
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
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
> 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
> > 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
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 :|
[Qemu-devel] QCOW2 cryptography and secure key handling
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
