1. Deny SHA-1 signature verification in FIPS provider
For RHEL, we already disable SHA-1 signatures by default in the default
provider, so it is unexpected that the FIPS provider would have a more
lenient configuration in this regard. Additionally, we do not think
continuing to accept SHA-1 signatures is a good idea due to the
published chosen-prefix collision attacks.
As a consequence, disable verification of SHA-1 signatures in the FIPS
provider.
This requires adjusting a few tests that would otherwise fail:
- 30-test_acvp: Remove the test vectors that use SHA-1.
- 30-test_evp: Mark tests in evppkey_rsa_common.txt and
evppkey_ecdsa.txt that use SHA-1 digests as "Availablein = default",
which will not run them when the FIPS provider is enabled.
- 80-test_cms: Re-generate all certificates in test/smime-certificates
using the mksmime-certs.sh script, because most of them were signed
with SHA-1 and thus fail verification in the FIPS provider. Keep
smec3.pem, which was used to sign static test data in
test/recipes/80-test_cms_data/ciphertext_from_1_1_1.cms, which would
otherwise no longer verify. Note that smec3.pem was signed with
a smroot.pem, which was now re-generated. This does not affect the
test.
Fix some other tests by explicitly running them in the default
provider, where SHA-1 is available.
- 80-test_ssl_old: Skip tests that rely on SSLv3 and SHA-1 when run with
the FIPS provider.
2. Disable EVP_PKEY_{sign,verify} in FIPS provider
The APIs to compute both digest and signature in one step,
EVP_DigestSign*/EVP_DigestVerify* and EVP_Sign*/EVP_Verify*, should be
used instead. This ensures that the digest is computed inside of the
FIPS module, and that only approved digests are used.
Update documentation for EVP_PKEY_{sign,verify} to reflect this.
Since the KATs use EVP_PKEY_sign/EVP_PKEY_verify, modify the tests to
set the OSSL_SIGNATURE_PARAM_KAT parameter and use EVP_PKEY_sign_init_ex
and EVP_PKEY_verify_init_ex where these parameters can be passed on
creation and allow EVP_PKEY_sign/EVP_PKEY_verify when this parameter is
set and evaluates as true.
Move tests that use the EVP_PKEY API to only run in the default
provider, since they would fail in the FIPS provider. This also affects
a number of CMS tests where error handling is insufficient and failure
to sign would only show up when verifying the CMS structure due to
a parse error.
Resolves: rhbz#2087147
Signed-off-by: Clemens Lang <cllang@redhat.com>
Include a hash of specfile, patches, and sources in the FIPS module
version. This should allow us to uniquely identify a build that we do,
so that we can be sure which specific binary is being submitted for
validation and was certified.
The previous solution used $(date +%Y%m%d), which had some risks related
to build server timezone and build date differences on different
architectures.
Resolves: rhbz#2070550
Signed-off-by: Clemens Lang <cllang@redhat.com>
Invocations of EVP_PKEY_CTX_set_rsa_padding(RSA_PKCS1_PSS_PADDING)
before setting an allowed digest with EVP_PKEY_CTX_set_signature_md()
would fail with SHA-1 use in signatures disabled, because OpenSSL's
internal default for the digest was SHA-1.
This isn't documented in any of the manpages, hence we expect users to
always call both EVP_PKEY_CTX_set_rsa_padding() and
EVP_PKEY_CTX_set_signature_md(). We do not want set_rsa_padding() to
fail if users set a non-SHA-1 signature algorithm after setting the
padding mode, though, so change the internal default to SHA-256 if SHA-1
is disabled.
Resolves: rhbz#2062640
We want legacy policy to be able to talk to older RHEL that only
supports SHA1 signature algorithms, so allow SHA1 signatures even in
seclevel 2 if rh-allow-sha1-signatures is set to yes.
Resolves: rhbz#2060510
Signed-off-by: Clemens Lang <cllang@redhat.com>
providers/implementations/signature/{ec,}dsa_sig.c accept a NID_undef
digest, so to prevent SHA1 from working with ECDSA and DSA, we must
return a negative value in securitycheck.c.
Resolves: rhbz#2031742
The EVP_DigestSign API is used in TLS to compute a SHA1 HMAC, which is
OK from our point of view, but was blocked so far. Modify
0049-Selectively-disallow-SHA1-signatures.patch to check the EVP_PKEY
type for HMAC (and TLS1-PRF and HKDF), and allow SHA1 for these cases.
Note that TLS1.1 signs a MD5-SHA1 hash with a private key, which does
not work with rh-allow-sha1-signatures = no, so the minimum TLS version
will be TLS 1.2.
Resolves: rhbz#2031742
Signed-off-by: Clemens Lang <cllang@redhat.com>
Dmitry Belyavskiy
Clemens Lang
Peter Robinson
Sahana Prasad