For DH parameter and key pair generation/verification, the DSA
procedures specified in FIPS 186-4 are used. With the release of FIPS
186-5 and the removal of DSA, the approved status of these groups is in
peril. Once the transition for DSA ends (this transition will be 1 year
long and start once CMVP has published the guidance), no more
submissions claiming DSA will be allowed. Hence, FIPS 186-type
parameters will also be automatically non-approved.
Previously, we had addressed this by completely disabling the DHX key
type in the OpenSSL FIPS provider, but the default encoding for DHX-type
keys is X9.42 DH, which is used, for example, by kerberos.
Re-enable DHX-type keys in the FIPS provider, but disable import and
validation of any DH parameters that are not well-known groups, and
remove DH parameter generation completely.
Adjust tests to use well-known groups or larger DH groups where this
change would now cause failures, and skip tests that are expected to
fail due to this change.
Signed-off-by: Clemens Lang <cllang@redhat.com>
Resolves: rhbz#2169757
- Remove the hobbling script as it is redundant. It is now allowed to ship
the sources of patented EC curves, however it is still made unavailable to use
by compiling with the 'no-ec2m' Configure option. The additional forbidden
curves such as P-160, P-192, wap-tls curves are manually removed by updating
0011-Remove-EC-curves.patch.
- Enable Brainpool curves.
- Apply the changes to ec_curve.c and ectest.c as a new patch
0010-Add-changes-to-ectest-and-eccurve.patch instead of replacing them.
- Modify 0011-Remove-EC-curves.patch to allow Brainpool curves.
- Modify 0011-Remove-EC-curves.patch to allow code under macro OPENSSL_NO_EC2M.
Resolves: rhbz#2130618, rhbz#2188180
Signed-off-by: Sahana Prasad <sahana@redhat.com>
Add the patchfile that was committed but not referenced in the spec
file. Fix the patch to apply on openssl 3.0.7 and fix the gettable FIPS
indicator parameter for the RSA asymmetric cipher implementation.
Resolves: rhbz#2179379
Signed-off-by: Clemens Lang <cllang@redhat.com>
NIST SP 800-56Br2 section 6.4.2.1 requires either explicit key
confirmation (section 6.4.2.3.2), or assurance from a trusted third
party (section 6.4.2.3.1) for the KTS-OAEP key transport scheme and key
agreement schemes, but explicit key confirmation is not implemented and
cannot be implemented without protocol changes, and the FIPS provider
does not implement trusted third party validation, since it relies on
its callers to do that. We must thus mark RSA-OAEP encryption and RSASVE
as unapproved until we have received clarification from NIST on how
library modules such as OpenSSL should implement TTP validation.
This does not affect RSA-OAEP decryption, because it is approved as
a component according to the FIPS 140-3 IG, section 2.4.G.
Resolves: rhbz#2179379
Signed-off-by: Clemens Lang <cllang@redhat.com>
In testing, we noticed that using output keys shorter than 14 bytes with
the X9.42 KDF does not set the explicit FIPS indicator to unapproved as
it should. The relevant check was implemented, but the state in the
implementation's context was not exposed.
Resolves: rhbz#2175864
Signed-off-by: Clemens Lang <cllang@redhat.com>
```
providers/implementations/signature/ecdsa_sig.c: scope_hint: In function 'do_ec_pct'
providers/implementations/signature/ecdsa_sig.c:594:46: warning[-Wpointer-sign]: pointer targets in passing argument 2 of 'ecdsa_digest_signverify_update' differ in signedness
providers/implementations/signature/ecdsa_sig.c:325:69: note: expected 'const unsigned char *' but argument is of type 'const char *'
```
```
providers/implementations/signature/rsa_sig.c: scope_hint: In function 'do_rsa_pct'
providers/implementations/signature/rsa_sig.c:1518:44: warning[-Wpointer-sign]: pointer targets in passing argument 2 of 'rsa_digest_signverify_update' differ in signedness
providers/implementations/signature/rsa_sig.c:910:62: note: expected 'const unsigned char *' but argument is of type 'const char *'
```
Resolves: rhbz#2178034
Signed-off-by: Clemens Lang <cllang@redhat.com>
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
