The biggest problem appears to be this: It's very slow going. One machine operating in FIPS mode (especially, as I've mentioned previously on this or another list, with Windows Server up to 2003 -- I have not yet tested 2008 or Vista) tends to prevent interoperability with non-FIPS-validated systems.
In my opinion this is a rather stupid state of affairs, since it means that the only way to get things to work together is to disable FIPS-validated operation mode. It should be a priority for NIST and the cryptographic vendors to figure out a way to steer the general public toward the algorithms specified as acceptable by the FIPS standards, even if they (the members of the general public) don't use FIPS-validated components. (FIPS 140-2 only affects procurement and theoretically use by the US Federal Government, but there is nothing which precludes interoperability with non-FIPS-validated systems -- other than the fact that most non-FIPS-validated systems don't support the algorithms specified by FIPS 140-2.) OpenSSL appears to be almost unique in that it supports all of the ciphersuites specified by FIPS even when not in FIPS mode. Thus, products built with it can (given the appropriate cipher string) interoperate with FIPS-validated implementations. A question: Is there/should there be a "FIPSCOMPAT" or equivalent string which can be added to the cipher string, to add all FIPS-specified ciphers to the cipher list? (I would also suggest "FIPS" as a standalone cipher string, which would only be valid if the library were already running in FIPS-validated mode.) -Kyle H On Mon, Mar 2, 2009 at 4:13 AM, Steve Marquess <marqu...@oss-institute.org> wrote: > rajan chittil wrote: >> >> ... .I have seen in some fips enabled library, if one application gets >> into fips mode , whole library will be in fips mode and all the application >> in the system will be in fips mode. > > That would be a strange library. > >> is this true for openssl ? Is the fips enabled at system level or >> application . >> > > The OpenSSL FIPS Object Module v1.2 (fipscanister.o) is an object module, > i.e. static code. It remains entirely private to the process that contains > it, and so what that process does with it can't affect other processes. > > If you embed fipscanister.o in a shared library, as most will do and as is > done automatically when building a "FIPS capable" OpenSSL distribution, then > it behaves like a shared library. The read-only data and code are shared by > all applications on the system that map that library. The private copies of > writable data belong to the respective processes that map and make calls to > the library, and again what one process does with the API has absolutely no > effect on other processes. > > That said... > > At this point in time the people who worry about FIPS 140 validated products > at all generally think only in terms of achieving "buzzword compliance" for > specific applications. By "buzzword compliance" I mean that in practice the > emphasis is almost exclusively on establishing paperwork compliance with > policy requirements mandating acquisition of validated products, in order to > market (as a vendor) or procure (as a program manager) a specific product. > Considerations of actually *running* said products in FIPS mode are > generally very secondary or absent. Likewise consideration of cryptography > not singled out for scrutiny as requiring FIPS validation (e.g. kernel > crypto, well known products using crypto in apparently incidental ways) is > minimal. As an exercise for the reader, take a poll of the ciphersites > accepted by many government and DoD web servers today which indicate that > said servers obviously can't be in FIPS mode. I've long been amused by the > fact that *none* of the HTTPS proxies I've seen that are proliferating > throughout the U.S. DoD enforce use of FIPS compatible ciphers. FIPS > validation for now is a paper chase, not an operational reality. > > But, in anticipation of a future time when FIPS mode might become an > operational reality we designed the OpenSSL FIPS Object Module to > potentially support a system-wide global FIPS mode switch. If all the > applications on a system use a FIPS capable OpenSSL library, and if all > those applications use the OPENSSL_config() call, then FIPS mode could be > enabled for all such applications in one fell swoop by appropriate options > in the system-wide openssl_conf file. System vendors could also ship the > same binary code to all customers, with only those customers desiring FIPS > mode changing that global configuration to enable it. > > That may happen someday, but for now it's just one application at a time. > > -Steve M. > > -- > Steve Marquess > Open Source Software institute > marqu...@oss-institute.org > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
