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@gmail.com] Sent: Friday, December 01, 2006 4:35 AM To: Cryptography Team Development List Cc: Ron@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@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:
- 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
- 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
- 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