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
Dmitry Belyavskiy
Clemens Lang