Hello Steve, Even if a vendor letter is good for CMVP, how is the vendor supposed to know ? I would say openssl should give such a tool so that vendor and the testing Lab can know such things. It is more than critical that the applications link to the intended crypto module. This convoluted and complex object module linking etc. with 207 page user guide is specific to openssl's approach to FIPS, and therefore should be addressed by the project. It should not come down to some vendor document written in good faith. Thanks again for your comments. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf Of Steve Marquess Sent: Tuesday, March 15, 2016 12:30 PM To: openssl-users at openssl.org Subject: Re: Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
