On Mon, Nov 24, 2014, Philip Bellino wrote:
> Hello,
> I am looking for some help and I do not profess to be an expert in this
> area, so forgive me for asking the following.
>
> I am running openssl-fips-2.0.7 with openssl-1.0.1j in my application(in FIPs
> mode) and am trying to figure out how to get around the following issue:
>
>
> sha_locl.h(128): OpenSSL internal error, assertion failed: Low level API call
> to digest SHA1 forbidden in FIPS mode!
>
>
> >From the openssl-1.0.1j "CHANGES" file, I see the following entry:
>
> Low level digest APIs are not approved in FIPS mode: any attempt
> to use these will cause a fatal error. Applications that *really* want
> to use them can use the private_* version instead.
> [Steve Henson]
>
> Does this mean that if I want to use low level digest APIs that I would
> comment out the ' if (FIPS_mode())' test below?
> If this is correct, am I now violating FIPS?
>
> >From crypto/crypto.h:
>
> #ifdef OPENSSL_FIPS
> #define fips_md_init_ctx(alg, cx) \
> int alg##_Init(cx##_CTX *c) \
> { \
> if (FIPS_mode()) OpenSSLDie(__FILE__, __LINE__, \
> "Low level API call to digest " #alg " forbidden in FIPS mode!"); \
> return private_##alg##_Init(c); \
> } \
> int private_##alg##_Init(cx##_CTX *c)
>
>
> If I am barking up the wrong tree(so to speak), what would be the correct
> course of action for me to take?
>
BIG DISCLAIMER: This is a rather complex topic with many differing opinions so
I'll only give mine FWIW.
During the design of the FIPS module it was hoped that changing applications
to support FIPS mode would be a relatively simple process. However it was also
realised that existing applications could perform operations which would
normally be prohibited in FIPS mode. For example use of weak or unapproved
algorithms or APIs that bypass some of the FIPS requirements.
If these were allowed by default then each application would have to be
carefully checked to see if it didn't use any prohibited algorithms or APIs
a tedious error prone process which could result in some applications claiming
compliance when they weren't.
To partly resolve this a form of "blocking" was introduced which returns
errors or in some cases hard asserts failures.
[The reason for the hard assert failures is that some APIs which need to be
blocked have no mechanism to return an error *or* they would always
succeed so applications might not even check errors with potentially severe
consequences]
That however isn't the complete story. There are some unusual circumstances
under which the use of an unapproved algorithm or API might be acceptable even
in FIPS mode. An internal example of that is the use of MD5 for TLS in the PRF.
As a result a mechanism was included to bypass the algorithm or API blocking.
The fact that this isn't done by default means an application writer
(hopefully!) has to think very hard before decidicing to override the
blocking.
TL;DR: in your case it's highly likely you'll have to use the EVP APIs for SHA1
use.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
