On Sat, 2009-08-29 at 17:34 -0400, Steve Marquess wrote: > Mark Phalan wrote: ... > > Due to the way the FIPS Capable OpenSSL is built it ends up with > > older implementations of ciphers (all the ones that fipscanister.o > > implements). These cipher implementations are used regardless of > > being in FIPS mode or not. As the ciphers from fipscanister.o (FIPS > > object module 1.2) come from an older release of OpenSSL they do not > > perform as well as the current implementations (e.g. AES is *much* > > slower on Intel Core 2 CPUs). > > > > The net result of this is that we'll probably deliver two versions of > > libcrypto. One using the latest cipher implementations (0.9.8k) but > > not FIPS enabled and the other FIPS enabled with the more poorly > > performing cipher implementations. > > > > This is seems to be an inherent problem as certification always takes > > some time - the FIPS certified cipher implementations will always > > lag the latest and greatest stable version. Is this something we just > > have to live with or is there a plan to somehow get the best of both > > worlds (speed and FIPS in one library)? > > Ok, a (hopefully) more thoughtful and considered response. You've noted > a real problem and yes there is a plan ... or more accurately, some > wishful thinking that aspires to be a plan. >
Thanks for the comprehensive reply! I've got a few comments and questions inline. > First some background. Our primary object from the very beginning (over > five years now!) was to produce a "universal" validated OpenSSL -- one > that could be deployed everywhere to support both the traditional > ubiquitous OpenSSL usage as well as the less prevalent but important > FIPS 140-2 environment. To that end we desired: > 1) Exact drop-in functional equivalence with the standard OpenSSL > API when not in FIPS mode. > 2) Runtime configurable FIPS mode > 3) Enforceable FIPS mode for easy retrofitting of existing > applications (not strictly required for the validation but highly > desirable for real world utility) > > What we wanted, then and now, was to make it easy for a) individual > application developers to add FIPS mode support to their products, and > b) O/S vendors distributions to contain but one version of OpenSSL that > could be optionally enabled for FIPS mode via a global configuration > option. The reality today is that FIPS validated software is > essentially a niche product with limited selections, generally obsolete > as purchased, and far more often procured than deployed. FIPS > validation has too often been a barrier to entry into the government/DoD > market for many software developers; we wanted to level the playing > field to open up the market for FIPS validated cryptography. > > The original thought was to just validate the entire OpenSSL library. > That would have been technically possible (the existing algorithm > implementations all passed the CMVP tests for cryptographic correctness) > but would have had the fatal disadvantage of imposing obsolescence on > the entire library. So we gathered all the FIPS relevant code into a > separate area (roughly speaking the ./fips/ subdirectory) and created a > bastardized interface between that code and the rest of OpenSSL. That > segregated source code was compiled into a "monolithic" object module > (fipscanister.o) to satisfy the module boundary requirements of FIPS > 140-2. This approach was a compromise forced by our schedule and > funding limitations. It had the disadvantage of leaving a lot of > superfluous code in the source tarball and build tree used to create the > monolithic object module. Not only does that superfluous cruft confuse > the CMVP and test labs, it has often confused end users who build > fipscanister.o and then mistakenly also use the libcrypto and libssl > libraries created as a byproduct, instead of building them from a proper > "FIPS capable" OpenSSL distribution. All that incidental cruft is > supposed to be discarded after building fipscanister.o, but it really > shouldn't be there in the first place. > > Another disadvantage is the constraints of the expedient ad-hoc > interface between fipscanister.o and the FIPS capable OpenSSL. That > interface can't be changed (without new validations) because > fipscanister.o can't change, so significant changes in OpenSSL (such as > 1.0) cannot be accommodated. This is unfortunate :( > As you noted the incorporation of > fipscanister.o in a FIPS capable OpenSSL displaces the corresponding > FIPS allowed algorithms of the latter. While we retain functional > equivalence (goal 1 above) any platform optimizations or other > improvements of the newer implementations are lost. The nature of this > interface is such that we can't easily avoid this displacement within > the constraints of the existing fipscanister.o interface and 0.9.8 > versioning rules. Do you think delivering two versions of libcrypto in this case is a reasonable workaround? > > Long term what we'd really like to do is create a truly independent and > separate FIPS mode algorithm implementation in the form of a FIPS mode > ENGINE. That way the associated source distribution would contain only > relevant source code, and the "FIPS capable" OpenSSL distributions would > function entirely independently of the FIPS related code when not in > FIPS mode. The FIPS validated ENGINE implementation would also remain > usable with a wider range of subsequent OpenSSL releases. Nice idea. > > That goal is unlikely to be realized in the near future. We can only > make such extensive changes in the context of a FIPS validation, and > those validations are very expensive, both in dollars and time. We have > been fortunate enough to have had several sponsors for the validations > to date, but with the exception of the very first groundbreaking > validation these sponsors have been schedule sensitive and could not > afford the time required for a comprehensive overhaul. If and when > sponsor(s) desiring that result appear we'd be delighted to tackle it, > until then we're stuck. > > We've also considered some makeshift workarounds based on the v1.2 > module. Steve Henson has some ideas on using linker trickery to > implement a 0.9.8 FIPS ENGINE as a shared library, or parallel "shadow" > implementations that would require a 0.9.10 release. The conclusion is > that such workarounds would be possible, but would only be a half baked > solution requiring some non-trivial effort. > > I should also note that developments in FIPS 140-2 testing requirements > for 2010 mean that even the existing v1.2 module will no longer be > compliant. The commercial vendors who have been obtaining "private > label" validations based on v1.2 will find that those validations will > no longer be rubber stamp formalities as is the case today. Can you point me to more information about this? Does this mean that delivering a FIPS Capable OpenSSL (v1.2) as part of an OS will be essentially worthless to users of that OS in 2010? Thanks, -Mark ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
