From ac1d88784907c9603b3849b2c3043259f75ed2a5 Mon Sep 17 00:00:00 2001 From: "Daniel P. Berrange" Date: Wed, 14 Oct 2015 09:58:38 +0100 Subject: crypto: add QCryptoSecret object class for password/key handling Introduce a new QCryptoSecret object class which will be used for providing passwords and keys to other objects which need sensitive credentials. The new object can provide secret values directly as properties, or indirectly via a file. The latter includes support for file descriptor passing syntax on UNIX platforms. Ordinarily passing secret values directly as properties is insecure, since they are visible in process listings, or in log files showing the CLI args / QMP commands. It is possible to use AES-256-CBC to encrypt the secret values though, in which case all that is visible is the ciphertext. For ad hoc developer testing though, it is fine to provide the secrets directly without encryption so this is not explicitly forbidden. The anticipated scenario is that libvirtd will create a random master key per QEMU instance (eg /var/run/libvirt/qemu/$VMNAME.key) and will use that key to encrypt all passwords it provides to QEMU via '-object secret,....'. This avoids the need for libvirt (or other mgmt apps) to worry about file descriptor passing. It also makes life easier for people who are scripting the management of QEMU, for whom FD passing is significantly more complex. Providing data inline (insecure, only for ad hoc dev testing) $QEMU -object secret,id=sec0,data=letmein Providing data indirectly in raw format printf "letmein" > mypasswd.txt $QEMU -object secret,id=sec0,file=mypasswd.txt Providing data indirectly in base64 format $QEMU -object secret,id=sec0,file=mykey.b64,format=base64 Providing data with encryption $QEMU -object secret,id=master0,file=mykey.b64,format=base64 \ -object secret,id=sec0,data=[base64 ciphertext],\ keyid=master0,iv=[base64 IV],format=base64 Note that 'format' here refers to the format of the ciphertext data. The decrypted data must always be in raw byte format. More examples are shown in the updated docs. Reviewed-by: Eric Blake Signed-off-by: Daniel P. Berrange --- qemu-options.hx | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) (limited to 'qemu-options.hx') diff --git a/qemu-options.hx b/qemu-options.hx index 5affc82e..f37a2eb 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -3678,6 +3678,83 @@ Dump the network traffic on netdev @var{dev} to the file specified by The file format is libpcap, so it can be analyzed with tools such as tcpdump or Wireshark. +@item -object secret,id=@var{id},data=@var{string},format=@var{raw|base64}[,keyid=@var{secretid},iv=@var{string}] +@item -object secret,id=@var{id},file=@var{filename},format=@var{raw|base64}[,keyid=@var{secretid},iv=@var{string}] + +Defines a secret to store a password, encryption key, or some other sensitive +data. The sensitive data can either be passed directly via the @var{data} +parameter, or indirectly via the @var{file} parameter. Using the @var{data} +parameter is insecure unless the sensitive data is encrypted. + +The sensitive data can be provided in raw format (the default), or base64. +When encoded as JSON, the raw format only supports valid UTF-8 characters, +so base64 is recommended for sending binary data. QEMU will convert from +which ever format is provided to the format it needs internally. eg, an +RBD password can be provided in raw format, even though it will be base64 +encoded when passed onto the RBD sever. + +For added protection, it is possible to encrypt the data associated with +a secret using the AES-256-CBC cipher. Use of encryption is indicated +by providing the @var{keyid} and @var{iv} parameters. The @var{keyid} +parameter provides the ID of a previously defined secret that contains +the AES-256 decryption key. This key should be 32-bytes long and be +base64 encoded. The @var{iv} parameter provides the random initialization +vector used for encryption of this particular secret and should be a +base64 encrypted string of the 32-byte IV. + +The simplest (insecure) usage is to provide the secret inline + +@example + + # $QEMU -object secret,id=sec0,data=letmein,format=raw + +@end example + +The simplest secure usage is to provide the secret via a file + + # echo -n "letmein" > mypasswd.txt + # $QEMU -object secret,id=sec0,file=mypasswd.txt,format=raw + +For greater security, AES-256-CBC should be used. To illustrate usage, +consider the openssl command line tool which can encrypt the data. Note +that when encrypting, the plaintext must be padded to the cipher block +size (32 bytes) using the standard PKCS#5/6 compatible padding algorithm. + +First a master key needs to be created in base64 encoding: + +@example + # openssl rand -base64 32 > key.b64 + # KEY=$(base64 -d key.b64 | hexdump -v -e '/1 "%02X"') +@end example + +Each secret to be encrypted needs to have a random initialization vector +generated. These do not need to be kept secret + +@example + # openssl rand -base64 16 > iv.b64 + # IV=$(base64 -d iv.b64 | hexdump -v -e '/1 "%02X"') +@end example + +The secret to be defined can now be encrypted, in this case we're +telling openssl to base64 encode the result, but it could be left +as raw bytes if desired. + +@example + # SECRET=$(echo -n "letmein" | + openssl enc -aes-256-cbc -a -K $KEY -iv $IV) +@end example + +When launching QEMU, create a master secret pointing to @code{key.b64} +and specify that to be used to decrypt the user password. Pass the +contents of @code{iv.b64} to the second secret + +@example + # $QEMU \ + -object secret,id=secmaster0,format=base64,file=key.b64 \ + -object secret,id=sec0,keyid=secmaster0,format=base64,\ + data=$SECRET,iv=$( Date: Thu, 15 Oct 2015 16:14:42 +0100 Subject: crypto: add support for loading encrypted x509 keys Make use of the QCryptoSecret object to support loading of encrypted x509 keys. The optional 'passwordid' parameter to the tls-creds-x509 object type, provides the ID of a secret object instance that holds the decryption password for the PEM file. # printf "123456" > mypasswd.txt # $QEMU \ -object secret,id=sec0,filename=mypasswd.txt \ -object tls-creds-x509,passwordid=sec0,id=creds0,\ dir=/home/berrange/.pki/qemu,endpoint=server \ -vnc :1,tls-creds=creds0 This requires QEMU to be linked to GNUTLS >= 3.1.11. If GNUTLS is too old an error will be reported if an attempt is made to pass a decryption password. Reviewed-by: Eric Blake Signed-off-by: Daniel P. Berrange --- qemu-options.hx | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'qemu-options.hx') diff --git a/qemu-options.hx b/qemu-options.hx index f37a2eb..49afe6c 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -3627,7 +3627,7 @@ expensive operation that consumes random pool entropy, so it is recommended that a persistent set of parameters be generated upfront and saved. -@item -object tls-creds-x509,id=@var{id},endpoint=@var{endpoint},dir=@var{/path/to/cred/dir},verify-peer=@var{on|off} +@item -object tls-creds-x509,id=@var{id},endpoint=@var{endpoint},dir=@var{/path/to/cred/dir},verify-peer=@var{on|off},passwordid=@var{id} Creates a TLS anonymous credentials object, which can be used to provide TLS support on network backends. The @option{id} parameter is a unique @@ -3654,6 +3654,12 @@ in PEM format, in filenames @var{ca-cert.pem}, @var{ca-crl.pem} (optional), @var{server-cert.pem} (only servers), @var{server-key.pem} (only servers), @var{client-cert.pem} (only clients), and @var{client-key.pem} (only clients). +For the @var{server-key.pem} and @var{client-key.pem} files which +contain sensitive private keys, it is possible to use an encrypted +version by providing the @var{passwordid} parameter. This provides +the ID of a previously created @code{secret} object containing the +password for decryption. + @item -object filter-buffer,id=@var{id},netdev=@var{netdevid},interval=@var{t}[,queue=@var{all|rx|tx}] Interval @var{t} can't be 0, this filter batches the packet delivery: all -- cgit v1.1