Re: Question about FIPS Enabled OPENSSL in WINCE platform
Hi Steve, Thanks a lot for you clarification. The user guide states : = The Microsoft Windows mobile operating systems are among the most challenging platform for the FIPS Object Module, due to the wide variation among individual system configurations. Representative Build These instructions are necessarily only representative of one specific configuration and may require substantial modification for specific Windows CE or EC platforms. Typically a version of Visual Studio will be used. In this representative example the following environment variables are defined in a .BAT file, setenv-wince6.bat: @set FIPS_SIG=perl /opensslfips2.0/util/msincore = It also states: The standard OpenSSL build with the fips option will use a base address for libeay32.dll of 0xFB0 by default. In the event of a clash with another dynamically loaded library which will trigger runtime relocation of libeay32.dll, the integrity check will fail with the error FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELATED A base address conflict can be resolved by shuffling the other DLLs or re-compiling OpenSSL with an alternative base address specified with the --with-baseaddr= option. == This procedure is perfectly valid for user mode dll but for kernel mode dll if we try --with-baseaddr=0xc08a ( 3GB) , the build will fail. Though link.exe prohibits the use of base address 3GB, editbin.exe enables us to follow user guide completely by allowing base address to be defined 3GB. EditBin.exe can only modify binary and cannot link. So I have defined set FIPS_SIG=perl mymsincore.pl and in mymsincore.pl I call editbin.exe allowing us follow the effect of --with-baseaddr=0xc08a, then call normal msincore script (which is in effect doing the exact same thing stated in user guide). This produces binary which can set FIPS mode properly. Now my question is since I have followed following clause: - ...There shall be no additions, deletions or alterations to the tar file contents as used during module build... Is the libeay32.dll thus produced a FIPS140-2 validated module. Thanks in advance, -Abhijit On Tue, May 28, 2013 at 8:28 PM, Steve Marquess marqu...@opensslfoundation.com wrote: On 05/28/2013 09:28 AM, Abhijit Ray Chaudhury wrote: Hi, We have an application running in WINCE Kernel address space as a DLL. We require to have it compiled against FIPS enabled openSSL. ... To get around the problem we have added following line in msincore script, all the build procedure and files remains exactly same as in source distribution. == system(editbin /nologo /rebase:base=0xc08a @ARGV[$#ARGV] @ARGV[$#ARGV].rel); == Please let me know : a If the libeay32.dll thus produced will still be FIPS 140-2 validated module ? The answer to that question is prominently featured on the NIST CMVP web site, http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747: ...There shall be no additions, deletions or alterations to the tar file contents as used during module build... and is also clearly stated in the Security Policy document (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf) -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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question about FIPS Enabled OPENSSL in WINCE platform
On 05/29/2013 05:40 AM, Abhijit Ray Chaudhury wrote: Hi Steve, Thanks a lot for you clarification. The user guide states : ... Now my question is since I have followed following clause: - ...There shall be no additions, deletions or alterations to the tar file contents as used during module build... Is the libeay32.dll thus produced a FIPS140-2 validated module. Did you modify the tarball? Yes. Is modifying the tarball allowed? No. I didn't write that statement that appears so prominently on the NIST CMVP web site, but I can't think of a way to state it more clearly. You're confusing two different things: the requirements for claiming FIPS 140-2 validation, and getting the code to run. Most definitely not the same thing. -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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question about FIPS Enabled OPENSSL in WINCE platform
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. 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. Thanks in advance , -Abhijit On Wed, May 29, 2013 at 5:37 PM, Steve Marquess marqu...@opensslfoundation.com wrote: On 05/29/2013 05:40 AM, Abhijit Ray Chaudhury wrote: Hi Steve, Thanks a lot for you clarification. The user guide states : ... Now my question is since I have followed following clause: - ...There shall be no additions, deletions or alterations to the tar file contents as used during module build... Is the libeay32.dll thus produced a FIPS140-2 validated module. Did you modify the tarball? Yes. Is modifying the tarball allowed? No. I didn't write that statement that appears so prominently on the NIST CMVP web site, but I can't think of a way to state it more clearly. You're confusing two different things: the requirements for claiming FIPS 140-2 validation, and getting the code to run. Most definitely not the same thing. -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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question about FIPS Enabled OPENSSL in WINCE platform
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Question about FIPS Enabled OPENSSL in WINCE platform
Hi, We have an application running in WINCE Kernel address space as a DLL. We require to have it compiled against FIPS enabled openSSL. For that we followed following steps: = 1. compiled openssl-fips2.0.3 and built fipscanister.lib. 2. took openssl-1.0.1c and linked to create FINGERPRINTED libeay32.dll. 3. Linked libeay32.dll in a driver code to load the library and call FIPS_mode_set(1). 4. From the platform builder noted the load address of libeay32.dll as ROMDll. 5. Tried to recompile libeay32.dll using that base address. = Now the problem we have faced is: == link.exe won't accept baseaddr 2GB, even with /LARGEADDRESSAWARE flag. link.exe accepts baseaddr 2GB with /LARGEADDRESSAWARE /DRIVER flag, but it adds a section called INIT, fro which current msincore script generates wrong sha1 and fingerprinting fails upon running it. == To get around the problem we have added following line in msincore script, all the build procedure and files remains exactly same as in source distribution. == system(editbin /nologo /rebase:base=0xc08a @ARGV[$#ARGV] @ARGV[$#ARGV].rel); == Please let me know : a If the libeay32.dll thus produced will still be FIPS 140-2 validated module ? b Is there a better way solving the above described problem ? Thanks in Advance, -Abhijit __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question about FIPS Enabled OPENSSL in WINCE platform
On 05/28/2013 09:28 AM, Abhijit Ray Chaudhury wrote: Hi, We have an application running in WINCE Kernel address space as a DLL. We require to have it compiled against FIPS enabled openSSL. ... To get around the problem we have added following line in msincore script, all the build procedure and files remains exactly same as in source distribution. == system(editbin /nologo /rebase:base=0xc08a @ARGV[$#ARGV] @ARGV[$#ARGV].rel); == Please let me know : a If the libeay32.dll thus produced will still be FIPS 140-2 validated module ? The answer to that question is prominently featured on the NIST CMVP web site, http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747: ...There shall be no additions, deletions or alterations to the tar file contents as used during module build... and is also clearly stated in the Security Policy document (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf) -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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
