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
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 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 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
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
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/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
