On 05/29/2013 11:34 AM, Abhijit Ray Chaudhury wrote: > Steve, > > Apologies if I got you confused. > > I am writing below what I did : > =============================== > 1. downloaded openssl-fips-2.0.3. > 2. exported variables as dictated by user guide and suited for my > build enviroment. exported FIPS_SIG=perl mymsincore.pl (I have written > mymsincore.pl which calls editbin.exe, that gives the desired base > address, followed by msincore script came with openssl-fips) > 3. ms\do_ms gave me fipscanister.lib > 4. built wcecompat library as stated in user guide. > 5. compiled openssl as mentioned in user guide. > ===================================== > Note that, NONE of the files in openssl-fips-2.0.3 tarball was modified.
Ah, good. A colleague who was paying better attention than I also pointed that out. Even though it sounds silly, you can't modify *any* files in the workarea created by unpacking the source distribution tarball. So in particular you can't modify the file ./openssl-fips-2.0.3/util/msincore, even though that file isn't actually used in the generation of the FIPS module proper. You can't for instance even modify the file ./openssl-fips-2.0.3/README.FIPS; the CMVP was especially adamant on that point when we did the very first validations, which is why I (over)emphasize it. > The only trick I had to use to follow the user guide is the > environment variable refers to mymsincore.pl which calls msincore > script came with openssl-fips. I guess I am supposed to adapt the > environment variable according to my need. > > kindly let me know if I have created FIPS 140-2 validated binary. Ok, if you created the FIPS module (the fipscanister.lib and technically also the fipscanister.lib.sha1, fips_premain.c, fips_premain.c.sha1 files) *exactly* as documented in the Security Policy and without *any* modification of the ./openssl-fips-2.0.3/ workarea, *then* you have a FIPS module you can claim as FIPS 140-2 validated. Having achieved that your question is really about limitations on the subsequent process used to link that validated FIPS module into an executable application. Here the restrictions are far less severe; you have only two responsibilities: 1) Verify the digests of the FIPS module (fipscanister.o, fips_premain.c) against the *.sha1 files. 2) Set the integrity test digest. The msincore utility does that in your situation. Different "incore" utilities are used for other cross-compiled platforms. Note the CMVP does not (to our knowledge) impose any specific requirement on the "incore" utility. While it can be very dangerous to presume an understanding of their thought processes, as they see FIPS 140-2 validation from a very different perspective than the typical software developer/engineer, I believe it goes something like this: The integrity digest is verified at runtime as part of the mandated POST (Power Up Self Test, a key FIPS 140-2 concept). The code that performs that check is carefully and formally reviewed and tested. That integrity test consists of calculating a HMAC-SHA1 digest of the TXT and RODATA segments of the FIPS module as mapped in live memory, and comparing it against a known value embedded in the module. The "incore" utility (in this case) stores that known value. No formal testing is required for that utility because for given any fixed string of bits (i.e. the TXT+RODATA segments) there is only one possible correct value for the HMAC-SHA1 digest. If an untested and defective incore utility stores an incorrect value then the POST will fail, therefore only the latter need be formally tested. BTW I have drafted a page in our new wiki: http://wiki.openssl.org/index.php/FIPS_Build_Guidelines that will hopefully over time expand into a useful resource for your class of question. It's a tricky topic. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
