[openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

[Steve Marquess]

On 03/15/2016 02:22 PM, Satya Das wrote:
> Hello Steve,
> 
> Thank you for your comments.
> 
> Is there a way to verify that the correct version of object module (fipscanister.o) was assimilated into the libcrypto.so ? 
> I just need some surefire way to run an engineering check on the build. Essentially what my question boils down to, is 
> that there is code in there somewhere that comes up with the run time hash and compares with the embedded hash.
> Is there a way to use those code pieces to somehow double check that the embedded hash matches the object module that
> libcrypto should have been linked to ?
> 
> ...

In a word, no. In principle a utility could be written, for most
platforms, based on the "incore" utilities used for cross-compilation
(some of which are included in the FIPS module tarball). To my knowledge
that has not been done, and would be moot anyway because as noted in my
original response *no* technical test of *any* kind can determine the
absence of the procedural "pixie dust".

Let me elaborate on that a bit as I didn't get the point across the
first time. If I build the OpenSSL FIPS module and fail to follow the
mandated build process exactly, the result is not validated. So for
instance any of the following failures:

a) I download openssl-fips-2.0.N.tar.gz instead of getting the official
snail-mailed CD;

b) Neglect to check the tarball digest against the value in Appendix B
of the Security Policy;

c) Build with "./Configure ..." instead of "./config", even though the
build options are identical;

d) Edit the README in the ./openssl-fips-2.0.N/ workarea created from
the tarball;

...mean the result is not validated, even though it may be *exactly*
bit-for-bit identical with one built without those procedural errors. No
technical test can verify the presence of the magical pixie dust of FIPS
140-2 righteousness!

Keep in mind that this issue - how do I tell if application X is using
FIPS module Y -- is the same for *all* FIPS validated cryptography. Most
of which is proprietary with the content of the module and the digests
unknown.

If you ask the CMVP this question they will say "get a letter from the
vendor". That is a sensible answer; the letter will be the CYA you need
for any audit or assessment. While you may be able to prove a product
does *not* use FIPS validated crypto; you can never prove a product
contains a righteous FIPS 140-2 validated module other than with such
documentation.

An aside of historical interest: I started getting sucked down the FIPS
140-2 rabbit hole nearly two decades ago, when I had just such a vendor
letter in hand. But, that vendor kept shipping software that clearly did
*not* use FIPS validated cryptography (I could get it to use non-allowed
algorithms). After I complained repeatedly that vendor finally confessed
"our product version that uses the FIPS crypto is very old, you don't
want that". Well yes I did (i.e. my client did) and insisted on getting
the righteous product. So the vendor ended up sending us a hand-labeled
CD :-(.

The moral of that story is that you should get the vendor letter (or in
the OpenSSL FIPS module case do the section 5.5 documentation thing) and
move on; I didn't and was condemned to an eternity of tilting at the
FIPS 140-2 windmill...

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc