On 03/26/2014 05:25 PM, Mark Hatle wrote: > 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 ... >>> >>> 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.
Rough rule of thumb, US$15K (for an "uncomplicated" platform) and about three months. We don't have much control over the time, though, and disruptions in the validation testing process are not uncommon. For instance, we've had a number of platforms here stalled for three months just waiting for official test vectors so we can start testing, and those poor sponsors will still have to wait another three months or so at best. We absorb the risk of complications, costwise, but can't do anything about schedule slips. For most of our clients the time hurts more than the money. Three months is a long time when you're losing sales. Note that cost is independent of the nature or complexity of the code change, and many changes will not be permitted at all (for instance, we're usually unable to backport vulnerability fixes). Platform portability code changes that don't touch the actual cryptographic algorithm implementations and are clearly specific to the new platform(s) usually are possible. > (We don't want to do it ourselves, we want everything we do to come > from the openssl.org.) You actually can't do this type of "change letter" mod yourself, only the vendor of record (OSF) and the original test lab (InfoGard in this case) can do that. So it's a bit of a captive market which we try not to abuse. We are aware that the sponsors of the original very difficult and expensive #1747 validation (DARPA, DHS, and other government and commercial sponsors) wanted that validation to be widely used in just the way you're trying to use it. An open source based validated module benefits a large community. Note BTW that OSF (the OpenSSL Software Foundation) and openssl.org are not synonymous. The former is a legal entity formed for the purpose of engaging in commercial contracts and the like (performing FIPS 140-2 validations, for instance, which require lots of paperwork). Some but not all of the members of the less formal OpenSSL project are engaged in OSF activities. >>> 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: > > ... * 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. You built the FIPS module exactly as required; good. That process really matters including even the apparently silly parts like starting with a snail-mailed CD. What follows is far less critical. > ... * modify the fipsld script to call 'openssl sha1 -hmac ....' ... > > 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? It's allowed. As noted earlier you can modify the fipsld scrip used for creating the final application executable (e.g. libcrypto) as long as the *.sha1 digests are verified. For cross-compilations we typically use an shell script to set environment variables, for instance: http://opensslfoundation.com/testing/validation-2.0/platforms/android-x86/setenv-android-x86.sh which usually avoids the need for such hacks. -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 gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
