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.
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. 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.
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.
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.
-Steve M.
--
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
USA
+1 877-673-6775
marqu...@opensslfoundation.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
