ISO 19790 AS10.09 says the module shall not perform any cryptographic
operations or output data in an error state, but OpenSSL does not have
checks for the module state in EVP_DigestUpdate() and
EVP_EncryptUpdate().
Upstream and their certification lab says these checks aren't needed,
our lab disagrees. We asked for clarification from CMVP. While we are
waiting for that, add a change that will allow us to submit. We will
drop this patch one we found a solution together with upstream.
See #22506 for the discussion upstream.
Resolves: RHEL-17104
Switch explicit FIPS indicator for RSA-OAEP to approved following
clarification with CMVP. Additionally, backport a check required by
SP800-56Br2 6.4.1.2.1 (3.c).
Resolves: RHEL-14083
This will trigger the tests for the golang package when the openssl
package is updated, which would be particularly useful when openssl
adds a new algorithm tightning.
Manual configuration is necessary as Go applications dlopen's
libcrypto.so.* and openssl doesn't normally appear as a dependency at
RPM level.
Signed-off-by: Daiki Ueno <dueno@redhat.com>
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>
