On 3/26/14, 2:41 PM, Steve Marquess wrote:
On 03/26/2014 12:30 PM, Mark Hatle wrote:
Looking at the fips_canister.c I see that ia32 (32-bit and 64-bit)
systems are not enabled with the cross compiling when using 'Linux'.
But ia32 (32-bit) is enabled on Android systems.
This is preventing me from cross compiling and using the fipsld with the
incore script to link my applications.
I modified fips_canister.c as shown in the attached patch. So far in my
testing (building various applications and running them on the target
system), the incore script is working correctly.
Would it be possible to add this change to the fips_canister in a future
version, or would this require a full re-validation of the openssl-fips?
A "change letter" update would suffice. That's still a non-trivial
expense, in both time and money, but not nearly as expensive as a full
validation.
Do you have an idea of the potential expense and time it would take to do this?
We're certainly interested in getting this done in the community. I can ask
my management to help pay for this change, but I need some idea as to a
reasonable cost. (We don't want to do it ourselves, we want everything we do to
come from the openssl.org.)
Until then, my only other option is to use something like qemu to run
the linked application to get the necessary checksum, in order to
recompile/relink the final binary. Is modifying the fipsld script in
such a way acceptable for FIPS compliance?
You can't modify the fipsld present within the openssl-fips-2.0.N.tar.gz
source distribution (*no* such modifications are allowed), but you can
use *another* external modified fipsld script that respects the
requirements of the Security Policy (i.e., verify the *.sha1 digests as
you go).
What I am doing right now:
* build a target system (x86_64) that includes a compiler
* boot that system
* download (and verify) openssl-fips-2.0.5.tar.gz, openssl-1.0.1f.tar.gz
* extract, build, install, openssl-fips (no modifications) using the rules from
the UserGuide.
* extract, build, install openssl (with appropriate system config)
* (run test cases, verify it's all working)
* copy the incore script as well
* tar up the results of the build and transfer it back to the host
On the host system (where we cross compile our apps)
* extract the build, and install the components into their final location
* modify the fipsld script to NOT call the 'fips_standalone_sha1' [since it's
for the target, not host]
* modify the fipsld script to call 'openssl sha1 -hmac ....' from the host
* [likely will have to add the qemu hooks here until the change is made]
* build my app, using my custom fipsld script to do the link
So -my- interpretation is that I didn't modify the openssl-fips sources, I
modified the install location and fipsld script -after- it was built.. but I
ensure that the steps performed are technically the same. So this is "OK".
Does this seem reasonable?
That point is a little confusing. When the FIPS module was first
validated only native compilation was supported. Later we worked out how
to support cross-compilation, and the precedent of using an external
fipsld (and/or incore) utility for building the FIPS module has since
been well established. Fipsld and incore (and some other files) are
really part of the build environment, like the compiler and linker, and
don't need to be in the source distribution tarball proper. If/when we
ever do another open source based validation we'll probably leave those
build utilities out of the FIPS module tarball entirely. Until then any
change to the tarball contents means (at best) a "change letter" update,
even something as trivial as a change to a comment.
That makes sense to me.
Thanks for the help!
--Mark
-Steve M.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
