[Cryptography Team] Re: [Newbies] [ANN] Squeak CryptographyCertification Validation Officer

[Kyle Hamilton]

OpenSSL's situation is rather interesting.  The OpenSSL FIPS 1.0 code
is not available for procurement, but people/companies who already
have copies are allowed to use it and it retains its validation.  See
http://oss-institute.org/index.php?option=content&task=view&id=166&Itemid=
for information (it was mistakenly listed as "revoked", but it is now
properly marked as "not available":
http://csrc.nist.gov/cryptval/140-1/1401val2006.htm , certificate
number 642).

The other package that I'm thinking of (for Windows) is Crypto++,
available at http://www.eskimo.com/~weidai/cryptlib.html .
(Certificate numbers 343 and 562, since there are two different
versions -- 343 refers to the VC++ 6.0 version, 562 refers to the
VC++.Net version.)

I wonder... could the squeak VM have a public key which validates a
signature on the crypto code whenever an object derived from that code
is accessed?  Or can the code be made immutable in the VM itself?

-Kyle H

On 10/11/06, Ron Teitelbaum <Ron at usmedrec.com> wrote:
> Hi Kyle,
>
> I discussed this with the certification lab that I spoke too.  It is a very
> interesting question and one that we will need to address when it is time to
> do the actual certification.  I know that the common criteria is less
> strict, and that is where we are focusing now.  There are a number of ways
> that we can ensure that the code is not modifiable, including coding signing
> the VM, removing the compiler, crc checking the code before it runs, etc.  I
> agree with you that this is going to be an interesting challenge, and it
> will be expensive process once we get to the point when we think we are
> secure the code and the VM and can pass the CC.  But I also feel that having
> the certification would be a very good thing for Open Source in general, so
> it's a path worth going down.  The lab thought that it would be difficult
> also but they believed it was possible.  I planned to discuss this with the
> lab that worked with OpenSSL but after realizing how much work there was
> left to do before working with a lab, I figured it could wait.  If they
> succeed then it makes it easier for us.
>
> One of the tenants I've been working under is Good Enough Security.  The
> idea is that if we try to build the perfect system we would find it a task
> that is so daunting that we would never try.  If we try to make incremental
> improvements using the best information that we can find, working with the
> best possible people, and going through some of the certification processes,
> even if we don't succeed, we make Squeak better, and more secure, and more
> likely that businesses and developers will comfortably adopt Squeak.
>
> My understanding of OpenSSL was that they had their certification but it was
> pulled, they are working to restore that certification now, and they have
> passed the lab stage and are waiting again for the government.
>
> One of the other things to consider that I have mentioned already is that
> Microsoft CryptoAPI is FIPS certified.  It is possible that we could attach
> to that and develop Squeak systems that are also certified, but I haven't
> read through the security policy document thoroughly enough to know how
> difficult that would be.
>
> What other package where you thinking of?
>
> Hope that helps!
>
> Ron Teitelbaum
> Squeak Cryptography Team Leader
>
> > From: Kyle Hamilton
> > Sent: Wednesday, October 11, 2006 6:05 PM
> >
> > Welcome, Krishna!
> >
> > In the grand scheme of things, how can the integrity of the
> > cryptographic component module be verifiably maintained in Squeak?
> > Because of the NIST/FIPS requirement of a security boundary, the
> > implementation must be an immutable "black box" -- put data in, get
> > data out.
> >
> > OpenSSL has a FIPS-validated component (no longer available for
> > obtainment, but people who obtained it before it was made
> > no-longer-available) that would operate in the context of an extension
> > to the interpreter.  [They're working on a follow-up validation for a
> > to-be-made-available version of the library.]  There is also at least
> > one FIPS-validated, freely-available module available for Windows
> > other than OpenSSL.
> >
> > I bring this up only because I can't see how such a black box could be
> > created (and its internal state verifiable at all times) unless it's
> > not written within the Squeak environment itself.  There isn't any
> > means that I know of "sealing" classes and preventing data from being
> > examined -- thus there isn't any means of enforcing a "black box"
> > boundary the way that FIPS requires.
> >
> > Any thoughts on the matter?  Anyone?
> >
> > -Kyle H
> >
> > On 10/11/06, Ron Teitelbaum <Ron at usmedrec.com> wrote:
> > >
> > > Krishna Sankar is joining our team as the new Squeak Cryptography
> > > Certification Validation Officer.
> > >
> > _______________________________________________
> > Cryptography mailing list
> > Cryptography at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>
>
> _______________________________________________
> Cryptography mailing list
> Cryptography at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>


-- 

-Kyle H