[Cryptography Team] Todays Meeting update

Fri Dec 1 14:12:03 UTC 2006

Hi Kyle,

I hope you are feeling better and are back to 100% soon, thank you for your
summary of the OpenSSL validation.

Ron

> -----Original Message-----
> From: Kyle Hamilton [mailto:aerowolf at gmail.com]
> Sent: Friday, December 01, 2006 4:35 AM
> To: Cryptography Team Development List
> Cc: Ron at usmedrec.com
> Subject: Re: [Cryptography Team] Todays Meeting update
> 
> 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