When the BER encoded BITRSTRING field has a zero length, then skipping
the unused-bits byte that a BITRSTING normally contains will cause a
underflow and thus may cause an out of bounds read by the caller of
sk_ep11_parse_spki().
Assisted-by: IBM Bob:2.0.0
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Check for the size of struct cca_rsa_pub_key_section, instead of
struct cca_ec_pub_key_section.
Assisted-by: IBM Bob:2.0.0
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When EVP_PKEY_get0_EC_KEY(), EC_KEY_set_ex_data(), EVP_PKEY_get0_RSA()
or RSA_set_ex_data() fails, the function returns -EIO without freeing
the data struct or the data->key_blob that were allocated before.
Assisted-by: IBM Bob:2.0.0
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Field spki_size is defined as size_t, so it can never be negative.
Before the check, sk_ep11_valid_ep11_blob() ensures that hdr->len is
never greater than key_token_length, so the subtraction can never
overflow the result, but it still can be zero.
Assisted-by: IBM Bob:2.0.0
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
For long-length field encoding, check if the number of length bytes
exceed the data size.
Assisted-by: IBM Bob:2.0.0
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
A malformed CCA key token with a zero size section can cause an endless
loop in sk_cca_get_pka_section().
Assisted-by: IBM Bob:2.0.0
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Array element key_value_structure.public_exponent[0] is written twice,
but key_value_structure.public_exponent[1] is not set, leading to a
wrong public exponent value (i.e. 0x01) in the key value structure.
CCA key generation will fail is this case.
Assisted-by: IBM Bob:2.0.0
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Functions SK_CCA_generate_ec_key_pair(), SK_CCA_generate_ec_key_pair(),
SK_EP11_generate_ec_key_pair() and SK_EP11_generate_rsa_key_pair() are
supposed to allow parameter key_token to be NULL. In this case the
required buffer size is returned in key_token_length only.
This size query does not work because the parameter checking rejects
the call with a NULL key_token returning -EINVAL.
Currently the size query is not used by any known caller, but lets
correct it anyway.
Assisted-by: IBM Bob:2.0.0
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When creating or writing files, make sure that the file is not a
sysmlink. Such files created by libseckey are typically stored inside
the zkey repository and the owner and mode of them are changed to.
allow read/write for the owner user and the 'zkeyadm' group. It
would allow a symlink-following attack if the file being created are
symlinks. Make sure to open such files with the 'O_NOFOLLOW' flag.
Assisted-by: IBM Bob:2.0.0
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The previous function, EVP_PKEY_meth_remove(), was deprecated in OpenSSL
3.0 and fully removed in OpenSSL 4.0. As a result, it fails detection of
OpenSSL 1.1+ if OpenSSL 4 is present.
Closes: https://github.com/ibm-s390-linux/s390-tools/pull/204
[seiden@linux.ibm.com: Add link to GH PR]
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
With OpenSSL 4.0.0 function X509_NAME_get_entry() returns a const pointer.
Make the local variable also const to avoid compile warnings like:
warning: assignment discards ‘const’ qualifier from pointer target type
[-Wdiscarded-qualifiers]
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Re-enciphering an EP11 secure key may fail with an error message like:
"zkey-cryptsetup: Failed to re-encipher the secure volume key for device
'<device>'"
or
"zkey: Failed to re-encipher '<key>' from CURRENT to NEW master key"
or similar.
The verbose messages show the following debug message:
"Command XCP_ADM_REENCRYPT failed. rc = 0x20"
This is due to uninitialized variables, which might cause the EP11 admin
request to contain garbage data, causing it to fail with CKR_DATA_INVALID
(0x20).
Fixes: 0be7efc956 ("zkey: Add support for re-enciphering EP11 secure keys")
Fixes: 4e2ebe0370 ("libseckey: Fix re-enciphering of EP11 secure key")
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Joerg Schmidbauer <jschmidb@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
OpenSSL function i2d_ECDSA_SIG() returns a negative value in case of
an error, so check the returned length for <= zero to detect an error.
Reported-by: Holger Dengler <dengler@linux.ibm.com>
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The provider functions OSSL_FUNC_keymgmt_import_types() and
OSSL_FUNC_keymgmt_export_types() do not get the provider context passed.
However, the implementation of these functions in the secure key provider
need the provider context to pass the call to the default provider
and append some of its own types to the result.
Up to now, the provider context was obtained using a global variable
holding the secure key provider handle. This may not be save if multiple
instances of the provider exist.
Just recently OpenSSL added support for an extended form of these
functions, namely OSSL_FUNC_keymgmt_import_types_ex() and
OSSL_FUNC_keymgmt_export_types_ex(), that get the provider context passed
as argument. Make use of these new functions, if compiled against an
OpenSSL version that supports them. For older OpenSSL versions still use
the global variable as before.
See OpenSSL commit 5e3b84505e
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
With parameter OSSL_ASYM_CIPHER_PARAM_IMPLICIT_REJECTION one can enable or
disable the implicit rejection mechanism for RSA PKCS#1 v1.5 decryption.
For the default provider, this is enabled by default.
We do not support implicit rejection so far, so disable it for the
default provider operation context when the key contains an RSA secure key,
and reject to set it to anything else then 0 (disabled).
See OpenSSL commit 5ab3ec1bb1
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Since OpenSSL 3.1 a new RSA-PSS salt length constant exists to select
the maximum possible salt length based on the RSA-PSS parameters and the
digest used: OSSL_PKEY_RSA_PSS_SALT_LEN_AUTO_DIGEST_MAX
This is the default salt length when no other salt length is set by
the caller.
In contrast to OSSL_PKEY_RSA_PSS_SALT_LEN_MAX, OSSL_PKEY_RSA_PSS_SALT_LEN_AUTO_DIGEST_MAX
also ensures that the resulting salt length is not larger than the used
digest size. The salt length calculated with OSSL_PKEY_RSA_PSS_SALT_LEN_MAX
may be larger than the digest size, dependent on the RSA-PSS parameters.
FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection
5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the
salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of
the hash function output block (in bytes)."
See OpenSSL commit 6c73ca4a2f
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
With parameter OSSL_SIGNATURE_PARAM_NONCE_TYPE one can choose to generate
a deterministic signature, i.e. using a deterministic nonce K.
We do not support that so far, so reject to set the nonce type to
anything other than 0 (random nonce K).
See OpenSSL commit f3090fc710
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The provider functions are passed to OpenSSL in the dispatch array
casted to 'void (*)(void)', so they can not be type checked by the
compiler. Add function prototypes using the OpenSSL provided
function typedefs to allow the compiler to check the function
signatures.
No functional change.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
OpenSSL commit ee22a3741e3fc27c981e7f7e9bcb8d3342b0c65a changed the
OpenSSL provider's keymgmt_match() function to be not so strict with
the selector bits in regards to matching different key parts.
Adapt the secure key provider's match function accordingly.
This means, that if the public key is selected to be matched, and
the public key matches (together with any also selected parameters),
then the private key is no longer checked, although it may also be
selected to be matched. This is according to how the OpenSSL function
EVP_PKEY_eq() is supposed to behave.
OpenSSL function SSL_CTX_use_PrivateKey() calls the providers match
function to check if the private key specified matches the public key
of the certificate using EVP_PKEY_eq(). EVP_PKEY_eq() includes the
private key into the selector bits here, although the certificate
only contains the public key part.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The re-enciphering of EP11 asymmetric secure keys does not work.
First, the result of the re-encipher operation of the private key
part must be copied back into the user supplied key token buffer.
Second, the public key part, i.e. the MACed SubjectPublicKeyInfo
(SPKI) structure must also be re-enciphered (i.e. re-MACed), since
the MAC is calculated with the EP11 master key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The libseckey is a secure key library to perform secure key operations
with OpenSSL. It provides a framework to create OpenSSL PKEYs with a
secure key attached. Such a PKEY contains the public key parts in clear,
but the private key as secure key blob. Only the private key operations
are actually performed with the secure key, public key operations are
performed in software by OpenSSL. It supports CCA and EP11 secure
keys for RSA and ECC crypto operations.
Because many PKEY method related functions are deprecated since OpenSSL
3.0, two versions of the OpenSSL secure key support are needed. One (using
a PKEY method override) for OpenSSL 1.1.1, and another one (using an own
OpenSSL provider) for OpenSSL 3.0 and later. The desired implementation is
selected automatically at compile time, using OpenSSL version defines. The
interface of both implementations is the same, so a user does not need to
care which one is used.
Reviewed-by: Juergen Christ <jchrist@linux.ibm.com>
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
