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

[Satya Das]

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 ?

Please note that I am not automating the build, which has been discouraged in the User Guide 
(yes I have read probably around 40% of it). However because of the complex build flow I want
to have a post build manual check before using the openssl rpm in rest of the product.

Thanks

________________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Steve Marquess <marquess at openssl.com>
Sent: Tuesday, March 15, 2016 6:02 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

On 03/14/2016 08:30 PM, Satya Das wrote:
> Hello,
>
>
>
> I have a simple problem I am trying to solve. I have built a fips
> capable openssl shared object (.so). I also have the sha1 hash of the
> fipscanister.o in a file called fipscanister.o.sha1. I also have the
> sha1 hash of fips_premain.c in a file called fips_premain.c.sha1. In
> order to make sure the build is good, I want to make sure that the .so
> was indeed built with these versions of fipscanister.o and fips_premain.
>
>
>
> Is there a way to do this ? I am on centos 6.6 x86_64 and linking to
> object module 2.0.11 from openssl 1.0.1e with patches.

Hmmmm.  Several comments:

1) Please read the OpenSSL FIPS User Guide,
https://openssl.org/docs/fips/UserGuide-2.0.pdf. It answers most (I
would even say all) of your questions. Yes, it's a long dull slog to
read but then open source FIPS 140-2 is a horribly convoluted topic.

2) The libcrypto shared library is just an application in the context of
FIPS 140-2, and in general you're not going to be able to reconstruct an
object module file (foo.o) from an executable binary image that was
built from it. Nor is there any FIPS 140-2 related requirement to do so.

3) The fipscanister.o file is a little bit more (and less) that your
typical object module ("module" in the usual software engineering sense.
It is discussed in the OpenSSL FIPS User Guide, in particular section 2.3.2.

Note the SHA1 digest of the libcrypto shared library file, or of any
other application, is completely irrelevant to FIPS 140-2. In fact the
CMVP specifically disallowed any integrity test that contained such
"extraneous" data (see section 2.3.1). We were told at the time that was
because of the risk of SHA1 digest collision.

3) The "file integrity chain" (section 2.4) requires that the interim
files created from the official source distribution tarball be verified
using SHA1 hashes. Somewhat oddly, given the rather intense focus on
ideological righteousness elsewhere, you're allowed to do this with an
un-sanctified SHA1 implementation. Notice for instance that the stock
build process uses an interim utility ("./fips/fips_standalone_sha1")
built from the same code as used in the FIPS module.

Also note that this is first and foremost a procedural or paperwork
chain. You can have two software products that claim to use FIPS 140-2
validated crypto, and those can be bit-for bit identical, yet with one
satisfying the FIPS 140-2 validation requirements and one not; no
conceivable technical test can distinguish them (we call this difference
FIPS "magical pixie dust").

4) The canonical FIPS module integrity test, common to all FIPS modules,
takes the form of the "incore integrity test" for the OpenSSL FIPS
module (discussed in detail in -- you guessed it -- the User Guide).
Note that this incore integrity test does *not* include all of the
contents of the fipscanister.o object file.

5) As Jakob has correctly noted, there is no point in trying to automate
the FIPS module build-from-source; you'll lose the FIPS 140-2 magical
pixie dust of righteousness which is the whole, entire, and only point
of using the FIPS module. Section 5.5 has some recommendations, which I
often summarize by suggesting the module ("fipscanister.o" et. al.) be
built once in a solemn candle-lit ceremony and only those resulting
install targets preserved (no point in keeping the source, it can't be
changed and can't even be transferred via the usual common sense means).
At a minimum you'll need an official CD (section 6.6; yup, snail mail is
a "trusted path"). We're still sending those out for free, in spite of
the significant financial losses the OpenSSL FIPS business sustained
last year.

-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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users