[Cryptography Team] Todays Meeting update

[Kyle Hamilton]

First, please allow me to apologize for my absence from this list.  I
have been ill, and am still not quite up to full strength; however, I
have been following the discussions as best as I've been able.

My comments are interspersed with the quote below.

On 11/30/06, Cerebus <cerebus2 at gmail.com> wrote:
>
> > We may want to review openSSL and integrate that or NSS into squeak for
> > people that have to have an FIPS validated system.  This would remove our
> > need to be validated, and shift our job to interpreting and implementing
> > external modules properly.
>
> Personally I prefer NSS over OpenSSL.  OpenSSL's FIPS status is still
> sorta in question (Why does the cryptval list still say "Not
> Available"?).  NSS has better certificate management features.  In
> addition, I've found it easier to get RedHat to address bugs &
> features in NSS than it is to get active OpenSSL developers fired up
> to fix things.

Funny, I've found the opposite.  (And I'm on the mailing lists for
both, as well as the commit lists.)  This doesn't necessarily mean
that your experience is invalid.

As for the "Why does the cryptval list say that OpenSSL is "Not
Available"?" question, it's a slightly complex answer but it's
important to understand what happened, how, why, and what the
direction is.

First off, OpenSSL is the first FIPS-validated module that can be
distributed as source code, and compiled by the end user.  For every
other module (including NSS), in order to say "FIPS-validated", one
must use the precise binary libraries that the developer produced, and
that the laboratories ran their tests against.

As you can probably imagine, things got confused.  There were endless
arguments, debates, and discussion between the developers, the labs,
and NIST.  It took about 5 times as much money as the Open Source
Software Institute (http://oss-institute.org/) had originally raised,
and two and a half years, to shepherd through the validation process.

Now, I'm going to quote directly from the Computer Security Resource
Center's Cryptographic Validation  (http://csrc.nist.gov/cryptval/ )
web site:

...begin quote...
 If a validation certificate is marked not available, the module is no
longer available for procurement from the vendor identified on the
certificate, but may still be retained and used to demonstrate
compliance to FIPS 140-1 or FIPS 140-2.

If a validation certificate is marked as revoked, the module
validation is no longer valid and may not be referenced to demonstrate
compliance to FIPS 140-1 or FIPS 140-2.
...end quote...

As of right now (2006-12-01 09:03:30 GMT -- December 01, 2006 at
2:03:30 AM Mountain Standard Time), this is what certificate 642
(OpenSSL's certificate of validation) states:

...begin quote...
OpenSSL FIPS Object Module
(Source Content Version: OpenSSLfips1.0.tar.gz; Resultant Compiled
Software Version: 1.0)

(Not Available)

(When built, installed, protected and initialized as specified in the
provided Security Policy. Appendix B of the provided Security Policy
specifies the complete set of source files of this module. There shall
be no additions, deletions or alterations of this set as used during
module build. All source files shall be verified as specified in
Appendix B of the provided Security Policy. Installation, protection,
and initialization shall be completed as specified in Appendix C of
the provided Security Policy. Any deviation from specified
verification, protection, installation and initialization procedures
will result in a non FIPS 140-2 compliant module.)

Validated to FIPS 140-2
...end quote...

This states "Not Available", not "Revoked", which is an entirely
different beast.

I have a copy of the OpenSSL FIPS-1.0 code, which I obtained before
the certification was changed to "Not Available".  This means that I
am able to use it to demonstrate compliance in any binary software
that I originate, even now -- I have procured it, and the "cannot be
procured" applies to integrators, not end users.  However, anyone who
did not have the software as of the date it was marked "Not Available"
cannot use it to demonstrate compliance.

The reason for this is because there is a small amount of
cryptographic code which resides outside the "security boundary" --
i.e., the HMAC-digitally-signed binary library which is generated at
OpenSSL-FIPS's compilation time.  (There is a message from Dr. Stephen
N. Henson in the openssl-dev mailing list archives which I can find
and point you to, dating from either the end of July or sometime in
the entire month of August, which goes into more detail.)

(As an aside, OpenSSL validated to Level 1 -- "Multi-chip standalone".
 Please see http://csrc.nist.gov/cryptval/140-1/140val-all.htm#642 for
full and up-to-the-minute information.  It is literally impossible for
a module in a general-purpose computing system to get anything more
than a Level 1 validation, simply because general-purpose OSes have
debugging capability which can examine the contents of memory owned by
another process or library.  A Level 2 validation shows resistance to
such attacks.)

So, let's look at the circumstances surrounding this series of events:

1) A completely new approach to FIPS-validated module distribution
(source code, instead of binary code or hardware).
1a) A lack of composite understanding by the lab
1b) A lack of composite understanding by the developers
1c) A lack of composite understanding by NIST

2) A fairly large US-government sponsor for the validation (which
sponsored the validation so that it could save procurement budget
money).
2a) The Department of Defense Medical Logistics Standard Support program

3) A large development community which was completely shut out of any
ability to make any suggestions, modifications, or evaluations of the
code as it was going through the validation process.

It is amazing, frankly, that it got validated in the first place.
However, now that everyone involved has an understanding of what the
process entails and the bugs present in the FIPS-validated code (it
doesn't compile on HP/UX-64 [or any 64-bit platform that I'm aware
of], and it's an absolute bitch to get it to compile and run in a
FIPS-validated configuration on Win32 since the supported
configuration relies on an open-source toolchain which does not
integrate well with Microsoft's toolchain), the FIPS-1.1 validation
should go more smoothly.

In this case, Open Source's strengths were hobbled by administrivia
and bureaucratic "flaming hoops" that got smaller and smaller (and
thus got harder and harder to jump through without getting singed)
that prevented those strengths from coming into play.

> > I'm told that if we want to do CC then we should look into foreign labs
> > since CC is international and a validation from say the EU would be valid in
> > the US.  Apparently Oracle saved a bundle doing this.
>
> I'm given to understand that the US CC evaluators are backed up into
> the next decade as well.  CC validation takes forever.  It takes
> longer to get a PP approved (SLOSPP-MR took years, frex.).

It doesn't surprise me.  Validations take a long time.

FWIW, the FIPS validation laboratory that the OSS Institute used was
Domus IT Security Laboratory, of Ottawa, Ontario, Canada.  (This from
http://www.oss-institute.org/index.php?option=com_content&task=view&id=165&Itemid=123
)

-Kyle H