Richard Levitte wrote:
>So lets see, would libcrypto.so and libssl.so be considered FIPS
>certified or not? Right now, I can't really say... Things like
>"Catch 22" come to mind...
It gets tediously complicated, so bear with me. Along with the
FIPS 140 validation certificate, a document called the "Security
Policy" will be published. This document describes the conditions
under which an application can claim to be "FIPS 140 validated".
It is over 50 pages long.
In *rough* summary, the conditions are:
1) The FIPS 140 validated source code (the 26 files with SHA1 HMAC
digests as published in the Security Policy) must be used to
generate the libcrypto.a and/or libcrypto.{so|sl}, using "./config
fips ...". A SHA-1 HMAC of the library file is generated at this
time.
2) The application must be linked against the libcrypto.{a|so|sl}
as generated above, and the SHA-1 HMAC of the library validated
at build time. For static linking a SHA-1 HMAC of the entire
application executable is generated.
3) At runtime the application must call FIPS_mode_set() to verify
the SHA-1 HMAC of the entire application binary (static linking)
of the libcrypto.{so|sl} at the point where the dlopen() with
an explicit path occurs (dynamic linking).
4) All cryptography is performed only using the FIPS mode libcrypto
library.
So, the application can claim FIPS 140 validation only if all those
conditions apply. Link your application without verifying the
libcrypto.sha1 at build time, or fail to call FIPS_mode_set(), and
the result isn't FIPS 140 validated even though essentially the same
crypto code is executing.
Note libssl is considered by FIPS 140 to be
"outside the cryptographic module boundary"; all the relevant crypto
code is in libcrypto. The FIPS 140 validation, in fact, applies to
only a subset of the code in libcrypto -- the 26 files shown in the
fingerprint.sha1 files in the openssl/fips/ tree.
-Steve M.
