Implementation Guidance for FIPS 140-3 and the Cryptographic Module
Verification Program, Section C.H requires guarantees about the
uniqueness of key/iv pairs, and proposes a few approaches to ensure
this. Provide an indicator for option 2 "The IV may be generated
internally at its entirety randomly."
Resolves: rhbz#2175868
Signed-off-by: Clemens Lang <cllang@redhat.com>
FIPS requires a number of restrictions on the parameters of the various
key derivation functions implemented in OpenSSL. The KDFs that use
digest algorithms usually should not allow SHAKE (due to FIPS 140-3 IG
C.C). Additionally, some application-specific KDFs have further
restrictions defined in SP 800-135r1.
Generally, all KDFs shall use a key-derivation key length of at least
112 bits due to SP 800-131Ar2 section 8. Additionally any use of a KDF
to generate and output length of less than 112 bits will also set the
indicator to unapproved.
Add explicit indicators to all KDFs usable in FIPS mode except for
PBKDF2 (which has its specific FIPS limits already implemented). The
indicator can be queried using EVP_KDF_CTX_get_params() after setting
the required parameters and keys for the KDF.
Our FIPS provider implements SHA1, SHA2 (both -256 and -512, and the
truncated variants -224 and -384) and SHA3 (-256 and -512, and the
truncated versions -224 and -384), as well as SHAKE-128 and -256.
The SHAKE functions are generally not allowed in KDFs. For the rest, the
support matrix is:
KDF | SHA-1 | SHA-2 | SHA-2 truncated | SHA-3 | SHA-3 truncated
==========================================================================
KBKDF | x | x | x | x | x
HKDF | x | x | x | x | x
TLS1PRF | | SHA-{256,384,512} only | |
SSHKDF | x | x | x | |
SSKDF | x | x | x | x | x
X9.63KDF | | x | x | x | x
X9.42-ASN1 | x | x | x | x | x
TLS1.3PRF | | SHA-{256,384} only | |
Signed-off-by: Clemens Lang <cllang@redhat.com>
Resolves: rhbz#2175860 rhbz#2175864
This was already blocked for encryption and for both signature creation
and verification in RSASSA-PSS, but RSA-OAEP decryption was missing.
Resolves: rhbz#2142121
Signed-off-by: Clemens Lang <cllang@redhat.com>
The previous state of the patch did not work correctly when used with
negative salt lengths, which OpenSSL uses a magic values. Setting the
saltlength to max would yield an approved state in the indicator, while
it is not approved.
Additionally, update the patch to change the default PSS salt length
with the current state of discussion upstream (see
https://github.com/openssl/openssl/pull/19724).
Resolves: rhbz#2142087
Signed-off-by: Clemens Lang <cllang@redhat.com>
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)."
It is not exactly clear from this text whether hLen refers to the
message digest or the hash function used for the mask generation
function MGF1. PKCS#1 v2.1 suggests it is the former:
| Typical salt lengths in octets are hLen (the length of the output of
| the hash function Hash) and 0. In both cases the security of
| RSASSA-PSS can be closely related to the hardness of inverting RSAVP1.
| Bellare and Rogaway [4] give a tight lower bound for the security of
| the original RSA-PSS scheme, which corresponds roughly to the former
| case, while Coron [12] gives a lower bound for the related Full Domain
| Hashing scheme, which corresponds roughly to the latter case. In [13]
| Coron provides a general treatment with various salt lengths ranging
| from 0 to hLen; see [27] for discussion. See also [31], which adapts
| the security proofs in [4][13] to address the differences between the
| original and the present version of RSA-PSS as listed in Note 1 above.
Since OpenSSL defaults to creating signatures with the maximum salt
length, blocking the use of longer salts would probably lead to
significant problems in practice. Instead, introduce an explicit
indicator that can be obtained from the EVP_PKEY_CTX object using
EVP_PKEY_CTX_get_params() with the
OSSL_SIGNATURE_PARAM_REDHAT_FIPS_INDICATOR
parameter.
Change the default automatic behavior when signing to use at most the
digest size as salt length.
Signed-off-by: Clemens Lang <cllang@redhat.com>
Resolves: rhbz#2144012
The Implementation Guidance for FIPS 140-3 says in section D.N
"Password-Based Key Derivation for Storage Applications" that "the
vendor shall document in the module’s Security Policy the length of
a password/passphrase used in key derivation and establish an upper
bound for the probability of having this parameter guessed at random.
This probability shall take into account not only the length of the
password/passphrase, but also the difficulty of guessing it. The
decision on the minimum length of a password used for key derivation is
the vendor’s, but the vendor shall at a minimum informally justify the
decision."
We are choosing a minimum password length of 8 bytes, because NIST's
ACVP testing uses passwords as short as 8 bytes, and requiring longer
passwords combined with an implicit indicator (i.e., returning an error)
would cause the module to fail ACVP testing.
Signed-off-by: Clemens Lang <cllang@redhat.com>
Resolves: rhbz#2144003
NIST SP 800-131Ar2, table 9 "Approval Status of MAC Algorithms"
specifies key lengths < 112 bytes are disallowed for HMAC generation and
are legacy use for HMAC verification.
Add an explicit indicator that will mark shorter key lengths as
unsupported. The indicator can be queries from the EVP_MAC_CTX object
using EVP_MAC_CTX_get_params() with the
OSSL_MAC_PARAM_REDHAT_FIPS_INDICATOR
parameter.
Signed-off-by: Clemens Lang <cllang@redhat.com>
Resolves: rhbz#2144000
NIST SP 800-131Ar2, section 8 "Deriving Additional Keys from
a Cryptographic Key" says that for KDFs defined in SP 800-108, "[t]he
length of the key-derivation key shall be at least 112 bits". It further
specifies that HMAC-based KDFs "with a key whose length is at least 112
bits" are acceptable.
Add an explicit indicator for SP 800-108 KDFs that will mark shorter key
lengths as unapproved. The indicator can be queried from the EVP_KDF_CTX
object using EVP_KDF_CTX_get_params() with the
OSSL_KDF_PARAM_REDHAT_FIPS_INDICATOR
parameter.
This also modifies the previously applied HKDF indicator patch to use
the same interface to query its FIPS indicator. This provides better
consistency across the various KDFs with explicit indicators.
Additionally, the new constants are clearly marked as being specific to
Red Hat.
Signed-off-by: Clemens Lang <cllang@redhat.com>
Resolves: rhbz#2144019
The current draft of FIPS 186-5 [1] no longer contains specifications
for X9.31 signature padding. Instead, it contains the following
information in Appendix E:
> ANSI X9.31 was withdrawn, so X9.31 RSA signatures were removed from
> this standard.
Since this situation is unlikely to change in future revisions of the
draft, and future FIPS 140-3 validations of the provider will require
X9.31 to be disabled or marked as not approved with an explicit
indicator, disallow this padding mode now.
Remove the X9.31 tests from the acvp test, since they will always fail
now.
[1]: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5-draft.pdf
Signed-off-by: Clemens Lang <cllang@redhat.com>
Resolves: rhbz#2144015
Use RSA-OAEP in FIPS self-tests and support a fixed OAEP seed to make
the test deterministic as required for a known-answer test.
Switch the signature FIPS self-test to use the digest_sign and
digest_verify provider functions using the EVP_DigestSign and
EVP_DigestVerify APIs, as the existing signature self-test does not
cover hash computation.
Switch the existing Diffie-Hellman FIPS self-test to use FFDHE2048,
a known safe prime from RFC 7919.
Signed-off-by: Clemens Lang <cllang@redhat.com>
Resolves: rhbz#2102535
Backport patches that improve performance of AES-GCM on Power9 and
newer, and ChaCha20 on Power10.
Resolves: rhbz#2051312
Signed-off-by: Clemens Lang <cllang@redhat.com>
When OpenSSL was not previously initialized, EVP_PKEY_Q_keygen() would
cause a segmentation fault. Avoid this by backporting a fix from
upstream.
Resolves: rhbz#2103289
Signed-off-by: Clemens Lang <cllang@redhat.com>
FIPS 140-3 requires us to indicate whether an operation was using
approved services or not. The FIPS 140-3 implementation guidelines
provide two basic approaches to doing this: implicit indicators, and
explicit indicators.
Implicit indicators are basically the concept of "if the operation
passes, it was approved". We were originally aiming for implicit
indicators in our copy of OpenSSL. However, this proved to be a problem,
because we wanted to certify a signature service, and FIPS 140-3
requires that a signature service computes the digest to be signed
within the boundaries of the FIPS module. Since we were planning to
certify fips.so only, this means that EVP_PKEY_sign/EVP_PKEY_verify
would have to be blocked. Unfortunately, EVP_SignFinal uses
EVP_PKEY_sign internally, but outside of fips.so and thus outside of the
FIPS module boundary. This means that using implicit indicators in
combination with certifying only fips.so would require us to block both
EVP_PKEY_sign and EVP_SignFinal, which are the two APIs currently used
by most users of OpenSSL for signatures.
EVP_DigestSign would be acceptable, but has only been added in 3.0 and
is thus not yet widely used.
As a consequence, we've decided to introduce explicit indicators so that
EVP_PKEY_sign and EVP_SignFinal can continue to work for now, but
FIPS-aware applications can query the explicit indicator to check
whether the operation was approved.
To avoid affecting the ABI and public API too much, this is implemented
as an exported symbol in fips.so and a private header, so applications
that wish to use this will have to dlopen(3) fips.so, locate the
function using dlsym(3), and then call it. These applications will have
to build against the private header in order to use the returned
pointer.
Modify util/mkdef.pl to support exposing a symbol only for a specific
provider identified by its name and path.
Signed-off-by: Clemens Lang <cllang@redhat.com>
Resolves: rhbz#2087147
Disabling EVP_PKEY_sign and EVP_PKEY_verify also breaks EVP_SignFinal,
which is used by many applications, among them OpenSSH. This change thus
broke sshd in FIPS mode. Revert it for now until we found a better
solution.
Related: rhbz#2087147
Signed-off-by: Clemens Lang <cllang@redhat.com>
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>
