aboutsummaryrefslogtreecommitdiff
path: root/crypto
AgeCommit message (Collapse)AuthorFilesLines
2015-09-15crypto: introduce new module for handling TLS sessionsDaniel P. Berrange2-0/+575
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: Daniel P. Berrange <berrange@redhat.com>
2015-09-15crypto: add sanity checking of TLS x509 credentialsDaniel P. Berrange1-0/+546
If the administrator incorrectly sets up their x509 certificates, the errors seen at runtime during connection attempts are very obscure and difficult to diagnose. This has been a particular problem for people using openssl to generate their certificates instead of the gnutls certtool, because the openssl tools don't turn on the various x509 extensions that gnutls expects to be present by default. This change thus adds support in the TLS credentials object to sanity check the certificates when QEMU first loads them. This gives the administrator immediate feedback for the majority of common configuration mistakes, reducing the pain involved in setting up TLS. The code is derived from equivalent code that has been part of libvirt's TLS support and has been seen to be valuable in assisting admins. It is possible to disable the sanity checking, however, via the new 'sanity-check' property on the tls-creds object type, with a value of 'no'. Unit tests are included in this change to verify the correctness of the sanity checking code in all the key scenarios it is intended to cope with. As part of the test suite, the pkix_asn1_tab.c from gnutls is imported. This file is intentionally copied from the (long since obsolete) gnutls 1.6.3 source tree, since that version was still under GPLv2+, rather than the GPLv3+ of gnutls >= 2.0. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-09-15crypto: introduce new module for TLS x509 credentialsDaniel P. Berrange2-0/+264
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: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2015-09-15crypto: introduce new module for TLS anonymous credentialsDaniel P. Berrange2-0/+224
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-09-15crypto: introduce new base module for TLS credentialsDaniel P. Berrange3-0/+294
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: Daniel P. Berrange <berrange@redhat.com>
2015-09-15crypto: move crypto objects out of libqemuutil.laDaniel P. Berrange1-5/+8
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: Daniel P. Berrange <berrange@redhat.com>
2015-07-27crypto: fix built-in AES decrypt functionDaniel P. Berrange1-4/+4
The qcrypto_cipher_decrypt_aes method was using the wrong key material, and passing the wrong mode. This caused it to incorrectly decrypt ciphertext. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1437740634-6261-1-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-07-20crypto: Fix aes_decrypt_wrapper()Kevin Wolf1-1/+1
Commit d3462e3 broke qcow2's encryption functionality by using encrypt instead of decrypt in the wrapper function it introduces. This was found by qemu-iotests case 134. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
2015-07-16crypto: avoid undefined behavior in nettle callsRadim Krčmář1-4/+39
Calling a function pointer that was cast from an incompatible function results in undefined behavior. 'void *' isn't compatible with 'struct XXX *', so we can't cast to nettle_cipher_func, but have to provide a wrapper. (Conversion from 'void *' to 'struct XXX *' might require computation, which won't be done if we drop argument's true type, and pointers can have different sizes so passing arguments on stack would bug.) Having two different prototypes based on nettle version doesn't make this solution any nicer. Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com> Message-Id: <1437062641-12684-3-git-send-email-rkrcmar@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-07-16crypto: fix build with nettle >= 3.0.0Radim Krčmář1-6/+10
In nettle 3, cbc_encrypt() accepts 'nettle_cipher_func' instead of 'nettle_crypt_func' and these two differ in 'const' qualifier of the first argument. The build fails with: In file included from crypto/cipher.c:71:0: ./crypto/cipher-nettle.c: In function ‘qcrypto_cipher_encrypt’: ./crypto/cipher-nettle.c:154:38: error: passing argument 2 of ‘nettle_cbc_encrypt’ from incompatible pointer type cbc_encrypt(ctx->ctx_encrypt, ctx->alg_encrypt, ^ In file included from ./crypto/cipher-nettle.c:24:0, from crypto/cipher.c:71: /usr/include/nettle/cbc.h:48:1: note: expected ‘void (*)(const void *, size_t, uint8_t *, const uint8_t *) but argument is of type ‘void (*)( void *, size_t, uint8_t *, const uint8_t *) To allow both versions, we switch to the new definition and #if typedef it for old versions. Signed-off-by: Radim Krčmář <rkrcmar@redhat.com> Message-Id: <1436548682-9315-2-git-send-email-rkrcmar@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-07-09crypto: fix builtin qcrypto_cipher_freePaolo Bonzini1-1/+3
This was dereferencing a pointer before checking if it was NULL. Reported-by: Christian Borntraeger <borntraeger@de.ibm.com> Reported-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-07-08crypto: add a nettle cipher implementationDaniel P. Berrange2-2/+210
If we are linking to gnutls already and gnutls is built against nettle, then we should use nettle as a cipher backend in preference to our built-in backend. This will be used when linking against some GNUTLS 2.x versions and all GNUTLS 3.x versions. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1435770638-25715-7-git-send-email-berrange@redhat.com> [Change "#elif" to "#elif defined". - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-07-08crypto: add a gcrypt cipher implementationDaniel P. Berrange3-0/+308
If we are linking to gnutls already and gnutls is built against gcrypt, then we should use gcrypt as a cipher backend in preference to our built-in backend. This will be used when linking against GNUTLS 1.x and many GNUTLS 2.x versions. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1435770638-25715-6-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-07-08crypto: introduce generic cipher API & built-in implementationDaniel P. Berrange3-0/+448
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: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1435770638-25715-5-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-07-07crypto: move built-in D3DES implementation into crypto/Daniel P. Berrange2-0/+416
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: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1435770638-25715-4-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-07-07crypto: move built-in AES implementation into crypto/Daniel P. Berrange2-0/+1653
To prepare for a generic internal cipher API, move the built-in AES implementation into the crypto/ directory Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1435770638-25715-3-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2015-07-07crypto: introduce new module for computing hash digestsDaniel P. Berrange3-0/+262
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: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1435770638-25715-2-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>