- 17 3月, 2016 3 次提交
-
-
由 Daniel P. Berrange 提交于
There are a number of different algorithms that can be used to generate initialization vectors for disk encryption. This introduces a simple internal QCryptoBlockIV object to provide a consistent internal API to the different algorithms. The initially implemented algorithms are 'plain', 'plain64' and 'essiv', each matching the same named algorithm provided by the Linux kernel dm-crypt driver. Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NFam Zheng <famz@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The LUKS data format includes use of PBKDF2 (Password-Based Key Derivation Function). The Nettle library can provide an implementation of this, but we don't want code directly depending on a specific crypto library backend. Introduce a new include/crypto/pbkdf.h header which defines a QEMU API for invoking PBKDK2. The initial implementations are backed by nettle & gcrypt, which are commonly available with distros shipping GNUTLS. The test suite data is taken from the cryptsetup codebase under the LGPLv2.1+ license. This merely aims to verify that whatever backend we provide for this function in QEMU will comply with the spec. Reviewed-by: NFam Zheng <famz@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
There are three backend impls provided. The preferred is gnutls, which is backed by nettle in modern distros. The gcrypt impl is provided for cases where QEMU build against gnutls is disabled, but crypto is still desired. No nettle impl is provided, since it is non-trivial to use the nettle APIs for random numbers. Users of nettle should ensure gnutls is enabled for QEMU. Reviewed-by: NFam Zheng <famz@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 19 12月, 2015 1 次提交
-
-
由 Daniel P. Berrange 提交于
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: NEric Blake <eblake@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 15 9月, 2015 5 次提交
-
-
由 Daniel P. Berrange 提交于
Introduce a QCryptoTLSSession object that will encapsulate all the code for setting up and using a client/sever TLS session. This isolates the code which depends on the gnutls library, avoiding #ifdefs in the rest of the codebase, as well as facilitating any possible future port to other TLS libraries, if desired. It makes use of the previously defined QCryptoTLSCreds object to access credentials to use with the session. It also includes further unit tests to validate the correctness of the TLS session handshake and certificate validation. This is functionally equivalent to the current TLS session handling code embedded in the VNC server, and will obsolete it. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Introduce a QCryptoTLSCredsX509 class which is used to manage x509 certificate TLS credentials. This will be the preferred credential type offering strong security characteristics Example CLI configuration: $QEMU -object tls-creds-x509,id=tls0,endpoint=server,\ dir=/path/to/creds/dir,verify-peer=yes 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-x509,id=tls0,.... \ -vnc 127.0.0.1:1,tls-creds=tls0 Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Daniel P. Berrange 提交于
Introduce a QCryptoTLSCreds class to act as the base class for storing TLS credentials. This will be later subclassed to provide handling of anonymous and x509 credential types. The subclasses will be user creatable objects, so instances can be created & deleted via 'object-add' and 'object-del' QMP commands respectively, or via the -object command line arg. If the credentials cannot be initialized an error will be reported as a QMP reply, or on stderr respectively. The idea is to make it possible to represent and manage TLS credentials independently of the network service that is using them. This will enable multiple services to use the same set of credentials and minimize code duplication. A later patch will convert the current VNC server TLS code over to use this object. The representation of credentials will be functionally equivalent to that currently implemented in the VNC server with one exception. The new code has the ability to (optionally) load a pre-generated set of diffie-hellman parameters, if the file dh-params.pem exists, whereas the current VNC server will always generate them on startup. This is beneficial for admins who wish to avoid the (small) time sink of generating DH parameters at startup and/or avoid depleting entropy. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Future patches will be adding more crypto related APIs which rely on QOM infrastructure. This creates a problem, because QOM relies on library constructors to register objects. When you have a file in a static .a library though which is only referenced by a constructor the linker is dumb and will drop that file when linking to the final executable :-( The only workaround for this is to link the .a library to the executable using the -Wl,--whole-archive flag, but this creates its own set of problems because QEMU is relying on lazy linking for libqemuutil.a. Using --whole-archive majorly increases the size of final executables as they now contain a bunch of object code they don't actually use. The least bad option is to thus not include the crypto objects in libqemuutil.la, and instead define a crypto-obj-y variable that is referenced directly by all the executables that need this code (tools + softmmu, but not qemu-ga). We avoid pulling entire of crypto-obj-y into the userspace emulators as that would force them to link to gnutls too, which is not required. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 08 7月, 2015 1 次提交
-
-
由 Daniel P. Berrange 提交于
Introduce a generic cipher API and an implementation of it that supports only the built-in AES and DES-RFB algorithms. The test suite checks the supported algorithms + modes to validate that every backend implementation is actually correctly complying with the specs. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> Message-Id: <1435770638-25715-5-git-send-email-berrange@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 07 7月, 2015 3 次提交
-
-
由 Daniel P. Berrange 提交于
To prepare for a generic internal cipher API, move the built-in D3DES implementation into the crypto/ directory. This is not in fact a normal D3DES implementation, it is D3DES with double & triple length modes removed, and the key bytes in reversed bit order. IOW it is crippled specifically for the "benefit" of RFB, so call the new files desrfb.c instead of d3des.c to make it clear that it isn't a generally useful impl. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> Message-Id: <1435770638-25715-4-git-send-email-berrange@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Daniel P. Berrange 提交于
To prepare for a generic internal cipher API, move the built-in AES implementation into the crypto/ directory Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> Message-Id: <1435770638-25715-3-git-send-email-berrange@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Daniel P. Berrange 提交于
Introduce a new crypto/ directory that will (eventually) contain all the cryptographic related code. This initially defines a wrapper for initializing gnutls and for computing hashes with gnutls. The former ensures that gnutls is guaranteed to be initialized exactly once in QEMU regardless of CLI args. The block quorum code currently fails to initialize gnutls so it only works by luck, if VNC server TLS is not requested. The hash APIs avoids the need to litter the rest of the code with preprocessor checks and simplifies callers by allocating the correct amount of memory for the requested hash. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> Message-Id: <1435770638-25715-2-git-send-email-berrange@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-