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
