[Cryptography Team] Re: [Newbies] [ANN] SqueakCryptographyCertification Validation Officer

[Krishna Sankar]

Extending further, it depends on the Security Target and the TOE. If I am
correct, the CC evaluation is for a (platform, function, version) tuple
anyway. Like Ron points out, first we could bound the target configuration,
by teeing off of a set of libraries that are already certified. We can then
improve upon the base and have more ambitious plans.

I think one of the first tasks would be to put together the ST and ToE. The
security claims we want to make also have a bearing on the current
discussion. I haven't dug deeper into the profiles yet.

Cheers
<k/> 

> -----Original Message-----
> From: cryptography-bounces at lists.squeakfoundation.org 
> [mailto:cryptography-bounces at lists.squeakfoundation.org] On 
> Behalf Of Ron Teitelbaum
> Sent: Wednesday, October 11, 2006 4:54 PM
> To: 'Cryptography Team Development List'
> Subject: RE: [Cryptography Team] Re: [Newbies] [ANN] 
> SqueakCryptographyCertification Validation Officer
> 
> 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/cryptograph
> > y
> 
> 
> _______________________________________________
> Cryptography mailing list
> Cryptography at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
ptography
>