On 08/22/2011 05:28 PM, Harvey Shepherd wrote: > ... >> >> Building the FIPS module (fipscanister.o) and the usual shared >> libraries out of the same source distribution is unwise. For the >> older v1.2.3 module, the shared libraries generated as a byproduct >> of the FIPS module build are unsupported, buggy, and obsolete. For >> the upcoming v2.0 module, currently only in HEAD, the shared >> libraries are not "FIPS capable". >> >> Please, please always keep in mind that the OpenSSL FIPS Object >> Module and the OpenSSL library are separate and distinct software >> components. They should be built separately, with the "FIPS >> capable" OpenSSL libraries incorporating the independently >> generated FIPS module. >> >> For the v1.2.3 module use >> http://www.openssl.org/source/openssl-fips-1.2.3.tar.gz for the >> FIPS module and the latest 0.9.8 distribution (currently 0.9.8r) >> for the FIPS capable libraries. > > I have those two components already, but from my reading the User > Guide doesn't seem to say that the two MUST be linked together, and > since the crypto library produced by the FIPS Object Module seemed to > provide all the SHA-1 and AES-128 functionality I needed for > Net-SNMP, I was hoping I could get away without using base OpenSSL at > all (in order to reduce complexity and the library size).
You're not reducing complexity or size that way ... you're just getting a buggy and unsupported OpenSSL "crypto library" no simpler or smaller that what you would get from a supported distribution. > ... > > It was my hope that in exclusively using the FIPS Object Module > crypto library, there would be no need to worry about enabling FIPS > mode, as I assumed that the FIPS Object Module would not implement > anything that was outside of the FIPS mandate. Using the FIPS module exclusively, without the usual OpenSSL API (libcrypto), is theoretically possible but will be difficult. That API isn't documented because it isn't intended for direct use by applications. You will still need to enable the FIPS mode of operation. Note the "FIPS capable" OpenSSL -- the one you're trying so hard to avoid -- will automagically disable non-allowed cryptography when built as intended and when FIPS mode is enabled. > As I noted above, I > can't follow the Security Policy guidelines exactly anyway, due to my > build changes. > >> An attempt was made to document the various aspects of this process >> in the User Guide, http://www.openssl.org/docs/fips/UserGuide.pdf. >> > > Yes, I've read this document from cover to cover but it doesn't > really cover cross-compilation at all, apart from a single mention > that it can be done. It doesn't specify if the setting of environment > variables such as CROSS_COMPILE prior to performing the build > invalidates the FIPS certification, or explain exactly how the cross > compilation should be performed. Well, the main reason I've delayed so long in updating the User Guide to cover cross-compilation is that the rules aren't clear. Not to me and probably not to anyone. All we have so far is a very small sample size of "change letter" modifications that demonstrate what is allowed, and no counter-examples of what isn't allowed. So, to be sure you really need to closely follow the example of those few cross-compiled platforms currently included in the #1051 validation. See for instance http://opensslfoundation.com/testing/validation-2.0/platforms/android/TestingInstructions.pdf, the detailed build commands for a cross-compiled platform (Android on ARM). The distinguishing features of these cross-compiled platforms are: 1) The canonical "./config fipscanisterbuild; make" commands are preserved exactly so. Note in the original validations (years ago) the CMVP was very insistent that no command line options be used. That may not be the case today (recently they seem a more relaxed about source code based modules), but we have taken the trouble to keep it that way for the new platforms. 2) The target system parameters that are implicitly determined by ./config and ./Configure are explicitly specified by a set of environment variables (see setenv.sh). The correspondence between those and the implicitly determined values is easy to demonstrate. 3) No other source/script/makefile modifications are made other than specific portability mods that can be justified as affecting only the new platform, and as having no impact on any cryptographic functionality. Note that for the cross-compiled platforms we have occasionally had to modify ./config and/or ./Configure, with those modifications carefully vetted by the test lab. If you can build your cross-compiled module with steps 1 and 2 only, with no mods as in step 3, then you could presumably claim the result as legitimate (my personal opinion, non-authoritative and unverified by the CMVP). Step 3 clearly requires a change-letter modification, however (very rough rule of thumb: $10-15,000 and four weeks, if you really have to have it). -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com
