Re: Question about FIPS enabled OPENSSL build on armv4 platform
On 03/28/2013 11:30 AM, Abhijit Ray Chaudhury wrote: 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). Same answer as before: ... IMHO passing arbitrary compiler options by any means is a gray area. ... In similar situations I advise our clients not to take such liberties. ... Absent clear guidance from the CMVP you'll need to decide your comfort level with making that claim. The Security Policy and CMVP scripture do not specifically forbid stealth specification of arbitrary compiler options, but doing so is arguably contrary to the spirit of the validation process. Note the CMVP took pains to forbid the use of ./config or make command line arguments, which are otherwise often used for the same effect. In general I hate to quote scripture, because that just ducks the question at issue, but in this case the relevant part of I.G. G.5 is worth study: The CMVP allows user porting of a validated software, firmware or hybrid cryptographic module to a operational environment which was not included as part of the validation testing. The validation status is maintained in the new operational environment without retesting in the new operational environment as long as the porting rules are followed. However, the CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when ported and executed in an operational environment not listed on the validation certificate. ... Note: A user may post-validation recompile a module if the unmodified source code is available and the module’s Security Policy provides specific guidance on acceptable recompilation methods to be followed as a specific exception to this guidance. The methods in the Security Policy must be followed without modification to maintain validation under this guidance. Are you using unmodified source code? Presumably yes. Does the Security Policy describe compilation? Yes (./config; make, no ./config options allowed). Does it provide specific guidance on acceptable recompilation methods? Well, good question. Tweaking of compiler options is commonly done for porting, and passing them the way you did (by binding them to all compiler references) is a common technique. So one *could* argue that G.5 user affirmation covers typical porting techniques, as long as the source is not modified and the canonical ./config; make is used. We don't make that argument here at OSF. If you ever get a clear and definitive answer to that (from the CMVP) please share it. -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 build on armv4 platform
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question about FIPS enabled OPENSSL build on armv4 platform
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
