Steve, Thanks a lot for your explanation. I am not clear on one crucial point.
Below are the steps I used to build fipscanister.o: 1. export env variables. (note CROSS_COMPILE="/opt/fip-tools/"; and /opt/fip-tools/gcc is a shell script). 2. ./config 3. make It built fipscanister.o for me. 1> Is the fipscanister.o thus built, a FIPS 140-2 validated module ? 2> If not , could you kindly clarify the need for source distribution , instead of FIPS validated object module distribution ? 3> Also in configure script I found following line: "android-armv7","gcc:-march=armv7-a -mandroid -I\$(ANDROID_DEV)/include -B\$(ANDROID_DEV)/lib here machine architecture is passed as gcc option, so isn't it also a violation ? 4> Even the version of egcs, cc1, ld etc. on a validated platform can lead to code generation that could be technically termed "not tested". Sorry for so many questions, but if you can kindly clarify, it will be great. Thanks in Advance, -Abhijit On Thu, Mar 28, 2013 at 6:14 PM, Steve Marquess <marqu...@opensslfoundation.com> wrote: > On 03/27/2013 11:51 PM, Abhijit Ray Chaudhury wrote: >> Hi, >> >> I am probably re-posting same question after I made some headway in >> compiling, linking and running FIPS enabled openssl module in our >> platform. Following are the steps I followed: >> >> 1. Downloaded http://www.openssl.org/source/openssl-fips-2.0.2.tar.gz : >> >> 2. I have used following script to setup the environment: >> =============================================== >> export MACHINE=armv4t >> export RELEASE=2.6.23 >> export SYSTEM=Linux >> export ARCH=arm >> export CROSS_COMPILE="/opt/fip-tools/" >> export HOSTCC=/usr/bin/gcc >> ================================================ >> ./config -t >> Operating system: armv4t-whatever-linux2 >> Auto Configuring fipsonly >> Auto Configuring fipsonly >> Configuring for linux-armv4 >> /usr/bin/perl ./Configure linux-armv4 -Wa,--noexecstack no-bf >> no-camellia no-cast no-idea no-md2 no-md5 no-mdc2 no-rc2 no-rc4 no-rc5 >> no-ripemd no-seed >> ================================================== >> >> 3. created a shell script: /opt/fip-tools/gcc >> ============================================== >> /opt/gccarm-4.1.2/bin/gcc -march=armv4 -Dmalloc=XXX_malloc -Dfree=XXX_free $* >> ============================================== >> -march was needed as we need to specify the cpu architecture, else >> build fails as openssl header file tries to guess the CPU >> architechture. >> -Dmalloc was needed, as we have custom memory allocator. >> >> 4. built fipscanister.o linked with our customized openssl-1.0.1c and >> created signed libcrypto.so. >> 5. compiled with our application and run it in our target platform. >> >> ======================================================== >> >> Now my question is : >> >> As I have not changed a single file in openssl-fips-2.0.2 source tree >> and since FIPS_selftest() , FIPS_mode_set(1) passes in our platform, >> does that mean libcrypto.so that I built is FIPS compliant ? > > The term "FIPS compliant" has no real meaning. The question should be > "is the OpenSSL FIPS Object Module 2.0 a FIPS 140-2 validated module as > used in this context?". The immediate answer is no, one reason being > that you did not use the specifically mandated commands > > ./config > make > > to create the FIPS module. The Security Policy is pretty clear on that > point. > > Note use of environment variables MACHINE, SYSTEM, HOSTCC, etc. to > define the target platform for the cross-compilation toolkit is > generally acceptable, but IMHO passing arbitrary compiler options by any > means is a gray area. > > Assuming you use the mandatory canonical build commands your best option > (short of formally adding your platform to the existing validation) is > to "user affirm" per section G.5 of the Implementation Guidance document: > > http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf > > Unfortunately the guidance isn't crystal clear on the question of > indirectly finessing compiler options. In similar situations I advise > our clients not to take such liberties. However, my opinion is just > that, one opinion of many. You could try asking the only definitive > authority, the CMVP (http://csrc.nist.gov/groups/STM/cmvp/contacts.html) > for an determination on the specifics of your situation, though they > tend to avoid such implementation level details (typically responding > "ask your test lab"). > > Absent clear guidance from the CMVP you'll need to decide your comfort > level with making that claim. > > -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
