CC and Squeak.
Locked
 
|
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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
|
|
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: [hidden email] > [mailto:[hidden email]] On Behalf Of > Cerebus > Sent: Thursday, November 23, 2006 10:44 PM > To: [hidden email] > 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 > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
|
|
In reply to this post by cerebus-4
Yup.
This is what I was talking about last year with respect to Spoon. On Nov 23, 2006, at 7:44 PM, Cerebus wrote: > 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 > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ > cryptography _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
«
Return to Squeak - Cryptography
|
1 view|%1 views
| Free forum by Nabble | Edit this page |