From: "Daniel P. Berrange" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Markus Armbruster <armbru@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: [Qemu-devel] [PATCH v3] Describe flaws in qcow/qcow2 encryption in the docs
Date: Wed, 22 Jan 2014 15:47:10 +0000 [thread overview]
Message-ID: <1390405630-4288-1-git-send-email-berrange@redhat.com> (raw)
The qemu-img.texi / qemu-doc.texi files currently describe the
qcow2/qcow2 encryption thus
"Encryption uses the AES format which is very secure (128 bit
keys). Use a long password (16 characters) to get maximum
protection."
While AES is indeed a strong encryption system, the way that
QCow/QCow2 use it results in a poor/weak encryption system.
Due to the use of predictable IVs, based on the sector number
extended to 128 bits, it is vulnerable to chosen plaintext
attacks which can reveal the existence of encrypted data.
The direct use of the user passphrase as the encryption key
also leads to an inability to change the passphrase of an
image. If passphrase is ever compromised the image data will
all be vulnerable, since it cannot be re-encrypted. The admin
has to clone the image files with a new passphrase and then
use a program like shred to secure erase all the old files.
Recommend against any use of QCow/QCow2 encryption, directing
users to dm-crypt / LUKS which can meet modern cryptography
best practices.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
---
qemu-doc.texi | 23 ++++++++++++++++++++---
qemu-img.texi | 23 ++++++++++++++++++++---
2 files changed, 40 insertions(+), 6 deletions(-)
Changed in v3:
- Addressed feedback/typos from Eric & Markus
In v2:
- Addressed typos reported by Peter
Still welcome info about any other flaws qcow2 has in this
area that should be documented.
diff --git a/qemu-doc.texi b/qemu-doc.texi
index 4e9c6e9..6f0b80b 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -547,10 +547,27 @@ File name of a base image (see @option{create} subcommand)
@item backing_fmt
Image format of the base image
@item encryption
-If this option is set to @code{on}, the image is encrypted.
+If this option is set to @code{on}, the image is encrypted with 128-bit AES-CBC.
+
+The use of encryption in QCow and QCow2 images is considered to be flawed by
+modern cryptography standards, suffering from a number of design problems:
+
+@itemize @minus
+@item The AES-CBC cipher is used with predictable initialization vectors based
+on the sector number. This makes it vulnerable to chosen plaintext attacks
+which can reveal the existence of encrypted data.
+@item The user passphrase is directly used as the encryption key. A poorly
+chosen or short passphrase will compromise the security of the encryption.
+@item In the event of the passphrase being compromised there is no way to
+change the passphrase to protect data in any QCow images. The files must
+be cloned, using a different encryption passphrase in the new file. The
+original file must then be securely erased using a program like shred,
+though even this is ineffective with many modern storage technologies.
+@end itemize
-Encryption uses the AES format which is very secure (128 bit keys). Use
-a long password (16 characters) to get maximum protection.
+Use of QCow / QCow2 encryption is thus strongly discouraged. Users are
+recommended to use an alternative encryption technology such as the
+Linux dm-crypt / LUKS system.
@item cluster_size
Changes the qcow2 cluster size (must be between 512 and 2M). Smaller cluster
diff --git a/qemu-img.texi b/qemu-img.texi
index 1bba91e..de74fda 100644
--- a/qemu-img.texi
+++ b/qemu-img.texi
@@ -402,10 +402,27 @@ File name of a base image (see @option{create} subcommand)
@item backing_fmt
Image format of the base image
@item encryption
-If this option is set to @code{on}, the image is encrypted.
+If this option is set to @code{on}, the image is encrypted with 128-bit AES-CBC.
-Encryption uses the AES format which is very secure (128 bit keys). Use
-a long password (16 characters) to get maximum protection.
+The use of encryption in QCow and QCow2 images is considered to be flawed by
+modern cryptography standards, suffering from a number of design problems:
+
+@itemize @minus
+@item The AES-CBC cipher is used with predictable initialization vectors based
+on the sector number. This makes it vulnerable to chosen plaintext attacks
+which can reveal the existence of encrypted data.
+@item The user passphrase is directly used as the encryption key. A poorly
+chosen or short passphrase will compromise the security of the encryption.
+@item In the event of the passphrase being compromised there is no way to
+change the passphrase to protect data in any QCow images. The files must
+be cloned, using a different encryption passphrase in the new file. The
+original file must then be securely erased using a program like shred,
+though even this is ineffective with many modern storage technologies.
+@end itemize
+
+Use of QCow / QCow2 encryption is thus strongly discouraged. Users are
+recommended to use an alternative encryption technology such as the
+Linux dm-crypt / LUKS system.
@item cluster_size
Changes the qcow2 cluster size (must be between 512 and 2M). Smaller cluster
--
1.8.4.2
next reply other threads:[~2014-01-22 15:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-22 15:47 Daniel P. Berrange [this message]
2014-01-22 15:56 ` [Qemu-devel] [PATCH v3] Describe flaws in qcow/qcow2 encryption in the docs Eric Blake
2014-01-27 15:12 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1390405630-4288-1-git-send-email-berrange@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).