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
