[Cryptography Team] Todays Meeting update

[Kyle Hamilton]

On 12/1/06, Cerebus <cerebus2 at gmail.com> wrote:
> On 12/1/06, Kyle Hamilton <aerowolf at 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/d5cfaedc804d8b27/3f0181d44571b601?lnk=gst&q=fips+validation+revoked&rnum=1#3f0181d44571b601

> >  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