On 12/1/06, Cerebus cerebus2@gmail.com wrote:
On 12/1/06, Kyle Hamilton aerowolf@gmail.com wrote:
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.
I think this is compelling reason enough to drive implementations toward NSS. Great information though, and I appreciate the insights.
As Ron has suggested, we can use a platform-native library to do the actual work, integrating new primitives to call it. I suggest OpenSSL because there's much less "we can't do this" that I get from the openssl-dev list than the dev-tech-crypto list. However, NSS is a valid suggestion as well. In that case, though, we're limited to the platforms which have been validated with it.
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.)
Please, if only to satisfy my own curiosity.
My apologies, it was by Steve Marquess at the OSS Institute: http://groups.google.com/group/mailing.openssl.dev/browse_thread/thread/d5cf...
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.)
I see from the pre-val list that RedHat/Sun have a newer version of NSS (I can't recall which version) in pending review (i.e., testing is done & it has a recommendation) for both level 2 and level 1. Is there something different that NSS has done that OpenSSL did not, aside from the validation of source vs. validation of object?
This I don't know. I'm not a member of the FIPS administration/development list. However, as RedHat is one of the sponsors for it, perhaps you could find out from their support team? (I would like to know, actually. I'm looking at the 140-2 document, describing what would be necessary -- "locks or tamper evidence" is the part that software-only systems cannot do.)
However, there are other aspects that could be implemented, including "role-based or identity-based operator authentication".
"Secure installation and generation" is what OpenSSL does; "Secure Distribution" is not available in the source code form as far as I can tell.
Though, also important to note: Level 1 is for a single operator. Level 2 is for multiple operators. As it stands, Squeak is a single-operator system (there's no authentication except what the underlying OS imposes, and that only for access to OS-level objects). It would take a major reengineering of the underlying design philosophy of Smalltalk to change that property.
-Kyle H