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 0xFB00000 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=0xc08a0000 (> 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=0xc08a0000, 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=0xc08a0000 @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 List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
