From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52871) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1cDD-0007Iv-Vz for qemu-devel@nongnu.org; Tue, 23 Jul 2013 09:01:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1cD7-0006Oh-5d for qemu-devel@nongnu.org; Tue, 23 Jul 2013 09:01:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35085) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1cD6-0006OV-Tf for qemu-devel@nongnu.org; Tue, 23 Jul 2013 09:01:01 -0400 Date: Tue, 23 Jul 2013 14:00:53 +0100 From: "Daniel P. Berrange" Message-ID: <20130723130053.GW2477@redhat.com> References: <20130723124706.GB5002@irqsave.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130723124706.GB5002@irqsave.net> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] QCOW2 cryptography and secure key handling Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?Q?Beno=C3=AEt?= Canet Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On Tue, Jul 23, 2013 at 02:47:06PM +0200, Beno=C3=AEt Canet wrote: >=20 > Hi, >=20 > I have some budget to improve QCOW2's cryptography. >=20 > My main concern is that the QCOW2 image crypto key is passed in clear t= ext. 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 im= proved > 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 --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|