2015-09-02 11:57:27 +02:00
|
|
|
crypto-obj-y = init.o
|
|
|
|
|
crypto-obj-y += hash.o
|
2016-03-11 19:09:22 +01:00
|
|
|
crypto-obj-$(CONFIG_NETTLE) += hash-nettle.o
|
|
|
|
|
crypto-obj-$(if $(CONFIG_NETTLE),n,$(CONFIG_GCRYPT)) += hash-gcrypt.o
|
2016-07-05 12:45:42 +02:00
|
|
|
crypto-obj-$(if $(CONFIG_NETTLE),n,$(if $(CONFIG_GCRYPT),n,y)) += hash-glib.o
|
2016-12-13 11:42:56 +01:00
|
|
|
crypto-obj-y += hmac.o
|
|
|
|
|
crypto-obj-$(CONFIG_NETTLE) += hmac-nettle.o
|
|
|
|
|
crypto-obj-$(CONFIG_GCRYPT_HMAC) += hmac-gcrypt.o
|
|
|
|
|
crypto-obj-$(if $(CONFIG_NETTLE),n,$(if $(CONFIG_GCRYPT_HMAC),n,y)) += hmac-glib.o
|
2015-09-02 11:57:27 +02:00
|
|
|
crypto-obj-y += aes.o
|
|
|
|
|
crypto-obj-y += desrfb.o
|
|
|
|
|
crypto-obj-y += cipher.o
|
2017-07-14 20:04:05 +02:00
|
|
|
crypto-obj-$(CONFIG_AF_ALG) += afalg.o
|
2017-07-14 20:04:06 +02:00
|
|
|
crypto-obj-$(CONFIG_AF_ALG) += cipher-afalg.o
|
2017-07-14 20:04:07 +02:00
|
|
|
crypto-obj-$(CONFIG_AF_ALG) += hash-afalg.o
|
crypto: Add tls-cipher-suites object
On the host OS, various aspects of TLS operation are configurable.
In particular it is possible for the sysadmin to control the TLS
cipher/protocol algorithms that applications are permitted to use.
* Any given crypto library has a built-in default priority list
defined by the distro maintainer of the library package (or by
upstream).
* The "crypto-policies" RPM (or equivalent host OS package)
provides a config file such as "/etc/crypto-policies/config",
where the sysadmin can set a high level (library-independent)
policy.
The "update-crypto-policies --set" command (or equivalent) is
used to translate the global policy to individual library
representations, producing files such as
"/etc/crypto-policies/back-ends/*.config". The generated files,
if present, are loaded by the various crypto libraries to
override their own built-in defaults.
For example, the GNUTLS library may read
"/etc/crypto-policies/back-ends/gnutls.config".
* A management application (or the QEMU user) may overide the
system-wide crypto-policies config via their own config, if
they need to diverge from the former.
Thus the priority order is "QEMU user config" > "crypto-policies
system config" > "library built-in config".
Introduce the "tls-cipher-suites" object for exposing the ordered
list of permitted TLS cipher suites from the host side to the
guest firmware, via fw_cfg. The list is represented as an array
of bytes.
The priority at which the host-side policy is retrieved is given
by the "priority" property of the new object type. For example,
"priority=@SYSTEM" may be used to refer to
"/etc/crypto-policies/back-ends/gnutls.config" (given that QEMU
uses GNUTLS).
The firmware uses the IANA_TLS_CIPHER array for configuring
guest-side TLS, for example in UEFI HTTPS Boot.
[Description from Daniel P. Berrangé, edited by Laszlo Ersek.]
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200623172726.21040-2-philmd@redhat.com>
2018-10-11 20:21:11 +02:00
|
|
|
crypto-obj-$(CONFIG_GNUTLS) += tls-cipher-suites.o
|
2015-03-13 18:39:26 +01:00
|
|
|
crypto-obj-y += tlscreds.o
|
crypto: introduce new module for TLS anonymous credentials
Introduce a QCryptoTLSCredsAnon class which is used to
manage anonymous TLS credentials. Use of this class is
generally discouraged since it does not offer strong
security, but it is required for backwards compatibility
with the current VNC server implementation.
Simple example CLI configuration:
$QEMU -object tls-creds-anon,id=tls0,endpoint=server
Example using pre-created diffie-hellman parameters
$QEMU -object tls-creds-anon,id=tls0,endpoint=server,\
dir=/path/to/creds/dir
The 'id' value in the -object args will be used to associate the
credentials with the network services. For example, when the VNC
server is later converted it would use
$QEMU -object tls-creds-anon,id=tls0,.... \
-vnc 127.0.0.1:1,tls-creds=tls0
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
2015-03-13 18:39:26 +01:00
|
|
|
crypto-obj-y += tlscredsanon.o
|
crypto: Implement TLS Pre-Shared Keys (PSK).
Pre-Shared Keys (PSK) is a simpler mechanism for enabling TLS
connections than using certificates. It requires only a simple secret
key:
$ mkdir -m 0700 /tmp/keys
$ psktool -u rjones -p /tmp/keys/keys.psk
$ cat /tmp/keys/keys.psk
rjones:d543770c15ad93d76443fb56f501a31969235f47e999720ae8d2336f6a13fcbc
The key can be secretly shared between clients and servers. Clients
must specify the directory containing the "keys.psk" file and a
username (defaults to "qemu"). Servers must specify only the
directory.
Example NBD client:
$ qemu-img info \
--object tls-creds-psk,id=tls0,dir=/tmp/keys,username=rjones,endpoint=client \
--image-opts \
file.driver=nbd,file.host=localhost,file.port=10809,file.tls-creds=tls0,file.export=/
Example NBD server using qemu-nbd:
$ qemu-nbd -t -x / \
--object tls-creds-psk,id=tls0,endpoint=server,dir=/tmp/keys \
--tls-creds tls0 \
image.qcow2
Example NBD server using nbdkit:
$ nbdkit -n -e / -fv \
--tls=on --tls-psk=/tmp/keys/keys.psk \
file file=disk.img
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-07-03 10:03:03 +02:00
|
|
|
crypto-obj-y += tlscredspsk.o
|
2015-03-13 18:39:26 +01:00
|
|
|
crypto-obj-y += tlscredsx509.o
|
2015-03-02 18:23:31 +01:00
|
|
|
crypto-obj-y += tlssession.o
|
2020-05-25 13:16:53 +02:00
|
|
|
crypto-obj-y += secret_common.o
|
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 <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-10-14 10:58:38 +02:00
|
|
|
crypto-obj-y += secret.o
|
2020-05-25 13:19:12 +02:00
|
|
|
crypto-obj-$(CONFIG_SECRET_KEYRING) += secret_keyring.o
|
2015-10-14 14:14:04 +02:00
|
|
|
crypto-obj-y += pbkdf.o
|
2018-07-18 12:55:05 +02:00
|
|
|
crypto-obj-$(CONFIG_NETTLE) += pbkdf-nettle.o
|
|
|
|
|
crypto-obj-$(if $(CONFIG_NETTLE),n,$(CONFIG_GCRYPT)) += pbkdf-gcrypt.o
|
2019-08-06 15:12:18 +02:00
|
|
|
crypto-obj-$(if $(CONFIG_NETTLE),n,$(if $(CONFIG_GCRYPT),n,y)) += pbkdf-stub.o
|
2015-10-15 13:35:28 +02:00
|
|
|
crypto-obj-y += ivgen.o
|
|
|
|
|
crypto-obj-y += ivgen-essiv.o
|
|
|
|
|
crypto-obj-y += ivgen-plain.o
|
|
|
|
|
crypto-obj-y += ivgen-plain64.o
|
2015-10-23 17:14:25 +02:00
|
|
|
crypto-obj-y += afsplit.o
|
2019-10-14 18:28:27 +02:00
|
|
|
crypto-obj-$(CONFIG_QEMU_PRIVATE_XTS) += xts.o
|
2015-10-24 12:44:13 +02:00
|
|
|
crypto-obj-y += block.o
|
|
|
|
|
crypto-obj-y += block-qcow.o
|
2015-10-24 12:55:48 +02:00
|
|
|
crypto-obj-y += block-luks.o
|
2015-09-02 11:57:27 +02:00
|
|
|
|
2019-07-29 15:55:47 +02:00
|
|
|
util-obj-$(CONFIG_GCRYPT) += random-gcrypt.o
|
|
|
|
|
util-obj-$(if $(CONFIG_GCRYPT),n,$(CONFIG_GNUTLS)) += random-gnutls.o
|
2020-05-20 15:20:23 +02:00
|
|
|
util-obj-$(if $(CONFIG_GCRYPT),n,$(if $(CONFIG_GNUTLS),n,$(CONFIG_RNG_NONE))) += random-none.o
|
|
|
|
|
util-obj-$(if $(CONFIG_GCRYPT),n,$(if $(CONFIG_GNUTLS),n,$(if $(CONFIG_RNG_NONE),n,y))) += random-platform.o
|
2019-07-29 15:55:47 +02:00
|
|
|
util-obj-y += aes.o init.o
|
