Question about FIPS Enabled OPENSSL in WINCE platform

[Abhijit Ray Chaudhury]

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=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 ?
b> Is there a better way solving the above described problem ?

Thanks in Advance,
-Abhijit
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org

[Steve Marquess]

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
marq...@opensslfoundation.com
marq...@openssl.com

[sunil.s...@gmail.com]

Hi Steve,

The msincore script was added in 2012 here as follows to support CEOS PE COFF DLLs.
http://testhub.opensslfoundation.com/osf/testing/validation-2.0/platforms/wince5/PatchAnnotation.pdf

The problem is the fipslink.pl and msincore scripts in its current form only support CEOS user-space DLL's. IT does not work if the DLL is a CEOS ROM DLL. fipslink fails.

I am believe whoever is using these scripts on CEOS is doing so on FIPS libraries running as a user-space DLL. We have tried it for a user-space DLL and it works fine. But our solution runs in the kernel.

We require to do a change letter with FIPS running in the CEOS kernel space.

What is the process to submit a patch to the msincore script so that it works when the FIPS library is running in CEOS kernel space as a ROM dll ?


Basically we are requesting a change in the tools to support the underlying Operating System in our case Win CE 6.0 correctly.

Thanks
Sunil

[Abhijit Ray Chaudhury]

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

[Steve Marquess]

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.

[sunil.s...@gmail.com]

Steve,

Thanks for the clarification. Abhijit pointed out an example from the user guide. It is a representative example from the guide. Sorry for the confusion caused.

Reading the user guide again, I think we understand why the FIPS_SIG environment variable is been provided for the Window CE OS. We have an unsupported operating system configuration that we need to overcome.

Please note that we will be using an unmodified version of the tar ball and using the ENV variable as suggested in the FIPS user guide to overcome an unsupported Windows CE Operating system configuration.

Thanks,
Sunil

[Abhijit Ray Chaudhury]

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

[Steve Marquess]

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.

[sunil.s...@gmail.com]

Hi Steve,

The wiki page is extremely useful as it covers the area we are requesting.

In particular this is what we are attempting to do.

"The "incore" utilties (incore, incore6x, msincore, incore_macho) calculate and insert the incore digest of the executable file linked with the FIPS module, and are not used during creation of the actual FIPS module proper (fipscanister.o, fipscanister.lib). Note most openssl-fips-2.0.N.tar.gz tarballs contain one or more incore utilities; these cannot be modified in place. However, specification of separate utility files residing outside of the unpacked tarball is permissible."

Thanks again.

Sunil