[Cryptography Team] CC and Squeak.

[Ron Teitelbaum]

Hi Tim,

I know that there have been validations on VM type software.  The issue is
not how difficult the requirements are for the end users that implement our
code, but that there is some path to make it possible.  The end product the
security policy document may be very difficult for someone, and our goal may
eventually be to make it easier for someone to meet the criteria specified
in the security policy but for right now we just want to have a path no
matter how difficult it is.  Keep in mind that we are working now towards CC
validation now not FIPS 140-2.

I've been very busy and haven't been able to look for someone connected with
a lab that might be willing to volunteer some time.  I will start that
process soon, if anyone knows someone please let me know.  

You might be correct; the requirements may be too stringent for us to fit
Smalltalk into it.  That is one of the things we want to find out.  Still
after we are done if we significantly improve the security of Squeak, trying
to reach our goal of CC Validation, then I will consider this process a
success.  Also if we help to illuminate the process for others that may not
even be using a VM based language that is good too.

I am pleased to have you on the team, and strongly encourage your
participation.  

Ron Teitelbaum
Squeak Cryptography Team leader


> -----Original Message-----
> From: cryptography-bounces at lists.squeakfoundation.org
> [mailto:cryptography-bounces at lists.squeakfoundation.org] On Behalf Of
> Cerebus
> Sent: Thursday, November 23, 2006 10:44 PM
> To: cryptography at lists.squeakfoundation.org
> Subject: [Cryptography Team] CC and Squeak.
> 
> I was poking through the list archives and I notice a large amount of
> traffic relating to CC certification.
> 
> All the CC OS PPs require--at a minimum--implementation of
> discretionary access control over user actions.  As Squeak has no
> concept of users or access control at all, I don't think any CC
> certification is a realistic goal.   In fact, as Squeak is a live
> system, I don't think access control is implementable without
> rewriting the VM from scratch; and the result wouldn't be anything
> like the Squeak you know and love.
> 
> For that matter, the live nature of the Squeak image will make FIPS
> certification problematic.  FIPS certification requires strict version
> control over the crypto code.  While subclassing a FIPS certified
> crypto class would be OK, overloading a FIPS method could invalidate
> the certification (unless it calls super for the certified sections).
> Extending a FIPS certified class would be a similar problem.
> 
> Other crypto libraries have similar issues, but compiled code can
> generally show that they are using a fixed API and are linked to a
> certified version.  A live system such as Squeak faces unique
> challenges.  Every application built on an ostensibly FIPS-certified
> Squeak crypto library would have to be examined to ensure that FIPS
> code is not being overloaded, and even then you can't be sure that the
> final system isn't being modified by the end user...
> 
> -- Tim
> _______________________________________________
> Cryptography mailing list
> Cryptography at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography